 Hey everyone, welcome to today's CNCF On Demand webinar about enabling self-service infrastructure on any cloud with Backstage and Pulumi. I'm really excited for this session. I love everything around Backstage and combining Backstage with Pulumi is really awesome. Now I can give my company, people inside my company the ability to self-serve them, some of the golden path, some of the best practice infrastructure definitions on any time they can just come, can fill out and get the infrastructure created. You can even go further and create templates for day two operations, which is really awesome. So not only creating a new repository for your microservices or a new EKS cluster or AKS cluster, you can even say, okay, let's update the cluster, let's create additional nodes and you guess it, there's much to do. So let me share the slides with you and kick off the session. We have much to cover. So I quickly share my screen and also start with the slides. Okay, so you should see now enabling self-service infrastructure on any cloud with Backstage. Pulumi is the title, shortly to my person. My name is Engendiri. I'm working as a customer experience architect here at Pulumi. I like everything, cloud transformation, enablement. I've worked in different places, always with the same question, how we get the company up to speed, the company up into the cloud and the teams also enabling them to leverage the full potential of what the cloud services offers. So really, really interesting subject. And yes, I love to continue everything from continuous integration, continuous deployment, you name it. You can follow me on some of the social media. So I'm on EKS, I'm on LinkedIn and the most important part, I'm also on GitHub and there you will find most of my work. Let's go quickly through the agenda before we start. So I want to give you a short introduction about Pulumi and Backstage. What is Pulumi? What is Backstage doing? I find this very interesting to understand further what we present here and how we can marry both technologies together. So the gluing part will be all done with the Pulumi Backstage integration. So this is our Pulumi Backstage plugin. I will go into more detail into this. And then we come to the interesting part to say, okay, how are we going to build Backstage software templates? How are we going to build Backstage software templates using Pulumi? Very interesting. And then of course, nothing is done without any action and without any moving parts. So I'm going to show a little demo I presented, I think five, four, five templates, provisioning different services and you will get a good understanding on how to create your own services. And of course, we're going to wrap up everything. So short introduction about Pulumi, it's going to be really, really a short introduction. So what is Pulumi? Pulumi consists of different parts. So we have our build part, deploy part and manage part. As you can see, Pulumi fits perfectly into your existing tool chain, your existing cloud provider and your existing IDE. So your existing CI CD systems. So on the left side, you can choose from the Pulumi supported languages what you want to use. Yes, we are using a generic programming languages to define your infrastructure. So choose Go when you already use Go for your application code, for example. And then you can also define your infrastructure code in Go IDE. As I mentioned, Pulumi is not inversive. You can just embed it into everything. We have even colleagues here at the company who use Vim, for example, to create all their code. So everything works. There is no limitation here. And you can leverage the existing tool chains, existing package managers. When you create a Pulumi component, you want to share with your colleagues. The main part is also our huge provider library. So you can choose not only from the three big ones, AWS, Google and Azure, to create infrastructure. There is also lots more, also smaller cloud providers. So for example, DigitalOcean or Hetzner, you name it. You can create different on different cloud providers. You can create your infrastructure, but not only infrastructure. You can also provision your SAS services. You can provision your databases and so on, very interesting here. On the right side, of course, you can save your Pulumi programs, your code in your use the source code management tools. For example, Git, GitHub, GitLab, you name it. And you can execute this with different parts. You can use Travis Jenkins. You can use Tecton. You can even use a BitOps approach to deploy your applications, to deploy your infrastructure. So very interesting and very easy to combine all these pieces in your program. Some of the features, we will see also in action, but I think it's very interesting to see also a little summary. Yes, most of the clouds, I would even say all the major clouds presented in the Pulumi provider registry. You can use any of the languages Pulumi is supporting. Pulumi uses a state management to save your state. You can self-host it. We will see this a little bit later. You can self-host this. You can even use the free Pulumi cloud service. Secret management is in builds or batteries included, but replace it also if you use a different secrets management, for example, Vault or Azure Secret Manager, AWS Secret Manager, feel free to use this one. You get preview plans, as I mentioned, CICD integration, web folks, the REST API, automation API, very, very interesting parts. Yeah, let's head over to the Pulumi high level view. So, I found this very interesting to show a little bit about the Pulumi architecture. So, as you can see, Pulumi consists of different parts. We have one part is the language shows. This is when you write your codes here. For example, you choose Go, you start to write, you import the Pulumi library, and this is the part which get then executed the moment you say, for example, Pulumi preview or Pulumi app, Pulumi, the Pulumi CLI, let's head over here, takes care to start a service. In this case, the Go service, the Go language service will be started and then communicate with the CLI, translating all the commands, all the resource creations in your code into commands for the CLI. The next piece are the providers. This is, for example, when we use AWS, we import the Pulumi AWS provider, we start to code creating an EKS, for example, when we say again, Pulumi app, Pulumi not only detects now the language, but also which provider and starts also a microservice for this specific provider and then communicates via gRPC codes with the provider to do all the methods, create, update, delete, you name it. Last but not least, when all the commands are created or deleted, what you wanted to build in your Pulumi program, the state of this operations gets all saved in the state backend. So there are different ways for the state backend. Yes, you could use, for example, the Pulumi cloud. You could also self-host this. So for example, if you have an S3 bucket, there are many, many more integrations available. The most common one when people say, hey, I want to host the state on my own is the S3 bucket. So you are completely open for this. And yeah, Pulumi, we define our resource, the resource gets created, the cloud provider delivers us additional informations about resource which gets created and then we save the state in the state backend. Next operation we want to delete, we want to change the number of EKS nodes. For example, we do again a Pulumi app. Now we compare against the state and then do the update, for example, because it doesn't use a new resource anymore. How does a Pulumi program look like? So a Pulumi program always contains a project. And inside the project, we have our Pulumi program. There is also the Pulumi template file, the Pulumi YAML file which defines, which says which runtime to use. For example, if you're going to use Python or YAML, it's everything is defined, the name, the description, some of your config parameter. And this is important for the next piece of our architecture is the stacks. Pulumi defines different types of stacks. You can think about this, I mean, the most common thing which people use in terms of stacks is reflecting their stages. So having a dev stage, having a QA stage or a prod stage, that's the most common way to use stacks. I also saw people using stacks, for example, for ephemeral environments giving them some automated names and then gets created. People do their work, check, for example, yes, that's fine. The new EKS settings, for example, they work as we expected. And then the ephemeral environments gets destroyed again. But the most common thing is using stacks, reflecting your different environments. And here comes also the thing you can now start to override config values, for example. So you can define on a high level, on a program level, you can say, hey, every EKS cluster, EKS cluster has to have six nodes. But then you say, okay, does it make sense in dev? Do I want to save, for example, money or I want to speed up time to create a new Kubernetes cluster so you could say, okay, on a dev cluster, for example, we don't need six nodes or maybe we don't need six nodes with an EKS large setup. So you can override the machine type, you can override every variable. Now we come to the next part and this is the resources. This is our small building blocks where the magic happens. We can start to say, okay, I want to create a VPC, I want to create two different subnets and so on and so on. You can all define like a cooking recipe and all of these resources, they have input and output parameters. And then now you can see, okay, you can take the output from one of the resources as an input of the next resource. So you can say, okay, a VPC, I always need from a VPC, I need the ID to set, for example, a subnet. So getting out the variable of the ID, putting into the next resource and now comes the situation, Pulumi detects this kind of dependencies and creates in the background a dependency graph. And depending on which resource needs the output of a resource as an input of the next resource, Pulumi will then say, okay, I'm going to create this resource in parallel, these resources have to wait when it's finished the other one to get the value out and put it as an input variable in. So that's the thing. And with this way, you can nicely create the graph and really speed up your deployment because most of the resource, for example, which don't have any dependencies, they just create it in parallel and you will get much quicker infrastructure provisioning. Last but not least, every project has on its own the way to define project outputs and project inputs. So you could say, for example, I create a project for the database team, the owner or the database team, they define whatever they need inside, but me as a developer, for example, I just want to know the URL, for example, of my database and the user name and the password and all the stuff. So the infrastructure team and now we come back also to the backstage part so I can just provision, for example, a new database code is written from the database team. I don't know what they are doing inside, but what I know is this is when the project is done, it will give me as an output the database world or the database password. And there's also an interesting part, we can reference to this. So not only you can run the Pulumi program and take the values, copy paste them into your next program or in your config files, you can combine two Pulumi programs and say, hey, it's called stack references, please Pulumi, look into this specific Pulumi program with the specific stack, for example, the DevStack, and get me out the database URL and the database password. So everything is highly automated and I don't need to copy paste where I use around different stacks or worst case communicate via ticket or something like this. So, hey, what is the database URL? Okay, so that's it about Pulumi. Of course, there's much, much more and the documentation of us is full of many, many use cases and many things you can apply. But now let's head over to Backstage. What is Backstage? Backstage is an open platform for building developer portals. That's very important. Backstage is not a developer platform on its own, it's just a framework, a way to build developer portals. It was created by Spotify and it is donated to the Cloud Native Computing Foundation, so it's completely free. You can be sure that as part of the foundation, there will be no license changes or something around this. So you can really commit yourself on Backstage and start to build your internal developer portal around your internal developer platform, for example. And I just mentioned this, yes, you get unified tooling for services. You can create documentation, you can use see who owns which part in the company. So having the way to model your whole company inside a tool is very, very interesting. Because you could say, okay, I have, for example, the LDAP service, every company has looking up a directory of employees, for example. So I can use Backstage now, search for a specific component and say, okay, is there a component? Is there something around LDAP, for example, or internal directory? And then I see, hey, there is already a component and these are the owners and it's part of a bigger project. So you can really create the whole relationship of your company, of your different products, of your different development teams inside Backstage. So that gives a very, very powerful tool in the hand. And now we see also the three, let me say, the three bullet points which collide. So we want to increase speed. We want to scale out. So nobody wants to wait for information of somebody. You don't want to write a ticket or you don't want to write a mail to say, hey, who owns the LDAP service, for example, or how can I consume the LDAP service? And one part, and this is the thing we're going to discuss also in this webinar, is you want to contain also the chaos inside your company. So go to your company, tell 10 different teams, hey, create me an EKS cluster, for example, whatever programming language they're using or whatever IAC tools they're using and you can be sure everybody creates or every team creates a slightly different version. And this is the thing, you get a high fragmentation of different ways but this is not something you would like. What you want to is, okay, you want the deterministic way when you say, this is the way we order an EKS cluster we provision an EKS cluster. It's me who's ordering or maybe the next team is tomorrow or tonight you could be all around the world and there will be every time somebody ordering a new piece of infrastructure, you can be assured that they will always get the same way because you create now a specific way to order this and this highly helps also speed up the need for speed. And here we can see what is in the middle. Yes, it's backstage and when we want to provision our infrastructure, of course, there's also Pulumi. Okay, we just talked about this and was creating new software, completely fine new software, new infrastructure. You have a centralized location to manage everything very, very cool. And of course you can explore existing ecosystem inside your company and then this helps also not only the whole inner source movement but also the way to collaborate. So when you know, for example, who is the team behind the software XYZ you are using to order something or you're using to print out your bills or whatever. Now you can also approach them and say, hey, this is the team, this is the persons inside the team. I can ask them, I can contact them and say, hey, can we talk about this new functionality or which is also nice. There's also the git repository connected to in backstage, for example, so you could go when you have access in some kind of inner source movement that everything is open and visible. You can just create a pull request on this code and improve the code, for example, very, very powerful. Architectural-wise, and now this comes also why we're having this webinar, you can extend backstage with plugins. It's built on a plugin architecture and the Pulumi created a plugin around this and that's very, very cool. It's built on material design, type script and React. So something I would say not uncommon and you should be able to quickly come into the whole backstage code and start to change the backstage code, for example, extend the backstage function to your needs because everything is in a fairly standard way written and it should be easy to extend everything. I did it and I'm 100% sure that you also be able to change this and to extend backstage to your needs. Okay, that's not the same slide. You can see our plot of this in the background. So let's talk about the backstage Pulumi plugin. Okay, the backstage Pulumi plugin consists of, let me put this here, consists of two components, two independent components, we have one component is the scaffolder backend module and the next component is the backstage plugin itself. I put the QR code on top of it where you can see the code, where you can have the detailed instruction on how to install the backstage, the Pulumi backstage plugin. It's also available here, as you can see on Rody when you want to use a managed backstage, for example, and as you can see on the left icon here, it's also listed in the official backstage plugin catalog. So you can also browse this through and then just click on explore and you will be redirected to the GitHub repository where you see the detailed instruction. Oops, so, okay, let's have a look into the Pulumi scaffolder backend module. This contains currently, as we're speaking, of two new actions. So we have the Pulumi new action and the Pulumi app. If you maybe worked with Pulumi, this should be very familiar, you should know about the commands. So with the Pulumi new command, you can use templates. So self-created templates from your company, you could use the template library Pulumi's offering and you could say, okay, create from this template, for example, the EKS Go template because you want to use Go, the Pulumi program and with the Pulumi app, the second action, you could then just apply everything and deploy it. So Pulumi new creating a new project. If you have already a project, you don't need to create the Pulumi new. What you can do then is just call Pulumi app, for example, when you just already created this one and it's part of your scaffolder skeleton or your scaffolder template. We will see this, what I mean in detail. The Pulumi new has many configuration possibilities. So you can define which stack, which Pulumi cloud organization you are using the name. Template is very important. Let me use the laser pointer to, where are you? I don't find this. Okay, so template just define, for example, the building template name or the URL, it doesn't matter. So just point what you want to use description and then you have additional configuration parameter to set the config. And if you want to use secret config, so they are automatically encrypted with the Pulumi secret provider, you can just say, okay, secret config and this object is the map just use them and it will be automatically encrypted additional arcs and then of course the folder to run Pulumi in. Next one is the Pulumi app has similar properties. So stack organization deployment and so on and so on. Very interesting. One part to mention is currently you can also use here in the Pulumi app command, Pulumi deployment. So just set the flag, it's, you can say it true or false. If you use true, it's going to use the Pulumi deployment. So you don't need to, for example, it will not be executed on the backstage server. For example, you don't need to provide the backstage server, all the SDKs of all the languages you're going to support. You don't provide, for example, different, the Go versions or C sharp or something like this, everything will be executed in the Pulumi cloud. This is really interesting and highly recommended that you check our documentations about Pulumi deployment as it will help up to avoid any CI infrastructure. Now, second component of our Pulumi backstage integration is the Pulumi plugin. The Pulumi plugin currently displays all the information from the Pulumi cloud back into your Pulumi and your backstage components. So you can see which organizations belongs, which programming languages behind this and so on and so on. And the second part is also the Pulumi activity. So when you're navigating inside your component, you can then just see, for example, all the runs you had and then you can jump from this to the Pulumi cloud. So this is the Pulumi card element in the component overview. As you can see, you see the organization repository, the runtime and the deep link to the Pulumi console. Second part is on a system overview. And again, you can change this when you want to create, you integrate this, for example, I created the Pulumi card here on the system because my assumption or my modeling is to say, okay, a Pulumi backstage system corresponds to a Pulumi organization. And I want to see all the informations of the whole Pulumi stacks inside a Pulumi organization on a system level. And as you can see, but you can change this if you say, okay, we want to differently, that's the beauty of backstage. If you want to use a different way to model your backstage entities, you can change this and then just assign the Pulumi plugin and say, okay, I want to show this maybe on a resource level. And last is the Pulumi activity view where you can see when a Pulumi run is executed and then you have all the informations here and you don't need, for example, to jump out of backstage. Okay, that's the Pulumi plugin. Before we dive into our demo and we will be shortly there with the demo code some words around the backstage software templates or software templates are a tool that helps you to create components inside backstage and it will execute, for example, all your code you put in your skeleton folder, for example, and you can gather all the variables so you have a way to collect informations to interact with your users, ask them for specific questions and depending on the input, you then just render different code. And also interesting is, okay, you just don't want to give people now a zip file and say, hey, here's your Pulumi program or here's your microservice program. You can also connect it to two different locations, for example, GitHub or Github, Azure DevOps is also supported, so you have a way to render the template with the variables and then automatically uploaded to your system to GitHub, for example. Writing templates, templates are stored in the software catalog onto the kind, the template, you will see this in the demonstration, templates are written in YAML and contains metadata input, what I just mentioned, input and then a list of actions you want to execute all the scaffolding actions, for example, also with Pulumi. Adding a template is also quite straightforward, so you could just go to your app config YAML, for example, and then you use the static location configuration and there are two ways to add the template here. One is the static location configuration, as you can see in the screenshot underneath. This is from my example. You can also use the catalog import endpoint plugin if you want to do bulk import stuff, so there are two ways to import your templates. Okay, let's head over to our action and see some of the code. So some explanation about the demo architecture. So again, I created here a so-called developer platform. It consists of two parts. So we have our Github's infrastructure, so because now we can use, for example, Flux in conjunction with the Pulumi operator to define infrastructure and deliver it via Flux in a Github's way. There's an example in our demo code for this. And the second part is our backstage infra itself. It will be hosted on Fargate using an elastic container registry and RDS and everything you need to host backstage. Here in this example, I didn't want to host it on the Kubernetes itself. You could also, for example, deploy it on your Kubernetes and then run it there, but I found it more convenient just to use a service. So there's one thing less to worry about. We're also going to use the Pulumi cloud because we want to upload our state files to the Pulumi cloud. And that's what we use here. And it's not really visible here, but the whole company infrastructure, the whole company definition is inside a Github organization. So we're going to model our company in the Github org and this is in the below part. So how is the interaction going on? We have the dev team. The dev team heads over to backstage, choose from different software templates, choose what kind of infrastructure or what kind of service they want to create. Backstage runs, in our case, creates the infrastructure, uploads everything to the Pulumi cloud and feedbacks all the necessary informations back to the development team and creating everything in Github. So it will be, for example, creating an infrastructure. You will get the Pulumi code automatically generated in your Github organization to then continue. So you could say, okay, from there, I'm going to use Github workflows, for example, or I'm going to use a different way to do my CI part. So this is just a reflection here. Or when you're going to use, for example, the Pulumi operator, you can just change the code and the flux will detect any code changes and will then execute the deployment and Pulumi operator will then execute the new the changes in the infrastructure. Okay, so let's open up our infrastructure. So here we have our backstage instance. Just press reload. It's our demo organization. We use all the time inside Pulumi. It's our Sapphire Archiotec Emporium and they created a software catalog. As you can see, there are already some components inside. So we have fluxes already installed on our Github system. The Pulumi operators installed. We have external secrets installed and the AWS load balancer is everything on this Github's infrastructure. We just saw in the beginning. So when we have a look into, for example, flux, we can see here is our Pulumi card and the organization name and the repository name, the runtime which everything gets executed. As you can see here, there are already some runs here and we can see much more runs here. So very interesting and you can drill down to every piece of them. Okay, that's so far the existing infrastructure. We have here our Github's infrastructure. There is a YAML error. That is not that important. We can check this later. So, and let's see, now it's still consistent here and then we see also what I mentioned before with the resource that we can see currently in the resource, all the providers which are used and how many resource are created using this different provider. You can see AWS, for example, is 116. Okay, so let's create new infrastructure. So here we create, we see here different templates. So we have, for example, a new EKS cluster. We can create a new Lambda function. We can create a microservice on Kubernetes. We can create a static website and create also a virtual machine. So this is completely made up from these services I defined which will be useful inside my company because we deploy plenty of stuff still on a virtual machine. So let's have a look into the code. How does the code look like? So let's pick this here. For example, the virtual machine. How does the code look like? So we drill down in our scaffold template. So as you can see, I told my backstage instance here using the backstage. So I use this backstage resource called location and I say to my backstage instance that, hey, point to this specific repository to the specific YAML file and location will consolidate everything. So I can say, okay, I define, this is everything under my template. So I named, for example, my location templates because this is everything template related. But you can use locations also for different backstage resources for backstage component resources and so on and so on. So you can really create your service catalog. In my case, all the templates gets generated here, aggregated using the location. And now let's have a look with the first one with the simple static website. How does a simple static website look like? So as you can see, I have here a folder. I want to group everything and inside the folder, I have my template folder. This is completely made up for me. You can name it as you wish. That's not the thing. But everything underneath this template folder is already possible to template, to use a template engine. So everything, it's similar to the cookie cutting process. So backstage has a template engine underneath. Before it was the cookie cutter, I think they changed it now to a similar approach. And you can see it will generate a folder and with the using the name I collected from the user. And this is also for file names. So everything inside the template folder gets rendered and the magic happens here. So this is our first template, creating a simple static website and S3 bucket. So all the meta information we just mentioned before description and so on, make it easy for the users to understand what is behind this. Every template has an owner. So if I have, for example, a question, something is missing in my template, I can just look up the owners here. In this case, it's a group, the infrastructure group, a specific type. So in my case, I gave it a serverless, for example, but you can also change the name. There are also some well-known types you can use. I, in my case, I said, okay, this is a template around a serverless infrastructure. And now we come to the next step where we define the properties. So the parameters, sorry. So we can define now the different pages that the user will be guided through. So we have our first step. We collect some informations, the name and the content. You will see this in an action. And I collect the name, the content, because this is a funny service. You can just write the HTML content inside Backstage and it will automatically generate an index HTML. It's very important to say, okay, this will be hosted on our S3 bucket. So where is the S3 bucket located in which region? I can define a default answer, collecting all the informations. We can also say, okay, which system belongs this and who's the owner? So I can choose our owner. I can say, okay, this is the infrastructure team, this is the team. So I just went here on group. You could also go on user and define, okay, it has to be a specific user. Next point are the steps and here where we execute all the scaffolder actions. So here in this case, we say, okay, fetch template is our first action. And as you can see with the URL, we say go into the template folder. You need to transform the template folder. As you can see, names are changeable. It doesn't need to be named template. And now I can pass to the templating process. I can pass all the specific us name. We just saw folders and file names are using the value name, content, region, and of course here the stack. So which organization to use? Next point is then the publish step. So in my case, because this is here a GitOps approach, I want to create a pull request because the ops team, for example, they needed to look on it before they approve it. So we have a pull request flow going on. And I still have here my spelling error inside. And the next point is then I just want to give feedback to the users to say, look at this pull request, for example, and when the pull request gets approved, you will get your static website. So let's head back to our backstage instance. And now we can say, okay, let us use now the static website. So let's say, let's see, a webinar. And you can say, hello. Okay. We want to deploy the development stack here in this case. And I'm going to choose an owner here. I say, okay, I'm part of the development team. So here you can see, I will just get some informations of the input I collected. And now I can say, okay, please create this for me. And as we can see, it starts. And when we go to the PR now, we see backstage created a PR for us in the repository with the infrastructure where our Github's operator is looking at. So the Github's operator is configured to just check here on this side. And we can now review everything. So let's imagine I'm not the platform team and I have to review this. I can say, okay, there's a component called CNCF webinar going to this project that's completely fine. And this is the code that looks also very good for me. Here's some, the references to the credentials for AWS, very good. So I say approved, looks good to me. So, and now I can squash this one. Okay. And as we don't want to wait too long for our flux operator to run, we can also say to the flux operator to say, okay, let's kick this off. Okay. And we can see here the CNCF webinar is created. Currently there is no reference because it's not executed on Pulumi slide. Let's see in the Pulumi cloud. If it's, yeah, we can see it's already executed. And we should now get hopefully our S3 bucket generated. So it's going to create here the stack. Okay. We let this run through. Okay, that's fine. So it should be, okay. And we have here now the link and we see hello CNCF webinar, very cool. So first story is completely done. So let's head over to the next one. Say, okay, we want to create a different one. So let's say, for example, we want to create a virtual machine. So let's look also into the virtual machine scaffolder code. So again, we go into the virtual machine, also created from the platform team, same pattern. We have the template definition owner and now additional informations we want to collect owner and so on. And here we define now the Pulumi template again. This will be a second view. I can define some required properties and then again, collecting the organization which Pulumi organization to use the region. And now we come to some interesting part. We can collect the instance type, some network cider. We can discuss, is this something I want to expose to the team or is it the infrastructure? Is it the DevOps person inside a cross-functional team who maybe provisions this for everybody inside the team? And he has more knowledge about the whole networking subject. It's really, it really depends on the team structure. There are different programming language supported here. So we can say, okay, depending on the team and on the approved language inside an organization, we use an enumeration. And because to give it better names, we can use the enum names and then overwrite it otherwise you could just see TypeScript or YAML. You can make it a little bit more appealing for the user's stack selection. GitHub repository location. So we can define where to save the code. And now we've come to the next point with our Pulumi plugin. So here we're going to use the Pulumi new command. And as you can see, collecting again the informations. So name, stack, organization, we just saw. And here's the interesting part. We use a template here. So in this case, the VM AWS template because we're going to deploy everything on AWS. And we set some of the Pulumi conflicts. I just talked about the Pulumi architecture in the beginning. So we collect the region, the instance type and the VPC network slider. Wait a couple of seconds. Sometimes there's a race condition going on with the transformation of the code. And now we can execute the Pulumi app command and say, okay, we're not going to use the Pulumi deployments. Again, setting the name, setting the repository URL. And here the repository project path means where is the Pulumi code? Sometimes it could be that you put it into a sub folder because you want to run a monorepository in your site and say, okay, application code is in a folder, infrastructure code is in a folder. So you can now define where to put this. And we want to get out some of the outputs. We want to display to the user some outputs. In this case, the URL of our service which runs inside the virtual machine. We render again the template. We publish it now with all the pull requests. We publish everything, the whole Pulumi code in GitHub. And then we display the informations. Okay, so let's create our virtual machine. So we say here, as VM, let us call it CNCF. VM. VM. VM. The owner is this time again, the development team. So I'm going to use my organization inside Pulumi, as you can see the organization here. Oops. And let's head back here. I can choose now the region. I take EU central. I choose a medium one. This can stay as again, if there's no need on this one, you don't need to display this. I will use Go, use the deployment environment to define it's a deployment. Giving my organization, my GitHub organization. And let's give it a, so test VM. Now it's the name of the repository. We can see now all the informations gathered again. Click on create and it should all up and running. So we head over to the Pulumi cloud. You can see now, hey, the CNCF webinar is here created. Okay. And it should also now start to deploy everything. Oops. So we deploy, the VM gets created. This can take a couple of seconds. You can also see that it's what it's going to do in the background. So it's going to create a VPC, a subnet internet gateway. So there's much going on and our instance and the same goes here. Okay. So now we publish this to GitHub. That's very good. And everything is deployed and registered. So we have now the feedback from Pulumi with the URL. I'm going to open this one. Let's maybe take a couple of seconds. We get the IP address. We can see the code in GitHub. You see everything is deployed here in our GitHub repository. The code is now visible. I can now work on this. And I can see also that some of the properties, the default properties is set. And let's see. And yeah, here is it. Hello world from Pulumi. The service is up and running. And we can also watch this here in our service catalog. We see that the card is displayed. And we should also see for this component, the activity. And we can then jump from here back to the Pulumi cloud. Okay. So last thing before we wrap up the session is give you the last thing. So now we want to maybe want to deploy something bigger to say, okay. So now we use some deployments. Can we see something more sophisticated? Maybe to say, okay, what is with application code? So let us open this in a new tab. Again, I think for this one, I need a Kubernetes cluster. Okay, I got. So again, we have our template definition. Nothing changed before. We collect some of the properties. We configure the infrastructure. We can now define, for example, additional functionalities here. I want to enable also a configuration scanner. And here I'm using, for example, 3V. You can add additional tools and then you can extend your GitHub pipeline, for example. Choosing again a repository. What we do here now is, I want to deploy this on a Kubernetes cluster. So here in this case, I say, okay, I want to deploy a Kubernetes cluster of the type resource. Please show me everything of type resource. And then I'm fetching the information because I attached to this Kubernetes cluster some informations about the Pulumi organization because we want to use stack references. We want to get the informations out. Then we render again the different templates. So we render the flux template because we want to tell the flux operator, hey, here, look into this Git repository, that you find the application code to deploy. And after this, we also render the real application code of the application. And let's see, so this is one part, as you see again, using the code for flux defining a Git repository, defining a customize to say, okay, please look inside this Git repository. We just created look in the customize folder. There you will find the Kubernetes manifest you need to deploy. So it's my assumption again. So when we look into the template folder of the code itself, you can see there's a customized folder. And inside the customize folder, there's a simple Kubernetes deployment, a simple service. And here we have the application code, a simple hello Pulumi backstage world. Okay, so now we can choose this one, can give it a name. So we say microservice or let me say sales, microservice and we say the owner is the development team. And then we can say here again, as a cluster, we use the EKS cluster development. Let's choose 3V as a scanner. That's fine. I use again our demo repository. So, and we can so now create, okay. And perfect. So two things we created here. We created a pull request. You can look into this pull request for the Git apps repository. So it created inside the flux apps folder. It created the sales microservice application YAML with all the stuff here inside, which gets executed from flux. So creating a Git repository, creating the namespace for the application. So I can approve this pull request. And when we take a look into the next part, we can also see the application code. So this is the application code. We created a microservice inside. There's a Docker file. And we can see automatically that the GitHub workflow is creating a container. So a new Docker container gets created. It will also create the customized file with the SHA ID. So this will also generate it and set inside the customization YAML. That's very interesting. So when we have a look, we should see now on commit on the customize. So here is our microservice. That's cool. Microservice is up and deployed. And hope, yeah, we see that the customize also calculated from this container image and set it the new tag, the SHA number of the tag. So we have a 4E here. And if we take a look here, we see, yeah, 4E, that's the version we have. So everything is set up completely fine. Let's have a look into the 3V part, for example. So where is login, built and push, da-da-da-da-da, post build? Where was the part we activated? Workflows build, oh, I think he didn't collected the 3V part. Okay, I did an error in the code. So let me have a look into the template definition. So why the 3V did not render, generate, generate. Okay, here I wrote 3V. It should have printed the scanner. So let's have a look into this. How did I collect the 3V variables? Scanner should be set template flux. Scanner should be set, not sure why he did not generated the stuff. Interesting. So let's see what did we collect it here. It's not, it's not visible. What did I collect it? Probably let's click on start over next. Okay, I selected 3V. Not sure why it did not render the 3V part. Yeah, here's it. No, no, that's not, that's, here's it. Here's the 3V stuff. Okay, he used the 3V config check, my fault. So it's part of the action. So when we go to the 3V action in the generate, it's not an extra step. So maybe that should have been. So we have here the run check for misconfiguration and we can see some plenty of information here. Wow, I should have fixed this. Okay, but at least gives me feedback. Every time when I run now my microservice, I get feedback that there is something to change. So I applied also a compliance development team gets all the tools already installed and just don't need to care that, for example, a misconfiguration check will be happened. Everything is also registered here as we can see. And yeah, so that's it. I think the Lambda one, we can just quickly check here. Lambda, so we will quickly skim over this and then we can also again set the properties. We set the language, the stack, and then the Lambda webinar create. Again, create the Pulumi new, download the properties and let's see that it gets deployed. So let's have a look into the Lambda deployment. So we see update number two is running and this should deploy now all the Lambda resources we need. So just give it a second. And yeah, we can see the role is created and so on, so the Lambda function gets created and it should give us as output the URL of the Lambda. So let's see that this gets created. So the bucket gets created and API gateway gets created. So everything people really don't care and maybe, yeah, I'm not able to do this in this quality. Like for example, the platform team would like to have it. So we defined this in our code. We will have a look into the template again. So we see it's deployed. We get the URL also. So here is the URL for the Lambda. Serverless with Pulumi, we get the current time out, perfect. It's working, bam. And we can see the code. So this is our Lambda function and so on, this is the website which gets delivered with this stuff. Okay, now I have a quick look into, yeah, the Lambda is also here, perfect, fine. And let's have a look into the template definition. So again, as I mentioned before, kind template. Let's have a look into the Lambda, into the code. And we see again, properties gets collected, all the informations, region, language, and so on, where to save the stuff. And here we call again Pulumi new. We use the template, the inbuilt template of Serverless AWS. We set the region and then we execute Pulumi up and as an output, we want the URL and the URL gets then displayed here, perfect. Okay, that's fine. So let's close this and finish our slides. Okay, so follow up, wrap up. We just saw how to define backstage templates. We created backstage templates. We registered the backstage templates to our backstage instance using the static location, the static location configuration to say, okay, here is our template. We used the kind location to bundle several templates together to say, okay, these are all my paths. I want them all deployed. You could split them also. So there's also many, many possibilities. And yeah, the QR code for the Pulumi code for the Pulumi backstage plugin is on the top and some resources I found very useful for to dig into the backstage in general and Pulumi looks if you're interested into it and again, the backstage plugin. Okay, so with this said, thanks all for watching. If you're interested more into backstage, just let us know. I'm more than happy to show additional content around backstage and how to combine different deployments inside Pulumi or how to use, for example, the Kubernetes plugin inside backstage to see information of your Kubernetes deployment or multi cluster deployments and so on and so on. So many, many interesting things. So hope you liked it. And I will say thanks for watching and see you next time. Bye.