 Hi everybody. Welcome to the DevNation Tech Talk. This month I'm going to be talking about Red Hat developer hub. It's actually a really cool thing to talk about at the moment because everyone's going nuts on backstage. So what I'm going to do is I'm going to do a presentation which explains the ins and outs of IDPs, what backstage is, what Red Hat developer is on top of that, what it adds to it in terms of the things called plugins. And then I've got a nice little demo to show you how to actually play with it. We've also got a way in which you can actually start to play with Red Hat developer hub right now for free. And I'll explain how you do that at the end. It's to do with actually logging on to the sandbox and doing an installation of the developer hub onto the developer sandbox. But anyway, what I'll do is I'll start with the slides and then I'd say if you've got any questions while the talk is going on, please feel free to put them in the chat and I'll address them as I see them. So what we're going to cover today is basically why we need what's called an IDP. It's all about the fact that developers' lives are hard. And to give you a tiny bit of background, I worked for Red Hat. I'm currently a developer advocate. For 10 years before that I was a solution architect working with the various customers in the UK. But before that, I used to actually work for a living. And I was a software developer in the UK government space for a long, long time. And I used to have a lot of problems as a developer, not in terms of developing software, but just in getting used to the things that were around me, the tools, the frameworks, all the wasted time you had with building boilerplate code and being wound onto projects and stuff like that. And the whole goal behind the backstage, the Red Hat developer hub and the context of an IDP is to try and solve those problems. So we'll be covering all these things in the slide deck today. I normally go through them, but it makes more sense just to actually talk to them as we get to them. So the first thing I want to talk about is the life of Dev being hard. And I mean, there's too much pressure, especially nowadays. There are too many languages, too many frameworks, too many different ways of doing things. And a developer wants to develop. We're creators. We like writing code. We like solving problems. But the amount of friction we get from actually dealing with the tools and the sheer volume of tools nowadays is making it too hard. Now, there's a technical term for this and it's called cognitive load. It's the amount of effort your brain has to use to actually deal with these things that actually add nothing in context to the software you're writing. And it all comes down to the fact that technology has become so varied and complex that it's hard to just write that code. I say, if you're thinking of your frameworks, your boilerplate, the patches, the environment, your heart, you're very hard pressed to find brain space to think about efficient and elegant ways to actually write the source code itself. And the goal behind this, the backstage, the Red Hat developer hub and the whole concept of IDP is to reduce the effort and unnecessary thought processes you need when writing code. And that's the simple statement of it. That's what it's designed to do. I say, in the old days, I used to talk to customers about what we call the 70-30 problem. And the 70-30 problem is, you're paying for a developer to write code. And on average, back in the day, you'd spend 30% of your time as a developer actually writing code. And 70% would be installing frameworks, installing libraries, setting up the machines you were working on, and writing boilerplate code. And you would spend so much time burning that kind of effort and not actually writing code. And it was accepted that there was an overhead for developers. But it takes a toll on you as a developer because you're spending so much time concentrating on other things. So the solution to this is something called an internal developer platform. And an IDP is effectively built by a platform team to enable developer self-service. And that's quite a broad statement about that kind of covers it. And it provides, amongst other things, a single point of entry for a developer that has all the tools, guides, documentation, and access to the environment that a developer needs to do their job. And it also supports something called software templates, which are a type of pipeline for guiding the developer through the process of setting up to start writing software. And it also produces a simple and easy to use with less cognitive load mechanism for producing software. And those are the goals behind the IDP. Basically, put it simply, an IDP allows you to open a browser, go to a portal, and everything you need as a developer is there at your fingertips. All the kind of having to have separate tabs for Google, separate tabs for your OpenShift interface, your Kubernetes interface, separate tabs for Sonicube, and all these kind of things disappear. You have a single portal of control and everything you need as a developer is in there. So why do we need an IDP? Well, we need an IDP because organizations are different. You know, you can't come up with a single solution to this. You know, whilst reducing a developer's cognitive load, you can have an IDP that mandates an approach. It can't be too opinionated. Because when you're opinionated on what a developer can do, you're limiting what a developer can do. And every organization has subtly different ways of doing things. You have different mandates on the technology they want to use, the approaches they do to actually doing this, the projects, the whole thing. And the concept of a completely configurable IDP is a perfect solution for both problems. With a perfectly configurable IDP, you've got the ability to produce a single point of contact for the developer, but you've got a configuration that allows the organization to produce the tools that are particular to them for the developer to use. And it's all about easing the developers into it. Yeah, when you start on a new team or a new project, there's always that horrible time when you're trying to learn where things are or what you have to do and where JIRA is and where your swim lane tools are and all that kind of stuff. It's not a fiddly couple of weeks to get to that position where you can start to write decent code. And often these processes within an organization are similar to other teams and other projects, yet you're hitting the same problems every time you start a project or join a new team. And a good IDP will provide a configurable mechanism for automating that process. And in the case of Red Hat developer Havin backstage, these are what we call software templates and we'll go into those in depth later. But before we talk about the whole concept of the IDP, I want to very quickly introduce what we call the inner and outer loops. And there's a nice visual overview here. I mean, this is a good visual representation of the theory behind the current state of the DevOps situation. You've got what's called the inner loop, which is the actions of the developer. And the developer just focuses on this. They code, they build, they debug, they push, they repeat. You know, your job is to write code, to test code, to get code to a point where it can be delivered. And the outer loop is the options of the platform engineer and the ops person. And that's driven by the arrival of source code. And it's the review, the build, the check, the test deploy, or triggered by the push action within the inner loop itself. Now, the IDP, the Red Hat developer Havin, the backstage is designed to cater for the inner loop, giving the developer all the tools they need to be able to work consistently in that inner loop. And it's what a developer actually does within the inner loop. So the inner loop concept is a nice abstraction, the process of writing and deploying software. And the inner loop is the action of the developer, code, build, test, commit, whereas the outer loop is the automated action of the ops engine, build, scan, test, and deploy. And the crossover point, as I said, is the submit action of the code delivery. So we're going to give a quick introduction to backstage here. Now backstage is incredibly trendy at the moment, everyone's talking about backstage. Now backstage is an open source project released to the community by Spotify. And to put it simply, put it incredibly simply, it's a database of manifests and catalog entries and a mechanism to build a portal for a developer. At the end of the day, backstage is a web app. It's a complicated web app, but its output is a web page, a web output is a portal that actually interacts with the developer itself. And the strength of backstage is its concept of what it calls plugins. And these plugins, which actually plug directly into the source code of the web app itself, allow for the extended visual and programmatic components. What I mean by that is that when you install a plugin into backstage, it provides additional visualization components that can be served to the user as part of the portal. And it also provides a number of actions that can be consumed to call external processes. And this will make a lot more sense when you understand other covers what backstage actually is. So what's the downside of backstage? Well, backstage is a clever and elegant framework. And it's a framework. As such, when you install backstage, it gives you the scaffolding for setting up the ability to create portals. But there's no real content as such when you actually install the base backstage. It's got fantastic extensibility. But if you install backstage and go to the portal it creates, it's generic. There's almost no content in it whatsoever. It's just the framework. And as such, it requires ops staff to create manifest templates, plugins to actually configure it specifically for the end organization. And that goes back to what we were talking about with an organization needing it to be specialized for the way in which their developers work. And also being open source, and we love open source, but open source is community supported. And this thing can be a beast to install. It's easy to install out of the box, compile the code, run the code, up you go, you get yourself a little portal. But the minute you start to include things like authorization, like plugins, it becomes a little bit more complicated. And it's quite difficult to debug. So when talking to customers that now we're using backstage, it is that situation of getting backstage up and running that is the issue and getting it running in such a way that it's configured for the way the developers want to use it. So what is Red Hat Developer Hub? So Red Hat Developer Hub is a productized version of backstage. We're going to be honest here. Red Hat Developer Hub is backstage. But instead of actually downloading source code, what you do with the Red Hat Developer Hub is you download a pre-built and a pre-opinionated image. Now, what I mean by pre-opinionated is it's got a lot of stuff pre-installed. It's got a lot of configuration set up. It's still got the extensibility. It's still got the ability to add plugins and do all those things. But it gives you a much quicker start point. You know, if you're installing backstage, you download the source code. You do a Yarn install. You then run it and you get this portal out of it. When you're using Red Hat Developer Hub, you get access to a pre-built image. You just execute that image as a container. And you can run it as a container on RHEL. You can run it as a pod within OpenShift for Kubernetes. And it's this concept of it being a pre-built version of backstage. And it also has a number of supported plugins which extend the visualization and the functionality. But they're pre-installed. So out of the box you get a certain number of plugins already installed so you don't have to wire them in yourself. And that's the beauty of it. As a question of the thing, backstage should be used to orchestrate self-service deployments of infrastructure as code. Absolutely. And I'll get onto how it does that in a second. In fact, I'll do it now very, very quickly. One of the plugins that come out of the box with Red Hat Developer Hub is a plugin into Argo CD. So if you're doing, for example, Kubernetes distributions or OpenShift distributions, you can actually use the Red Hat Developer Hub to build your manifest and then control the placement of those manifest on target clusters. So yeah, but what you've got to think about with backstage and Red Hat Developer Hub is it's a framework. Everything you want to do, things like Git, things like interacting with test engines, interacting with Kubernetes, interacting with Ansible, you have to do through a plugin. There's nothing in the base backstage. There are some initial plugins they provide for talking to GitHub and GitLab and all those kind of things. But they have to be installed. So all this functionality that you want to give a developer so a developer can interact with it, you have to actually install on top of backstage. With Red Hat Developer Hub, there's a huge amount that's pre-installed and the ability to actually add additional plugins through something called dynamic plugins makes it much easier. There's a caveat with direct plugins, but we'll get onto that when we talk about plugins. It gives a single pane of glass for developers that anyone's used backstage has seen a screen very similar to this. So the Red Hat Developer Hub is an opinionated version of the backstage portal. And you'll see on the left-hand side it has a navigation panel. That navigation panel is extensible, but there's a number of core components. We'll talk about those when we get into the Red Hat Developer Hub. It also allows you to extend it from a developer perspective. So if you've got the correct R back, you can add objects to it. And we'll talk about what underpins it in a second, but put simply everything within backstage and OpenShift works in the same way as Kubernetes. It's based on an object model, and that object is a declarative object that's defined in YAML. Now the nice thing about the interface and the portal itself is it encourages extensibility. So if you've got, let's say, an API you want to add, if you've got the API definition defined in YAML, which is understood by Red Hat Developer Hub or backstage, you can just add it as a component of the hub. And what it does is it actually processes it, but it brings in the swagger so you can see the API definitions and where you go. But to understand how backstage and Red Hat Developer Hub works, you've got to understand that there are two views into this product. As a framework, both backstage and Red Hat Developer Hub, which of course is built entirely on backstage, and we need to keep stressing that. We're doing a lot of extensions to backstage in terms of role-based access control and much better authentication and authorization. We're also doing the dynamic plugins. Now those things, changes we've made are being fed back in to the upstream backstage. So you can go and install backstage once we actually committed this to the upstream and you'll get those features. So we're being very open source about this, but at the end of the day, Red Hat Developer Hub is based 100% on backstage. And they are, to put it simply, their web applications. And they work by serving a portal to an end user that is based entirely on configuration of the framework at the server. And this creates two distinct percent of the use Red Hat Developer Hub stroke backstage. The first one is the maintainer. And that's the person who configures the server side Red Hat Developer Hub or the server side backstage. They're the person who actually pre-fills the templates, installs the plugins, sets up the learning paths, sets up the technology radar, sets up all those things that'll actually be portrayed and pushed to the end user as part of the portal. And then you have the consumer, and that's people like me, the developer, who actually work with the provided portal that it gives. So when I log on to Developer Hub, when you see the demo, I'll show you it from a user perspective. This is what you see from a user perspective. This is how you interact with it, this is what it does. But there are two distinct personas and they've got different skill sets. The maintainer needs to know how the engine works, how we can add things to the engine, how to track objects within the engine. And the consumer needs to be a developer, and that's the key thing about this. The portal that's provided is meant to ease the developer's access into the software, into the writing of the software itself. So it's a very, very nice way that you don't have to have any knowledge of how Red Hat Developer Hub or backstage works in order to consume the portal and use it from a developer perspective. So we'll talk about the framework of Red Hat Developer Hub now. So we're going to get down into the gritty, what actually underpins the concept of Red Hat Developer Hub. And it's based around an object model, very similar to Kubernetes. And I said the object model drives the capabilities of the provided portal. So for instance, there's a database that backpins backstage, backpins Red Hat Developer Hub. When you install Red Hat Developer Hub on let's say OpenShift, you use a Helm chart which will install a Postgres database and the application itself. The application itself uses the database as the truth. Everything in the database is actually rendered within the portal. So if you can think of the application as a sausage machine that's consuming the objects that define the database and providing the portal. And these objects represent identically the way that we do it with Kubernetes, using a declarative YAML format. And you can probably see on the right-hand side I've got a template definition. It's a template object within the actual Red Hat Developer Hub. And the template defines things like parameters and the steps that are executed as part of the template. Interestingly enough, when we get onto templates in a second, when a template is actually embedded within the system, the end users can then instantiate it and by instantiating it, what the Red Hat Developer Hub does is it processes the template and generates a number of wizards to actually prompt for all the parameters and steps, and then it executes the steps using actions that are defined in plugins. And those plugins provide external connectivity. So we've talked about Red Hat Developer Hub and Backstage being a framework that generates a web page. There are plugins for the actual Red Hat Developer Hub and for Backstage that do GitHub, and that provides GitHub Actions. Why do I say GitHub Actions? It's like GitHub colon fetch or GitHub colon clone. And the visibility of those actions within the template calls the actual action in the plugin. And you can see if you look very, very closely there's a fetch colon template action in here and one of the steps. That fetch colon template is one of the actions of the internal plugins of Red Hat Developer Hub that actually goes and gets the actual template code itself. You give it a URL and you give it some values to embed in it. So it's that kind of fantastic extensibility where you can add plugins that provide actions and then write templates that a developer can use which actually uses those actions. It's a very extensible system. The core component in both Backstage and the Red Hat Developer Hub IDPs is the catalog. And the catalog basically is the central store that the user sees of the active objects within the Red Hat Developer Hub application. And it close all the templates, components, resources, users, APIs. There's a level of R back on there in terms of controls and visibility and it's self-filling. So if you've got a certain type, for example, if you look at the pull down there, that was done on a Red Hat Developer Hub that had a huge amount of objects created within it. And you can see it as APIs, components, groups, locations, resource, system, templates and users. When you install, after this session, if you want to go and install the Helm template on the developer sandbox, you'll get a catalog that has two or three items because the base database only has locations and components in it. You can add yourself as a user of which point users become. But this catalog gives you visibility of all the objects within the system that you can see. And this is where you go after you've created things. This is where you go when you want to actually look in on the components that you've physically created within the Red Hat Developer Hub. So now about understanding plugins themselves. We've talked about the base framework. The plugins are the real power of the Red Hat Developer Hub and the real power backstage. By design, backstage is an extensible framework. As I said, out of the box, it's an empty framework, just maintaining the base objects that it actually provides. And the plugins provide backstage with the ability to extend the visualization of the IDP for the end consumer. And it does that using tabs. I'll talk about that in a second. And it provides executable external end points for inclusion in the templates. And those are actions that are provided by an external source like GitLab or let's say Kubernetes or OpenShift or Argo CD or Tecton or things like that. If you look on the right-hand side, that is a screenshot from Red Hat Developer Hub. And this is basically visualizing one of the components in the catalog. So I've gone into a template and I've created a component from the template. In reality, what that template did was it copied a Git repository into my Git repository. It built the appropriate pipelines and Argo CD manifests and it deployed that application into OpenShift. So basically, it used Argo CD to deploy a Tecton pipeline. That pipeline was executed and that generated the components of the application itself. What you're seeing on the right-hand side down, I'll show you this as part of the demo, as well as the tabs in the actual portal itself that are plugins. So we've got a plugin that comes in Red Hat Developer Hub that plugs into the topology of the target Kubernetes or the target OpenShift system. So this template actually creates components in an OpenShift cluster and then gives you the ability to actually drill down into those components through a topology page in the same way you would do as if you logged into the OpenShift user interface. The advantage with this is you're going to be able to do all of that in one portal. I can do all my creation. I can do my instantiation of my templates. I can look at APIs. I can go and read learning paths. I can generate documentation for my software, but I can also look at the software running in the OpenShift cluster and there are other plugins in there for Tecton so I can see the active pipelines that are executing on my cluster. There's an Argo CD plugin that allows us to develop a hub via the plugins that are provided. Now the good thing about this is that the RHDH Red Hat Developer Hub comes with a number of fully supported plugins and these wrap Red Hat technologies, they're core components that we brought out of other products that are directly useful to developers. Now the advantage of this is that they are fully supported out of the box. So for example, there are six currently and it's going to grow. There's a lot more in. There's stuff coming in terms of secure software chain. There's stuff coming in terms of S-bombs and all those kind of software material things. But at the moment when you ship you get a plugin for authentication authorization with key cloaks. That installs key cloak and allows you to interact directly with key cloak from within the developer hub itself. So if you're building an application that requires authorization, you can build the authorization components using the key cloak. You can connect that key cloak instance and authenticate. We've got GitOps with Rgo CD and that's a visualization panel from Red Hat Developer Hub that visualizes the application components from Rgo CD. For those of people who don't know what GitOps or Rgo CD is, it allows you to basically take a set of defined declarative YAML from a GitHub repository and push that to a target cluster, OpenShift cluster or Kubernetes cluster. The advantage of that is Rgo CD then sits there and watches the state of the objects it's created and the state of the Git repo. If the objects change let's say you've got an application that's defined to be 15 replicas and some developer logs onto the OpenShift cluster and lowers it to 14 or 13 or 12 Rgo CD will reset it to the value defined in the GitHub repo. If the GitHub repo changes let's say an admin comes along and wants redefine the deployment or redefine their number of replicas for the application. He can change the declarative YAML and push it into the Git repo. Rgo CD will instantly see the push into the Git repo, take the information and apply it. It's a compliance engine that makes sure that the application definition on the cluster always matches the definition of the Git repo. That plugin allows you to see that visualization within the developer hub and again this is what this is reducing is the cognitive overload of the developer having to leave this page to go into another system to understand the mechanics of the other system to find the components within the other system. It's designed to make it incredibly simple and easy to visualize all the components he needs and developer needs he or she needs to actually do their job. The third one is pipelines with Tecton. That works exactly the same way as the Rgo one. It provides visualization within the Red Hat developer hub portal of your active pipelines. So you can see the pipelines are in flight. You can see results of previous pipelines . You've also got the application topology for Kubernetes. You saw that in the screenshot and that's that topology vision of the application within a name space and that's got drill done as well. So you can click on the roundalls and it will bring up the pods. You can click on the pods you can click into the logs. As all the functionality you would normally have to leave your development environment leave your IDE and go into open shift or use OC as a command line to go and see but with this you just move to Red Hat developer hub portal itself. We've also got a visualization component for container image registry for key. So if you've got key locally or you're using the public key.io this gives you visibility of your images. So you can look at the tags, you can look at the history of the image as it was created. You can actually execute the builds on the key.io site to actually rebuild the Docker files to generate the images. And finally the nicest one in my opinion we got the multi cluster view. And what that allows you to do as a developer is get visibility of all the clusters you've got access to. So all the open shift clusters or Kubernetes clusters. So you can see the state of your application running on multiple clusters. You can see the state of the cluster itself. So this allows you to develop your software and all those kind of things. But it's not limited to those. There's a number of plugins that are already for backstage. Everyone's writing plugins because as I said backstage is a framework which allows for this level of extensibility. And because Red Hat Developer Hub is backstage, any plugin produced for backstage will run natively with Red Hat Developer Hub. And Red Hat Developer Hub will support dynamic additions of appropriately coded plugins. The problem at the moment is you have a plugin you want to add into your backstage instance. And it requires code changes in the actual backstage app to enable the actions that are offered by the plugin. So you have to stop your backstage instance, change the code or add additional code files, recompile it, rerun it and away you go. So it's down time to actually add a plugin. So what we've been developing is this concept called dynamic plugins. Now dynamic plugins work by having a generic handle within the backstage system which can handle the actions that are provided to it whilst it's running. So you can have it. The only caveat is you have to write the code for the plugin to match the parameter definitions or to match the the actual method definitions of the dynamic plugin way of doing things. But this means that people going forward can develop their plugins to be dynamic which means you can actually add them to a backstage system or the Red Hat Developer Hub system without having to take the system offline. But you can see on the left-hand side there we've got this concept of additional plugins from GitLab, from GitHub, from Sonocube, for testing, for Sneak, for code analysis, from IBM, for Watson X, for Tecton, for Dynatrace, Jira. So you can actually embed your Jira software in there. So, you know, you can have access to your Jira while you're doing your developments. Jenkins for builds and vault and things like that. And this isn't going to grow massively. So as I said backstage is incredibly popular at the moment. And so people are writing plugins left, right and center. We're going to talk about templates now. So we've talked about the framework. We've talked about the way it works. We've talked about the way the developer initially interacts with Red Hat Developer Hub. But we're now going to talk about software templates. And this is where it really comes into its own in terms of strength. So a template allows a creator to provide a set of executed instructions populated by parameters via a wizard which interact with core and plugin functionality. In English what you can do is you can chain together a number of tasks using plugins to scaffold things for users. And the majority of examples I've seen of this so I say for example we've got a template that we use for one of our demos and what it will do is it will create a Git repo in your own Git account. It will copy the base code in there. It will change some manifest codes for Argo CD. It will actually implement and deploy those applications to Argo CD. It will actually create the tecton pipeline objects within the target cluster and it will do a build. And the theory behind this is you've got let's say a new starter or someone joining a team or someone who wants to get a quick start on an existing project. You can write a template that pre-fills all the stuff they need. It gives them access to the original source code, builds an instance of the application, deploys an instance of the application. So all those things that the developer would have to do themselves to go through a set of phases external to their development to actually get, to actually do you can write as a template. The only limitation on the template is literally your imagination because you can write plugins to do external actions, you can add those plugins into the system and then you can write templates to use them. They work a little bit like pipelines but they're focused on execution functionality from within the core of the framework or externalised components via actions provided by plugins. They're very like pipelines but it's all to do with the actions themselves and it allows templates to be massively extensible and templates are the remit of the maintainers. Now there's a certain level of access that a developer has and I'll show you it on the demo that I show on the developer sandbox where I can import a template from somewhere else. I've got a template which I've taken from the backstage maintainers and I've changed it slightly and I can actually import that template as a user and when I import that template as a user it produces the cookie-cutter object for executing it. So once I've imported the template I can simply go to the create button on the developer hub and I'll be given access to that template. I can click on it it'll generate a wizard that generates input points for all the parameters that are required to execute the template and when I've entered all those parameters through the wizard I hit create and it executes the template and that's the beauty of it is that I can instance these things as a developer if I've got the rights to do it so as a developer I could write templates myself to ease consistent tasks I do or constant tasks I do that are always a pain to actually set up. I want to introduce the Red Hat developer hub user interface now again it's incredibly similar to backstage so it looks a lot like the IDP that's produced by backstage but it comes pre-opinionated so the pre-compiled Red Hat developer hub provides a standardized but configurable IDP UX it's that kickstart if you were starting with backstage you would start with the absolute basics and have to build everything yourself when you're starting with Red Hat developer hub it comes pre-built and it comes with a number of opinionated things that we think are a good start point for developers and it's based around a home page so every time you log on to the base application you'll give an access to a home page and this home page has a quick access set of links which are completely configurable and for example with this one here I've got access to developer tools I've got access to CI CD tools but you can have links to the chat facility for developers you can have links to IDEs which are very nice as well you can have links to let's say reference libraries and tools like that and it provides a left hand navigation panel with the core components from Red Hat developer hub they include the catalog we talked about before which is basically your visibility of all the active objects that are currently running within your developer hub it provides something called GPTs we now call them software templates they were originally called golden path templates via create, self documentation so there's something called docs which uses tech docs facility within the Red Hat developer hub backstage community and basically you write sort of markup in very similar to rebe.md so you use a gear hub to document objects which can be attached to other objects within the system so what this means is you could run your application you could define your API via an API object to publicize to other people in your organization what your API does and then you could document the code and the mechanisms of the code in a doc file that's attached to your component and that's automatically executed and provides another object within the developer hub so other people can have visibility of this self documentation you've done which tells how it was written and how it's actually provisioned so it's very very useful for that and it solves one of those major problems we've always had developers that there's 15 buckets of documentation everywhere this allows you to basically produce a single point of documentation shareable APIs so you've got the API objects that uses swagger so if you know how to write swagger or to export swagger you can create API objects based on that again I'll show you as part of the demo an example of this and it basically expands the swagger documentation and gives you a nice readable definition of all the APIs that are offered through the API objects that are instantiated and learning paths now learning paths are linked to useful archetypal articles on development so when you install Red Hat developer hub out of the box that learning paths entry is full of learning paths to the point of Red Hat developer website with loads of things about different use cases for what you can create talk about artificial intelligence all these kind of things that a developer might want to go and look at or actually have to refer to whilst they're developing their software and again it's through a single point and on the right hand side you have what's called your starred entity so any object you can find within the catalog you can apply a star to so if you find an API you're interested in you can star it if you find a template you know you're going to use 15 or 16 times within the organization you can star it and that gives you quick access directly to that component from the right hand panel it's kind of a shortcut it's kind of a star based shortcut menu for entities within the actual developer hub itself so I'm going to do a demo now or a number of demos I say if you've got any questions please feel free to put it in the chat and I will answer them as we go but what I'm going to show you basically is a number of instances of the Red Hat developer hub to show you different components of the stuff I've talked about but I'm going to focus primarily on an instance of Red Hat developer hub that you can install in 30 seconds using the developer sandbox for those who don't know what the developer sandbox is Red Hat Red Hat developer website has access to a hosted 4.14 OpenShift cluster and you can get on there using an account which you can create it's totally free, gives you 30 days of access to the latest version of OpenShift you're restricted to one project on namespace but we've got Helm Chart which allows you to install and execute the Red Hat developer hub and what I've done before this demo is actually set up an instance of the Red Hat developer hub running on sandbox and again it's totally free and there's no cost for this you can start to have a play with it and see what it does so first of all I'm going to show you what it looks like so I've installed the developer hub as exported by the instance I've got on the sandbox if you want to look very quickly at the OpenShift topology I've run the Helm Chart and the Helm Chart has installed a Postgres database and it's installed the developer hub itself this route here takes me to the developer hub and you can see it's saying welcome back because I've already been on here if I go to settings what I've done is I've actually linked this into GitHub so it uses my GitHub account as authentication and it also has access to my GitHub account so I can use the Red Hat developer hub using templates to provision GitHub repos and interact with GitHub repos what you can do as well is you can actually use GitHub org authentication so you can set up an org within GitHub and then grab members who are other GitHub users and then you can tie that authentication and authorization into Red Hat developer hub so it uses the org and a number of people actually working on the same software and the same repositories going back to the home page you'll see I've got a number of quick accesses these are completely configurable so we've got a base set that we think are reasonably useful things like monitoring tools things like security tools and they are completely configurable on an instance basis I could as the installer of this go into my installation change some configuration files and I could change the way this looks on the left hand side we've got the basic stuff you get out of the box you'll notice this is smaller than some of the other examples I've shown you and we've got the catalog and the catalog basically lists all of the objects that are currently within my visible instance of the Red Hat developer hub again this can be controlled by an R-back so you can control who can see what and you can see that I've got a Myangular app which is an instance that they are used to actually create an Angular app there's a learning path being published in the next couple of days on the Red Hat developer website that walks you through this I did a test with it just to see if it was working it works an absolute treat if I look at the kinds you can see I've got access to four kinds a location is an interesting object that's created as part of the backstage engine behind the scenes that's a temporal indicator of something that's been created within the system and you can see these locations actually refer to GitHub templates that I've actually installed or instances I've actually installed because I actually use a GitHub hosted YAML file to define my user so when this starts up when the system starts up it goes and pulls this YAML definition and the YAML definition for my user I'll show you very quickly is basically this one here and it basically creates a user entity, it creates an ownership entity as well these are internal entities internal objects that are used to tie things together so when I create something in the system it will be created using this so I can trace back objects that I've created but again it's a little bit under the covers there so pop out to the catalog templates are the interesting ones so the templates are the ones that actually define the steps that you can actually do things in an automated fashion we've talked about templates as part of the presentation I've already got one template installed on the system and if I pop very quickly to create you'll see that I've got this one template called the Angular app template it's got some tags to say give some information about it if I hit choose it will actually walk me through the parameters and then do all the things that are defined in that template and afterwards before we move on to the next part I'll show you what a template looks like the APIs are basically APIs I've got no APIs currently installed if I hit register existing API I can just point it at a piece of defined YAML from a github repo which defines the information about what my API exports and the swagger instructions for it and it will build a swagger API for it and produce that API object learning paths is links to a number again this can be opinionated so when you install you can change these but out of the box it lists to a number of useful articles currently on the Red Hat developer site to extend over time as we produce more and more articles that are relevant to what you do in Red Hat developer hub there'll be much more of these articles appearing directly from within the developer hub itself but now on to the cool bits I'm going to hit create so I've got one available template at the moment which is Angular template but what I want to do is I want to install a template I predefined so a template I built somewhere else and so if we go very quickly here I've got this thing called template test I lifted it from the backstage site so I took a copy of it and it's basically it's a template object so as we said it's a declarative API when you push this piece of YAML in the engine will read it as a template and create a template for it it's got a name of our HDH demo one it's got a title, it's got a description which is also the tags for it it's got a specification which is the owner which is service now if I scan down you'll see it's got parameters so there's a number of parameters it defines it defines name and owner and there's a type and whether it's needed and how the user interface responds to it when it's building the wizard and I've got a location as well if I scan down to the steps this is what the template actually does now if you remember when I was talking about the plugins the plugins export actions that you can consume as part of templates what this template does is this I have fetch base which is action fetch fetch a template and it looks in the code repo in a subdirectory for template and then basically it passes the parameters dot name and parameters dot owner so what this does is it creates a template using the information that's in that subdirectory with those parameters it then does fetch docs excuse me what that does fetch.plane is it will lift all the files that are currently in the point in the github repo I'm pointing at and it will actually tag that URL to them so it's bringing this over as well it will then do a publish to github so the template contents and the document contents will be written into the repo that I actually provide as one of the parameters so this published code on github action within the github plugin and what that does is it basically looks at the point in the file system it's working in which is this point where we're pushing things in the target path here and it will publish it directly to the github repo that you stated and you can do things like branches and all those kind of things I then got something called register which uses an action catalog register and what that does is it creates an entry in the catalog for this component so the component is going to create an object that it pulls from the template it's going to create some documents via a linkage I'll show you how those linkages work and then it's going to register that component and when it's done it's got a couple of outputs which actually produces as an end game for the template being executed in this case it gives you access to the repository that it's created because you know it builds the files and then it publishes them to the github repo and it gives you a linker to the catalog entry that it creates as part of the register so it's a very simple it's a very sort of pithy sort of template so what I'm going to do is actually register an existing component so I'm looking at my template page and I know I've got this template that I can use so I'll do register existing template and I give it the direct URL of where that template lives and I hit analyse and what it does is it says right what I'm going to do I've read that template definition I'm going to generate a location which is the temporal stamp of an object being created and I'm going to create you a template called red hat red rhdh demo one and I'll hit import and that's done that's finished so it's added a location into the catalog and it's added a new template now we can test that by going to the catalog looking at the components and looking at the templates and we've now got a new template called the red hat developer test scaffold template from backstage now if you remember when we went to create the first time we were given the angular app template as the template we could do if I now click on the create you'll see I've got access to this additional template which is the one we've actually brought in from the template I haven't done anything of any consequence yeah I just added that set of actions as a template that I can use as a developer so I'm going to go choose I'm going to create it and some names so I'll call it demo and I'll set myself as the owner and what this is doing is this is actually going through the template and generating a wizard for all of those parameters that it needs to execute the actual template itself I'm going to use github I'm going to use my github name which is Utherp0 which is the one I log on because I've actually set up a user which authenticates through github so that Utherp0 is my github username I'm logged on to the red hat developer hub as Utherp0 and repository let's say what was it February 22 February 22 demo as a repository name that repository does not exist in github at this point I go to next step and it tells me that it's going to create group default Utherp0 as the owner and this is going to be the repo URL when it actually does the does the action and I hit create so what it's doing now is it's executing those actions that are defined in the template and it's done it already it fetched the base documents it fetched the file contents it fetched the document contents I told you about it published them to github and it registered it and if you remember it had two outputs and the outputs were the repository that it creates and the catalog entry and if I click on repository fingers crossed it's created a Feb 22 demo repo for me in github and it's populated it with all the contents that were in the original directory that it pulled it from so there's a little bit of random text in there and some random source material as well and there's also a catalog info.yaml file now what that does is it actually creates a component and this is the register part of it so if we pop back here click on open in catalog you'll see we've now got a component called backstage docs there is no group default cncf because I haven't created that group but it's basically because the cncf actually created the original one but that template which was actually defined sorry that component which was defined in a piece of yaml had four links in it and there are links to backstage that I can now click on directly to the discord chat and go to the storybook if I go back to the catalog you'll now see I've got two components that I own one of those is the backstage docs one so you've seen what I've done I've used a template which is defined as yaml and I've used that template to create additional objects I've used that template to create an external git repo and I've used that template to create an object within the Red Hat developer hub system that I can actually interact with which is really really cool I'll give you another example of this my angular app which is the one again I haven't created a group so ignore that for now this one basically creates an angular app a git repo for you fills it with source code for the actual angular app itself but it creates a link in here to dev spaces so I'm running on sandbox and sandbox has got access to dev spaces which is an embedded IDE I can click on this from within the Red Hat developer hub and what it will do is it will take me on to the actual work spaces within sandbox itself to run my IDE so from within the actual Red Hat developer hub itself I can go into the actual source code and edit the source code, interact with the source code and push it back into the GitHub repo and things like that it's going to complain bitterly because I've got an existing workspace, I've done this already I've clicked on it to open the existing workspace and it will eventually take about 30 seconds or so but it will bring up the dev spaces dev spaces are full IDE for editing your code doing tests, actually playing with the code itself running within the browser running within the sandbox and I've got to that directly from a link that I've created as part of the template I did to create it within my Angular app now whilst that's working yeah it's working now, so it's giving me access to the source code I could change the source code I could commit the source code in here and I would see changes in the GitHub repo and all those kind of things again it's a pity example it shows the power of what you can actually link into the developer hub what I'm going to show you now is if I pop over to this one this is actually an instance of developer hub that we've been using for demos that's got a huge amount of components in it and I wanted to show you this because I did a demo using a template and what this template did was it it did a huge amount of things it created a GitHub repo, it used Argo CD to actually instance it in a tecton pipeline it used the tecton pipeline to build the application then it executed the application in the end of the OpenShift cluster so basically if I look for example in this company catalog for me and you'll see there's a number of components I previously created if I look at this one which is a demo I did for a customer if I look at the topology overview it will take me directly into the cluster so this is the application running on the cluster but I'm viewing it through the portal in the Red Hat Developer Hub I can also look at things like tecton so this is another one of the plugins we produce and this actually will take me and show me the status of the pipelines that I've actually executed and what's more I can click on the CI and it will give me a breakdown of the pipeline I used to do this now these are all through plugins this pipeline technology isn't in Red Hat Developer Hub the Kubernetes technology the OpenShift technology isn't in Red Hat Developer Hub but it's all brought into the portal I can interact directly with it as if it's part of a single component system and that's the power of it you give the developers a tool where they can just interact directly with everything they need in one place and that includes libraries and all those kind of things I want to show you something very quick on this as well one of my colleagues added an API so he was working on something to do for the generation so he actually created the software for it he set up the API object and he installed it so I could see it so I can click on this API here and basically it can give me the relations about who owns what components and where it's used within the Red Hat Developer Hub itself but if I click on the definition it will go and list all of the endpoints that I can call and I can expand it and look at it so it's done a kind of swag of viewpoint but it means that you can actually publish your own APIs within the Red Hat Developer Hub appropriately and that's one it's one of those lovely features that brings everything together I think I'm coming to the end of the demo I just want to quickly pop back over here a second to show you one more thing and that is so you're not limited to just creating templates and interacting with components it also has the capacity for building its own docs and also having website linkages so I've got for example some APIs, some YAML definitions for Red Hat Developer Hub that have a list of critical websites I need when I'm doing certain types of programming so I'll have one that has like the Quarkus website you know the Quarkus scaffolder links to some Red Hat Developer blogs on how I use Quarkus with land chain for J to write artificial intelligence so I can bring all those together in a single documentation object called a website object and I can put that into developer hub and then I can star it and I can get access from it immediately so I can be looking at my developer hub I can jump to my source code I can go to that helpful little website URL set and I can click on those to go and find more information so I was a very very quick introduction to what underpins backstage and what underpins Red Hat Developer Hub itself I just want to pop back onto the slides for a second because I've got a QR code here if you go to that QR code I'll leave it up for the rest of the session but if you point at that QR code it will take you to the Red Hat Developer website which has a number of useful articles free ebooks you can download including the first three chapters of a book on Red Hat Developer Hub it also gives you linkages into the sandbox and that sandbox is what I've actually been running that demo on I showed you the instantiation of the template and the actual execution of the components it's also got this learning path on it which you can go to and this learning path is something I wrote that was actually published on the day we released Red Hat Developer Hub and this walks you through very simply how to set up Developer Hub using the helm chart on the developer sandbox how to set up GitHub authentication and then to actually instantiate that template you saw me instantiating as part of the demo so as an endpoint if you're interested in anything after this with the Red Hat Developer Hub Red Hat Developer Hub stuff itself please feel free to go and have a look at it follow the links and read that learning path we've got another learning path coming imminently in the next couple of days and that one is going to do the Angular app that you saw the other example of and that one links into Dev Spaces so when that one is published you'll be able to install the Angular app you'll be able to have a play with the actual application to the free version of OpenShift that we call Developer Sandbox and that was pretty much it and if there's any more questions please put them in I've just seen one now saying can you talk a bit about licensing is it like to put a maintainer or consumer it's actually without being rude it's a bum on seat license it's the first bum on seat subscription we've done so basically you pay for the number of users if you're actually consuming your Red Hat Developer Hub and when we talk users they are that user object that you actually saw so when I logged on as a user that is one user and what we do is we sell sort of batches I think 5, 10, 50, 100 also some of the gone parts have actually overlapped similar functionality of Odo and Dev Files the 1080 functionality was absolutely what I've seen with this is that for example you can set up a template that instantiates a Dev Spaces based on a Dev Files to drive the way that Dev Space will actually build the software deploy the software and pre-configure and do dependency injection on the software the thing with the templates is it's limited only by your imagination the plugins we've given you the plugins that come out of the box with the Red Hat Developer Hub in terms of getting access to Argo CD getting access to the command lines for Kube CTL and OC means that you can do anything through an action so you could write a little plugin that gave you direct connectivity via Odo into your applications and then you could call Odo actions from within the template it's a lovely little system in terms of being able to do extensibility the only thing as I said before is that out of the box if you use Backstage the plugins aren't there you have to physically build those plugins into the system it's not a mature technology Backstage is reasonably new Red Hat Developer Hub has only just been released at release 1.1 we're getting dynamic plugins we're getting a couple more additional plugins to do with trusted content it's going to evolve very very quickly the last thing I'd say before we close the talk is that there's a huge community interest in Backstage and for me because Red Hat Developer Hub is Backstage anything that goes on in the community is just going to push everything forward and it's going to be absolutely fantastic with a number of customers I've talked to in the Backstage room you spend a huge amount of time configuring it and it feels hard and it shouldn't feel hard the complexity of this should be in producing something that the developers can use it shouldn't be complex just to set it up and that's the advantage you get with Red Hat Developer Hub it's a pre-built pre-opinionated but still massively extensible version of Backstage so that's pretty much it for the session thank you for attending we'll be back next month with a topic I think we're going to be talking about Service Interconnect I'll be hosting that with a colleague Service Interconnect is an incredibly interesting technology about point-to-point service communications but I hope that was enjoyable and again feel free to use the QR code and again sandbox is totally free so go and have a play with it use the HelmChart install it follow the learning path just get a feel for what it does and then you'll see about how rich this can be and if we haven't got any more questions I think we'll call it a day then