 This talk is called backstage re restoring order to your chaos and we have Dave here. Um, so I don't, I don't want to say much else. My name is Casper. I'm a CNCF ambassador, but the floor is really, it's really yours, Dave. So please give him a big round of applause. I think I turn this thing on. My good. You guys hear me? I'll try harder. Uh, cool. Well, thanks, Casper for the intro. Um, so I think this is one of the first times, if not the first time that any of us are talking about backstage to the KubeCon audience. So I'm going to try to do kind of a quick intro, go through a little bit of what backstage is, why it even exists and then do a quick demo. But I'm going to dig into one of the features in backstage that we're pretty excited about, but haven't talked a lot about this thing called software templates. I'm going to try to demo that too. And then I'm trying to leave as much time as I can for questions at the end. So we'll see if the demo gods are kind, we'll have plenty of time for questions. So let's get started with, like I said, what backstage is and why it really exists. So we call backstage an open platform for building developer portals. And we created at Spotify a few years ago, and we open source it in March of 2020. And then a few months later, we donated to CNCF and then just a few weeks ago, it moved from the sandbox to the incubation stage. And at Spotify, we've always believed that the speed and innovation that our company depends on can't really exist without our development teams having a fair amount of autonomy to decide what they want to do and how they want to do it. But as we learned when we were growing, the faster we grow and the more autonomous teams like this, we have the more fragmented and really complex our ecosystem becomes and then everything really slows down again. And this, we really started analyzing this back in 2016 when the company was in hyper growth mode, we were hiring a lot and trying to onboard engineers, but it was really confusing and it was hard. I might just die. And it took us longer and longer. We good? All right. It took us longer and longer to onboard people. Our headcount went up, but our develop developer effectiveness was kind of going down specifically. We were measuring a metric. Um, it was the time to the 10th PR. So from when the person started till the 10th time they made a PR to our internal GitHub. And in 2016, that metric hit about 60 days and we somewhat panicked and set out to figure out what to do about it. And what we did was build backstage outside of Spotify. Of course we've the same sort of thing is happening. There's an explosion of available technologies. There's ecosystems like the CNCF one or any cloud console you look at. And they're, there's more and more of these sorts of things and they're all getting kind of more confusing and larger and more complex. So it becomes really hard to understand in depth, all the pieces of these things, keep track of how they all fit into your company's ecosystem. Learn all their languages, their interfaces, whatever their portals are, all these things. And then of course every company uses a slightly different subset of all of these tools. So they face slightly different challenges and onboarding employees that have worked at a different company, isn't that easy because you have to onboard them to your tools and can't depend on them using the same ones. The whole stack gets more complex and the same sorts of things. Onboarding gets harder, collaborating cross teams gets harder, all of this stuff. So let me jump back again to what backstage actually is. I called it an open platform for building developer portals. And I think at cubecon, we all know what an open platform is, but it's the developer portals part that I want to touch on. I think a developer portal is a fairly new product category and it's good to spend at least a second defining what it is and definitely what it isn't. We don't think that a developer portal is just an internet page with a collection of things for your devs or a wiki or something like that. But it's also much more than something like a service catalog. To us, a developer portal is one front end for your entire platform. For all the tooling that your developers need, things like CICD and monitoring, security tooling, testing, whatever tooling that you're accessing daily as a developer should live in this one place. It's also a place where your services, your applications, your data, your machine learning models, kind of whatever the actual software you're running is, should be managed through. And of course documentation, whether it's for components or APIs or tutorials, even things like org charts and strategy docs can live in this one place to make it easy to find everything you need to build software. And we think that regardless of where these components are coming from or who manages them, they still are in one place. So in a nutshell, to us, it's a place that lets developers focus on creating features and keeping your business running by consolidating everything they need into this one place. So they can perform all the daily kind of basic tasks they need from here without constantly learning another new tool and figuring out another new interface. And we think that every shop, development shop wants roughly the same few things. They want speed, they want scale, but they don't want to compromise safety or quality. And of course, they want to tame a lot of the chaos in their software ecosystem that comes from all of that speed and all of that scale. And Spotify was no different. So we built this developer portal that we now know is backstage to tame all of that chaos. And that changed things for us a lot. It aligned a lot of these different autonomous distributed teams and brought together hundreds of them, thousands of engineers and tens of thousands of software components of all different types. And backstage enabled much better collaboration within Spotify, unlocked a lot of potential across our teams. So I want to talk a little bit more about how we view backstage and what it does. There are lots and lots of features in the portal, but the three main things it does are these three things in the slide, say create, manage and explore. Create is of course just creating new things, but creating them in a way that adheres to your organization's best practices, creating them in a way that makes sense for your software ecosystem. Manage is really your day to day maintenance. Once you've created something, especially once you have it running, you need to operate the thing. You need to keep it working. You need to know that it's working. All of that day to day stuff. And then explore is really the collaboration piece. You might be working on a team that builds a couple of components that own some piece, but then it needs to interact with something else or it needs to get data from somewhere else and you might not know what that something else is or you might have a rough idea. So at Spotify, maybe you need to load playlists from the playlist system, but you have no idea what the service is called or what the API is or how you call it. So explore is what we call having a place to go to find where that API is, what it is, how to call it, where the document, where the docs are, all of those sorts of things. And we know that the global developer population is massively growing and we know that it's massively growing at a whole bunch of the companies you all work for and we think the more that it's happening, the more tool like backstage becomes critical because you need to handle all this growth of the people into the software complexity. And the other thing backstage brings is the open source community around backstage for extensibility, for both support of all of the tools that you have that other companies have or that other companies may help you with the way that we know open source does, but also for support in the human sense. Like if you have a problem, you have someone to talk to, you can get some help. You can come to KubeCon and talk to people. And that's exactly what backstage brings together. So when we open source backstage, we really focused on that last piece, the extensibility and making it possible to make for different organizations to work with all of their tools. We think that backstage is power and its uniqueness in this ecosystem is from this highly extensible plugin architecture. And backstage plugins are effectively just additional functionality to make your backstage instance customized to your company in your software ecosystem. And plugins can come from anywhere. We have examples of people that have internal plugins very highly customized or something that only their company does. And of course, they have open source ones that are shared across many of the adopters of backstage in the Spotify's internal backstage. Even before we ever open sourced it, we had a very similar model. We had contributions from all over the company into this one single unified experience and plugins with the similar model that came from other teams. So the model looked a little bit like, like the bullets here. I'll get to the picture in a second. But we have the team that maintains the core of backstage, which used to be internal now as the open source maintainers. Then we have a team that owns the Spotify instance of backstage, just kind of makes it run, keeps insures that it keeps running, responds to pages, things like that for our internal one. Then we have experts on the individual components that need to be in backstage that they have plugins for that own that plugin end to end. And the central team isn't really involved. It's just an extensible piece of backstage. And then, of course, we have feature teams that own the features of Spotify that our users know and love, like the play listing feature that I just mentioned. And, of course, I have tight feedback loops between all of those teams to ensure that these things keep moving. Then I want to talk a little bit about what plugins actually are and what they can be. And that's the picture on this slide. So we have a lot of customization in plugins, lots of different types of plugins. For example, we have this tech radar plugin at the bottom. I'm going to see if I can make this work. Yeah, this guy. Nope, I can't find it. And that's really just a front end piece. So it's a lot of UI and there's a much behind it. Then we have plugins like the service catalog, which has its own database and has a backend service. So there's much more to this plugin than just something like a simple UI. And we have things like the CircleCI plugin, which instead of a database and a big backend just has a proxy that goes out to actual CircleCI so that you can get CircleCI UX in backstage but not having to replicate any more of CircleCI specifically for the plugin. And I couldn't find a better slide than this, but really our goal with plugins and especially our goal with this ecosystem and with being in CNCF is to make backstage the front end for all of these CNCF tools, at least for a bunch of graduating projects, hopefully incubating projects as much of the landscape as we can cover. So if you own any of these tools, you work on any of these tools, you're interested in working with us on backstage. Please swing by our booth, come talk to me, reach out to us on Discord on CNCF Slack anywhere. We're really interested in elevating the level of support that we have for all of CNCF projects within backstage. And then, of course, I can't help but show off some of these numbers because we're incredibly proud of the community we have around backstage and the support that we've gotten from CNCF, overall open source community and everyone else. I'm not going to read all the numbers to you, but one number that I want to point out that isn't on this board is 20. So I said when we started, we were at about 60 days to our 10th PR. Since we introduced backstage and started iterating on it, we've gotten that number to stay below 20 pretty much always. And it's averaged for these past few years that somewhere between 10 and 14 days. So I'm sure backstage isn't the only thing responsible for that, but it's a huge part of it. And then beyond these numbers, backstage has a proven track record across many different industries. We have adopters of over 100 adopters across tons of different industries at very different levels of technical maturity in very different, even kind of parts of the tech ecosystem. And this is just a small collection of them. But of course, we're continuing to see more and more companies adopt backstage. And just like I said with plugins, we'd love to see more adopters, more companies that are comfortable sharing, more companies that want to kind of come speak with us, be in our public adopters list, jump on to this slide, anything like that. So the flip side of the thing I just said for project owners, any end users, any companies that see value in something like what we're talking about here, again, kind of swing by our booth, come talk to us, slack us later, whatever is easiest for you, but let's talk and let's see if we can make backstage work for you. So I want to quickly talk a little bit about some of the kind of core philosophies that we view make backstage successful and that we've really built around. The first one is this interface. And we think that backstage, like I said, it's kind of the interface for all of your platform tooling, but it's more of just an aggregator. The idea is that there are many tools and this one interface unifies them, but backstage isn't there to replace them. And the simplest example I can give her, maybe it's not the simplest, but one of my favorite examples I give for this is something like CI CD, where there are a lot of things that as a developer you want to see in your CI pipelines and about your deployments, but you don't necessarily every day need to go super deep into every single detail. So the idea with backstage and with the CI CD plugins that we have at Spotify is to give any developer a quick kind of one glance, like the build succeeding, maybe if they're not what's going on, what's the latest commit that's running in production, things like that. But if there's a problem and if you really need to dig in, then we don't want backstage to be a duplicate of all of the details of your CI CD system. We then give you a way to click through from that plugin to that build in your CI CD system and debug it there rather than debugging from backstage. Then there's this autonomy point that I touched on a little bit and the idea there is that each team can operate its own thing and make their own decisions for themselves, like I was saying. There's no big central team that dictates everything for the whole platform. And so at Spotify we have over 150 plugins that are produced by about 100 other teams that are outside of the backstage organization. And these plugins provide, like I was saying, it's not CI CD, the status of the build and a way to click in to see the details of it or for data pipelines, we provide what's going on with your pipelines. We show things like the schema kind of coming into the pipeline, coming out of the pipeline, the SLOs, details that you want to see at a quick glance and make sure things are green, but not every last bit of what you would need to know in like a detailed data pipeline or CI CD management solution. And then the last thing that we think is incredibly important is ownership. Backstage has a software catalog and one of the primary roles it serves at Spotify and for a lot of our adopters is enforcing ownership because we believe that for each piece of software there should be a single owner and especially at Spotify, but I think at most places by a single owner, I mean a single team that owns it. So you can have a primary contact, but it's not necessarily a single human point of failure. And that team should own that service, should be an easy team to find. So in the playlist example I gave earlier, if I don't know who to talk to, I can go to backstage, I can find the playlist system, I can find the team that owns it and then I can slack them or email them or walk over to their desk depending on how far away from you there are. But the flip side of that too is that team owns all the metadata for the service. So there are things that I'll show you in a minute where we know we have life cycle states like production ready or experimental or we can declare some dependencies and all of those things are up to that team. That team can say we're operating a tier one service and it's I don't know production or it's a tier three service and it's still experimental or whatever and put that in the catalog. So I'm going to try to do a quick demo and this demo I'm explicitly doing off of our public demo site largely to show you that we have a public demo site and anyone can hit it. Cool. I can actually load it. And of course I'm showing a different thing on my screen on that one so I'm going to turn around so I can see what's going on. But this is just a simple view of the software catalog. And by default we go to a very developer focused view. So you see the default is just showing me things that are owned by me. So I'm logged in as this guest user and you see here everything I'm seeing is owned by the guest user. So this is kind of the managed version of what I was talking about before. If I want to see everything that I can click on all and I see things owned by other users by other teams and I see all different types of things. And then I can quickly click into one of these and you can see some more details and there's things like links to the source code in GitHub. So this is what I mean where like backstage wants to be an aggregator but not the owner of everything. You click through to see more things. We have a bunch of these tabs and I'm going to go through every one of them. But this is kind of what I was saying like we have CICD there's API documentation. You can see dependencies. You can see docs kind of whatever your company needs to show up its developers every day can be here. And this is just what we have in the default demo. And we have a significant richer demo at the booth. So if you want to see a little bit more of this or dig in or ask a bunch of questions and watch someone click around it. Highly recommend going there. And if you just want to click around to this UI more this is demo backstage dot I owe. And you can see it for yourself and click around and hopefully I didn't just DDoS the site by telling everyone to go there. Cool. So that's the manage and like a very high level thought on Explorer. I want to dig in to create because like I said the thing that I want to talk a little bit in depth about was software templates and internally those feature we call the scaffolder. So the idea with software template like I was saying before is you can create things and bake all of your company's best practices into these components. And of course you can continuously update these components and you can continuously update the templates so that every next thing created is created with whatever today's or this minute's best practices are. And of course these components are automatically registered in the software catalog. So you see them in backstage and one of the things that's really useful about this but is that you have these templates and so you don't have to have all the boiler plate things done every time by any of your developers. If it's a bunch of Kubernetes YAML or configuration for CICD or whatever else you can just fill out the level of form in backstage and it will create what you need. But this is of course much more than just about that YAML. The thing that I was saying before about your company's best practices is been really important for us and we found that a lot of people end up having to have some sort of enforcement or some sort of like stick or punishment or whatever for teams that aren't adhering to all the best practices when they're creating new things. And this way we're giving people a way to do that but we're really doing it by giving them the path of least resistance to creation. It's a one-click button and a quick form so it's kind of the easiest way to do it but also the way that ends up with the right thing. The other reason why I think software templates are a really great thing to talk about is it's one of the easiest ways to bring backstage into your organization. Some of the things I just showed like the service catalog and some of the manage and explore capabilities require a lot of your components to already be in backstage or for you to have good metadata on your services or at least have a way to generate that metadata. And a lot of companies have that but plenty of companies don't have easy ways to do that. They might either manage this in people's heads or manage it in like spreadsheets or docs or something like that that's harder to kind of export in a clean way into a database like the software catalog. But something like saying now all of our developers have a one-click way to create new services or new data pipelines or new ML models or whatever it is you're doing is a really easy way to start with backstage and to get an org to start using it. So let me see if I can have luck with a demo a second time. Though now I think I'm just going to see if I can share my screen which may be a bad idea or whatever. Let's not do that. So this is very similar to the backstage instance that I just showed you but this is running locally on my machine and you'll see that there's now a big create button as well that I don't know if you you may not have noticed but this button doesn't exist on the public demo site just because we don't have a place to create things so if I go to create and I just click on creating the simple template it asked me a few questions of what I want to create so let's say kubecon demo and then like I said we care a lot about ownership so I'll pick a team to own it let's just assign it to the backstage team I go to the next step it's going to put it in this org and I need to name the repository so let's say it's kubecon demo and now it just confirms what I entered and I click create and it starts showing you what it's doing and while it's doing that I can try to quickly show you a little bit of YAML because we're at kubecon assuming I can get there no maybe I promise I have a window on my machine but it doesn't want to get there I wonder if it's because this is full screened yeah so now yes so now if I go here this is what the template looks like and effectively what it's going to do this is going to be hard for me to be looking over my shoulder but effectively we just have all the all the form fields at the top and then at the bottom of the actions it does things like registering the service catalog creating the repository and there's a few links that it ends up showing so I can dig a little bit more into this but I'm guessing that this thing will be close enough to done so you see some of the links that I was talking about it's like here you can go straight to the repository and see that it created the code repo for me and again this is like backstage showing you the high level but if you want to get into the details you certainly can and then you can open it in the catalog and see more details about what's going on with it if it was working apparently my demo is not happy yeah thinks it worked I can do another one and we'll see if it is happier and if it's totally not then I can show you a video of a time when it actually worked while I'm at it let's see if it did work yeah so I have no idea why it didn't register in the catalog I might need to restart my local instance but you can see all the work it was doing it uses GitHub actions and it deploys to GKE and so I have this KubeCon demo deployed here and at least those parts worked but let me restart this thing locally to make sure that that's not my problem and then I will do another one or a second cool so I can show you that and then once this thing starts I want to also show that we can do much more like we can do custom actions within these things so this is kind of a typical workflow within Spotify where you create a repository and you create some things along with that service but what if you want to do I mean almost anything else like you want to use an onboarding flow where you want to use backstage to add employees to something like workday or maybe when you create a service you also need to register it in ServiceNow or register it in any other system that it should have done because I restarted it but now let's see if it's any happier so now if I go to create the second template is basically the same template but it also adds a dashboard into Grafana so backstage and we'll call it the same and let's see if it does any better and so here you see there's a new step for create graphs in Grafana and then if I can get back yes I can get back over to MyYaml you see there's this graphs section and the graphs section it's pretty simple it does create graphs in Grafana but then it has this action and the action is defined in this create typescript file and this action of course the top has a lot of the parameters but you can see the meat of it is really just that it makes a few rest calls to Grafana and I'm not going to bore you going through the details of every call it's making but effectively this just means that whatever you can do in typescript or whatever API calls you want to make here you could add to the template and make it so that it can call out to like I was saying service now or in this case Grafana or whatever else you may need to workday and then should have a dashboard here so yeah I have the dashboard my unexpected error is my ad blocker and I don't have CPU data yet but as I just deployed if we want to prove that it worked I can certainly show that in a minute but I'm hoping that this time I'll actually have this thing in the catalog yes so this is what the last one should have looked like nothing like restarting it to fix everything but here it's basically the same thing you saw from the the sample data I had before but it's in the catalog and it's the thing I just named so I can go here and click view source and see that same repo and I can go through all the other tabs are not going to have a whole heck of a lot because they're fairly simple the only interesting one is the CICD one because this is showing me the work that I was actually doing so I can click on the commit and I can see some high level details of what it was doing I can even scroll and see the steps here and then again like I kept saying with my CICD example if something's wrong and I want to go into the details I can click through and now it's showing me in GitHub the GitHub actions details and I can click on that and click through I mean here again it all worked so it's not super interesting to click through every detail of it but this way if it fails backstage gives you a way to dig into the details and then maybe I've waited long enough to have metrics no like well I won't bore you all by waiting long enough for me to get metrics but we can always come back to that later so yeah so that's the scaffolder that's our software templates and now I need to make the other window be on top again cool all right I've never been good at shifting from demo to not demo without it being awkward this thing wants to be full screen cool all right so then I promised everyone time for questions I'll quickly talk about manage and explore in a little bit more detail and then I'll stop talking and let people ask stuff so manage and explore really depend on the software model and we found this model to work fairly well for all the companies we've worked with but of course we're always learning new things the place I want to start on this is in the middle of the entities right here on components because that's the easiest part to understand in the beginning a component tells us effectively just something that has some code like a service or a library or data pipeline kind of whatever it is that your key code is and these components they belong to systems which belong to domains so a system might be many services it might be services and databases and memcache and whatever it is so in my playlist example you can imagine that the Spotify backend for playlists it's a lot more than just one repo of code there's caching layers there's databases there's a bunch of stuff so all of that together is the playlist system and then each piece of that is a component a domain is really a collection of systems that might live in one space so you might say at Spotify you might have some like the podcast systems are a domain or the music playback systems are a domain and then going in the other direction of course components will expose APIs or depend on resources and then of course because we have ownership and things like that I don't hear there's users and groups as well but those I think are fairly self-explanatory and then all of these things can have types so components can be services or websites or libraries like I was saying APIs can be I don't know Proto GRPC APIs or GraphQL or whatever they are a database can be Cassandra or Dynamo or whatever and all of that is also stored easily in the service catalog and then the thing that I think is really important is this concept of relations between these components so like who owns a piece of software so like this service or this component belongs to this group or this API is exposed by this service or this collection of service maybe all expose the same API for different reasons and of course what groups the user is a member of for the ownership conversation so all of this builds a pretty kind of complex but incredibly important and useful graph of software knowledge within your systems and then the last thing is just annotations is a way to kind of add additional data that isn't necessarily critical to anything backstage does but you might want additional data about your components annotated and of course at Spotify we put all of this in YAML in our case the YAML lives in the repo with each service so when you make a change to your service you can make a change to the YAML maybe you made some change that puts it in production you've changed the metadata to be in production that's in YAML thankfully it's not required for everyone else there are plenty of other ways to get stuff into the catalog and we have a lot of adopters that aren't using YAML and then just for fun let's show some YAML this is the an example of catalog info this is a really simple thing and this is a component that's its kind I mean most of us I think can read this it's a service you can see it's life cycle it's owner things like that and then of course there's soft links as URLs and with that this QR code gives you a bunch of links to various other backstage things like backstage.io some additional information about our community places you can ask questions we have a pretty active Discord community and then on the left that's pretty self-explanatory we have a booth of the project pavilion we're booth number two I think now I forget but we're on the backside of like the far left closest to the door booth so come by check it out ask for a more detailed demo from the demo that's set up there or just come by and say hi and talk about cool things you want to do with backstage and with that I'm done I'll leave the QR code up but I guess until we get kicked out I'm happy to answer questions or talk to anybody yeah we have five minutes for questions we have one question from the virtual audience and I will start there and we'll go through the I have metrics oh it works nice so that's a question here are there any plans to redesign and decouple the plugin system currently it demands code-based change of the front end and the back end there are plans but there isn't really a good road map so that's very much one of the things that people talk to us about are a few people have asked for and then it's just a matter of either when we get time for it or I mean if anybody from the community wants to help we're more than happy to have those conversations too I think on that specific point right now backstage is 100% maintained by spotifiers and we're kind of trying to get more community involvement on the maintainer side in code ownership and get much more activity there like that's a perfect example of a thing that isn't critical to us but we're trying to do for the community but if somebody steps up and wants to kind of be an active maintainer own a part of backstage and build that I certainly don't think anybody on the team would mind Hi one concern or question I've had looking at backstage is we're talking a lot about we looked at the cloud native like landscape and there's so many tools out there what happens when it's all in one place and then does that make it then harder for a developer potentially to find the thing they're looking for? I understand that it's an aggregate and it's not the tool itself but if you're putting a lot of place things in one place is that not going to get then overwhelming? I think that's certainly a concern I think it largely comes down to how we're collecting those things I mean we of course don't want to be the XKCD comic of we're just the 15th place and the biggest reason why we have confidence that this works is because of how well it's worked at Spotify like we like I said we have the slides at 150 but it might very well be closer to 200 plugins by now so we have like like I said we have org charts in backstage we have all of our data stuff we have all of our backend stuff like there's so much in there and it's worked really well for us at least so I think you're completely right that it can get overwhelming and there's just like too many buttons and too many things or it can just become the 15th place you go but at least for us at Spotify I don't know if it's like some secret sauce in the way that our teams have designed it or if just this strategy just works and it should work for everyone but we have Spotify we've had that problem and the hundred or so adopters that we've been speaking with that have adopted it so far they're not nearly at the 150 plugins we have but from what they've set up so far they've been nothing but happy with it so I think it probably just comes down to like being careful about how you lay out the UI and ensuring that you make it very developer focused like any given engineer hopefully doesn't need to see more than let's say a dozen or so tools on a regular basis so if you can give them a view that shows that dozen even though maybe you get one dozen and the person next to gets a completely different dozen then that makes the tool have hundreds of things but you only care about the 12 you care about and that's I think really the answer we've had at Spotify sorry I like danced around until I came to what I thought was the answer hey I imagine that when you guys came up with this idea of building this tool you probably had to somehow explain like defend why you need this tool so do you have on Spotify any metric on what was the impact on your development flow after you you mentioned it yeah the the metric that I like of course most easily had is the one I talked about this kind of time has PR but that's entirely an onboarding metric we have a small team that does engineering satisfaction and collect a bunch of metrics across our team like I don't know meantime to recovery or deployments per day like all of this stuff I honestly haven't looked at that data personally in a pretty long time so I can't say like these are the three metrics that we think were most impacted at backstage but especially in the very early days of backstage the project team around backstage spent a lot of time with those metrics and figuring out kind of what we should add to backstage first or what we should tweak around backstage to ensure that and of course we have all of the like analytics on which pages are being used internally which pages aren't and like where people are getting into trouble to make the flows better so I don't have a real answer I don't I'm not sure if Suzanne or Emma at the booth would have a better answer because they're I think closer to that stuff but I can probably find it for you or I can just kind of hand wave and say we have a whole bunch of people that did metrics and I trust them and it worked pretty well but I couldn't tell you what exactly they did we are unfortunately out of time I'm sure you'll be around maybe just yeah I'm free for a while so I'm happy to hang around here or get out of this room so someone else can use it and just hang out in the lobby and answer as many questions as we have