 Hello everyone. We're getting started slowly. So this presentation is about we're going to build our own Hiroku with cloud native stack, which is essentially like cross-lane backstage and Argo CD and some bit of like, you know, get repository, of course. So this is kind of like what we're going to go through. The first we're going to talk about like, you know, the Hiroku experience and like, you know, what they give you and then architecture of our solution that will do like, you know, that will give you a similar experience. And then we have this hands-on tutorial that we will write code and like, you know, write YAML, see it all in action. And then a group of a Chikario who is a big company, they have this setup in their production with lots of like, you know, cross-lane resources and different configurations. And they will they're going to do a demo as a he's going to do a demo as well. Cool. Yeah. Well, I'm Wafak. I am an engineer at Upbound and maintain a cross-plane. I'm the tech lead of the control plane squad that maintains cross-plane and providers. I'm Siddhartha. I'm director of infrastructure in cloud at Group of Chikario. Cool. So the Hiroku experience, right? So Hiroku is, you know, even Hiroku was there even before Ducker came out and like, you know, their concept of like, you know, that is like, you just have a Git repo, you make code changes, Git push and everything is live, right? And on top of that, they've got this like, you know, metrics and activity. And like, you know, you just write code, commit and watch it live. And what you get from them is like deployment and then scaling and monitoring and some of the security guardrails that they have in place. However, it's not as flexible. Like, the more opinionated you get, the more like, you know, the less flexible it's flexibility you can provide to your users and customers. So a lot of companies, they start with Hiroku, but everyone knows, like, you know, they're going to outgrown Hiroku, right? So what you don't get from Hiroku, and one of the some of the reasons that you would not continue using it is that they don't deploy stuff in your own internal network, because like, you know, it's all in the, in their accounts and like, in their essentially hosting service, right? A cloud service, to some extent. And they don't allow you to use your own cloud accounts and complex applications developed by multiple teams. For example, if you want to have like lots of microservices, some like auto scaling with AWS, like advanced scenarios, essentially, with more than like, you know, a few dino, dino's they call. And also like your own guardrails, right? It's just like, the opinions of Hiroku's design are good, but they don't work for everyone, especially the big companies, right? So what we want to have is a Hiroku that you can customize more. And you can have like, you know, under, you can feel it under full control. So I'm going to go through like a few tools that we're going to use. The first one is cross-plane, right? So cross-plane is this tool that allows you to build your own internal cloud platform to provision cloud resources, essentially. And you can interact with it through IAC tools, like Terraform or Kubernetes applications, or CI-CD pipeline through GitOps, because it's essentially built in Kubernetes API. It gives you, it installs CRDs and you can interact with them with that, just like all other CNCF tools. And backstage is another CNCF tool that allows you to have a service catalog in your company. And on top of that, they allow you to have a software template concept where you can click and create a new application like Git repo with some of the like, you know, presets and like, you know, CI-CD actions if you want to. And then also they have this like, you know, Vivo Pay, who is owning this service? Where is it located? Is there like, you know, docs for it that I can look up? And what's the API? It's essentially like an internal service catalog. And then what we're going to do is to interact with Kubernetes cluster. We're going to have a cluster. We're going to deploy all these three tools, all two of the tools, and then also Argo CD. And we're going to manage all of that, like, you know, our platform consumers who are developers are going to interact with it through backstage. And then our platform builders are going to like, you know, build that crossplane compositions and all the things that are like, you know, designing the HeroQ experience. We're going to write our own software templates, for example, for Node.js or other languages. And in a very high level, this is like a really basic diagram. But I think, like, you know, the more we go, like, you know, you're going to understand the details backstage, what, what, how we are going to do it is like, you know, backstage will have set of software templates. When you request a new service, it's going to create a Git repo with all the CI CD, and then Argo CD will take over to deploy. And what it deploys is both application and infrastructure. And then crossplane is going to talk to the provider. So with one click, you're going to get like, you know, for example, RDS instance, like buckets, even cluster, if you would like to, together with your application. And yeah, without further ado, we can, we can just start the tutorial. Do go to that page because there are places where I will just like copy and paste the ML because it's just too long so that you can like, you know, keep an open tab and you can just copy and paste the same thing. And also like, you know, later you can, you can follow it. Cool. I think everyone got it. So the first thing is that open the repo, open the repo. So the first thing is essentially, we're going to go through the like your experience, right? We're going to look at like, you know, how, how it actually works. In order to do that, let's go to heroku.com actually and create a new application. Can you put it like here or something? Cool. So we just created our own application and I already logged into Heroku. So I'm going to create a folder. Just a second. Are you able to see it? No, okay. Is it better now? Oh, it's because of the yellow thing. Yeah, I couldn't get that right. It's just, let me just make this, is it readable now? This is, I'm going to switch to another color light background. Is this better? Is this good now? Okay. Yeah, sorry about that. It's not disabled in this external monitor for some reason. But yeah. So let's get in it, our repo. And we're going to copy some of the Hello World code that I have here. So it's going to be a Node.js application, right? Packages. And this is to have Node.js compile. And we got a very simple server.js, just like in Hello World and using the port that Heroku mounts. And then we're just going to get status, commit. Cool. So I have created my commit. Now I'm going to add Heroku's own remote. Git repo. Nice. Now I'm going to get push your code main. Cool. So one experience that we're actually not going to be able to give is this like, you know, Git log, because we're going to use GitHub. It doesn't allow you to edit this login. It just builds right when you do the push and deploys it. We're going to use GitHub actions to do that operation. Cool. So if you refresh, open up. Yeah. And now we're seeing the Hello World. So whenever we make a change, the same thing happens. Git push and builds it and it deploys it. So that's kind of like, you know, the Heroku experience that I'm going to like, you know, try to get to. And additionally, there is this add-ons concept. For example, let's see. Okay. For example, yeah. So add-ons is like, you know, how you add infrastructure to your Heroku application. But for example, if you want to add buckets, you can use this bucket here. And it would like to make an environment variable available for you like bucket name and credentials to be able to use it. We're not going to do that for now. But yeah, now we are going to start to install our tooling to our cluster. I'm just going to copy a bunch of code here. And it's going to be a kind cluster. We're going to work on a Heroku namespace and deploy everything important there. So this cluster is going to host backstage crossplane and also Argo CD. And I've just set the namespace. So I'm going to create a backstage app. So backstage is a little bit different than the other two in that it's actually a bunch of like, you know, libraries that allows you to build your own UI, right? So it's essentially a TypeScript library set. So that's why they have this MPX command that scaffolds the backstage. And then you go and edit those TypeScript files. For example, we're going to add an action that creates Argo CD application. In order to do that, we're going to have to like, you know, make some code changes. So let's create our backstage app, actually. So it takes a little while. So I have it already in my local. So I'm going to commit a crime and open this in GoLand. Because your Yarn install just takes too long, I have already like, you know, this scaffolding. So what you see here is usual TypeScript. Like, you know, it's got like two packages, one app for frontend and one for backend. And we're just essentially going to just like run the MPM start and see what the initial state is. Oh, Yarn Dev. Yeah, MPM on Yarn. Yeah. So it's coming up. Yeah. So this is like, you know, very initial backstage UI. It's got an example website. It's got create new component. So this part is the catalog part is you're supposed to see like, you know, all the software that your company has up and running, right? And when you go to the page, it's to show a relations, CI, CD dependencies, documentation. And if you click the source, if it has like, you know, GitHub repo, it would take you there. And the create part is where we will work most of the time at the moment is where you have a template, for example, not just template, right? You choose that and it creates a GitHub repo and scaffolds everything. So in order to do that, we are going to have to create a GitHub token so that we can have it. We can give it permissions to create it back. It needs to have repo and workflow permissions. I'm just going to copy this. Okay, I'm going to close this because it doesn't have any credentials. So we're going to put it and then open it again. Cool. So we got that right. And there is, we need to check if it's, so there's this app config. You've got app config local and production. And this is like, you know, the core app config, depending on the environment, these override the main core app config one. For example, when I run re yarn dev, it uses this empty file. I'm going to build an image and deploy to Kubernetes cluster. It's going to use this production one. So I would like to check integrations, integration of GitHub, but it has the token. Yeah. So it's essentially environment variable. So I'm going to do yarn dev again. I'm going to go to this create. Yeah. So I'm going to create a service. So what it does is like, in three steps is the like, you know, the base, you give it a directory for scaffolding. Hey, like, you know, these are like, you know, starting point for my repo and it's got some good templates that it can fill with users input. Right now we just give like, you know, hey, I am the owner. This is the repo address, but we can extend that. And then it publishes to GitHub repo story and then registers it back to, to this instance. So if we go to that repo that is just initialized for us, was it private? Okay. So this added like, you know, a very simple, like some, its own sample and catalog info. This is like, you know, what backstage uses when you want to import a service. So our GitHub token integration is working. That's what we confirmed. So we're going to deploy this to our kind cluster. There's a bunch of options here, but we're just going to use in memory DB. And on top of the standard, we're going to add this template option. Normally it doesn't allow you to add templates in the UI. It has to be like, you know, compiled in with your application, but we're just going to enable that and add it through the UI. So I'm going to production, just remove everything, paste this. Cool. Don't need to have this open anymore. I'm going to build an image and load it to my kind cluster and deploy it. So this is like, you know, and then I will have a like a QPCTL port forward, just like I'm going to do with Rgo CD. And then, yeah, first I need to load the image. And there's the next step we are going to create a secret that has the GitHub token that we created in the earlier step. Let's wait. Actually, we don't have to wait. Okay. GitHub token is created. Okay. Image is loaded. So we're going to deploy with like very simple manifest. It's going to have like deployment, one replica using our image and a service that expose it through port 80. And the service account, which will be useful later on. So I'm going to copy this manifest regarded here. Cool. So I am seeing it. It's up and running. And I'm going to open it. Okay. Port forward, connection refused. Demo gods don't like us today. Invalid queue. Did I? Okay. Okay. Oh, the, oh, okay. Yeah, right. The secret, right? Yeah, I just need to stick to the script here. Okay, thanks. So I'm just going to delete the part so that comes back again with the secret. Come on. Yes. Now it's in our cluster. That's cool. So yeah, that's out of the way. And now I'm going to install Argo CD, but the images it uses, it hits the Docker pull limits. So I'm just going to have a script here that will preload the images so that we don't see that problem. Cool. Yeah. And just like, you know, we're going to install it to Heroku namespace. We're going to make it use our preloaded image. Okay. That's, that's okay. The important ones are installed. Cool. Argo CD is there. Let's wait for it to come up. Oh, I preloaded the images. This was supposed to come up fast. Okay. So it's just like, you know, very frequently used images. And in this Wi-Fi, they hit the document because everyone pulls images right now. And yeah, let's kill all of them. They know how to get back up. Cool. So they are getting back. So I'm going to get the initial admin password of Argo CD. If it comes up ever, okay, you got it. And port forward that one as well. It's in Chrome. Yeah, I am taking the risk. Cool. So admin. Okay. We got Argo CD as well. This is going well. And now we're going to install crossplane with helm and then install provider GCP because like, you know, we're going to provision bucket from GCP in our scaffolded application. Okay. So we got these two. So we're going to start with just like the backstage example scaffolding. We're going to start with a very simple template just to validate that we got everything right. So when I installed provider GCP, I also need to give like GCP credentials. So I'm creating a provider config object. That's created. And it's also need to have the secret. I already have this environment variable available for my service account in GCP. I mean, I hope I do. But yeah, cool. So the installation part is done. I think who I hope. So we're going to have a like simple hello world template, just like the similar, just like, you know, the existing template, but with actual, like, you know, some code in it and like from our own template, get up repo. So this is kind of like, you know, how backstage you either compile it into your application templates, or you create a repo and tell it, Hey, like, you know, you can catch that from there. And whenever you make a change, though, you have to refresh it. So I'm going to create a new repo. Get clone. So this is going to serve like, for example, in a company, this repo would be maintained by a platform team, because they would kind of like, you know, set the compositions like, you know, what you can do and like, you know, the best practices of languages. In this case, we're going to go with Node.js. And let's initialize the repo. Cool. So I'm going to talk about a our first templates. So a template a scout, like in order to prepare a scaffolding for backstage, you need to first create a template YAML that will tell it like, you know, hey, go and take the, for example, in this case, we've got some properties like that we will ask to users, Hey, what is the service name? Who is the owner of it? And then choose a location. They're going to like, you know, we're going to choose a repo. And then there are steps. So these steps are very familiar. They're very familiar to get up actions in that, like, you know, you choose an action and then like, you know, give some input and output and it takes like, you know, one by one. So initially what we're going to do is just like, you know, hey, I have a skeleton folder. And these are like, you know, the values that I took that I got from the user, and these are going to be used in our skeleton template so that it replaces them, because we don't want scaffold to be like exactly the same for everyone. We want them to be different depending on the user input. And then it's going to publish the GitHub to our repository URL. And then it's going to import that to the catalog registered using like, you know, hey, go to this repo and take the catalog info YAML that has the backstage information. So let's go ahead and create this in template YAML. So I'm going to create a skeleton folder that will be essentially what's going to go to the repo. And component, this is where you see the go templates that backstage parses and replaces catalog info. Without that catalog info YAML, you can't register the like your service to backstage. We're going to have a very simple back package JSON. Why do I keep opening this JSON? And then we've got our basic simple hello world. So one thing to see here, like, you know, I have templates in actual code as well. Like for example, when I create a repo, I expect this to be replaced with service name and owner, which is like, you know, something that we're going to use in crossplane part of the side part of the code as well. So let's continue server.js. And I have a typo here, as usual. Cool. So we've got our first backstage. What is it? Okay. We've got our first backstage template. So we're going to commit and push. And then we're going to go to backstage and click create. Okay. Okay, cool. So I'm so I'm going to take the URL of that template YAML to import it to backstage. It has a really nice integration with GitHub that is able to figure out, like, you know, how to fetch anything from from a GitHub repo. And we imported it and we got it and create and you see hello world on Kubernetes, our own, our own templates, KubeCon. And you see, like, you know, how many times I had to try. So move off. This is creating our repo with our own, like, you know, hello world code. Let's see. Yeah. And as you can see, server.js has like, it's replaced with owner and KubeCon and A2. So for example, if you have images or like, you know, GitHub actions, especially, it's very, very useful. You would need to change it like image tag and or image repo. So you need to have, like, you know, some sort of templating in the scaffolding code as well. Cool. So I'm going to clone this very new repo to, was it ER or MPM? It's just MPM start. And let's see. Of course, it's not HTTPS. Cool. So I just, like, you know, went through, like, very small cycle, very simple app. Like, you know, hey, I'm a developer. I just want a hello world on this specific language and I created it through templates. So this is, like, you know, mostly just backstage and backstage and GitHub magic. So in the next step, we're going to go through, like, you know, hey, let's add image and ham chart because we want to deploy this to our Kubernetes cluster, right? So we're going to add image and chart to our template. So we need a Docker file. Well, let's change the metadata to something new so that we have a couple of, actually, let's copy this and create a completely new one. Okay, I have the code here. Okay, this is not the template repo. Cool. So I have one template here right now. Even I can't see it, but zero to hello world. So I'm just going to copy this into another image chart. Cool. So I am adding a Docker file, which is very simple. I think Heroku also supports Docker files, but I'm not 100% sure. But we have to have it. Docker file for bills, just alpine npm install and run it. Very simple one. So let's build it to make sure everything is tight. Cool. Because we aren't going to, it hasn't gone through the backstage template. It's just like, you know, prints whatever was in the skeleton. So the next thing is we're going to have a ham have a ham chart. We're going to have a ham chart, but there's a detail here. And I think people who work with ham charts a lot will be able to catch it is that if you, okay, in my image chart folder, okay, so I have, I should just use VS code for creation of everything. Okay, I'm adding to the skeleton a chart folder. And it's going to have its own templates folder and also values file. Values. Yeah, I'm all and also chart. Yeah, I'm all. This is a little bit as you see, there are like, you know, some backstage templating here. And I know, like, you're going to realize that, you know, hey, actually, that's what that's how ham does it too. And I put that tag here because when I build it, I want it to be the get commit. We're not, we're not doing much, much versioning really. And this is like, you know, how I'm going to deploy my hello world application, just a service and the deployment. The one thing to notice here is that this, like, you know, notation without this, like, you know, the helmet backstage would like, you know, it would clash essentially. For example, if you if you don't have it here, then this dot values, but backstage would try to interpret that and would fail because there's no, like, you know, image intact in the user input, right? So you put this row and end row as beginning and end of the parts where you don't want backstage to touch. It just treats it as like, you know, plain text. So service dot YAML. Cool. We got it. And here, as you can see, like, you know, these two things are going to be replaced by backstage, but this part is going to be overridden by values. YAML. And I will add a GitHub action in right now to replace this tag with the commit once it builds the image chart. And yeah, and our GitHub actions will essentially be, hey, like, you know, check out repo, Docker build. See, this is, for example, this builds, like, multi-platform images, right? We don't want your developer to deal with that at all, right? So we are able to just take that load from them by having it just in the SCA folder. So I'm going to create the GitHub action folder. Cool. And in this CI dot YAML. Okay. So I think this is, yeah, now we're going to, like, you know, create a new commit and push our new image, new template, actually. And let's go and register it. Keep contemplates, image chart and then template YAML. I'm just going to use this. Import. Yeah. So when I go back to the create menu, I have any software template that I can use. That's what they call them. And I click choose. So I create this repository. And this time it's going to do a little bit more magic than the first one. Cool. It's been created. Let's go and see it. Okay. Now we've got the initial commit. It has GitHub workflows, and it started to build the images, like, you know, and it's going to build hand chart OCI image as well. And it will push to GitHub packages to be ready for consumption. And yeah, it'll look like just like this. Yeah. I mean, we can deploy the hand chart, but I think we're a little bit on time. So I'm going to, like, you know, just skip to the next step on where we use these images with Argo CD. But if you want to look at it, how it's going, yeah, it's just building lots of stuff. For example, in this scaffolding in GitHub action, you can have like all technologies like image scanning and everything so that your developers don't really like, you know, need to be careful about those or you don't need to have a wiki page about how to like create a new project in this language. Cool. So packages are pushed. See, like, you know, two packages and developer didn't even do anything. So we're going to create just another template now. Template that is exact copy of the earlier one, but with some changes. Cool. And let's change the name. Hello world with github. Cool. So one thing, this is where we add custom action to backstage. So the extensibility story of backstage, essentially, you make some code changes. And I had to write a new like module for for it to interact with Kubernetes because right now, as far as I remember, there's no like action to interact with Kubernetes. There's core Kubernetes integration with backstage that reads files and shows the status if the labels are right. But there is no nothing like, you know, hey, go create a deployment or go create anything and on the cluster. So we I have written this like, you know, it's, it's a very simple, but I don't want to want to go into details, but this will let us have the custom action that will create an Argo CD application as part of the scaffolding. And the reason that we did, we don't do this as part of GitHub actions that I don't want GitHub repo to have access to my cluster, because my cluster is kind of cluster is private and private clusters are like, you know, everywhere, right? So you don't want to have like, you know, you may not want to have, you may not want to give typical config to the repo. Yeah, so we're going to go back to our backstage implementation and add this npm packages. So I'm going to show you how you can add them, you essentially to register them in the create plugins part of the application. So I'm going to packages and backend. Here you have the source plugins, and then you got the scaffolder. That's what we're concerned with mostly. And now it doesn't do anything. It just create router with defaults. And I'm going to change it to essentially initially initialize the built in actions and add two actions from my package. One is Argo CD create have an application. And the other one is wait for last workflow, because we want to create the repo wait for the action to complete to push the images and create our go CD application to pick that up. Cool. So we just added that and let's see if it's all good by running it locally real quick. So there's an endpoint called create where we can go and actually create actions. Cool. So this is like a list of actions that are registered in this backstage instance. And when we go to the bottom, yeah, our actions are here. So we're cool. All good. And in addition, our backstage service account needs to have permissions to create these Argo CD applications. It doesn't have them by default. So I'm going to cat. Cool. I just created the permissions, but I'm going to have to like, rebuild and push it to the cluster. Load it to the cluster. Cool. So this is like, a little bit different than Heroku in the sense that we're going to create the repo actions, build the image and like an Argo CD to pick up. But when we make another change, Argo CD is not going to automatically pick it up because Kubernetes or Argo CD, as a concept, they work with like an image tags and they don't continuously check whether there's a new image pushed to that image tag. And if we push like, you know, different tag, then like, you know, something has to go tell Argo CD, hey, there is this new version or digest has changed it, right? So there's a small project called Argo CD image updater, but it doesn't quite work with GitHub container registry for some reason. So we're not going to have like, you know, hey, I'm going to make a change and like, you know, it will automatically propagate. But for the first run, it's going to do that. And then later on, I'm going to update the tutorial with, if they fix that problem, essentially. Yeah. So we have, we have to rebuild the, like you have to do this rebuilding for templates as well. But as I mentioned, we enabled it to be able to like, you know, import that from the UI. Cool. Yeah. And I have to kill the backstage pod so that it picks up the new image. Cool. It's going to come up in a minute. And also, these are like, you know, two new steps that I have to add to my scaffolding actions. One is GitHub rate. And the other one is Argo CD create. So let's go to template.yaml right before registering. I would like it to wait for the workflow to complete. And then Argo CD is going to create it. Cool. So I have just pushed my new template. And let me check if Argo CD is up. It is up. This is nice. Port forward. Yeah. So I'm going to, because we're using in-memory database, all the existing templates are gone. So I'm going to import the one that we just created from scratch. Argo CD1 template. Yeah, I'm all registered and import. Cool. Choose it. Move off. So we're just like, you know, going through the same cycle, but like, you know, with different setups like one by one and create. Okay. This is actually not worked. There should be two more steps there. Let me check. Let's go to our template and did we not commit? Okay. I forgot to save, of course. There is no way around it anyway. Cool. So I just like, you know, refresh the template. And yeah, it's all here. I am going to have to register it again. But this time the button is going to say refresh. We got that. I'm going to create another one. Keep calm. And create. Cool. Now we see our action step. And while it's doing its job, let's go to the next step, crossplane, which is the part that I'm most excited about. And in this part, we're going to first, without templates, as a platform team, we're going to define an API for buckets, right? And it's going to be like, you know, it's going to have only one parameter location. And we're going to include its custom resource in our hand chart. And then composition is going to have like, you know, hey, I want a GCP bucket that is going to be managed by a service account. And I will have service account key whose credentials are going to publish in a secret. And I'm going to have like I am member key ring crypto key so that it's encrypted like lots of this infrastructure so that developer does not have to know that it depends on our environment. So I'm going to install it this to my cluster, but not to the templates or the Git repo. So let's check the earlier one. What are we with it? Okay, it's still, yeah, it's still waiting for the github action. Okay, it's, it's completed. So let's look at, okay, it just came into here. Fill the fetch. I know. That's weird. Let's see if the package made it here. Oh, the version is 999 for some reason. Well, let's, let's move on to the crossplane and we can fix it there for now. But, but that's the idea, like, you know, the continuous integration part is kind of like, you know, end to end complete. Now I'm just going to like, you know, improve the skeleton scaffolding by adding like infrastructure resources. So let's copy this template as well. And you're going to see like, you know, in the next part of the presentation, so that is going to show like way more advanced stuff that is built with this methodology crossplane code. Okay, so I am going to create a YAML for, let's say platform that YAML, this is not going to be interpreted by backstage at all. It's just, I'm going to like, you know, keep still apply it, but it could be, you can have it in the single repo, keep templates repo, but it doesn't have to be. In addition, I'm going to add my composition. There's a copy button here that I never use. Cool. So, so as I said, like, I have to apply them like independent of any templating or backstage or anything so that environment gets ready. In production, I can use this in dev. I can use like mean IO composition, right? So that, hey, I'm going to, I'm going to create a crib. Hey, this is like dev environment. So you're going to get to a bucket with container. But in production, I want you to have like, you know, encrypted bucket as long as the secret and token is the same, like application can talk to both. Then like, you know, I can manage my environments as I want to. Cool. So this environment is production environment. And I have like, you know, encrypted and like, you know, limited bucket. So this part is good. Let's change the name of the template to anyone, not just application with bucket. The rest is pretty much the same. Except the new steps didn't make it here for some reason. Let me add the new steps. So we're creating like, you know, our go CD application targeting this chart that we publish, but the chart had a, had the wrong version for some reasons. So we're going to fix this in GitHub CI. Yeah, there it is. I was trying something and I shouldn't have tried it. Okay. So this is also fixed. We've got the image chart, our go CD application, our platform is ready. So what we are going to do is to include in our chart, like, you know, hey, I'm a service that I'm, and I'm going to use a bucket. I'm going to need a bucket, right? So bucket that, yeah, I'm all, let's go back to the crossplane part. Yeah. And this is all my developer needs to know, right? Just a very simple API with a single parameter, even location us, and then they are able to give, like, you know, hey, publish your credentials to this specific secret. And what I'm going to do is like, you know, mount the secret to my service so that when the whole thing deploys, first bucket is created, and then my application comes up with that credentials, and it works with the bucket. So this is like, you know, I didn't have to give GCP credentials. The developer didn't have to know anything. It's similar to, like, you know, Heroku's add-ons experience that they just, like, you know, use the, they just need to use their moment variable. So our Hello World application is going to have to change because, like, you know, we need to interact with Google GCP bucket. So this is a very small, so this may be like really bad TypeScript code because I'm not a TypeScript developer. And honestly, I kind of hate it with the yarn and NPM, but just bear with me. Okay, so what it does is essentially every 32nd, it generates a file, uploads it and lists the files, all the files from the bucket. So this is going to be our new application in server.js. And we're going to have a new dependency, which is Google Cloud Storage. Okay, so server.js is okay. And package is ready. Lacker file is okay. Yarn log is there. Okay, cool. Yeah, I think, I think we're there. We don't need to test it in local at the moment. So, yeah, as I said, like, you know, we just created this bucket. Yeah, I'm all in the chart. Let's make sure it's there. Now my service definition, the deployment needs to change. What I do here is that, like, you know, hey, take this credential and mount the Google Credentials JSON as credits.json, and then mount its address so that the GCP client can see it. One of the nice things about cross-band composition is that I don't have to know the composition to know the secret keys. It is defined as part of the API. So we don't define only the parameters and fields, but also connection secret keys that we can use so that we know what to mount and composition is responsible to populate those fields in the connection details. So I'm going to add here. We're going to mount it. Cool. So that's the final state of it. Cool. So I'm going to deploy this guy. That's, well, not modules. I don't want this. See, I told you I hate this. Okay, this is more sane. Let me just check whether we changed the metadata of the template. Yes. Cool. So we just pushed our new template to our repo. We're going to use it and we're going to see all coming to fruit in our Go CD UI. Register it, analyze. Cool. Okay, so I think we're getting closer to the production platform right now. This is not just application with Bucket and you're going to have go application with something else. Or in case of, for example, a group of folks have one application and input as like, hey, do you want RDS instance? Do you want Bucket? It's like a really rich UI. Keep going. NA6. Yeah, so while it's doing its job, this is kind of the last step that we showed the integration. Next steps for like, you know, like where you can take this angle, right? It's mostly like you can, for example, you can make different choices, like githubs, in githubs, most of the people, they have a different repo for deployment, right? So instead of like, you know, Argo CD picking up from the actual code repo, you can have the GitHub actions to open a PR there, go through some checks, and it would update the Argo CD application from the repo that is used for deployment, right? So because like, you know, we're just, we just have all these like standardized frameworks and applications on Kubernetes, we can just like, you know, edit all parts of the architecture. And you can use Argo CD image updater, which uses like, Semmer updates and everything. So I think it's pretty cool project, just didn't work for GitHub container history. And you can like, you know, add more input parameters, right? We just added Bucket, but you can add like, you know, hey, Bucket, but you can, you can add like, RDS instance and ask for only storage. And once they click, it creates like, you know, this most secure RDS instance in your VPN or IAM roles and everything. And the funny part is like, you don't have to give them the credentials. Instead of like, you know, like, for example, if you have to do it in Terraform, you have to give them the credentials. But in this case, you don't really. And when you make a new change, you just add another YAML to your hand chart. Hey, I wanted Bucket, but now I need RDS instance. You can just add the database and git push and new release. And you got your infrastructure ready for you. So it's all like, you know, it's part of the same pipeline, just application and infrastructure together. Cool. So this one has created our repo. Let's see. We got it images are pushed. Let's see. And our CD unknown, I think this is trying to fetch the image from GitHub container registry and Internet is too slow. What do you mean? Okay, I think it takes the wrong URL. So I'm going to edit this to fix it. It's probably in one of the skeletons. I got the URL wrong. Okay. This should be correct. Now, did they just implemented pull limits or something? Okay. Nice. So what we see here, as you can see, lots of things happening, like, right? We have our deployment service, but also Bucket. Bucket claim. And it resulted in Bucket composite resource out of sync. It's sinking. It's got 20 events. Okay. So it has created first a service account, service account key, crypto key and curing. So the reason that these are created before the bucket is that they are required for bucket creation. Like we have to give the KMS key name. So they're going to reconcile and like, you know, get up to speed to apply. Let me see what's the error here. Container port required value. Did we have the container port missing here? Okay. So I should have used the one in. Yes, I'm just going to copy this and fix it in the repo edit this file commit. I'm going to have to break this first and then have it refatch it. Is it really ugly? Okay. So I'm going to edit this deployment in the cluster to fix the problem. Apply dash and keep going. It's not even able to apply it. So let's delete this and let's sync it maybe. I have gone through the same thing a few times. It should have worked, but okay. So I'm going to delete this so that it fetches the new hand chart default automatic not get hand chart. It's going to be jr.na6-chart auto create namespace. Okay. Let's, let's create a new template because this one is not actually refresh the template with the fix and create a new repo. Yeah. As I mentioned, you can follow this tutorial when you get back from the conference. And as the next steps, like, I think there are like lots of things that can be improved. We can have different clusters and your Git repo could have branches like dev, prod and like, you know, main, let's say, and then those branches could just like, you know, push to specific clusters, which is similar to what, how Hiroku, I think they call it pipelines. They've got like their pipeline, prod pipeline and other pipelines, whatever you want to name them. So you can like, you know, you can get a little really, really close to Hiroku experience and still have your own like, you know, say in your network configuration infrastructure and everything. So let's go to NA7. Let's check if our fix made it. It actually didn't make it. Chart. Okay. So it says container port is required, but it's not there. And I just edit the file, add it by my hand. How can I think I added the wrong template. So I'm just going to copy it again. Sorry, folks. It's going to be okay. Okay. Okay. Now I got my new employment with the container port. I'm going to go to templates, crossplane template. Yeah, I'm all and refresh it, create a eight one. This is too much. I'm glad GitHub is not asking for money for this. So cool. This time it should work. Meanwhile, we can take a look at the Argo CD. Let's just delete the old ones. Okay. So our repo is created. So we're just going to take a quick pick, chart, templates, service. And yeah, right. Okay. All good. So yeah, this is kind of like roughly it. We're just going to wait for the image and also like, you know, bucket provisioning to complete. Yeah, but I think like, you know, that is kind of like wrapping up our tutorial. While we wait for it, do you guys have any questions about the architecture or looking at certain steps or frameworks? Can crossplane import existing infrastructure? Yes. The crossplane resources have a notion called external name, which is the way how it identifies a resource in the external API, which is like, you know, AWS API, let's say. So if you use like, if you create the ML with external name annotation and give the VPC ID when you create that, it's going to come up and say it's going to adopt the resource as if it was the one who created it. So yes, it would be possible. And you can do this in scaffolding as well. In composition, you can say, okay, like, I'm going to ask an optional parameter from user if they want to use the existing cluster, right? Or existing RDS instance, and in composition, they can patch that external name with that input parameter from user. So when they create any application, they can just point to something that that already exists. Any other questions about these parts? Oh, it's coming up. Okay, I'm just going to edit this. Small fix. I am calm. Oh, good. Okay. Oh, nice. It's all coming up. Pot it. So see, you did the pot is going to wait for container creating state for a while till the bucket provisioning is completed. And we see here that crypto key events is being created. Okay, Jason, I think my credentials might be wrong. I have a script, but I'm just going to apply this. Okay. So this is going to take a while. I'm going to hand over to Siddhartha to show their production environment built like with backstage cross pane and our go CD. And like, you know, a few other tools as well, all integrated together. Yeah, you can take it. It's working. Cool. We are going to share a little bit how group of what you can implement those tools, use the same ideas to make our developer day to day easier with removing all the complex that they have to create the ICD and the infrastructure and the cloud resource. So first, who is group of what you carry is group of what you carry is a Brazilian beauty company with 45 years of foundation is not built in the cloud. We have 44,000 employees. We have more than 4000 stores. We have two factors and native distribution centers. We are a multinational company. We are present in Brazil in another 15 countries, including us. We are the largest network of franchising the world. And we say that we are very complex ecosystem of beauty because we go from the industry to the point of sales to the logistics to our details to the labs to our omnichannel and we are through omnichannel company from the resource and development products to our clients. And we say that we are omnichannel because we have e-commerce. We have physical store. We have door-to-door sales. We have our distribution channels. So we are truly a omnichannel company and a multi-brand. So we have a bunch of brands. So that is a very complex ecosystem. And if you want to know more about our company, you can Google it. But how about try your products? You can go to this QR code and have a 15 discount on your first purchase using the cube 15 code and our marketing will be happy. So why you decide to create our internal developer platform? In 2019, we start our digital journey and a lot of say digital transformation and we can summarize that transformation into four pillars. We have two huge data centers that we are moving to the cloud. At the same time we are moving to the cloud, we are breaking our monolith applications into microservices. We are even moving how those microservices integrate moving from IBM bus to Kafka and APG and we are moving from an appropriate stack to more open source language. And because we are moving to the cloud and create a bunch of microservices, we need to give to the developers the autonomy they need. So that is why we start our internal developer portal. And basically the main idea is to make our developers day to day easier. So our internal developer platform in Portuguese we call PDD is the initial in Portuguese. So it is a bunch of tools, templates, utilities and automation that bring all the infrastructure, architecture, infosec standards to our teams. So developers don't have to worry about it. So basically it's a self-suffer portal that developers just fill some basic information and they have the application, a production grade and easily we are going to show in a few minutes. So the tool set that we are using is the same as you show in the tutorial. Our entry point is the backstage and we have our templates. So we do the Apple scaffolding, create the CI CD. We integrate with the toolings that we are using, that New Relics, Sonar and we go to the CD step using Argo CD and all the infrastructure that we provisioning we are using cross-plane. And our main provider is AWS. So I have a video if my Wi-Fi not work. So basically we already saw the backstage interface. So I'm not going to deepen the technical, I would say show basically the developers workflow. So they want to create a new component. We have a bunch of templates, the golden paths that are all built in. So FastFly, Serverless, Caught in Jungle. We have our front-end application as well and a more generic key for Docker and Slack, for example. Let's suppose that I want to create a FastFly application. So here is a minimal documentation of that template. So the developers know how that works. And we try to get the minimal information from the developers. They need basically the valor stream is just like a business unit. And they put the GitHub from the team. So basically they can fill the components. And then we go to the infrastructure part. So it gave them the autonomy to create the replication and create an infrastructure. So they can say, okay, I want to create a database. That's not 2002. And again, we try to get as minimal information required. We see there is no VPC ID, no even security group, anything. So they choose the engine type. So let's say I want to create a Postgres and the version. And I can even add more resources. So suppose that I want a S3 bug. Again, I can put a name. This is the same name, I guess. There is some validation. Should work. Yes. So after I select the template and choose the resource that I need, I can create. And that will take around 10 minutes to scaffolding the repository and provisioning the infrastructure. As we don't have that 10 minutes to wait for, I just have another repository already provisioned and created. So for our developers, they go to the backstage catalog, and they see all the information from their application, the repository. And we go there in a minute. They are go CD. So they can see the state, the new relic information, the sonar cube, and even the CI steps that, in your case, we are using GitHub actions. So if you go to the repository, I don't know if it's too small, we have in the same repository, the infrastructure and the application help values basic. So you can see the application information and the infrastructure. Basically, we scaffold the infrastructure. And we populate all the parameters. One thing that our fine ops team is happy because we put all the tagging to keep the cost. And we are using GitHub CI to do the CI and triggers the action in the Argo CD. And we can go to the Argo CD and we have the basically Kubernetes resources for the application. And we can see as well the resources, the cloud resources created by cross plane. So you can see that's the RDS. We see the RDS created. And in a few minutes, we have the application up and running and just the basic application that is basically one health check. And we have the resource. So we can see the database created. And we integrate the tooling that our developers need when integrated. So we go, they don't need to worry about integrating to new relic, to configuring their logs, to get the credentials for the database. We inject those credentials for them. So that's basically the workflow of our developers. And what are the benefits we are seeing with this approach? So currently, we are using our internal platform by our teams. We have 100 AWS accounts managed by this platform. We have more than 100 night applications, building user platform. We have at the moment 13 templates. And we have 195 resource. That could be a bucket, a database, a DynamoDB. And what are the benefits? We give the developers the autonomy they need. They don't have to talk to the infrastructure team to ask anyone. They can go to the portal and provisioning whatever they need. We reduce or deliver time. We don't have more jira ticked between teams. So we get the moment the developer asks for a repository until they have the host infrastructure provisioning takes around seven days. Now we can usually around 10 minutes. We can ensure our security and monitoring standard. So we put this image scanning, code scanning, all in the pipeline. We keep in the same repository, the product life, and the infrastructure information in the same repository. And because we are working in the same structure, it is a bunch of standard, we can have the teams collaborating better. So it is a pretty nice journey. And basically that's it. Thank you, guys. Feel free to reach me if you want to know about what we are doing. We would love to talk to anyone working on the platform because it's something new for us. And that's it. Thank you. I'm just going to show that it finally worked. I would die if I didn't show it. So with all the yellow screen and everything, I think it's finally come up. Okay. Yeah, just similar to the Argos Edis screens that Siddhartha showed, which were way more advanced. But here we've got our application, deployment, and then bucket. And it provisioned like in all these bunch of infrastructure, crypto, et cetera, service accounts. Finally, it published its own secret that has the credentials and it's mounted to the pod. And if we go to the pod, I think we're going to be able to get the logs. Actually, we can take a kind cluster is gone. Okay, my cluster is busted. But yeah, the secret is mounted and pod is running. And if you have any questions, you can come to here or cross lane booths or upbound booths. We would happy to take them. Thank you, everyone. Thank you.