 Hello everybody, and welcome to our talk in getting started in exploring backstage in 2023 and also beyond. My name is Mitchell Henches. I'm a senior engineer here at Spotify. And my name is Jamal Rahmat, software engineer at Spotify. So, exploring backstage. I want to kick this off with a story. Before I worked at Spotify, I worked at a company called Paul.com. Fun fact, they were the first adopter of backstage. And how did they actually adopt backstage? Well, first, it started off with one person. This typical person, we call it Spotify, a champion. He discovered backstage and really wanted to try it out. So he looked at the documentation, the open source report story, and then created one backstage instance internal. Configure it to his liking and then also check the other plugins that were available. Then also configure those to their likings. Now, after you have configured your backstage, the next thing you want to do is show it off. Share it with your colleagues. Well, this is where it became a bit harder. Back in the day, it was pretty easy to pick up your laptop and go to your colleague, because everybody was in the office. Nowadays, everybody is working remote. For example, Mitch, he lives in the mountains. So I cannot pick up my laptop and go to Mitch and show off my backstage instance. It's not working. So at that point, the champion needs to deploy backstage. But that's quite hard, right? You have to consider the internal build system. You have to use Kubernetes, probably. And what does the Docker image look like? Well, at this point, your proof of concept can be quite time consuming, which it actually shouldn't be. So for the past year at Spotify, we have developed certain tools to make sure your proof of concept phase goes way smoother to help these champions out. The first tool I want to discuss is backstage deploy. Well, as the name implies, it's a tool to deploy backstage. Well, to sum it up, it is an opinionated tool to launch a proof of concept backstage instance into the cloud. Not only that, backstage deploy will give you a public URL that you can share with other backstage explorers in your organization. So I can now grab that URL and send it to Mitch. I don't have to go to the mountains. But also, now that you have other users for your backstage instance, it will give you a better image on how backstage will actually be used within your organization. But before I go further with backstage deploy, like Mitch always says, let's take a gander. Let's do that. So the best way of showing off to you how cool a backstage deploy is is through the classic talk technique of doing a demonstration. So Jamal and I are going to pretend to be champions, if you will. For a hypothetical organization, we're going to call it Backstage for Convenience. Yeah, I know. And then we're going to deploy a little demo backstage app. So the first step is to have an actual instance to deploy. Let's go to the next slide here, please. So we're going to go through all these steps. To create this instance, we're going to use the existing tool known as CreateApp, which has been used in backstage for a while. So let's go ahead to the command line now. And let's create a little backstage instance. There's a little bit of magic here. This is running a little faster than I should, so a little show-biz action. Within the day, what we've done here is we have created a vanilla bare bones modern backstage app. That's great. We can now use backstage deploy and show this off to the rest of our organization. But that's not good enough because others in our organ to look at this, they're not going to be able to see the full potential of backstage. Some of backstage's strengths or its extensibility, its customizability, its integrations, and then to see like a bare backstage app. I think we need a little bit more. I think we need some flavor, some seasoning, if you will. So I have something in mind. Let's go back to the slides here for a minute. Now let's go to the next step. The specific season, the spice, if you will, that I have in mind is we should have it so you would log in with GitHub. If you're part of our organization on GitHub, then you can sign in to our demo instance. So let's go ahead and get that done. For the sake of realism, I am now going to take our bare bones backstage app and we're going to do all the steps you can sign in with GitHub. So importantly, a little disclaimer here. I'm going to be going pretty quick. I don't expect you to memorize these things. There will not be a quiz after, but for the sake of realism, I want to go to them anyway. So let's get started. Rapid round. Next slide, please. Step one, we need our backstage instance to be able to talk to GitHub. So it needs to have credentials. Let's add that to our app config.yaml and set stuff up. Next step, please. Now, we need our backstage instance to be able to talk to GitHub and pull down those users, slurp them down if you will. That's the technical term I'm going to be using for this performance. So we're going to go ahead and configure the catalog accordingly. Next step, authentication. When a user actually authenticates with our backstage instance, we need to associate that login with the user. We have slurped down, configured, nice. Next step, finally, when someone goes to our instance, they need to be able to sign in with GitHub. There should be a nice, big sign on with GitHub button. Let's add that to our app now. Next step, there is no next step. We are done. Nice, just that easy. Well, yes and no. Jamal and I, we've set up a backstage instance or two in our day, and we know the steps, right? We made it look relatively fluid here, but there's a lot going on, and maybe I talked a little bit faster in there too, right? So the issue is, for new champions, it can be a bit of like a barrier. It can be a challenge to even set up an initial instance with the customizations before they've even done the challenging part of deploying it. So this is making me a bit sad. I'm crushed right now. You know, Jamal, is there any way that we can lower this barrier so we can make life a little bit better for fresh adopters? I have something for you, Mitch. Oh, my God. I have backstage quick start. So what is backstage quick start? We announced this a month ago, and if I navigate to the announcement, it says, quick start will enable adopters to get up and running much faster by removing the need to stand up and maintain a code base in order to set up backstage, reducing the now manual installation process to as few as three steps through an install wizard. Okay, those were a lot of words. You probably already forgot what I said, but I'm here going to show you what it means. So first, we're actually going to deploy backstage quick start. Do I need to modify any config files for this? Tinker with any build system? No, I don't think so. I'm just going to run a command in the terminal to deploy backstage quick start. Man, some demo time. So, like the create app, we are using MPX to call backstage deploy. We specify we want to deploy it on AWS, then we pass in the quick start flag, telling backstage deploy, this is a quick start specific backstage instance, and then we also specify the location of our image. Presenter, whoa, already done. How do we keep doing that? I don't know. But in short, what basically is happening is we are deploying a container on AWS as well deploy is now printing a public URL that I can share with Mitch. So if you look in the logs, we here have an URL we can access. Boom. Now we have a login page. But first, we need to log in, of course. What's the password again? I don't know, I hope you know it. Well, as I said, this is a container, and container works with environment variables. In this case, for quick start specific is also expecting certain environment variables. So let's look at them. So here, for example, we have the quick start root user password environment, and whatever the value is set to that is the password. I'm obviously not going to show what the password actually is because I don't want anything crazy happening today. But let's log in. Whoo. And now we are at the wizard. As you can see, there are three steps. First, we're going to put in our access token. This is to set up our integration with GitHub. Oh, by the way, the wizard is already preset with data so you don't have to awkwardly see me copying and paste. Save and continue. Then we have to enter our GitHub credentials. This is to enable the OAuth log in with GitHub. Then we can specify organizations if you want to. Backstations by default added. The organizations is here for ingesting users and teams. So every user and team in the backstage GitHub organization will be ingested in this quick start instance. And then we have administrators. This is probably something new, and this is very quick start specific. What does this actually mean? It means that the user has the access to modify the config at runtime. Very powerful, of course, so you don't want to give it to everyone. In this case, I'm only going to add Mitch. Make the cut. Let's press save and continue and submit. Exciting. This is going to work. Whoo. Backstage is ready for you. So to recap what actually happened. So all the manual steps that Mitch had to do with code, setting up the GitHub OAuth log in, the org ingestion, and all that other stuff is now done to the wizard. Very fast. But what else can we do? Let's explore a bit. So here you see it mentions config manager. So let's go, oh, first have to log in and get up. So here we have the config manager plugin. Well, as the name implies, it's a plugin to manager config. What does it actually mean in detail? So for example, here we have my company catalog. My company comes from the config organization.tame. I obviously don't work for this company, so I want to change it up. So let's do that. We go to the config manager and then we choose the core app plugin. In and out. And we're going to change this to backstage. And the only thing we have to do is submit our form. And here we can see that my company has been updated to backstage. Normally, you would have to redeploy your application or restart your application. Now with Quick Start, that is not needed at all. But what else can we do? So as you can see, we have a lot of plugins here and they all have status running. So that means we can also turn off certain stuff. For my proof of concept, I don't want search. I just want it gone. I don't think I need it. So I go to the search plugin and then press stop plugin. So what is actually happening? On the back end, the search plugin is completely removed. But for the attentive audience member, you might have noticed that the search item in the sidebar has also been removed. So everything related to the search plugin back end and front end will be removed from your instance. Now that I have completely configured my proof of concept, I can grab the URL and share it with Mitch. Wow, would you believe it? I just got a direct message from Jamal. And he says there's a brand new backstage demo instance which I should check out. So let's go ahead and do that. All right, new URL. Let's give this a shot. Ooh, sign on to GitHub. That's the button I like to see. Let's do it. Everything seems to be in order here. And wow, this is backstage and it has my company name in the top left. It doesn't say my company. I'm already impressed. But just for the sake of all of you to show that it's not smoke and mirrors, if I go to the settings page in the bottom left, this is my name showing up. This is the real me. I signed into the actual demo instance and it all worked. Wow, I'm convinced we should adopt backstage at our company, I think. Yes, promotion incoming. All right, is backstage quick start doing this all on its own? No, backstage quick start is powered by something we call declarative integration or DI for short. This is currently being built in open source. Ben and Patrick today had a talk already about this, but I have a surprise for everyone here. You ready? Thursday, there's another talk about declarative integration by Patrick and Ben. I'll be there. Mitch, will you be there? Of course I'll be there. I hope to see you all there as well. All right, everyone. Thank you very much. Jamal has given you a nice sneak peak into quick start and how allows you to sidestep a bunch of that manual customization from earlier. It's extremely cool. Keep the hype alive. You'll be hearing more about this in the new year. But don't forget, there's also backstage deploy, which is incredibly powerful. Today, you can't use it with quick start. I'm sorry, but that doesn't mean that it's not still amazing at allowing you to sidestep and do all the funky cloud stuff yourself. If you do the traditional way of setting up a backstage instance, do that step one and two from earlier. Yes, it's a little bit manual. You can use backstage deploy and set up a nice, simple demo instance like that. And if you are interested in doing so, you could scan that QR code right there or the other one. You can see some more instructions for getting that set up. But in the meantime, we're ready for questions. Awesome, Mitchell. Questions? Hi, thank you for your talk. I was wondering if quick start would add any value for existing backstage instances or is it really just about new stuff and setting up a new one? That's a good question. Do you want to tackle this? Yeah, sure. I think quick start in mind right now is designed for just new starting people. Well, we are definitely thinking about existing companies that already have backstage running. So that's definitely on our mind. And in the future, that will also be recommended. Right, but the primary focus right now is... Yes, right. Exactly. Okay, it makes sense. Yeah. Is there any chance of getting that config editor plugin on its own separate from the rest of quick start? That thing was cool. And the config manager? Yeah. No, that would not be possible. Okay. It is built on top of quick start using all the fancy goodness in there. So to pull it out would be... You'd just be reinventing quick start. And where's the fun on that? Perfect. Next question, yes. Yes, thank you. This was awesome. And I like your subtle jokes also. So the editing or the changes that you made in the config and those reflecting into backstage, like today this would be something in the app config YAML maybe. Yeah. So how is that reflecting? Is it like doing a deployment or what is happening behind the scenes? Do you want to order me? Absolutely. I can take this one. Yeah, good question. So this doesn't actually involve a brand new deployment. All that config is being managed at runtime on your backstage instance itself. So it will internally refresh the config. Config, sorry. Excuse me. I see you're coming from. So to repeat the question that he's asking is the configuration maintain the repository? So if you have your repository over here under the deploy and now here's your backstage quick starting since running live on the cloud somewhere as a database, the copy of that configuration, the main configuration is over here in that database. So when you make the change to the config manager, it only mutates the database and then everything here is fine and the repository is unaffected. It's a little bit of a different paradigm and we're excited to talk about it more in the future. But yeah, yeah. I'll keep you on your toes. Are there any plans to extend the deploy script to other cloud providers like GCP or Azure? I think the potential is definitely there, but right now we're playing up by ear and AWS is our main focus. Yeah, I think most adopters use AWS, but so we want to make that like the best it can be and then look at other. But backstage deploy is open source so anyone can contribute if they want to. I dare you. Coming, coming. Quick question. So I support an AWS environment with a very scaled down list of AWS services, not the entire gamut. So my question is more so around light sale as it was depicted within your architecture. I'm assuming that is a strong dependency for that specific capability of backstage. Yeah, for... Do you mind if I take this question? Perfect, yes. So for backstage deploy, it's a very opinionated deployment thing and it's trying to keep things simple and that means building on top of like the most usable abstraction AWS. So yes, exactly. It leans specifically on light sale in the same way if we were to do something for one of the other clouds. It would target something where you can just minimally get a container on there and a database, marry them so they're happy forever. I know what you'd do, but yes, so light sale specifically. There's another one here. Is that a good thing or a bad thing? Many questions. I'm okay with it. Hi. I had a quick question regarding, let's say most companies usually have Azure login page and let's say GitLab or a GitHub enterprise version of the GitHub instances. And let's say when you're doing backstage and want to integrate both login from Azure and then get integration with GitHub. Now the same API or beta token from Azure won't work because now GitHub has its own personal access token or other forms of authentication. How do you handle such kind of, you know, multi-platform integrations with backstage if you had to? Because let's say you're on the streets of a CI CD job run but you can only show based on access token from GitHub and not the Azure one. This is then for backstage quick start? Not exactly back to the quick start but just wondering, I had a question about it. Yeah, I can. Let me just make sure I understand the question fully here. So you're saying what if you have an organization and you want people to be able to log in using their GitHub representation or their Azure representation? Yes, ideally Azure implementation but their GitHub instance is also using the Azure implementation to log in but the authentication or how you access the API of GitHub is no longer based on that Azure but a different auth mechanism implemented by GitHub. So if you want to, like, let's say I want to use Azure as my login page for backstage but now if I have to show status of a CI CD pipeline the same token or how you authenticate it with Azure won't work anymore if I make sense. I think this is a little bit, I'm less familiar with the CI CD integration shenanigans and how backstage operates if there's multiple different token providers and it sounds like this is the case where the same token, you need two different tokens of the same provider if I'm hearing you correctly which sounds funky but maybe I'm misunderstanding. Either way, I'm not sure that I'm super familiar with the area here. So, thank you. I'm sorry. Any other questions? Nice. Last one. I guess. I'm making you run, I'm sorry. Thanks for the talk. It's great. Zero recommendation for, hey, we've got this test instance where a new org, or an org that doesn't have backstage so we're going to check it out. Would we want to take a backstage quick start entrance instance and make it our permanent internal production instance at some point or would it be like, hey, at some point dump the quick start instance, start again using a harder method? That is a fantastic question. I think it's a bit of a, it depends on the kind of customization you're doing and also depends on future backstage quick start developments which happen in the new year. So, it's a big maybe. So, I hope that helps. Cool. So, thank you so much guys. This is a great presentation.