 The second session of the day with Jay Kumar, who's going to talk with us about boosting productivity of your engineering team with developer portals. Just a few reminders on logistics. Any questions you have throughout the day, please feel free to post them into the comments section here of the running chat. And all these sessions will be recorded, or are being recorded, and will be posted up to the Red Hat Developer YouTube channel. Probably take a couple of weeks to get them up there, but they will be there so that you can go back and watch this one in any of the other sessions that you might be interested in. With that, I'll turn it over to Jay, and thanks for joining. Thanks a lot, Mike. So hello, everyone. My name is Jevin, and I'm really excited to be here today in DevNation, modern app dev, and I'm working as an associate manager in Red Hat Developer Group. So today, we'll be talking about how to boost productivity of engineering team with developer portals. So let's get started. So, I mean, pretty much most of us would be developer, or would have been developer at some point in time in their career, right? So all of us know that how the landscape changed, like in the last five years, or like 10 years, or in a decade basically. So earlier, we were much into our cell, where we used to bother about just writing code without having to worry about all the surroundings, the toolings, or the frameworks available, or they were not there. But with cloud development coming in, and in current era, with abundance of frameworks or tools around us. I mean, as a developer, we are spoiled or pampered, and at the same time, we get overwhelmed as well. Okay, what is the framework to choose from? What is the version we need to use? Does it have any compliance issue? Does it have any security vulnerability? What are the toolings I need to use for my CI CD, for monitoring, and things like that? And it number goes on. So for a developer, it adds a lot of stress, and thus reduces productivity as well. On top of that, the learning curve doesn't stop, right? I mean, the technology is changing every day, and we have to keep up with that. And we never work in isolation. We always work in the kind of product or services where we have a lot of dependencies. We need to be within our org or outside our org. And it's very difficult to nail down, okay, what all dependencies do we have, who is the owner for this, or how to get rectified if some issues happen? And to add to that, the documentation, that's another pain. Documentations are either not there, or they are scattered all across, right? So that makes it pretty hard. So you are seeing some numbers in my slide. So that is from the productivity survey done by Salesforce year back. So these numbers talks about these pain points. It happens due to increasing workload, demand from other teams, could be due to the pressure of reducing transformation and all learning new skills or adopting ourselves to that. And 76% the majority says that cognitive load is so high due to these things that it impacts the productivity. So that was about the problem statement. And now we'll see how developer portals can help us or like engineers or developers to overcome this challenges. So in today's agenda, I kept it pretty light. We'll be talking about what developer portals are, like IDP, internal developer portal. And then we'll be talking about backstage, what it is, and we'll then dive into that developer hub. So without further ado, let's get started with IDPs. So what is internal developer portal? Basically, internal developer portal as the name says internal, it's internal to a particular organization or a team. And it is built by specific platform team. So what platform team does or whose platform team to set that boundary, let me try to explain. So basically I'll be using two personas over here. Platform team is the one who owns or maintains this kind of developer platform or portal and that's the product for them. So they consistently work on it to evolve this particular portal so that it serves the developers. So it is meant to serve a developer. How it will serve a developer? It will work as a self-service tool where a developer can come in with their request and try to do the things on their own without having to wait or following on a lot of tickets or the processes around it. It also helps developers with providing, how to call it, a guided or like a guardless kind of thing where if they want to set up application or they can quickly get to know what are the toolings my organization supports which I need to follow on and things like that. So this is how IDP makes life of developers easier but it's not easy to maintain and build. That's how it adds burden to platform engineering team as well who owns this. And over time, the complexity doesn't reduce, it increases with new tools and text coming in every time you need to keep on evolving this. So it just adds a neat point for both the personas over here. So let's try to see what is the gap in building IDP. So as I said, building IDP is not an easy thing and it requires a lot of effort and upskilling and that is what exactly a Spotify have realized. So backstage.io has come from Spotify. They were building this Docker portal internally. So many of your organization, wherever you are working on, you would have sense or have some format of Docker portal or might not be, but this is what Spotify felt as they were scaling or growing. Okay, there's a need to have a portal, a common portal and they worked on it and then soon realized it's not easy to keep up with it. Unless we get the whole community or the ecosystem around it to come and build and scale these particular portals. So that's how backstage was donated to the Alternative Computing Foundation, CNCF and there are different organizations or communities working towards evolving this. So the main goal of backstage is basically allowing developers to focus on what they want to do, that is coding rather than navigating to all the tools and technologies and thus helping to improve the developer productivity. So that was about backstage. And in the next slide you can see there are a lot of adopters already for backstage. I'm just taking some of these over here and this particular slide. So let's go to next slide and try to understand what is Red Hat Developer Hub. So Red Hat Developer Hub is an enterprise ADP and it targets to empower engineering to deliver business value faster. So it helps in four different ways. It provides a single pane of glass to increase the productivity. So what I mean by single pane of glass. So within an organization, no matter what service, toolings, or applications you guys are working on, everything will be available at a single place where you get to access not just this particular services because you can get access to all the dependencies. This particular services has the documentation. If you are building APIs, you can see the definition of these things. You can see your workload, you can see their health status, et cetera. And it also provides self-service guidance which we'll be talking in the next slide in a bit more detail. So these are basically how to call it. I will call it golden part templates where you get a predefined curated list of templates by your organization, which will help to scale or deploy application pretty fast. And next thing best practices with the tabs on automation and real-time viewer application or infrastructure health and security. So this is what it provides. And as you can see in the diagram below, developer hub primarily has three components. Software catalog is one of these things and it serves as a single pane of class. Then we have software templates which is talked about the guard rails and then we have plugins. So there are, plugins is what makes it, how to call it, more flexible where any organization or any user can add depending on their need. And there's a whole community to support this plugin system. So I just, I have listed like six of the plugins over here just to highlight some of these like one is like key clock, with R2CD second one, pipelines with Tecton if they're using Tecton. It also has application topology for Kubernetes. So if you guys would have used OpenFift, you'd remember topology view. So you can get access to that right in the portal. We also have OCM that is multi-questor view. And we also have a container image to Falkway. So these are some of the examples and we will be talking about each of these things in detail in the subsequent slides. And RHTX integrates with industry standards and technologies through broad ecosystem with multiple deployers, Jenkins, and many more. And it is based on backstage, that's up steam for us. And it works or provides consistent developer experience across different environments no matter where you deploy it or post it. So let's try to understand each of these in detail now. So what is software catalog? So as I said, software catalog provides single pane of glass of all the services, APIs entities right in front of you. It primarily helps to enable two main use cases. One thing is easier maintainability. How to use the maintainability? By that I mean, any team can get access to all the toolings or the product services they're building right in the place, that's easier to maintain and get a glance of it in the Singapore team. And at the same time, it makes things discoverable. So say you're working on a particular product and there could be different teams building something in similar flavors. Many times this gets hidden or gets often or you don't have visibility on those teams, right? So this adds difficulty factor to it as well. So this catalog can be built or created through the YAML file storage structure kind of thing. If you guys are into Kubernetes or open security you would remember YAML, I'll be showing it later. So it's pretty standard, you can define the entity, okay, what is the type, who is the owner and things like that and it will also open to the backstage. So that is about software catalog. So next is software template. The software templates are the best practices or the guardrails provided for any developers out there by the platform team. So it helps in creating new resources. So if you want to onboard any application website or services, you can use these to create these resources. It basically has a skeleton which tries to generate those applications for you. It takes you some configurations about your Git provider, we had GitLab, Advocate, or whatever it is and it tries to push this code, step-by-step code into the Git repository with configuration configuring the CI-CD tools of your choice. But again, it depends on the template which is chosen by the developer. And it's not just that, I mean, how to call it? Over the years, organization work to automate a lot of things, right? So some of these automations can be leveraged again as part of software templates. So once it is built, it can be harvested on for a long time. So software templates, basically, again, universe developers to focus more on creating solutions rather than spending time on following up or filing tickets. So let's see. So in this particular G, if you can see, these are the templates. So I'll be choosing a cloud platform. You need to provide some basic information about what is already preferred. Provide the registry, say Quay, and next step, provide the GitLab instance here. You can review it. OK, great. I'll just hit on create. So it goes through a few steps like publishing, registering, then adding deployment resources, and creating ROCD instances. As you could see over here, pretty quickly, you get to deploy the application and see it in overview. So that is about software template. Next, we'll see plugins. So basically, plugins add a different functionality or different features to the existing backstage instance. And these plugins are not limited. There is a whole community around it trying to build depending on their use cases. And you can leverage or they get benefit from all of these plugins out there. To list a few over here, there are 150 plugins in different areas like SCM, CI-CD, monitoring, ISO tracking, code quality, et cetera. So I'll just click on this particular link where you can see the list of plugins over here. So there are different plugins for three scale, for analytics module, for API docs, and the list goes on. So I'll go back to my slide again and let's try to dig deeper into the plugins. So if you guys have ever used backstage or stored a bit, you would have noticed that before version 1.18, to add a plugin, we need to follow some steps. That is like installation of plugin, configuration of plugin, and then configure backstage, then rebuild the whole thing and redeploy for a plugin to be added. And then it's ready to be used by anyone. After v.1.18, the process got a bit simplified. You have to install the plugin still and then do a declarative plugin integration. You still need to rebuild and redeploy. With dynamic plugin coming into the play, which is contributed by Red Hat again, it brings in the ability to add the plugin without having to rebuild or redeploy. Basically, you just need to provide some contribution and restart app. And that's all it needs. So that is about the plugins. I'll be moving to the next thing. That is the demo. So let me go to the demo. So this is the instance for Radowlapahab, which I have over here. And as you can see, this is the landing page. So in the landing page, you get option to search. So search is basically a search across back to instance, need a documentation or code or whatever it is. You can also use search from here. You can just search for backstage and it shows you all the listing over here. So with quick search, you can get to find the information what you're looking for. And it also has some quick access links depending on the organization. Say in the community, it has the website, blog, Slack, YouTube, or whatever. It has developer tooling supported by the organizations. It has CI CD tools, which you can learn more about. It has the clusters, the monitoring tools and the security tools over here. And then you can also start from the entities. Okay, I didn't just talk about entities. So what is that? So let me take you guys to the catalog. So this is the software catalog, what I spoke about earlier, where you can see all the applications right in a place. So if you see, there's different kinds over here, like API, component, group, users, everything. You get to see all the resources at a place and you can filter it based on, again, different categories depending on the kind. And you can start it if you are going to something very frequently or if something is owned by you, it will show up in the owned section. And you can also filter by the owner. So this adds a lot of benefit when you are searching through something. So let me try to, so one other example. So this is the backstage showcase application. I'll try to click on it and let's see what all we have to do over here. So as you can see backstage showcase, once I click, it shows me the overview. The overview of the website of my particular application and the blog or Slack and the GitHub source code repo, along with some information about my ARCO CD. This application uses CD, I mean, ARCO CD for deploying, for the part of CD for deploying. The compliance report, the GitHub stats, and many more. And all of these cards, what you are seeing is not just it, it is extensible, again, with plugins. So let me go to topology view and we'll get to see all the workloads running or powering this particular showcase. So as you can see, it's being listed over here. You can see the number of podcasts with one click and if you click on any of these, you get to see the details about the name, the labels, and you can, if you go to resources, you get to see the code information. It is running the service. If you click on view logs, you get to see the logs. You can download it or, so all the information right in the portal without you need to go someplace else. And if you click on the issues, it basically lists all the open issues in this particular repository. So as you get to see, there are like 74 issues over here. You can read through it or if you click on the comments, you can directly engage into GitHub. So I'll come back to this and this is powered by GitHub plugin. And you can also see the pull request or the merge requests. So currently there are like five pull requests open. If you click on any of these things, you get to see the descriptions. So what is this doing? And a lot more filtering based on closed or allow all the different states. That is about the GitHub source code control. Now I'll go to the CI tools. So in CI, this is using GitHub actions. So you get to see all the access being triggered over here. All the workflows, you can even the workflow. If you click on any of these, you get to see the branch, the masses, the commit ID and all the jobs, which has been run along with the job log. And again, just to repeat everything what you see, these are powered by plugins. So it's not just GitHub, it could be GitLab or any other provider or anything you choose to add. So in city section, you get to see the August cities, industry, the author, the message, revisions, et cetera. And if you want to dig deeper and look at the YAMLs and things like that, you can always use Kubernetes plugin which has a lot of information sewn over here, which you can click on, take a look at the YAML view. So that is about workloads again and image registry. So in this case, I was pushing the image to query. So you can see the vulnerabilities associated or that all the image tags over here. For example, for this particular tag, there is a security scan, it says hi. If I click on this, it shows me the advisory with the severity and the click, you can get to know more about the particular CV. You can read about it. So that's great. I get to see a lot of information right in the portal. And if you click on dependencies, as talking about in real-world scenario where your application is not dependent on just your thing, but many other things. So this particular section shows you all the dependencies the particular application has. If you click on the graph view, it shows you the graphical representation. Okay, who is the owner, whom to contact to and which system it is part of and what all it depends on. It depends on key clock, meetups of visibility, I will see the et cetera. And you can filter it and all those things you can perform in this particular view. So that was about the catalog and what information you can see into the catalog. So just to show you that if you want to interested in, so, okay, I spoke about YAML file. So if you click on the view, you'll get to see something similar, I mean, how it looks like. So you have to define the API version, the kind, the name, the component, and these annotations which power different plugins along with the spec, which says, okay, what is this type? What is the lifecycle system owner, et cetera? So that was about the catalog. And if you're working on API, how does it look like? Let me just open one. You can see pit store over here. So when you're working on API, this view is pretty similar what we're discussing the last time. In definition, you can see the swagger right into the portal where you can perform, get post, et cetera. You can test your things and you're good to go. So that is about the APIs. I'll go back to the learning path. So learning path is one of the important thing which we have, right? There's one of the gap where there are different toolings or different text tags growing and depending on the all both of it varies what they want to use. So this learning path is like curated set of tutorials kind of thing or the elements kind of integration where you get to see all the things which you need to learn or you can put it pretty quickly. So for example, if you're looking for deploying with corpus, you can click on this and it takes you to respective location and you can go through the courses and try to learn more or improve the knowledge. So that is about the learning path. Let's let me try to talk about software templates. This is what I spoke about the software templates. So there is a different kind of templates and these all will be curated based on the organization again. You can see as we have some Ansible job we have Argo CD which you can add to the existing project or you can create a brand new project. So whatever you choose to, you can perform over here. So just to give you example again, say if I click on this, I can just provide my GitHub or and I'll say test console, my test my node app, it lists all the users. So my user ID is in visible J over here. The system, if you click on next step, ask you what is the fear tool you'd like to use GitHub Action or Tecron and depending on this, the option changes. Say GitHub Action, if you click on next step, it gives you the summary. You can go back, modify it or you can hit create. So once you create it, it will be listed in the catalog view again. So these are the different options with which you can try out these things, software templates. And next I would like to show you the clusters tab which is powered by OCM plugin. So if you click on the clusters, you get to see all the clusters which have been configured through this. Like one is Dennis, which is in ready state and one is not ready state. Both are in AWS and one has the upgrade available, number of nodes. So if you click on this, you can put the drill down and you get to see all the useful links of basically whatever you need to get access to it. You can go to the console, you can go to the customer manager. You get to see the availability in the CPU course, the memory size, number of parts and cluster information also over here. So as I said, this is not just it. All these capabilities can be further enhanced depending on the need with the power of plugins. So there's something called settings where it shows the user who is logged in. If you like live theme or dark theme, you can change the theme accordingly and a different authentication provider. Currently I have configured GitHub. So you're seeing GitHub configuration being done over here, but it could be anything. So that is all I think pretty much which I wanted to show you guys right into the developer portal and how it makes your life easier. So just to summarize, we spoke about three things. One thing is catalog, where you get to see all the information, all the applications at a glance. Then we spoke about different plugins, which is basically enabling the developers to get all the information or see everything right there without having to worry about the Netflix. They just need to have a working knowledge if they're interested on it. Or else everything can be configured with help of software templates, which are available. And all this list can be released. And then we have a learning path and the information in the clusters. And what mentioning, I mean the plugins, which I spoke about. So all of these plugins can be added depending on the need or use cases the organization has and the whole developer community can benefit from it. So I'll go back to my question. I think that's all I wanted to showcase and I'll go back to my slides. So I think that's all I had from my side to say. Now I'll be happy to take any questions if there any. Thanks, Jay for a great presentation. There is one question in the chat here. Can it run in a Docker container and what are the resource requirements to deploy? So, yes. So basically to run the whole backstage instance, right? You can run it in any way. So there is already a repo, I mean, for the basically backstage upstream, you can use that or you can use the JNS showcase which are made of stream and deploy it. For this deployment, what we are using is basically HelmTech. HelmTech is also possible where you can just add the Helm repository and follow some steps, provide some configurations and it's up and running. Does that answer your question? I'm not sure that question in the, it was from Himanshu Gupta in the chat there. So if that didn't answer the question, feel free to follow up and then we can connect with Jay to clarify. Likewise, I know you had a question here regarding the cost of that. That's something that probably not really for this team to address but for the Red Hat Sales team to handle so we can be able to certainly have to connect out there. Great, well, with that, certainly Jay, appreciate your time and presentation today. Everyone joining, we're going to, I'll stop the stream here momentarily as we queue up for our next session. The next session coming up at the bottom of the hour here is, our next one, is Hunting Down the Monsters Hidden in Your Software Supply Chain by Hugo Guerrero. So I look forward to hearing that. And again, as a reminder, these will be, all these sessions will be uploaded to the Red Hat Developer YouTube channel, probably a couple of weeks with the holiday pending it might be into January before they're posted, I'm not 100% sure, but feel free to certainly have an opportunity to go back and watch this and any of the other sessions you may have missed. So look forward to seeing you hang around here or pop over to one of the other stages for some of the other tracks and we'll be back shortly. Thanks, Jack. Thank you.