 Thank you. Good afternoon everyone. Welcome to DevCon check. I am Rajeen Umman. I am Navinesh Sinde. We are part of developer experience engineering team at Red Hat. Yeah. Yes. Okay. Yeah. I would like to start with this quote. In 2011, Mark Anderson quoted this in the Wall Street Journal. He states that software is still eating the world. So basically his idea was like day by day, our daily problems are getting solved within the softwares. Everything is getting resolved within a software ecosystem. Yeah. So there are a lot of innovations which are happening right now in the industry like chat GPT, e-commerce applications, a lot of things which are happening right now. So how are we managing this? How are we managing this innovation in an engineering perspective? Innovation is good all the time. But how are we managing as an engineer? Managing the innovation means are you able to track the good things in the terms of good practices and all. So basically my point is every day that whenever the new innovation happens, like the stack is always the problem stack is getting more complex day by day. And like in an engineering perspective, software onboarding, the collaboration, management, everything seems to be different day by day nowadays. So it is good that we should we should resolve this kind of things. There are a lot of problems is coming right now. You can see some collage on my screen. In the collage, I have tried to address some of the problems which I come in my mind in an engineering perspective. When you develop a software, deliver a software, managing a software, a lot of problems will come to you. Some of the problems I have addressed here, like for example, consolidation of the efforts. That's a major thing. So something can be the management, something can be the templatization, better software, software management, a lot of problems are coming in the picture. So in the current scenario, many organizations want to actually more in the rapid delivery model with the less resources. That's a lifestyle which we are into. Who is going to take care of us? Is someone? Okay. So basically in our basically in the engineering perspective, so as an engineer, I have to develop some feature or I have to build some code and deliver to the production and I have to manage it effectively. That's a basic fundamentals of an engineer, like how to do the things in a better way. So engineers are actually struggling to make the things into engineers are actually struggling to make meet the technical depth features and everything, but we are not getting the right time. So these are some of the problems which you are trying to address here right now. And this is actually leading to us right now. We know everything. As a developer, I am developing the applications, I am maintaining it, I am putting it into production, but that is not the supposed job of mine. It is supposed job of an DevOps or a system administrator who manages infrastructure. I am getting, I am getting the, I'm being the jack of everything, but I'm not being the master of anything or an engineering perspective. I'm working on everything right now, but I'm not a master of anything. That's a primary problem for the developers now. So do we have a focus to solution which we can see every efforts in one place? Yeah, that is backstage. So backstage is a open platform for building the developer portals, which is home grown in Spotify as an internal tool, and it has open sourced in 2020. And it is donated to cloud native computing foundation. Spotify enables the developers, engineers, managers, what are the profile is like what you will get to know the inside set, what is happening in your organization in a consolidated view. And it has a huge community base also across the world. This approach actually simplified the life of the Spotify. Spotify has almost 1000 plus microservices and the software pieces scattered across their organization, but with the backstage they were able to handle it. So this developer portal enablement helps them to track every pieces of the software which are scattered and everything into a one single view. I told the developer portal, what is developer portal? Developer portal is nothing but an internet for the developers and it is a one single front end for the for our organization to handle all our services or our software stacks. So it unifies your toolings and it unifies your toolings, services, softwares, everything into a single stack. So a developer portal primarily integrate the tooling services and the documentation also, which is a pain for us to manage. Also, we will get to know the like who owns what, like we will get to know the some insights on the like who is taking care of what. So there are a lot of insights we will get after connecting the backstage with our software ecosystem. So that we can give some time to our developers that okay you focus on building some feature, we can track everything in one place like if something goes down or something goes there, we will be able to track everything. So we can make our developers to work on the focused mode. Yeah, backstage actually enables the better collaboration and it unlocks collective potential and empower a steam to do what they do to do best with the speed and the scale and house control. So backstage really helps you to deliver your software and the manage the software with the golden path practices. So backstage is it aligns the distributed culture of an organization and it helps you bringing all together into a single platform. Yeah, the core philosophy of backstage is actually it act as an interface to unify the things all together. I have mentioned this before actually. So it is it helps to build it helps it helps to build the single source of truth for your organization and it will keep up your autonomy in your software stack like autonomy means like different software different enterprises works in a different model. So within relation to that you will be able to see that how your software stack should be set up over there like you will get some insights over there right at that moment. And regarding the ownership you will be able to set up the ownership for your backstage components. For example, if I have a front end and he wants the back end for the front end I can set up the ownership for myself for the back end I can set up the ownership for himself. So we'll can so we'll be able to track that like who owns what. Also this empowers the responsible software development ecosystem also. Let's go through the three core terminology of the backstage which is core app and plug-in score is something like a how the kernel is for the Linux. So with the core like it is maintained at the Spotify. So it powers the basic functionality for the backstage. App is something like we do as something like you do a Linux installation or machine how it helps in our day-to-day activities. So app will app is just an instance of backstage which is deployed and we can we can take according to your needs actually. Plug-ins is a cool feature of the backstage that we can extend we can give that you can give the extensibility to your code. So for the enterprises we can adopt the backstage in their own manner. Yeah backstage actually helps you to create manage and explore the things. Creating means that you can build your software stack in an effective way. You can manage your software stack in a one centralized location and you'll be able to connect the pieces across it. So by connecting means that like your data is shared across the organization so that the discoverability of your tools and services will be huge. So software model talking about the software model so this is a way where we classify our software components into one. So in the score entity we are trying to classify our software right. How our friend and system should work like, how our back end system should work like. So we are classifying it into our like however classifying into our software system like that now. So regarding to that also there are many relationships also we can be able to manage like you can relate your software one component to another component how it talks. So for example I have a back end system I provides an API so we can build the relations on top of that. Also we'll be able to use the annotations to will we can use the annotations to extend the backstage actually. So it uses the Kubernetes or it uses the Kubernetes format to define the annotation so it will helps to extend your backstage with the and use the plugins also. So it is a very good thing. One thing we can do with the backstage is like with the docs so docs is always a main problem for the developers. So managing the documentation for example if I am an engineer if I want to find the technical docs, user docs like I have to go to multiple places and the multiple resources. So right now with the power of the backstage we'll be able to with the power of the backstage we'll be able to find everything in the one place with the power of the tech docs actually. And you can manage your content in the terms of mark down and you can able to find your services with the power of the search. Search will be able to do your search will be able to make sure that your content is shared in the backstage environment. So it is discoverable basically. Yeah search itself search it helps to find out the content. So with the search by default it is a memory search in a mechanism. So it is able to connect the software pieces across the system. If you search for a software template you'll get it. If you search for a documentation associated with a software template you'll get it. So it's already there. And good part of that is it by default it has an in-memory search but also it supports elastic search, loner and postgres as their back-end search engines. And this is suggested for the higher level usage actually. In memory it's not a good search mechanism in the terms of a large scale usage. So switching to the search engines makes sense actually. And it makes help to communicate within the service to service plugins and you can customize your search experience to your people. Yeah I'm handing over to Navinia. Thanks Rajan. So I will walk you through software templates in backstage. So all of us are aware of this famous quote which is time is money. And do you really want your developers to spend time building the same old boiler like developing the same old boilerplate code every time they want to create a new application? No right? So for this and with the advent of microservices every team has an autonomy to choose the solution which they like and which fits their purpose. For someone it might be Java, for someone it might be Node.js. So teams have got this independent decision on what they want to work on. But this creates a problem called as distributed fragmentation of developer tooling. Because someone might be working on Java, someone might be working on Node.js. So there is no common developer tooling and the only way you can know like how the developer tooling is set up is to speak with your colleague. So backstage addresses this challenge with software templates or golden paths. Golden path is nothing but an opinionated and supported path for developing your applications. With golden paths you can bootstrap your project ideas quickly by following standard practices like clean architecture. So golden paths are not meant to restrict or limit any developers. They are rather meant to be complementary to developers so that they can do what they do best like develop applications. Golden paths also allow to automate the creation of GitLab CI CD pipelines and deployment templates of OpenShift and Kubernetes. So on slide I have included few links to golden path templates which are available from Backstage as well as Janus IDP. Janus IDP is an open source community supported by Red Hat. It's currently working on Backstage. So you can check out the golden path templates available on Backstage as well as Janus IDP. There are plenty of golden path templates available there like clean architecture, React, Spring Boot with HelmChart deployment. Now coming to plugins. So Backstage has this customizable and extensible plugin architecture. In software systems there is no one size that fits all. Every organization has its unique requirements and it is a unique solution for that. And Backstage is really built in a way that it is open for extension by default and plugin provides a way to extend the Backstage architecture. So there are a number of plugins available on Spotify Marketplace. Also there are some plugins which are provided by Red Hat and the links to the same is provided in the slide which is Janus IDP.io slash plugins. So you can explore all the plugins here. Now this slide shows an example internal developer architecture of an internal developer platform at an organization. It has variety of plugins like Circle CI for managing your continuous deployment, Service Catalog to manage all your services at a single place, Lighthouse for your application analytics. And it's not necessary that you should use a vendor provided plugin. In Backstage it's very easy to develop your own plugin. So all of these plugins can be used as a mixed and match of variety of plugins. And you can extend the Backstage architecture as per your use case. So I would like to cover this plugin of Motomo. Motomo is nothing but an open source web analytics platform. So we have developed this plugin in-house at Red Hat and it will soon be available as part of community plugins in Janus IDP. Now we will like to go through a quick demo of Backstage. So this is a Backstage homepage where you can enable, where you can do all the things right now here. So right now first of all I am trying to do is going to show that how to do the software templating and how to bootstrap a software with the golden paths and all. So for software templating is the core of the Backstage where you can enable the developers to follow the best practices and everything. Let's see how we can create a software template. So we have defined a few software templates in our catalog right now. So I'm using the software templates for the, with this not just backed application. So after, you can add your organization, whatever you need. I can add, you can add your repository name. And you can who owns the system. Here comes the ownership of your code piece actually. So you can define the owner for a specific code which is going to bootstrap. And you can assign the system where it belongs to also. And you can modify the things however you want. So basically it uses the YML format to declare your software catalog for software catalog for your application. And you can define the actions which you need, which you follow. Once you do a create, you can see that software is getting cataloged in this specific group. So I'm doing a live publishing to the software in the catalog. So once you have done with it, you can see the, we can see a new rapport has been created just now, which states that it is the code has been bootstrapped by the HANA side, by the backstage. So similarly, also you will be able to track the software in the backstage, which will give the lifecycle, we can track the lifecycle for this specific software piece from the day one. So this is the, this is how we can track the, and if you are trying to reconfigure this with the summons, you can also just update the catalog.yml so you'll be able to track everything in the one place. Yeah, so this is a one example of a software templating. And everything is managed within the catalog. Yeah. So this is one of the IDP which we use right now, HANA side IDP. HANA side IDP is something which we can utilize for building an IDP. So in the HANA side IDP showcase, this is a showcase app which is available publicly. It's available in showcase.hanasidp.io. So in the HANA side IDP, we have built a plugin for managing our infrastructure, managing our security insights, everything. So Red Hat has a very great community called HANAs. So they manage this right now. So this is a showcase application. I'm trying to show you the plugins with the HANA side IDP which has developed recently. So which is one is the majority is a topology plugin. Topology plugin is built on the top of the basic native Kubernetes integration on the backstage. Backstage has a native Kubernetes integration. On top of that, the topology plugin has been built up. So you'll be able to get the insights of an infrastructure and in one place. For a developer, you don't need to go multiple places to see what is happening. If a port is down, you can see that. Like what is the status of the port? Then you can take the action items necessarily. So another plugin is called the Tecton plugin. You'll be able to see the Tecton pipelines over here. Another thing is image registry by the Koi. So you'll be able to see that like what is the image which you are using with the backstage, with your application. So you can see a tracker code of some image insights over here and also some security insights. At last, and also you can see that how the system is depicted here actually. How a system is getting related to here. If you see that actually, the showcase app is dependent on what all things. So you can define the dependencies and as a new developer here, she will be able to understand like how the system works basically. That insight is basically shared. And if something is broken, so we can identify like where this problem can be, where the problem is arised. And this is the documentation for the backstage tech docs powered. So you can able to manage the documentation in one place right now. So with the documentation, with the documentation you can manage the content over here. And this is a searchable piece of software. Even if you see here, you can search that actually. You can get the guides over here. So it is as much as extensible backstage. There is no limit for this extensibility we can get from this backstage instance. Also it is able to track the APIs. It can serve as your API catalog within your organization. So you can able to find the like what all APIs you are getting used within your organization. You'll get some insights on that right now. Yeah, yeah, I'm handing over to Adhavania. So currently, Janus IDP is an IDP provided by Red Hat. It is an open source one. There are also a lot of commercially available versions of IDPs like Red Hat Developer Hub which was recently announced at Red Hat Summit. This will soon be available in GA. There are also Amazon and Rody who have built their own IDPs and they are using backstage as their central nervous system for managing this IDPs. Next one is let's say you have decided to use backstage as your developer platform and you want to create your own IDP using backstage. What should be the adoption plan? So first step would be trying out backstage. To try out backstage, you can use the demo applications which are available on Janus IDP or you can use a demo application from Spotify as well. The next step would be POC which would be you set up the backstage instance on your local environment and you try out like you try a few configurations like configure backstage with GitHub or GitLab. The next step is building. Let's say there is some requirement for which backstage is not providing the plugin or you want to extend backstage there like we had for Matomo. So you can build your own plugins. So that is just a small feature where you just try out if backstage is really working for you and if it is the solution you are looking for. If it works for you then the last step is spread the word. Evangelize your adoption plan and extension. So we are welcoming contributors for Janus IDP. You can scan the QR code which is shown on the slide to join this Janus IDP Slack community. We are open for question and answer. Can you onboard an existing project to the next stage? Yes. Yes, I have to just add a YML file your software descriptor basically in your existing project. Backstage is able to track from the things from the writer that point. There is a VS code extension is also available. I think that's created by the Spotify. With that extension you will be able to create the template formatting. You don't worry about other technicalities. You can simply onboard the software with that. Yes. For each of those clients beneficial for organization but why it's beneficial for developers to contribute? So as a developer... I'm sorry just stepping, can you answer the question for the stage? Sure. The question is how backstage is beneficial for developers? So as a developer you are a part of an organization and like at Spotify they have a thousand plus micro services. So but it's shipped as a single product. So we as a developers we need to collaborate with multiple teams. Like frontend team needs to collaborate with backend. Backend team might need to collaborate with any another service. So every time you can't go looking for who is the owner for this application? What is their API? Like are they providing any swagger documentation? So for all of those things, backstage is providing a single pane of glass be it for developers, be it for managers or for non-technical folks? Do I have any other questions? Yes. You mentioned about application templates, right? Like you are looking for. Yes. So as one of the best practices of like in the game of Kubernetes is like implementing maybe like our revenue controls, who has the limits. So how much money do you have? Is it possible to put checks inside those main banks? Yes. So we are asking that you're asking that can we put the custom elements inside a code repository, right? Yes. Yes. This is completely flexible. So the things which is built on the backstage is in the plugin concept. Even if you feel so like so it is based on the plugin thing, it is completely customizable for in the case of software template, you can set you can ask for this check. This is a custom built form actually based on the questions which you predefined in your the Kubernetes descriptor file object descriptor files. It is a YML file. So the references of this content over the slide and the things are will be taken from the backstage websites as well as the HANA side pages as the credits.