 Hi. So this is my talk on maximizing developer experience with Backstage and exploration of the power of Backstage plugins. Who am I? I am Devapratha, a community engineer at Harness. I have been a part of a release team member for Kubernetes. The release was in 1.24 to 1.26. And I contribute to Kubernetes under C Contravex. This is a picture of me from last coupon when I was in person and this time, obviously, I'm in a virtual speaker. So in this talk, we will be covering on what is Backstage, what are the core components of Backstage and the highlight of this talk, the role of plugins and enhancing the developer experience to Backstage, and some learnings that we had while developing our Backstage plugins in Harness. So Backstage is an open platform for building developer portals, which is created at Spotify and donated to CNCF. Why Backstage? Because it is Backstage what essentially is basically it's an open source developer portal, which makes it easier for your developers. Or you could say it's a one-stop view for your developers for all the services they are using or all the apps or services, two links that you have taken subscription for your developers to help them develop your software. So every developer portal is unique. Even if they use Backstage or some of the developer portals, there are a lot of developer portals in the outside market, which are either inspired by Backstage or are completely different from Backstage. But what is important is the requirement of developer portals because as Gatner predicts, by 2025, 75% of orgs will have developer portals. So what is a developer portal? As I said, it's a one front end for your entire infrastructure. Unifies all your tooling services, apps, data, and dogs with a single consistent UI. Makes sense of everything in your ecosystem, regardless of how and where individual components are running. So let's develop a focus on what do the best. Develop the software, not spending time on scribbling down, going to GCP, checking the cluster logs, and coming again to your Graphana dashboard, check your service logs and all those things. Everything is available in a single place and you don't have to switch to different tools for the minimalistic information that you require. Why Backstage? Because it is open sourced. Obviously the biggest selling point of Backstage is its open source and you could customize your own Backstage instance or the way you need to use Backstage. So Backstage has something which are extensible plug-in architecture, which is customizable. It is well-dubbed model, modern technologies and common frameworks like TypeScript, React, and makes it easy to develop for and contribute to your depot. It is cloud agonistic and vendor-neutral. The software model contains something like core entities and for each kind there are like service, website, library, and there are some suddenly the relationship grabs in annotation. What is this relationship graph? Is basically when your developers come into your Backstage portal, they know the service they own or they know a particular service which is owned by which team and or let's say an API is visible or an API, Docs of API is visible inside Backstage, you could easily point out to the owners of that API or what all the dependencies of the API or a single service is running, you could give the relationship grab, which is very important in the software model. There are a lot of other core things which is out of scope of this talk, but you could explore it in Backstage.io's last talks. So what is a plug-in? As we discussed earlier, plugins are built to be extended and or you could say plugins are built to extend the use case of Backstage and customize for your particular infrastructure. Plugins are NPM packages, which is very important to understand why plugins are NPM packages because from usability point of view is you could develop your own plugin package inside NPM and pull it from NPM whenever you require them inside your Backstage instance. There are certain kind of plugins which are called front-end plugins which are back-end plugins and there are core features which are plugins too. So see the way the Backstage is built, it's plugins surround the whole usability of Backstage. Software templates are a Backstage which is a core part of Backstage functionality. Front-end and back-end plugins have different use cases and there are plugins like card-based plugins, overview plugins, service plugins, but what is important for us to understand here is let's say you have a URS service provider or you are a tool which provides, which is a product for developers to help in their day-to-day life. So you should think about giving a user usability to Backstage because developer portals are meant to make things easy for developers. Let's say they have a lot of tools for that company has a lot of tools to maintain their observability metrics and the company uses a cloud vendor for their all cloud-related, cloud infrastructure-related work. So all this data could be visible in a single place if your cloud provider has a plugin and your observability tool that you use has a plugin. So as a company, it is for you to think around. If you want to make sense for developers, if you want yourself to be useful for developers, you should think about plugins or you should think about how you should be useful in this whole Backstage ecosystem. And this is one of the USB of Backstage. It gives you the whole ownership of, how do you want to develop things? How do you want to put things in? Inside Harness, we being a product for developers, it's very essential for us to be a part of all these changes or all these trends that are upcoming to make things easier for developers. So the developers are optimized and their whole day is optimized and they're focused on what they do the best and software delivery lifecycle is at its best. So we have some of our products like continuous integration, continuous delivery, CCM, feature flags and all of these has a plugin. Some are work in progress, some plugins have been published to open source and you could find them easily in our Harness Last Backstage plugins repository. So what advantage it gives us is some of our customers who are already using Backstage could now use these plugins and help their developers get the minimalistic data they require from these all tools to be visible to them in single page. And inside Harness, we use something called IDP internal developer portal which is Backstage as a service and we also plan to make it commercial open source confirmation model. But what is important here is to understand the way we adopted Backstage because it was required not only by our customers but it also enhances the productivity of our own developers. And while adopting to Backstage, we also stumbled upon some of the use cases that was necessary for developers or that could help developers enhance the way they use our tools. So it's a win-win situation when you try to inculcate with developer experience through Backstage, you get ideas of features that needs to be there in your product essentially to help developers. So this has been quite a wonderful journey for us. It's a very short journey, like it's been few months only since we started with Backstage inside Harness. But yeah, the learning has been quite fulfilling for us and it has helped us to improve our own products and be more helpful to developer which is the core essence of what we do at Harness. So thank you. That's all.