 Awesome. Well, let's begin. Please settle in and of course, this is backstage con. So if you're supposed to be in Argo con, this is other room in here. Super happy to see people after lunch. This is very hard. You want to You want to take a nap, want to sit outside in the park, but this is this is really good. This is my first backstage con, by the way. I never imagined this kind of room. I thought this would be like two two rows and that'll be it. So super happy to see this milestone. There's a lot of people who worked really hard on this kind of a pet project from Spotify trying to elevate developer experience from a hacker mindset, but to see this large community come alive, you know, solving business problems and scaling companies. That's that's massive. So I'm really really happy to be part of that. My name is Himanshu. Himanshu Mishra. I go by Orco Hunter on everywhere, GitHub, Twitter, LinkedIn. Someone asked me why is this name Orco Hunter? I just googled the most unique username. So if you search for Orco Hunter, you'll find everything about me. I'm a product manager currently at Hardness and I lead the internal developer portal project, which is powered by Backstage. So I've been doing Backstage for for about three and a half years. Previously, I was with the wonderful team of Backstage at Spotify. I was an engineer. I was a developer advocate and eventually my job became to hear complaints about Backstage or also good things about Backstage. So that's what I've been doing so far and really fortunate to be part of this journey from, I remember there were like 50 stars on GitHub when I first made my PR and to like 24,000 from 10 to 10,000 members in the Discord community. This is this is massive. And finally, I think about open-source economy more than Roman Empire. I think about what makes good projects successful and how to keep that success. There's a lot of projects who gain very high momentum but what makes them fall apart and clearly Backstage is doing all the right things right now. All right, so let's dive in. Does anyone or let's see how many people can guess? When was Backstage open-source released? You've got four options. Please raise your hand if you think it was released in September 2021. Awesome. You got one person. Clearly, this is the right answer. We got option B. It was released in January 2020. All right. All right, we got four hands. There's two March left. There's 2020 and 2015. Who thinks it was released in 2020? Did I make this correct? Who thinks it was released in 2015? Awesome. Well, 90% people guessed it right. It was indeed released in March 2020. But I'm sorry for putting in 2015 because you can say it was created as Spotify in 2015. But it was March 16 and the GitHub repository was open-sourced. There is this orange website. I'm sure you've heard of it. It became number one there. I don't know who this James Kigley guide. We never thanked him for putting our repository on Hacker News. And we were trending on day one. But if you look at the comments, I don't care if it's open or supports plugin. I have no clue what it does. I just skimmed through the website and I'm still wondering what Backstage actually does. Is it me or is this just really unclear? It needs clear... So we've got a wonderful marketing team right now in Backstage 45. We didn't have any back then. It seems like a competitor for Datadog. Okay, that was definitely the intention. So the very next day, the Spotify team had to release a blog post. Does anyone remember the name of that blog post? The very next day. It's very catchy. Spotify people are not qualified to answer. What the heck is Backstage anyway? We accepted it, that it's hard to understand what this platform really does. And it was confusing initially, and there's a reason. Any great platform that starts, it's hard to figure out what it actually does. So slowly, shortly after the launch, Backstage released three core features and people started connecting with them. Which one is Catalog's logo? First, second, or third? Well, you have to shout out like, oh, well, I see some Spotify people cheating. That's fine. So the first one is Tick Dogs, the second is Software Catalog, and third is Software Templates. And people related with these problems, not with these products, they're related that it's hard to, you know, discover components internally. No one knows who owns what. We have got a technical documentation. It's not up to date. It's hard to share knowledge, and finally it takes too freaking long to create a new service. Can I do it in 10 minutes? So they're related with these problems, and Backstage became what it is today because of these core features, core ideas, that is very, very relatable. But today, I'm not going to talk about those. So if you remember the definition or the description of Backstage has not changed in a long time, it still is an open platform for building developer portals. And the two main phrases here are platform and developer portals. I personally think we have talked about developer portals for the last three and a half years. Today, I want to talk a little bit more about the platform that Backstage is. So really trying to do soul searching here. What is a platform? I hear this word all the time. What does it even mean? It's a platform. Definitely not the railway station where you catch trains. What does it mean when a software is a platform? What does it mean for you? Would anyone like to express what do you think a platform really is? You can shout. You build on top of it. That's a platform. Awesome. Any other contrary, you need contributions on top of it. You have to invite it. So you need a good path for contributors to come and build on top of it. Cool. So it's very similar. I think that's about right. But when we think about developers, what is a platform? Well, everything developer touches today is a platform. And if you think about it, I'm sure almost everyone in this room understands what a developer goes through. You have been a developer in the past or are you are a developer today? Just open your applications folder. Just open your the doc you have and try to start identifying how many of those have either apps, plugins, extensions or add-ons. Let's start. Let's start with the phone. Of course phones have apps. And these are not small apps. These are billion-dollar businesses which these operating systems created. You've got browsers which support extensions. You've got your code editors. And of course some of these are 30-year-old. They have been supporting plugins ever since. You've got your programming languages which support, you know, pluggable libraries which you can use to build your software. You've got your CI CD, your orchestration layer. They support apps. They support pluggable things. And if you really think about it, Spotify is also a platform, right? Not necessarily a developer platform, but yes, artists, you know, like put in their songs and listeners listen to them. So what I've observed is if you build something for developers, it ultimately becomes a platform or it dies out. Happy to chat about any tool that has been here for some time, which is not a platform and developers use them. So today, let's dive into that backstage platform. And I want to highlight these three important pieces which really make that platform really good. The first one is the composability system that exists in backstage. The second is the API refs and lastly the plugin framework. Of course, I'm not an expert on composability system, but as much as I understand, you might have seen three types of plugins in backstage. You have a simple card which you can put on the catalog page on mostly the overview tab. You have a tab which goes on your catalog and has a special route. And finally, you can build an entire page plugin which will go into your sidebar. So the composability system allows plugins to export these metadata, to export these, you know, what they call extensions, so that the backstage app can really use them and ensure, well, and this is how it looks. So the plugins export metadata for the backstage app to consume so that the app understands what is it, where should I place this? Should understand if the plugin is misbehaving, what should I do? Should understand whether should I load the plugin, and by I mean the backstage app, should we load the plugin if it's being used? Understands the routing and finally mixes all them up into the single page. This is my most favorite part about and I know people who have created it and if you know someone, you can't say they're genius, but they're absolutely are. So backstage core APIs have something called API refs, and here's an example of how a plugin can raise an error in the UI. You see three parts here. So the first one is a unique identifier of the API, in this case error API ref. It's nothing, it's just a simple ID which is unique across backstage app. You use this, use API hook to fetch an implementation of this API ref, and you finally get the API instance of this, and I will come to why this is super important in the backstage world. So this is how it looks. The backstage core and the plugins expose, and this is just a simple list of me searching API refs and finding all these APIs that exist in backstage. There is a default implementation all the time, but as a backstage integrator, you can always override most of it. You can provide how you would like to do stuff. For example, if you'd like to use let's say Sentry to manage your errors, you can do that. If you'd like to handle cost, cloud cost management from somewhere else, you can override that. If you want to manage tic-tocs from somewhere else, go ahead, override it. It's built to be customized and personalized for your needs. And finally, the plugin framework. This is the most exciting part. We have got around 200 plugins out there. Every company I talk to has plugins that they have built for their own needs. And of course, backstage makes it super easy for you. So today, I want to think about a few use cases and then just dive straight in. I know if you have read the abstract, I promise 16 things that backstage provides. Well, they're 18 now. So yeah, I keep learning new things. So let's imagine a data engineer and think about it from a place where in the company, they either have backstage or they don't have backstage and think about what their experience is going to be if they don't have this framework, if they don't have this kind of support structure which an IDP provides. So a data engineer wants to build a page where they can see all the golden data sets in the company. It's not made up. It's actually what this little bit some people know about a music company here they do. There's a security engineer who wants to build a new hub for their DevSecOps standards. There's an architect who wants to start measuring code health. And there's a platform engineer who wants to manage cloud developer environments like on demand, if you want to test something to it. And let's see how backstage helps. So I'll do a quick run through of this. Of course, this is very technical, but I'll try to explain in simple terms. So let's begin. Number one, backstage gives you a good boilerplate code. How many of people in this room have never written JavaScript in their life or not recently? Right, so it's not negligible. Like we live in a bubble where we think it's super easy to know how to bundle, how to create the first app. It's not. I tried last month to set up a pet project on Next.js. And it had server-side rendering enabled by default. I spent like entire weekend and was never able to figure it out. Eventually I created a backstage app for my pet project. Believe it or not, I use backstage for tracking what I'm going to eat through the week. So it gives you a boilerplate code to begin with. It gives you a local development environment where you can start coding and start seeing how it looks. You can make changes. It will auto-reload for you. And it also provides in standalone mode where you can run the plugin just on its own. You don't need the entire backstage app. This is where it starts getting interesting. You're building an application and you need to know who the user is in order to provide customizable experience. Are you going to actually ask them to sign in again? No, don't do it. Backstage has got you covered. You call the identity API. You get their email. You get their profile data and start showing them. Right? Remember the four use cases that the developer wants to build in a company which has backstage or an IDP. It gives you good build and test tools. You don't have to worry about whether we're going to use Webpack or in all these different tools which I know JavaScript engineers love to debate. Sorry, no one else cares. I just want to build my code. I just wrote a simple React component. Again, super important. You need to store stuff, right? Imagine, and I've seen this personally, companies, different teams, they start really complex projects and they end up doing DevOps. How much time is being wasted by every platform engineer if all of them are having a database up and running and maintaining that? Don't do that. Backstage has got you covered. You write your schema. You write your queries. You'll get a TP and we'll figure out where that is hosted, whether this is Postgres, whether this is SQLite, or maybe in future something else. There's the amount of effort that the backstage, especially the maintainers put, to ensure tools are replaceable is extremely hard. Of course, it uses connects to support multiple database providers. Do you need config to configure different behaviors of the app? Don't write another YAML parser. Backstage has got you covered with schema validation and everything. Do you need Cache Manager? Do you need Redis? Do you need Memcache? Why bother? Just use a simple cache API that Backstage provides. Whatever your app integrator has configured, you'll get to use that. Even just memory, sometimes that's good. Are you running tasks on a periodic basis or are you scheduling them? You might know that catalog and scaffolder, they run this, syncing, pooling, execution. There's a task scheduler for you if you're building a plugin. Use it. I personally worked on this, so again, this is going to be my personal favorite. Imagine you're building a plugin which has to read URLs from different third-party providers. How would you do it? You're given a URL like github.com, something, bitbucket.org, something. Are you going to ask for a token again and again? Are you going to ask for an app and realize how to do authentication? It's very hard. In Backstage, there's three AFLs conditions based on the Bitbucket API version, by the way. So, it has got you covered. Use the URL reader by Backstage. Read files, download files, don't worry about auth. You've got to cover it. This is something new I learned. There's an event broker. You can publish events and other plugins can subscribe to them. And if change is needed, you use it. Again, very important, if you want your developers to sign in via github and sign in via Google, what are you going to do? Go ahead, build an OAuth framework, spend a month on this. No, you shouldn't do that. Make the life of Platform Engineer really simple. Use the Google OAuth and GitHub OAuth provided by Backstage, and it will make it super easy for you to know what the GitHub idea is so that you can make requests to GitHub on their behalf. So, making life easier. Permissions framework, right? If you want to add a little bit of authorization in there, use the permission framework provided by Backstage so that you can differentiate actions. Basic things, you need alerting, but do you have to worry about what alerting framework should you use? No, use the one provided by Backstage and your integrator will figure out where that alert goes. There's a shared library of components. Why bother creating a new graph component? Why bother creating a new table? There's a storybook for you. Of course, it's based on Material UI. Just don't think about design too much. Ensure consistency and you can move on. Well, do you want to release features behind a feature flag? Yeah, Backstage has a feature flag where users can toggle and then get the behavior changed. Use it and then maybe release it to a couple of teams. Search is extremely hard. I was talking to a long-time Backstage adopter. Imagine if you were to build search on your own. It's going to be very, very hard. Backstage provides you with the search framework. You just decide what data needs to go in there and then your users can continue to search in your plugin. You need to understand how the users behave. Use the plugin analytics API, publish events, and then if it needs to be Google Analytics or New Relic or Segment, that's none of your business as a plugin developer. You just want to get some behavior data. Or do you not want to build backend? You already have a backend. You just want to build a simple UI component and make requests to the backend using the Backstage proxy. So use the Backstage proxy for that. This is endless. I haven't written Backstage code in a couple of months. I'm sure there are people in this room who will come and give another 10 examples. This is what's hidden in the Backstage platform. And I'll give you one of the examples that I deal with almost every day for the past year. We embed Backstage inside Harness, which is our software delivery platform. And just to show you the craziness, it does not run on the root path. It runs on app.harness slash customer ID, something, something, and there's never been a glitch. It works as it is. You never sign in into Backstage. You sign in into Harness, but you make sure the identity APIs are working very well. And we have been able to build plugins like crazy. We built scorecards. We built plugins for our integrations to our CI, CD, feature flags, and rest of the platform. We did all of this in within a year, actually, nine months, just because Backstage is an extremely powerful platform. So today, we have arrived. What is the answer look like? What is Backstage? I would not attempt to define this really soon. I don't think we should call that this is a catalog, this is how you measure service maturity, or this is a, let it settle, let it be hard. It's fine. It has a huge potential to become the great developer platform that it's going to be, and let the community explore and figure themselves out. So all I know is the journey has only begun, and yeah, it's going to be great. Thank you. Amazing as usual, Himanshu. Any questions from the audience? Please keep the controversial questions outside of the stage. It's upon yourself, Himanshu. It's inevitable. It's going to come. Brace yourself. Hey, thank you so much, Himanshu. This is really helpful. I had a question on, you had something about when you talked about the plugins. You have page plugins, tab plugins. You have card plugins. You have three different kind of plugins, right? How are they kind of controlling the contribution model over there? The reason I'm asking is, if you have a special, if you have a SBA, a single-page application, you have cards that are certain dimensions, right? Now you have a plugin that comes in, and how do you tell, is there a governance process that you have on which plugin, which dimensions, where it goes, et cetera, et cetera? Like how does that work? Yes, not an expert on this, but as much as I know, is if you're building a card plugin, you don't get to decide what the dimensions look like. It's the backstage app integrator, which decides that. So that's number one is, the plugin comes as it is. And then the integrator could make it full width. They could make it half width. For full-page plugins and tab, you get full control. OK, so that's not a soft plugin. It's more of a hard plugin with the integrator. So one good mental model for this is, imagine what this page is doing, right? This is a front end to the infrastructure. So what I have used so far is, try to think if you can build a card first, if you have a platform behind the scenes. Try to remove, as product builders, we love our product. We love our features. We are super obsessed with the things that we want to show to developers, but we don't realize that the developers have 100 people showing 2,000 things to them. So don't do it. Think about what they need on a daily or weekly basis. Put this on a card. If you have more information, put it on a tab, which is in the context of the service. And full page plugin is when you want to go beyond the service context. Thank you. I had one more question on your, you had inbuilt alerting. Like you said, you have an alerting framework as a part of it, because it's a platform. As we are going to hotel and more different open telemetry open sources, right out there, is backstage integrates with them? Or we are alerting platform. It's an open source by itself that is different from hotel. Like how is that working? Yeah, so a good question for the Discord channel. As much as I understand that the alerting is for the front end plugins, we do have some kind of telemetry in the back end. I may not have the right answer. So you've got some actually experts in the room, but put it on the GitHub discussion. If it's going to be built, it's not going to be vendor logged in. So it will again be an API driven. And you could plug in different vendors in there. There's another one there. This one is hard to get. Hey, thank you very much for the talk. I want to stop over the event broker part. I'm curious, what are the actually use cases for it? And what did you mean by components talking to the components subscribing to events? In which case exactly? Yeah, so I can think of a simple one where catalog contains all the metadata. And let's say you build a plugin where you want to know if a metadata of a component got updated. Let's say the owner changed. And based on that information, your plugin behavior has to change. So that's where maybe you would want to subscribe to those kind of events within the back end system. This is new. So I may not have the right answer. But yeah, that's a use case I can think of is a plugin changes its behavior. Let's say search index updates. And now the authorization plugin needs something else. I don't know. I'm making things up at this point. But yeah, plugins do need to talk to each other, these core plugins. Thank you. Any other questions? Come on, one controversial question. I made so many huge claims. Like developers use platforms. Now, really, if you agree with that, I think that's great to hear. No other questions. Perfect. Thank you so much. Thank you so much. No, no, there is one. There is one. Hold on.