 All righty, thank you so much to the Linux Foundation and Canvas for having me. And to all of you who are dialing in today, really excited to share with you what I view as the culmination of the work I've been doing so far at Upbound with Crossplane. So as the title says, we are going to be building something today. We're going to be building a developer self-service platform using Kubernetes and control plans powered by Crossplane. So we've got a lot of content to cover. Let's jump in. I'm really excited. But first, quickly, who am I? I've been working at Upbound in the Crossplane community since 2022. Before that, I was at Microsoft working in the Kubernetes ecosystem. And I started my career in 2017. I've worn in the cloud. So ever since I've left Purdue, I've been working on helping improve the public cloud. So at Upbound though with Crossplane, I've been talking with hundreds of teams from all over the globe, all these different organizations understanding what they're trying to solve with Crossplane. And it's amazing when you look at that, that's just have that broader scope of all these different conversations. Many organizations are trying to all solve the same problems. And there's a common theme and reason for why they're trying to solve those problems. And it's all around developers and Crossplane. So the objective, though, for this, for the 50 or so minutes that we have together is we are going to build something. That's the knot at having a to-do comment. We're going to build this developer self-service so the customer for this product, this platform that we're building, is application developer teams. And we're going to build it above Kubernetes, using control planes. And of course, powered by Crossplane, which is the framework that is going to enable us, that's going to give us the building blocks to build this thing. And you know, a quick word on the enabling developer self-service and our customers, the application team, there's this, this trend that I see in the industry about operating platforms as a product. And I think that's very fitting because as we're going to go through is you're building with control planes and you're building these custom APIs with these building blocks. It's very important that you approach this job as one of a product and as one where you are delivering something for consumer teams. And you empathize with those teams and the struggles that they have and you're in tune with what they're trying to solve. So with that being said, let's look at the agenda real quick for how this is going to shake out. The first topic we'll cover is just a description of the problem for developer self-service. So why are we trying to solve this? What are we trying to solve? I'll give a brief explanation of control planes. This talk is not, the focus is not cross plane 101, but we'll recap a couple of the core cross plane concepts before we dive into using cross plane and Kubernetes. And then we're going to shift over to talking about a baseline architecture for this thing that we're building. I've got a demo prepared that I'll show you that takes the stuff I'm telling you today and puts it into practice. This is the end of the chat Q&A. I'd love to hear your questions that you have about cross plane. So thinking framing the problem statement is, you know, enabling developer self-service. I think the ultimate question is really how do you enable app teams to ship software faster? Because for any organization, if you can ship code faster, you can respond to your users' feedback more quickly. You can be competitive against other products that you might be competing with and you can delight your users faster. So the ability for an organization to empower app teams to ship software faster I think is very, very important. And when I've talked to these hundreds of organizations, this is, you strip it all away, this is really what they're after. There's six different ways that I think about, you know, how we can improve that. One is enhancing productivity. So the developer team is spending less time waiting for the JIRA ticket that they filed to get processed and the infrastructure that they need to power their new application that they're building to get spun up so you can shorten that time so they're more productive. Secondly, they get compliance out of the box. So if there's a platform or an interface they can go to to say, hey, I want the company approved Kubernetes cluster because I'm going to build something in Kubernetes, then they don't have to worry about how it's been configured and to avoid non-compliance issues where another team comes along as as, hey, we got to shut down your infrastructure because you've misconfigured it. So you're taking away that cognitive load with this developer self-service if you have compliance out of the box. And the third way is with pre-tested configurations is you can give app teams starting points, well-defined starting points that are common across your organization for a set of infrastructure that's all related together and bundled together as a jumping off point for them when they're launching in the application because more often than not, when you're building a new line of business, it's probably going to follow the pattern that you're already using elsewhere in your organization. So you can build this pre-tested configuration that's good and then you can use that as a starting point. Fourth way, so providing a common way to do things across an entire organization. So as we think about this idea of building a self-service developer platform, there's now this common entity that you can interact with to collaborate and a common way of doing things really. And then you've got abstractions that up-level the need for app teams to understand the infrastructure that's going on. Once we've got this platform and this interface, you can now start to abstract things above and or abstract things below and make it easier to process things above. And finally, for some organizations that I've been talking to, they have a multi-cloud footprint. So they run in a couple of hyperskill cloud providers and they need to support infrastructure across those. So there is a desire to realize a platform that gives you this common abstraction across clouds so that if there's a disaster recovery scenario or some need to pivot into another hyperskill cloud provider, you've got that ability there. So those are the six things that I see is ultimately boils down to how do we help our app teams move faster, but six values that you get as part of also doing this. So let's do a quick recap of cross-plane and control planes. Think about this as a thermostat. I often get questions describing, what do you mean by a control plane? Perhaps a good analogy is thinking of a thermostat that's probably sitting on your wall in your house. There's an interface to that thermostat and its responsibility is to control the temperature in your home. So there's a control loop that that thermostat has. It's constantly checking on a cycle, whether or not the temperature is above or below the desired temperature that you've defined. And if the temperature becomes too hot, more than you want, then it's going to turn on the AC. And if it's too cold, it's going to turn on the heater. And your interface to that thermostat, in this case I've got the ecobee on the slide, it's just a slider or it's a knob or it's a button and you set your desired temperature. And then the thermostat's job is to maintain your desired temperature. There's no analogy, but it still holds. So as we think about Kubernetes then, Kubernetes job fundamentally is to maintain desired container infrastructure. You define your application as a set of containers, a deployment, and other aspects, you deploy that and then Kubernetes is going to maintain that desired state. So if positive were to crash unexpectedly, Kubernetes job is it's going to recreate them. If you provide a new deployment configuration, it's going to make it so. And the interface to Kubernetes is fundamentally the API server. And as I'm sure all of you are aware, kubectl is a command line tool that you can use to talk to the API server as a convenience. So you can get pods, you can apply configs directly to kubectl. What it's doing is that that CLI is ultimately making a call to your API servers endpoint. And so Kubernetes is a control plane for container infrastructure. But as we think about the thing that we're trying to build this developer platform that is helping teams move faster by consuming cloud resources, because that's fundamentally what they need when they build new apps, because when they run the applications, we need something else. And so that is a control plane. Its job is to maintain the desired cloud infrastructure. So it's up leveling it it's going it's going beyond just containers to the entire cloud, or any sort of SaaS service actually it's quite amazing. And the idea is, you submit a request to your control plane and it's going to fulfill it. If the state changes with some request of configuration that you made earlier, it's going to fulfill it or if it was made mistakenly. It's going to correct it if it's if it's drifting from the desired state that you've declared it to be. And so that's the job of a control plane. And so what's the interface that control plane. That is where you come into crossplane. Okay. So crossplane is the cloud native control plan framework. What it does is, it allows you to build control planes without needing to write any code. It's built on the foundations of Kubernetes so it sits in the Kubernetes ecosystem. And it gives you the building blocks. It's a framework it gives you the building blocks to to build your own cloud platforms. And thinking back to the beginning of what are we trying to build is a self service developer platform. That is a kind of cloud platform. Definitely an internal developer platform a self service developer platform. That is a cloud platform. And so you can use crossplane to build them. So think about it like this. And you, you have your control plane sitting there in the middle of the screen. And above it are a set of interfaces that talk to that control plane. Argo CD, which is a CD engine that we'll talk about in a little bit. It could be home. It could be a front and like backstage, which we'll also talk about here in a few minutes. You've got these interfaces that sit above your control plan that talk to your control plane. And then below your control plane is the important part, because that control plane needs to then interface with whatever underlying infrastructure it is that you want to talk to. If you're in an AWS shop, you need to talk to EKS, you need to talk to S3, or maybe you're an Azure shop and you want to talk to AKS or Azure web apps or what have you. There's infrastructure that's below your control plane. But it's not just limited to the public cloud providers, hyperscale providers, it can actually be any other service that has an API that's available effectively on the internet. If you wanted to talk to a provider to GitHub to create repositories from your control plane, that's something you could do. So there's basically infrastructure that sits below your control plane, and there's interfaces that sit above your control plan. And so cross planes right in the middle of that, because cross plane is your control plane. The second thing that cross plane gives you is, for one, it's fully open source. It's an open source project built on Kubernetes. You can find it at github.com cross plane cross plane. It's in the CNCF is contributed by up on fully open source project. So that's one thing that cross plane gives you the second thing is it gives you as I was saying before the building blocks that you need to go and build your cloud platform. What I mean by that is, you know, the resources that you want to talk to the cloud providers you want to talk to with your cross plane is going to vary from your organization to the next. So, what cross plane has done is it's provided the building blocks that we call cross plane providers that go and do that stitching together. So there's a set of building blocks that you use. Furthermore, it's extensible. So like I was saying earlier cross plane sits in the Kubernetes ecosystem. It gets to take advantage of all of the benefits that the Kubernetes ecosystem already provides. And we're going to talk about that in a few minutes when we get to architecture. But cross plane is incredibly extensible. And lastly, it gives you the ability to create your own API abstractions. Not only do you need the ability to have your control plane go talk to a cloud provider to create an S3 bucket or create an EC2 instance. But you also, as part of this developer self service, the whole idea is we provide an abstraction to our developers. So they can interact with that abstraction that under the covers goes and does all the things our control plane needs to do. We call that abstraction an API. It's an application programming interface. It's an interface to our control plan and cross plane gives you as well as the building blocks, the, the framework, the capabilities to go and create your API abstraction. So cross plane basics. Like I said at the beginning of the call, this is not something that this is not meant to be a cross plane one on one talk. You can make a loss over some cross plane concepts and assume that you know them. If you're not familiar with cross plane that this is your first time hearing cross plane because you dialed in because you wanted to learn more about developer self service. And you don't know about cross plane. One great way that you could learn about cross plane is by going to Victor far six videos who's on, he's got his videos on YouTube he's works at up bound but he makes incredible content for for the community and he's got a lot of great videos on cross plane so go check them out for sure. Okay, so we covered just a little bit about cross plane. Now we're going to pivot and focus in on what does it mean to do developer self service with cross plane. So the things that we need so we've got a control plan there in the middle, it's tethered to Kubernetes because you install cross plane into a Kubernetes cluster. So hence, that's our, their control plan instance. So the first thing that we're going to need is we're going to need an interface to to our control plan to that that API abstraction I was talking about. Oh, excuse me, we're going to need the API extraction that's what I was talking about the interfaces backstage report or something some other front end to our developer self service, excuse me, and then we'll need our own API abstraction. Third, we're going to need to then integrate from those API abstractions with the external cloud services that we want to talk to. And finally, there's likely a set of ecosystem integrations that you may want to consider applying with cross plane to to help you achieve your job. This again goes back to this idea that cross plane sits in the Kubernetes ecosystem. And so there's all this tooling like Kyverno, there's our ago for GitOps there's Valero for backup and restore all of these tools that the communities made that's applicable to cross to these that you can actually take pretty much wholesale apply to cross plane and reap the same benefits but now you're doing it at the cross plane level instead of just Kubernetes. So again, I'm going to demonstrate what that what that means, but those are the four key components that we need so interfaces and abstraction, integrating with cloud services and then ecosystem integrations. And the ecosystem integrations point as I was saying is you're likely to bump into these things as you think about building on cross plane and especially building on cross pin and a production capacity. So I think there's eight or so boxes up here right now. I was calling them out a little bit earlier but as you go and build with cross plane, and you build this platform as a product to support a set of app teams, you need to know how to that that control plane. You need to know how to make sure that if something goes down and been back up and store it, you need to think about where you store all of the artifacts that you're building. You need to think about front ends CICD. What do you do about secrets management, you know, there's connection details that you need to to ensure get to the right place for the the resources that you're creating. What are the policies and governance that you need to enforce. Do you need a policy engine. How do you integrate with your, your identity provider, all of these things in the ecosystem. There's tooling that's already available, and we'll be able to tap into that if we want. So the baseline architecture, this is I'm going to demo this for you in a few minutes but let me walk you through the baseline architecture what what I've built with cross plane for developer self service. So at the very top top of the screen, let's focus on that developer team because ultimately there are a customer there are consumer. They're going to interface with a platform front end that that one interface that I called out in previous slide. For my demo, I'm using port port is a assess service that you can use to build your own developer front end. You can use backstage backstage is another one that comes up quite a bit. I've talked with organizations who built their own homegrown web apps that as front ends internally in their company. Totally fine. There's a lot of flexibility here you do not have to use port, but I wanted to give port ago, and I'm quite pleased with it. So the developer team is going to talk to port which is the front end to our self service developer platform. So what port is going to do is it needs to translate the things that my developer teams talking to to the front end to cross plane. And you might think okay fine you just wanted to just draw an arrow directly from port down to cross plane. That's not actually the recommendation I'm going to make. One of the beautiful things about cross plane and existing in the Kubernetes ecosystem is you can apply get ops principles to a lot of your interactions with cross plane and we had up bound feel that this is a wonderful approach to take. And so it's what we it's what we recommend. So that port front end is actually going to to communicate out to get up, and it's going to store the cross plane resource claims that have to get created that you send to the control plane to say hey please go create XYZ set of resources. So it's going to go over and communicate to get hub and Argo CD or flux for the demo I'm going to show you today I've got flux configured. It's just a it's a CI CD engine. Either is great. They're the both wonderful pick your poison doesn't really matter. In the diagram I've got Argo I'll be showing you flux later on that engine is going to pick it up and it's what actually applies this the desired state that's in get over to my control plane. And then once you hit the control plane is a few things to call out. You'll notice the yellow box. I've listed a couple of the ecosystem integrations that I've configured with my control plan as a baseline. They are Valero, Prometheus, vault integration and Kyverno Kyverno's policy of vault is a central key store or secret management service that I'm using. Prometheus is for scraping metrics and then Valero is for back up in our store. The thing to remember is, if you're just starting out with cross plane. You probably don't need any of these ecosystem integrations you can get up with a very simple POC just fine without those. And cross plane has a way of managing secrets already, but as you start to think about what does it mean to go into production. It's that's when you're going to start to think about how do I leverage ecosystem integrations, otherwise I have to build stuff because it's likely that as an organization you're going to have a need to store your secrets and a central secret management service, and some using vault you could use something else. It's likely that you're going to want to be able to back up and restore the state of your control plane, and some using Valero. It's likely that your organization is going to have governance compliance requirements for how resources need to be configured, which I'll explain in a little bit. And then of course, we need a way to monitor this thing, you know, as it's running the production so that's what permit this is for. So, as a baseline, I've got all of that configured in this control plan in a very declarative way it's actually coming from GitHub as well too. So I didn't didn't touch on this yet, but not only are the claims to my API is coming from GitHub in that repo dot get. I also actually have the entire definition for my control planes configuration, sourced from get that actually applied to to my control plan into Kubernetes. And once all of this is done once the claim has gone through, submitted by the developer in my front end it goes to get our go or flux picks it up and applies it to my control plane. Finally then, our control plane is going to talk to the external cloud service. For the demo I'm going to show you later today it's integrated with GCP. So it's going to go create a GK cluster. So here's the thing. As you think about actually building a developer self service platform for your organization with cross plan. It's important that you. There's a number of business requirements that you need to collect before you're going to ever be able to actually go and figure out how do I architect with cross plan. I mean, we want this golden path for, for our app teams to be able to use, but that's going to require, you know, decisions about how we set up cross plane how we do our ecosystem integrations, what are the tendency requirements all of these things. There's a lot of questions that you have to think about. So I wanted to just walk you through at a high level some of the ones that I hear time and time again. As a, you know, very first question is who's going to use your platform. Is it application developer teams or is it some other team group of teams with a different responsibility in your organization. As a cliche we think of the developer self services strictly targeted teams but you could also build self service platforms that are used by other functions in your organization. Let's say like sales engineers or folks who need to an abstraction to go and bring up infrastructure without understanding the native gritty. So you need to think about who's going to use your platform. And then you need to talk with those, those plan, those users and think about what causes toil for them. At the beginning of the call when we were talking about developers and their toil it's usually the time it takes to just go and get a resource that's up and running that's configured correctly. But you need to depending on the platform that you're building for you really need to hone in on what is the toil that that those users experience. So once you've thought about that then you also need to start thinking about what is the interface going to look like what is the set of API is that you're going to offer. And for the sake of this call yeah I'm glossing over these things like these questions, what is your interface going to look like is a very like that's a deep set of questions that you need to think deeply about. And then it's going to take some time to kind of figure out iterate on what is that exact interface look like that we want to offer to our consumers of our platform. And as you're thinking about that interface, you know the inputs that you need to provide in the case of provisioning cloud resources like any case cluster. Maybe you want the ability so your consumer teams can set the number of nodes, or maybe you don't want that maybe you just want to give them the option of a small or medium or large cluster. But that's an input that they need to provide. And so we need to think about that incorporate that back into the interface that we're building. So there's a number of questions you should think about before you seriously consider building on cross plan and production. Otherwise you're going to get twisted up. Because you just you don't know what you're actually building it so there's a set of questions usually. And yeah so talk with your users understand their needs is absolutely the first thing if you're not doing this, your platform that you're going to build with cross plane is probably going to fail, because you're going to come out with a v one of something, and you're going to completely miss the boat. It's no different than building a product for commercial reasons it's you've got a set of users you need to understand their needs. And then business requirements beyond that. All the time is like how many control planes do I need. And it depends on your business requirements and do you have multiple software environments that you need to support thinking like a developer environment staging in a production environment or maybe you have multiple software environments across multiple regions, or maybe you have multiple software environments across multiple clouds. I, as Craig I don't know that but you do. So you need to think through these business requirements. So do you need to provision resources across clouds. How many teams are you intending to support. Do they need to be isolated from one another tendency is of course a big question that comes up. Is it okay if another team can see the resources that team team B is creating. You know, I don't know you have to tell me depends on your tendency and isolation requirements. Do you need to isolate certain resources to different cloud accounts is another one too. So if you've got like 10 billing accounts and AWS and you have to ensure that certain cloud resources are going in certain places. You know, that's a business requirement that's unique to your organization but you need to have that out on a list before you go and build a crossplane. And then lastly, you know what are your performance requirements how many resources do you intend to manage with crossplane. So if you've got 100 teams and each team, you know, creates 50 cloud resources as part of their requirement for their business application that's going to start to give you a ballpark for the number of resources that you need to support with crossplane and that sort of stuff. So this is all very important because as you go and architect with crossplane, the decisions that you make as to number of control planes you create, which tenants go where all of these things, it depends so heavily on your business requirements. So if you're feeling a little overwhelmed. Start simple. Start very simple. The questions I'm raising are things that you start to think about as you get past the initial phase of a POC with crossplane, and you start to build a roadmap for what does it mean to take this into production. So if you're not there yet. Start very simple with just a single control plane. Abiding by that baseline architecture that I was describing. Let's walk through what that means to have it just a single control plane and a baseline architecture. Here's the control plane. The first thing we call is that the total configuration is defined and get. So, what does that mean the API is the runtime configuration for that crossplane because you need to configure it so it can talk to GCP or AWS or Azure or whatever. The runtime configuration, the configuration of those API is your ecosystem interface integrations that you're going to lay down next to your control plane. All of that is going to be stored and get so you've got a single source of truth for your control plans configuration that's very important. So, for my case I've got Valero Prometheus vault and Kyverno. All of that the configuration of the helm charts for those things so it's all defined and get. On the API front specifically we talk about this control plane crossplane configuration. What that is is it's not only your API so your user to find the API is the custom interface that you've decided you need to build for your users for let's say any C2 instance or a vNet. It's those API's but it's also your dependencies on other crossplane configurations, and it's dependencies on the crossplane providers that you need. Recently, in crossplane we announced the release of family providers, which are scoped down, you know, tailored providers crossplane providers, so that you only need to to install the providers that your, your platform needs so it's it's more granular. There's less CRDs that you end up installing. So in this example on the screen, you know, I'm going to be taking dependency on the upbound provider AWS VPC EC2 and S3 providers. But going back to that number two in the middle with your crossplane configuration you can also declare dependencies on other crossplane configurations. So for example, upbound author this platform ref AWS, it's a reference implementation for a set of API's to provision EKS clusters, you can actually declare dependency on that layer on your custom top API's on top of it. And that goes into your total control plan configuration. So, you're ultimately going to build that as a package but the definition of all of this. It goes into get it goes into that single source truth. And that that is very important. So for the baseline architecture for even our single control plane. Let's use get let's use control plan config crossplane configurations. And let's have a single place to store everything. Popping back the cover on that control plan configuration and looking at what would the directory structure look like. It's literally this so it contains your API definitions. These are crossplane YAML, you know, objects so it's like you've got an XRD, you've got a composition. You've got that you have for each API like this is a kind of a classic crossplane concept. You've got your runtime configurations as I was describing with your provider configs, and you can also source your, your resource claims. All of this is declaratively stored and get. So even if you're thinking about just a single control plane. Use get ops, use a single source of truth it's going to make your life easier in as well too. So configurations and mentioned that there are some ecosystem integrations that I'm using. I have the configuration for those things defined in that same get source so you've got that single source. So in my demo. I've got backup schedules I've got my caverno policies for like S3 bucket public access denied. You know I've got an external secret store that I've integrated all of the configuration for those integrations that sit alongside crossplane. So you've got all and get you've got a single source of truth for for your control planes configuration. We find that's just very easy and it scales better because as you go up, and you decide hey I need to make 10 control planes. Each one's going to have a source of truth that you can look at to define the total definition. So if you've got that, that configuration of our control plane in place and get, then we need an engine to drive that configuration on to our control plane is cross planes over here are definitions over here we need something to bridge it. And as I was saying earlier that could be Argo, or that could be flux. You really just need a continuous delivery engine that's compatible with Kubernetes. That's going to sink across the desired configuration files from get over into the cluster. And it comes up as well where do you run Argo or flux, you could run it in the same cluster. If you're just thinking about a single control plane scope. That's the easier thing to do. So yeah sure just, you know install Argo into the same cluster where crossplane is, or flux, or as you're thinking more about crossband at scale. If you find that it's better to or easier for your organization have a centralized instance of Argo or flux running that you can then manage out to these external crossplane clusters you could do that too. That's going to scale better for for organizations that are looking at like a multi control plane architecture. But for just as the simple architecture of a single control plane, you can just plop Argo or flux right into the same same cluster is crossplane. Yeah, so this is the thing that sites talking about here. This is the bridge part that bridges are a control plane configuration to our control control. Alright so let's talk a little bit more about the top level interface. As I was saying, we need a way to interact with our control plane. And because crossplane is extending Kubernetes, there's an API server that you could talk to. So you can use kubectl to talk to crossplane to do stuff. But more often than not, that's probably not the interface you're going to want to expose to your users, you don't want to give them direct access to your crossplane. You probably want some abstraction because the whole point of this is to make it easier for them to simplify their lives to remove toil and cognitive overhead. So you, you might want to consider something like backstage port or some other third party front end, or homegrown interface that sits in front of your, your control plane really is the platform front end. And its job is to take an input from your users, translate that into a claim and get that into get as long as it gets it into get then that CD engine we were talking about in the previous slides going to be able to pick it up and apply it to our control plane. And then lastly on the ecosystem integrations and wanted to touch on each one individually. So get ops. If you're not familiar with good ops, it's an approach for managing a system where you, you know, declare your desired, your desired state and get. And then you use something to drive that desired state and reconcile it so that the, the realized state is the desired state. So get ops 100% compatible crossplane. Here's two examples of tools that you could choose to use that exists in the Kubernetes ecosystem. But again, if you have another tool that you like that is compatible with kube. You can use it on all means feel free to use it with crossplane. Yeah, so you're declaratively not only defining the control plane configuration but you're also driving the interaction with the API is because the claims are is what does that. And I'm recommending we put that all through get. So I think I've touched on this enough. Secrets management. So in crossplane secrets get generated for a variety of reasons, or are used for variety of reasons that could be credentials for a provider. They could be connection details to a resource, or perhaps there's a password, because you need to provide a password as an input to a database to a manager resource at creation time you know that could be a secret. And by default crossplane stores. If it generates secrets, it stores them as just Kubernetes secrets in the cluster. And that is a perfectly fine way to do things. However, as organizations think about crossplane at scale and in production. Oftentimes, they have central key storage services that they care about. So I see most often enterprises care about using a centralized key management service. And the point I wanted to make is this is something you are totally empowered to do with crossplane using the Kubernetes ecosystem. So, in the example I have the external secrets operator installed on my control plane. I've got it configured for vault, and I'm reading secrets from my external vault instance, and then I'm also writing secrets to that, that secret service. Now, in the demo I have Kyverno. You could also use open policy agent gatekeepers another one that's very popular. The idea of policy engines with crossplane is an interesting one because you can supplement what crossplane does to enforce governance. So think about, think about this because there's definitely some overlap between what you can do with a policy engine. You can do certain things and what you can choose to build as part of the API you define with crossplane. So the way I like to think about policy engines is it's this, the failsafe that you can put onto a cluster with crossplane to ensure that a resource configuration is never ever violated. So like let's suppose an example in the screen I've got this policy for restricting public access to my pocket. I create an API that as far as I could tell never allows the app team to have the power to set that property. It's a failsafe to have this policy in place to ensure that under no circumstances does that get violated. So that's one way that you could, you know, add a policy engine with crossplane. Again, going back to what I was saying earlier, you don't have to use a policy engine with crossplane. If you don't have a use case in production that requires using a policy engine, you don't have to. But if you've already, you know, your organization has aligned on using one of these to do central governance and policies. You are empowered again to use this with crossplane. Totally, totally a valid use case. Okay, and rounding out the ecosystem integrations before I think we flip onto the demo is Valero. So Valero, if you're not familiar with it's popular open source solution that you can use in kube to backup and restore kubernetes objects. You can use Valero with crossplane crossplane creates a bunch of crossplane specific objects, and you can back up that state, you know on a daily weekly monthly basis whatever your, your service level objective is to reach in terms of availability. So totally compatible with crossplane. And one thing that's very important to call out though when we talk about disaster recovery with crossplane is remember that disaster recovery for crossplane is not concerned with the data that's inside a cloud resource. Crossplane ensures the configuration of, of a resource but not the, the internal state, unless you tell it about it. So think of a good example is like, I create a, you know, cosmos DP and Azure, and I've got it configured to use 100 gigabytes of storage. Crossplane will ensure that, you know that resource, if someone goes in and fiddles with it and changes it down to 50 cross friends going to say nope, you said 100, I'm going to revert that change. Crossplane is not concerned though about the, the database entries that are inside that database it doesn't know what line of business app is using it to store user records. So when you think about snapshotting crossplane state, it's going to capture the resource configuration, but not necessarily the internal state that's something else that you need to think about. So make sure not to cross your wires when you think about what disaster recovery gets you for crossplane. And lastly monitoring and observability a very important thing as we think about not just running crossplane as a simple POC but monitoring it in production to know that the control plane is healthy. So crossplanes able to emit Prometheus metrics you just have to enable it when you install crossplane. And then once you've enabled Prometheus metrics you can use any, you know, observability solution that you're already using today to scoop those up and process them and render them towards and what have you, totally compatible with crossplane. So the final architecture just recapping is something like this, what I'm going to show you is it's got a port front end. We're going to use that port front end to create a cluster. It's going to flux is going to drive that cluster under control plan control plan is going to create it. So this is the final baseline architecture that we've arrived upon that is going to effectively be our developer self service platform. Okay, so last thing for the demo control plan architecture in Tennessee, I feel like I needed to have specific slides on this because I get asked this so much is like how many control plans do I need. Again, it's just going to depend on your business requirements. So I've listed five out here on the slide that I think actually covered earlier. So I'm not going to spend more time on this. But tendency, the takeaway here is depends on a couple of things we've grouped them as such. So one of the things I wanted to announce to is, as I've been reverberately walking through this upbound release yesterday, what we're calling the upbound crossplane architecture framework. And it's a guide that's available on the upbound docs today free anybody can go and look at it. And it walks you through these three core aspects of building a platform with crossplane from building your API's to architecting with control planes and then ecosystem integration. Everything I've described is available today in this framework with examples and best practices, and even more than what I've gone into detail today. So, as you were going to try and her jump over the hurdle of, I've got a basic POC with crossplane working to provision a bucket. How do I go into production. We think that this framework is going to be a good, you know, set of guidance for you to use to help you do that. So do go check that out and I think we'll drop a link in the chat as well. And really, as you're looking at this and you might be a little overwhelmed about, you know, building out this whole platform with these ecosystem integrations and managing 1050 control planes that, you know, depending on your business requirements, you might be feeling a little overwhelmed. And this is why we have upbound, which is the same name as the company to SAS product that's built around running crossplane at scale. And it's designed to take away some of the headaches of operating crossplane and production. So that is also available for you if you've not heard of upbound before but I would encourage you to go check it out. There's a free 30 day trial. You can get started by going to console that up on creating account and experiment with a managed service that removes a lot of the burdens of just operating crossplane and eventually having to deal with these ecosystem integrations on your own. So with that said, we have demo time for just a few minutes. I'm going to do a new share here on screen to give you a quick demo what this looks like in practice. Okay, so you should be seeing the port self service hub. What you're going to notice here is I have an action it's called create a GK cluster. And let's suppose that we give access for our developers to port, they can go and use this to self service create a GK cluster that's already configured according to our best practices. So we're going to click the create button. Our cluster, the API we defined it needs a cluster ID so let's call it my super cluster. And then we've also said all right how many nodes do you want to build the vision in this cluster. We give them the flexibility, minimum of one, say a maximum of 10 but we'll let's do three. And finally for the node size that actually backs that node pool. What node size do you want. We're not going to expose the nitty gritty of what GCP node sizes are how many CPUs and memory, we're just going to give them a rough ballpark because they don't need to know what suppose. So we've just got an option of do they want a small, medium or large, we'll do medium. And we're going to execute this. And now remember, and the flow I was walking you through I'll go open this up is it's going to go and create a claim and push that into get repo. And in that get repo. That's this the single source of truth from my control plane that I've already got spun up. So let's just watch this process we can go and actually click out to the GitHub. It's going to run a GitHub action is what it does. And it goes and creates and commits a claim. And it looks like it actually completed just fine. So if we go back to port. We see the log that said that the claim was created successfully inside of our get repo. I can prove that by going to my repo. And I'm sure that I've got outlined should be in control playing claims. My super cluster claim right here. It's got three nodes it's a size of medium, the claim is now live. So then the next step is we have to get that to our control point. So pulling up my terminal here, you should see. Yep, a terminal on screen. If I do. I'm going to talk to my control plan. I'm going to say, Hey, show me the clusters. It's only got my new cluster right now, because I think it takes a minute for flux to sink. So while we're waiting for it to sink and hopefully the demo guys are nice and it does. Let me show you what I've got configured on here so if I do coups et al get configurations. I've got my platform API configured, and it's got that platform or FGCP dependency that I was describing to you. I can also do flux get all, and I can show you these are all the ecosystem integrations that I've configured with this with this control plane. So it's got Grafana configured it's got Kyverno, Prometheus, it's got up on zone distro of crossplane installed we call that you XP. It's got the external secrets operator and it's got Valero. And so for example, I've already got this configured so I can do I think it's getting cluster policies. Yeah, and I can see like these are the policies that I've set in place on my control plane that Kyverno is going to be enforcing. And if I just let's try and get clusters one last time. There we go. Alright, demo gods were nice. So there is my super cluster the resource claim has been created on our control plane. And my control plane is now busy going and provisioning that new GKE cluster in GCP according to the parameters that were specified in port. So that is the demo. Now all of this, the architectural framework the guidance the reference implementation that I'm building here. This is available today at that link I was talking about with the crossplane architecture framework, except for this reference implementation. We're working on getting it into a shareable state. And once we do we'll have it linked out there on the framework so you can go in and you know bootstrap the baseline architecture that that I've been describing to you today. And so with that being said I think it is now time for any questions. So if there are questions I would be happy to take them. So let me take a look at q amp a. All right, so one individual asks hello what can be the criteria to choose between terraforming crossplane, or is it not possible to compare them. What about terraforming crossmen is great question get it all the time is fundamentally they're different tools, right with terraform, you're running it on your, your local machine or it's a one shot process that runs and tries to apply a desired state. And crossplane is just fundamentally different it takes a control plane architectural approach where now you have this, this entity that is long living that is constantly enforcing state it's got an API you can talk to all those things. What we do find is organizations have invested heavily in terraform, you think it's a great tool. And there's definitely a path for migrating from terraform to crossplane or using both in your organization and upbound is author to blog blog post about that. And I would recommend going and checking out that crossplane versus terraform blog it's going to help you think about the use cases for when it would be appropriate to migrate how you can migrate, or or not. Is it possible to send metrics to elastic was a second question. Off the top of my head I've never done this with elastic but if, if there's a Kubernetes way of doing things then the answer is yes is blanket I have to believe there is so probably yes but I'm not I'm not for sure. And then the last question that came in is can we get the slides. I do believe the slides are going to be posted after the fact. I also know that this is going to go up on YouTube. So, yes, we will make sure that you get this content. And from the chat. Yeah, thank you Stephanie for pasting in the blog post already any other closing questions here and we've got maybe a minute left. One last question from Mohammed this crossplane controller ignore changes for the auto scaling that's been done by the cloud provider controller for example in ETS no group. What crossplains going to do it this depends on very much on a resource by resource basis depends on the API, but if there's a property that is exposed in the crossplane manager resource. The crossplane is monitoring and it's it believes it's a certain value if something comes by and tweaks that without it knowing, then it will try and revert that. So, for your specific question I'll have to take a follow up and get back to you we can carry on this discussion in the crossplane community slack is a great place to do that. But that would be my immediate answer there. So, okay, I'm going to turn it back over to the Linux foundation. Thank you so much Craig for your time today and thank you everyone for joining us as a reminder this recording will be on the Linux foundation YouTube page later today. We hope you join us for future webinars have a wonderful day.