 Okay, folks, welcome. Thank you for joining this session on backstage. I'm Suzanne Daniels, I work at Spotify and I lead our developer relations efforts on backstage, both externally and internally, because we're quite a bit adopted of backstage. But yeah, before I start, I already asked, but now there's like double the people, so I'm really curious. Who heard before the session about backstage? Okay, cool. Who already tried out backstage? Okay, who has many questions? Cool. Let's do my best to answer that. So another question, who in the past few years onboarded at a company in an engineering role? Who thought that was a great experience? Who can actually find, not search, find the information they are looking for when they start a new project? They're trying to work with an API? Okay, that's zero hands. That's not too good. But unfortunately, it's the reality. It's also something we experienced at Spotify. So what we're going to discuss in this session is a few things. The first thing is, what did we experience at Spotify? And how did we solve that? AKA, how did backstage come to be? Spoiler alert. We're going to take a look, doing a demo, go over how it might be useful to you, but also how it might be useful to create plugins for backstage, for maybe an open source project you're working on, you're contributing or you're maintaining. So we'll go over all these things in just 30 minutes. So I'm going to keep the tempo quite high, hopefully. If I stop talking, I might be a bit jet lagged because I was with the backstage team in New York just a few hours ago for my feeling. Okay, let's start. So Spotify, a lot has been written about Spotify, about the agile ways of working. Like each conference I go to, there is mostly a session of somebody talking about something related to how Spotify works internally. We really embrace autonomous teams and think that there is this power they should have to really innovate and to bring things super fast to market and have not a lot of friction. So they should be able to organize themselves. But that comes with a few challenges. Then add to the mix that Spotify is quite a huge organization. There's tens of thousands of microservices we have. There's over 2000 engineers. So what happened is we weren't always that big. So that's a good position. But at some point we grew. So people were not able to find the information they were looking for when they, for instance, onboard it. Why is that? Well, because there were many teams and it is just not easy to find the right information, especially when that's outside of your knowledge domain. It is at some point that you can add engineers to your organization to speed up, but you will actually, you will slow down. And over the time, there were more and more new technologies as well that people needed to learn and they needed to share knowledge about. And well, okay, it was also difficult to find out who was running a call for a certain service. So something needed to change. It was at some point it was so slow that the number of days it would take an engineer to get to the 10th pool request went up to 60 days. Just imagine you're onboarding at this super hip company and you're that super, you know, you're going to learn new things and get to learn a team. But then you want to be productive at some point. And it takes 60 days to do 10 pool requests to get to that point. That's not so satisfying. So we tried to fix that. And one of the ways to fix that is to create a portal where you can find that information, where you can find out who is owning a microservice, who's working on what who's running on call. And that grows into a developer portal. The developer portal was named system Z and it was built and maintained by one team. And we've learned a lot of things about that by doing it in that way specifically. The biggest learning was that if you have one team maintaining that one portal for your entire engineering organization, which one, which wants to move without friction as soon as possible, shipping stuff out and learning new things and collaborating. And you depend on one team for a feature request or for adding maybe a new domain. For instance, ML. The team had a huge backlog. So we knew that that didn't work because if you can't put in the features fast enough to lighten the work for other people, they will find other ways because they're autonomous and you just want to get your stuff done. Like how many of you installed a tool in their company to remove friction for their day-to-day work? I see a lot of people nodding. I see hands. Yes. So that happened within Spotify as well. So actually instead of taming that chaos, it became even more fragmented. So we knew that we needed to change that. So we went back to the drawing board. So what is the problem with such a portal if you build yourself and you maintain it yourself? It is that people cannot collaborate easily with you. So one of the basic fundamentals was that they created this plugin system so that everybody could create functionality within that portal and could extend it and that they would not depend on just those six or eight people who are working on that project. So we set out to prioritize the developer experience and that was quite a hit because if you can create your own plugins, if you can create pieces of your own experience, you can maybe create a self-service portal for the service you're maintaining and delivering to the internal developer community. There's many different things you can suddenly do. So in the portal, there's this philosophy because you want to have speed, but you also want it to be somewhat safe. You want to scale, but you do not want to lose the quality and you want to control that chaos that you can't have not chaos. And in the middle of that is backstage. It was a huge success. The developers really liked it. Over 80% of the plugins were contributed by people outside of that core team. This is just within Spotify. Backstage currently has over 120 plugins, which are being maintained, built and maintained by the developer community. And yeah, at some point people asked us about it. Well, how do you work then? How do you solve the problem? And well, backstage was mentioned more and more, and we got a question like, can we use that? Why not? So at some point we decided to open source backstage. It was during the hack week a little over two years ago actually and quite soon after it was donated to the CNCF. We have recently a few months ago became incubator project and hopefully at some point we will graduate fingers crossed. But we have a thriving community. We have over a thousand people contributing to this project and a large sum of those people actually contribute code as well on a regular basis. Over 250 companies adopted backstage. A few are mentioning it publicly, but we know that there's also many, many more. If you've, by the way, adopted backstage or will adopt backstage at some point, we really value you putting your names in the adapter adapter list of the project. And that is super important, of course, because if you bet your developer experience on an open source project, it is great to know that other companies bet on it as well and are actively members of the community and maintaining their plugins that have been submitted. Over 60 plugins have been made available open source for many different tools and hopefully more will come. Because if you work on a project or if you are at the company and you are dependent on the project or on a commercial service and you create a plugin and you contribute it back, you know, the community will be really happy with that and probably will want to work with you and help you improve that plugin or be very thankful and use it. But that's really important for the success of backstage and for the success of your company, where you work for or you work with and you want to improve the developer experience there because everything that is available there, you do not have to build necessarily yourself. Okay, I think that's that's enough of the history or do you want more history or do you want to see backstage? Okay, great. I'm happy. Oh, it would be so difficult if you're with some something else. Cool. So, yeah, a little little little story. So I'm this engineer. And I just onboarded at this company, which is called rocket rockets. It's an interplanetary sort of uber. You just have this rocket and you right share it and go somewhere. Long story short. This is the company and I onboarded there. And as part of my onboarding, they have this this best practice. And that is that they have these these golden pass. And the golden pass are actually are actually a set of so set of documents, which will guide me as an engineer through a whole workflow, which starts at setting up your dev box. Then it will let me learn more about how this whole engineering organization I'm part of works and how things relate to one each other. It will learn me how to create how to create an API. For instance, it will learn me how to spin up the services I need to build my application. And there's like all these steps I go through. So within one week, when I'm working through this document, I get to learn the actual organization, how it is to work there. How it is to search for stuff at this company, how to set up an environment, which is pretty much like the things like the way I would be working later when I'm done onboarding, if there's such a thing. And this will build up my confidence. Confidence. So just imagine that at the end of that golden path, I would like have created my first microservice. And it's actually working. Sure, it won't probably be the million dollar application they were waiting for. But at least I've achieved something. Just imagine how powerful that is. And I get to learn to know the platform, which they work with, which is backstage. So after that week, I feel confident and I've had my first weekend, which was also good. And I come back and the next thing is I want to know the actual stuff that my company builds, that my team builds, that my team maintains. So here comes in the catalog. So in this catalog, in this catalog, I can see what my team owns, but I can also see all the components they have with this company. But let's just stick with my team. So this is the application I was hired to work on. It's the launch application. It's an application to order lunch while you're in this patient, because it takes a long time. Well, this is basically the homepage of microservice. You can find here all the information that might be relevant for you. For instance, how does this service relate to other services? Where does it depend on? What does it provide the service to another application? There's a link to the dashboard. I can create an incident or see current open incidents, only 23 days open, what could possibly go wrong. There's some other plugins like here. It's a Prometheus graph I have. And I can immediately click to my Grafana dashboard and show how my service actually is doing. All these cards you see here, they are actually plugins. So this could be anything that might be useful for the engineering organization or in the context of a specific service you're looking at. The cards you might have for a data pipeline might be totally different than one for a website. That's possible because you can show the plugins depending on the type that you are viewing at the moment. Let's discover a bit further. So there's some tabs here at the top. Also a great example is the GitHub plugin. This might show me how this was running and I can dive further in there and look at the log files. What is important to notice is that when I have a problem with my pipeline, I will still go to the tool I was using for that. So if there's a problem here, I will go either to get up, look at my action. I would go back to my IDE because I know that I probably forgot to run some command before I push my code. It just shows you the information. But in itself it's really powerful because if I would deploy something and I would have to look at all those tools and look at the status, I would have like 30 tabs open at some point because I'm not only looking, of course, at my GitHub actions. No, I would be looking at every single step in the pipeline. So I would open all these portals to check on the status if I wanted to know that. And now I can see this in one overview. It saves me a lot of time and a lot of frustration. And when I will actually open that portal is when I actually need to do something there. Yeah, there's over 60 plugins. So this is just how relevant this is. It might differ for you. So this is also a good example of something I really like. It's unknown. Come on. Why? Okay. I have so many questions now. Oh, great. Got a lot of live demos then. But anyways, so you can just imagine that those plugins would work and that would be we'll look at another one which I think will be better. But so yeah, also important to know is how does it actually work? Luckily, it's something we might not all love, but no, it's YAML. So this entity, which is the service you've been looking at, is a bunch of YAML. And that defines where it's what information it shows. And in the case of the plugins, it will determine where it gets the information. I have to change the integration key. Okay. But this model might look familiar because this is basically the Kubernetes object model, which we borrow because we think it's quite familiar and a good way to note this. So every plugin you have and you want to configure that, that will be in the annotations and all the core functionality would be in the YAML. So these dependencies, that's just the rule in the configuration. There's many different ways of generating this information. You could write a script, you could do it by hand, or you could get it from another system using a custom processor, which is something that either exists or you have to write it yourself. So that's what shows these beautiful graphs. Okay. So let's take a look at the API I'm using, which is the FlightInfo API. Other team manages that. There's two applications using it at this moment. And I can here find all the relevant information. But what I'm of course interested in is the documentation. So I just want to get going with this API. This could contain many different plugins. Am I using Postman? Maybe I want a plugin with a way to invoke Postman. Could all be possible. Keeping your documentation with your software is always a smart thing to do. So the same is with this API would just keep the documentation there. But it could also contain the tests and that sort of stuff. Okay. Let's move on. Because now I know a lot about how it actually works, what has been created, what happens when I add something to backstage. I know where to find the documentation. I've read about the API. So I know how to invoke it. I know how to build actually a bit of software already. So I feel a bit confident today. And I'm going to create a new project. Now, what is the fastest way to create a compliant app, which is according to the latest best practices? Most of the time, it is by copying an existing project and just yanking everything out you don't need. And tada, you have your repository. I see somebody nodding. Yes. No shame. This is the scaffolder functionality in backstage. We call it software templates. And with software templates, you can create your project within minutes. So for instance, I'm going to create a new React app. And I will get some questions. This is all configurable. You can determine this whole wizard. You can ask as many questions as you want and make it as complicated as you want. So I'm going to give it a name, give it a very meaningful description and the owner. The owner is not a person. It's always a team. That's a good thing to keep in mind. And I'm a part of the travel X group. I go next, next finish. Look at that. So some kind of enterprise. As you can see, there's a few integrations already configured, but there's many more possible. It's just that we have these available. And let me give the repository also a very meaningful name. So what this will do, it will populate the scripts with the information from the forms. And it will kick off everything that that is needed to create my skeleton application so that I can actually start working on the code. This is a way to ensure that the best practices in the organization are followed. This does not only need to be about creating a repository and putting in, for instance, the configuration for your Grafana dashboard and that sort of stuff. This is also possible to extend it by creating a ticket within the same workflow. Just everything that you need to do, which creates friction, you should get out of that workflow and put it in a software template. We're not going to wait for this because GitHub Enterprise is super slow today. I've tried this. But what will happen after this is done, it will create the repository with the skeleton files. According to my standards, it will create the stuff for my monitoring systems. It will make sure that everything is there and I just need to publish my code to the repository. And when it's done, it will also show up here in the catalog. Luckily, because otherwise, I would need to type YAML, which I do not like. So it will show up automatically, be registered here in the application. If you wonder, can I import also an existing one? Yes, you could do that totally. Or you can do it here and just put the repository URL there and it will find the file and you can have it within seconds in your catalog. But yeah, there's, of course, many more things you could do. There's some fun plugins. This is a good way of determining which technology I should use or which ones I should not use. So if I'm at the beginning of a project and I need to think about which technologies am I not going to use, there's the TechRadar and I can see what is frowned upon and what is totally exciting to go ahead with or what we are just figuring out if it's useful. Maybe I want to refrain from the technology if the consensus is that that's not a good idea. Another one is a plugin which was created by students. They added this very interesting internal marketplace before COVID even. Why is this so useful? You're working on this project and you need knowledge. You need somebody who is good at, for instance, CSS because help. I know. There you go. I need somebody who knows CSS, help, need someone to do CSS stuff. And I would just post this on the marketplace internally. And there you go. Well, let's take the marketing website. It must contain a lot of CSS. And there you go. I can put in a star date and an end date and that sort of stuff as well. And there it's on the board. So if somebody would have the skills to solve this problem, they could find it here. They could discover it. They could say, hey, I want to join this project or I want to first take a look at how they are doing with this app. Maybe also take a look at the pipeline because that's always an interesting indicator if it's a great project. Not so much maybe. As you can see, I just pressed the CI CD tab, by the way. And it shows GitLab instead of GitHub. And that is because there's just an if statement like, hey, if this entity has a GitLab slot, then, well, show GitLab and otherwise do GitHub. But also, I could also be Jenkins. Okay. This is an interesting one as well. Showing your costs for your project. We like to put it with the number of engineers. It would on average cost you. If you're launching a new project and super successful and you see that the cost of the project, well, the infrastructure would be two or three engineers. You might be extra motivated to tackle the problem and to bring the costs down. And yeah, so there's the error again. You don't believe this. So that's a really, really quick overview of backstage. That's trying to switch back. Okay. So why? Because great Spotify, great demo, maybe not. This, the ecosystem is super complex. And this is just the CNCF landscape map. And I know it's maybe a bit, you know, everybody shows this thing if they want to talk about complexity. But it is complex. It is hard. It is so hard nowadays to figure out what is it I need to solve my challenges with? How does it work? And then when somebody figures it out and says, hey, this is a great idea, if you look at the research and you look at the reasons why people have a problem with adopting open source projects, it is a lot of the time about people. It is a lot of the time about the knowledge. So if you have this platform where you can make at least sure that people have a smoother and less difficult experience using projects or using tooling, you may be solving an adoption problem there. Other reasons, we learn more and more about what makes developers tick. Smart people do research. And I read it and I'm like, oh, well, that's smart, which I thought about that. This is coming from the space framework. I don't know who's familiar with that, but I think it's a really interesting document touching upon a few things. And I wanted to share those with you. So what makes a developer happy? Well, it's a combination of a few things. It is the satisfaction and the well-being, which it might sound logic if you talk about happiness. Basically, this is happiness. But how do you get happy? Well, by feeling a sense of purpose, by being able to have great tools, by feeling that you're part of a community. Speed or productivity in general does not really equal happiness. There's a lot more to it. So you need to be able to collaborate better, have a better experience, performance, that's outcomes. Dashboarding, being able to visualize how you're doing might all help with that. Tech insights, the activity, that's the output. Dora metrics, maybe. This is a thing that we are mostly looking at because it's easy to look at measurements, like what is the output? What's the number of things we've done, the number of lines of code? And that goes up and then we're happy. But when that goes up, it doesn't necessarily mean that the developer is in a good shape. Maybe the developer is running straight to a burnout. You don't know if you only look at the data. But it is important to look at it. And collaboration and communication. So as you've seen in the demo, if you're able to find actual documentation and if you're able to share stuff with each other, if there's transparency and awareness of what's happening in the organization, then you're in a better shape. If you're able to contribute to each other's success, if you can solve the onboarding problem, which will also have a positive impact on your retention, and then the flow. Each time you need to go to a new portal or another framework learning a new language to do XYZ, yet another tool to deploy something, the infrastructure, and then another tool to deploy my code, and then the portal of my cloud provider, don't get me started. So if you can make sure that people stay in the flow, that makes a huge impact as well. And the sum of these things is what you need to do to make a developer happy. Because, very cheeky, but happy developers make happy code, which is our tagline. Even if you think like after this session backstage, I don't know, please take this home. Make your developers happy. It's so important. Because if you do not make them happy, they will be at some point happy, but like walking out of the door with yeah, but this is happening, folks. This is happening. You don't want that. You just want to, you know, make a great product, have fun together, code stuff. So to summarize, backstage is one front end for your entire infrastructure. Backstage is there not to replace your existing tooling, but it is to aggregate it, to beat that single pane of glass. You just use your tools, you're used to, but make it more easy, make it better, make it a great experience. You do not want to search for documentation, but you want to find it. You have the Google Docs, the Confluence. You have it like with your project in Markdown. You just want to be able to search that and to find it. Backstage is an interface. It is built for autonomy and for ownership. So each component is owned by a team, right? There's no single source, not one single source of truth, but one point to find it. And you might be wondering, like, how many people do I need to maintain backstage then? Well, that's about six people that we have within Spotify. And we have quite a few engineers and a lot of plugins. The architecture for the plugins, there you go. That's mostly TypeScript. So if you're good with TypeScript and JavaScript, you will be in a great shape. And it is something which is not probably the most difficult big investment you need to make. So there's three types of plugins. It can be from a webpage showing information, like the TechRadar I've shown you. It can be really with a backend system with business logic or with logic in there, like the documentation site you've seen. But it can, and that's the, I think, the biggest use case at this moment. It's leveraging an API which is already existing from the tooling or the service you've bought or the open source project you've installed. And that goes through the three-part proxy visualizing information. And that is how you can make developers happy. There are plugins. You can create new ones. You can put the power in their hands. It is work, but it's totally doable. So, yeah, that sounds great, but I have, like, a gazillion components running in the wild. It's a mess. I need to onboard new engineers. I don't know where to start. So, yeah, what do I do? Do I build that whole portal? No. Just start with one thing. Try to solve that. Do that great with a small team and expand from there. Share that knowledge. Build that internal community, because that is in the end what is really necessary for success with Backstage. And because I'm at time, I'm just going to show you the links. If you want to get started with Backstage, you want to try it out, you can set it up in a matter of anywhere between 20 minutes and 40 minutes. There's a great Getting Started guide on our newly launched Backstage Learn site. And at the end of this month, which is already in two weeks, no stress. There will be the Plugging Creation guide as well. There's a lot of documents, of course, but we think that these experiences might help you get started even better. So, check back in a few weeks. And if you want to create a plug-in, there's a great workshop available for you. And now I can maybe take a few questions. Yes? So, two questions. So, as far as hosting, is it basically we have to host it ourselves, or is there, like, Spotify or something else for us on Backstage? So, yes, there's an option to get Backstage as a SaaS solution. There's a partner called Rody, and Rody offers hosted Backstage. They're a great partner to the community, and we're really happy with that. But it's not a Spotify business model to offer a SaaS solution. But luckily, we have a great partner. Yeah, so the best way is to start small with a team dedicated to figuring this out from there, sharing those successes, sharing the learnings. And for instance, if you have an internal tech meetup, it's a great way to share that knowledge and to distribute that knowledge and share the value of what you've created. It is all about community, because you can implement a tool, but if no one's going to use it or invest time in it, it's just a waste of time in the end. So, it is an investment, but it's something you need to carefully think about. It depends also really on the culture you already have. So, if you have a culture of learning and sharing knowledge and collaborating at InnerSource, then you're set up for great success already. If you're not, you're also set up for success, but it might take a while longer. So, yeah, there's, so if there's interest in from the CNCF to put projects in there, yes, there is a lot of interest from the projects itself. So, there are plugins coming, there are a few already available, but yeah, I really hope that more projects will invest in this to create a plugin and to add the value, because in the end of the day, it will both be great for companies using this. It will really make the lives of engineers better, but it will also make the lives of projects better, because it will be more visible and they can drive better adoption, which is what we all know is a challenge. Now, it's happy little accident. Now, we noticed that this really worked, and we figured, like, if it works here, it might as well work anywhere. And well, given the number of adopters and the feedback we get, it is the case, yeah. What we also see is that, like, the whole loop with the external community works pretty well for a lot of plugins as well. And for Backstage itself, yeah, there's like so many contributions coming from outside of Spotify, which is so good for the project. We're really happy with all the attention and the investment companies make. So, yeah, you don't know what to expect, and this is like the best thing you can have, I think. Anyone else? Oh, yeah, one more. So, if you have like an organization of, say, 100 teams and thousands of components, how do you get the teams to put their information out there in a coherent way, so that not everybody invents their own way of naming it, and then describing information, and so on? It needs to be coherent in some way. Do you have any tips on that? That will always be a challenge, because, well, we all know naming things is hard, and providing barriers is also, yeah, but not maybe getting you to the result you might want. So, to give an answer, yes, you could maybe do that with software templates. Make sure that there's just a record looking at if it is according to the naming standard. That's a great way. Maybe it will be, if your naming standard is, for instance, the team, the platform it runs on, and the type of service, then you could maybe just make a few checkboxes, and it also generate the first part, or whatever you have prefix suffix. That might help a little bit, but the most important thing, of course, is trying to get that community to go for it and understand why it is necessary to do these things. But yeah, this is like the most easy way is to enforce it in your software template, for instance. But yeah, your cloud provider can, also, put in these mechanisms. But yeah, that's already one step further. Place is always better, I think. Yeah, it's time to round up. So, I want to thank you for your attention. And once again, just give it a spin. If you're stuck somewhere, or you think it's really good, or you think it's really bad, let me know. We have a very active Discord channel, and I'm there too. And otherwise, you can always just stalk me on Twitter. I'm really active there, more active than on my email, according to a lot of people. So yeah, thank you, and have a great day, and enjoy the rest of Dublin.