 I mean, welcome, everyone, to Kubernetes-powered control planes with universal crossplane. And today is a special day because I'm going to teach you how your organization can get started with crossplane to unlock your own golden age of cloud computing. Now, I want to caveat this with, I'm offering no silver bullets in today's talk. After all, the golden ages of antiquity did not just happen upon those civilizations. It took work for them to achieve that prosperity. But it was knowledge that set them down the path towards that prosperity. And crossplane is going to do that for you. So with that being said, a little bit of a who am I before we dive into talking about crossplane. I'm a products manager who started my career a little over five years ago working at Microsoft on virtualization technologies, things like device virtualization and tech to power the foundations of the cloud with virtual machines at Microsoft with Azure. And I also got to work on the Windows subsystem for Linux, which runs on Hyper-V with our virtualization technology. And it's an awesome tool that lets Windows developers have an integrated Linux command line experience on Windows. From there, I transitioned to helping Windows server customers migrate their existing app portfolios into Windows containers into the cloud on Kubernetes, to Azure Kubernetes service specifically. And the goal there is to help organizations start to unlock the power of the cloud and to start that, you need to get your stuff into the cloud. And so Windows containers was the technology to help do that. So now I have the privilege of working at UpBound in the company that created crossplane. And that's the focus of this talk is all about crossplane. So let's get into it. So before we talk about crossplane, actually, let's talk a little bit about the cloud. And let's take a survey of what it's done for us thus far. Now, I would argue that we're at the cusp of a golden age in cloud computing. Now more than ever, organizations have a wealth of options to choose from to build your services on top of, to accelerate your time to market, and to operate your software on a global stage. I mean, just think about it. I picked just a couple of different services. We're not just talking about the big three public cloud providers of AWS, Azure, and GCP, but also things like cloud players, Snowflake, Octa, Datadod, DigitalOcean. You could fill many slides with these different icons for these companies that are providing cloud services. And the list goes on and on. And the goal with the cloud is, it allows your organization to focus on building what matters most to your business. And you let the cloud handle the rest, whether that's managing the underlying hardware because you're running on VMs, or moving up around managing the underlying VMs because you're running serverless containers. The cloud helps you move up the stack and manages underlying things that you don't need to worry about. So it helps you focus on building your secret sauce to make your business useful to customers, to add value to their lives and to operate your business. So thinking though of the large public cloud providers for a moment, there's this long list of services that they're providing and it grows day by day. And usually there's these three letter acronyms that come along with it. And I think personally it can be painful to remember all these services, to stitch them together into a single platform. It's tough to do. And so many organizations end up doubling down on well, we're only gonna be an AWS shop or we're only gonna be an Azure shop. And that's fine, but then you're missing out on all the extra value that's getting created across the industry and these different cloud services and providers. Now there is commonality in services across the big three public cloud providers, but they excel in their own way. And so it would be great if you could go all the cart and choose which ones you want to have from across this list, inclusive of all of these different cloud services. But for a moment, let's talk about Kubernetes. I've got it highlighted on the slide right here, the different Kubernetes managed services that you can use across the different clouds. Now hopefully Kubernetes is about a new term for you. It's taken the industry by storm several years ago and the industry has really rallied around Kubernetes. And I think it's the adoption is exploded. And it's transformed the way that apps are written and deployed, there's a massive uptake. And you can see this data from the CNCF from 2021, the adoption of Kubernetes either in production or going into production soon across these different regions around the globe. And so I think it's safe to say that Kubernetes is not just a passing fad, it's here to stay. There might be abstractions that build on top of Kubernetes eventually, but Kubernetes has become a staple in how you architect and run your applications at scale in the cloud. But is containers all that Kubernetes is good for? Is containers all that it's good for? Let's think about that for a moment, put pause on it and we're gonna come back to that in just a few minutes. Okay, so let's talk about building in the cloud. And just as a refresher, so we're all talking on the same language and API. So what the cloud is built on, clouds, much like anything else in software abides by the software contract called an API. And so I went to Merriam-Webster, here's the definition. It's a set of rules that allows programmers to develop software for a particular operating system without having to be completely familiar with that operating system. And so what this looks like is you think about going to the cloud is each cloud provider exposes their own API. Okay, and I want you to pay attention to and to the top right of the screen, there's a golden age meter. And you're gonna see as we get closer to using technology to help your organization really excel on the cloud that golden age bear will eventually reach full. So just keep an eye on that. But for starters, this is how it looks. So AWS has its own API for interacting with the cloud and the various cloud services. Azure does as well, Google does the other cloud services that you can go and consume like data dog do as well. And that's a problem for you because if you want to use a service in that cloud provider, you have to go and talk to that API, but the API doesn't translate to the other clouds or the other providers, it's specific to that cloud. And so, okay, it's kind of a challenge. Now cloud formation came along and for AWS and it gave an easy way to model a collection of related AWS and third party resources so that you can provision them quickly and consistently and manage them throughout their life cycle by treating this infrastructure as code. But cloud formation is an AWS technology, it's pretty specific to AWS and it's gonna be difficult to manage, different services outside of AWS because it's an AWS technology. So the golden age meter, we're getting a little bit closer. We have this infrastructure as code technology now, this sort of paradigm that we can apply, but it's not gonna scale across the different cloud providers and platforms that we wanna go on support. So fine, you can go to the different cloud equivalents, that's great, doesn't really solve our problem of having a single coherent platform, but you are making progress toward the golden age. You've now got a infrastructure as code way to talk to these different cloud providers. So we're moving in the right direction, but there's still problems. And then Terraform came on the scene and with it, consolidates and you can just run Terraform as this single kind of entry point then manage resources in these different cloud providers. And we're making great progress now toward the golden age, but there's a problem with Terraform and there's a problem with other infrastructure as code technologies. And that would be that, I think two things I wanna call out. The first of all is that there's this idea of drift detection, which is if you go and Terraform apply something, it will go and it's a one-shot operation, it'll go spin up those resources in your cloud provider cloud service and then it's done. But what happens if someone comes along and changes the value because they didn't know they should in or something like that, you end up getting state that is drifted from your original desired state. And there are stories across the industry where this has happened and their environment runs away and it kind of blows up. The second thing is thinking back to that Kubernetes point earlier of all the great development and work that's going on the app development side of the Kubernetes, Terraform and other IAC tools don't really have great Kubernetes ecosystem integration because it wasn't built around Kubernetes. And so every infrastructure leader is trying to tackle this problem with two initiatives. They're trying to centralize the management of inference services so it's easy to manage. And they're trying to enable teams to work efficiently with quick access to tooling. So IAC, GitOps, service catalogs, modernization, containerization, all of these things promise speeding control in your infrastructure but they all fail to live up to the requirements of modern infrastructure. They're gonna add drift, they're gonna add sprawl, they're gonna add inefficiency. So what happens is the promise of this golden age, have we really achieved it? Or have we descended into this dark age of sorts where your SREs are functioning as a help desk? They're putting out fires, they're managing developers and becoming frustrated by the lack of resources, time and tools. Your software engineers are responsible for your apps and services but they're frustrated by the red tape and the processes that they need to go through in order to ship their code of production. This has significantly slowed down time to deployment and therefore your ability to innovate, which is not good for your business. Whenever infrastructure requirements change, a laborious cycle of scoping and negotiation and compromise has to happen. So, is your organization, it's cloud usage, it could very much be like this picture, is it actually on fire? Do we know if it's actually the infrastructure is provisioned the way it should be or did someone go and fiddle with something and there's now a drift, you look at the temple up in the top right, it's burning down and the golden age meter has just gone out the door, it's back to zero. And we're left with a shell of an organization as a result. But that's not all. What you need is a control plane. And I think the next question that is then asked usually by users is what do you mean by a control plane? So a control plane based architecture gives you a declarative approach to defining managing resources, continuous reconciliation of resources to eliminate that configuration drift and a pattern for achieving self-service. So a control plane needs to be able to configure, control, monitor, needs to be resilient kind of in line with that control thing and needs to go and reconcile changes and it needs a stable interface. And that control plane is going to control your clouds, apps and infra. So control plan, as you listen to that definition you might think back to, well, I know something that does that, Kubernetes, it does it for containers. But forget about containers for a moment. Kubernetes is a control plane. And primarily it has been used as a service to manage containers and app deployments, those sorts of things. But Kubernetes has a lot of really useful features and capabilities that just forget about containers for a little while and just ponder these things. So it's extensible. Kubernetes is very extensible. We'll talk about that more with cross-plane in a moment. It's got our back as secrets and configuration management. It's declarative, it's self-healing and it's got already a very strong ecosystem around it. Going back to that CNCF survey there is a very strong adoption of Kubernetes. So you need a control plane. Kubernetes does containers. What do we do? Well, that's where cross-plane comes into the picture. So inter-cross-plane. This is the open source framework for building your own control plane. Now upbound built cross-plane to help organizations build their platforms like the cloud vendors like AWS and Azure and Google build theirs. They all use control planes. The beauty of cross-plane is that it's open source. It's a CNCF project built on the foundation of Kubernetes that allows you to orchestrate anything. Infrastructure and more if you want. You can encapsulate policies, permissions and other guardrails behind a custom API line to enable your developers, your customers to self-service without needing to become an infrastructure expert. This is cross-plane and we're going to talk about what cross-plane looks like, kind of take a peek under the covers and see how it works. But before we do that, cross-plane the control plane revolution, as we call it, it's been three years in production. It has a very large and healthy growing community. It's an open source product. Just to be clear, upbound does not own it. We contributed it, but it is a fully open source project. It's got 5,900 plus GitHub stars, 30 million polls on Docker Hub. It's open source, open governance. And this is the technology that I believe will enable your organization to enter into that golden age of cloud computing where you can go and build on anything that you want and you can build a platform that is bulletproof and you're never going to have to re-architect again. I truly believe it. And this is why I came to work it up from Microsoft is because I wholeheartedly believe in this idea and I'm super excited to get to share it with you. So cross-plane, what is it? It's built on Kubernetes first and foremost if you haven't figured that out yet. So we're taking Kubernetes and we're teaching it some new tricks. We're teaching it some awesome new tricks. Kubernetes rock solid container orchestrator, I think we've already talked about that. So it's built on Kubernetes. So it allows you to then to unify your infra and your app configuration plus deployment with a single tool chain and pipeline. So if you're already doing app development that's centralized around Kubernetes clusters, you can use the same tool chain, the same tools, the same ecosystem to solve things related to infrastructure. Cross-plane is extensible by design so you can tailor it to your needs. And we'll talk about that more in a moment but just remember it's extensible. Just like Kubernetes, cross-plane is extensible. And because it's built on Kubernetes you get drift detection and reconciliation out of the just out of the box. It just works by default. So that pesky issue that you see with other IAC tools where you get this drift detection that can wreak havoc on your business cross-plane solves that for you. So going back to a couple of slides ago we were talking about your organization and how you build on these different clouds. This was the picture that I presented. How this changes with cross-plane and we're gonna see that golden age meter go to 100%. Boom. Is that cross-plane allows you to build your own API, a single platform that covers any cloud provider that you want, any cloud service that you want all under one roof. And you get to tailor this API to your business needs. It's really powerful. I think it's really the big selling point of cross-plane. And so that is your cloud control plane with cross-plane that piece right there. So let's talk a little bit more about what does it mean to get started with cross-plane? We'll look at a high level picture of how cross-plane operates and we'll talk through some of the key concepts. Okay, so the first and foremost cross-plane must be installed into a Kubernetes cluster. Now I think Kubernetes clusters have been commoditized these days. You can go and spin one up in your favorite public cloud. You can deploy your own if you really want to. I don't know why you do that, but you could. And from there, you can install cross-plane. It's just a simple helm install away. Next, you need a provider to be installed on your cross-plane instance. We'll talk a bit more about what that means. And you need to configure that provider so that it has credentials to access the cloud service API that you wanna talk to. And then from there, your control plane is ready to begin managing and reconciling resources requests. So it just as an example on the slide, we've got AWS there that cross-plane can talk to. We also have Datadoc. It doesn't have to be one of the big three public clouds. It can be any cloud service. So that's why Datadoc is just a stand-in. It could be anything else. Okay, so that is cross-plane in a nutshell. Now let's talk about a provider. Let's pick it apart. So a cross-plane provider is a package that bundles resources to allow a user to interact with some external cloud resource outside of your cluster. So you've got your cross-plane instance, you wanna talk to some cloud service. It's somewhere else in the internet and the world. You need to know how to talk to it. So providers bundle these resources that lets you do that. Now most of the cross-plane providers are created and contributed by the cross-plane community. If there's a provider that's missing, you can go and build it yourself. I mean, it's extensible. You can easily go and build it yourself. And to install it onto your cross-plane instance, it's just a simple CUBE CTL apply this provider YAML and it gets laid down on your system. And so what this looks like is you have this sort of diagram right here. And if we were to just peek open into one of those providers, we'll do the AWS one, you can see it's actually just a collection of managed resources and controllers. So a managed resource is the base building block of cross-plane. It's literally a CRD, Kubernetes CRD. They're opinionated. They follow this cross-plane resource model. XRM is what we call that, but they're compliant Kubernetes custom resources. And then for each managed resource, there's a controller and a controller is literally just a container that's deployed as a pod in your CUBE cluster that executes and does the create, update and delete operations for a given resource. So for example, think about AWS, there's over 700 managed resources for AWS, VMs, databases, VPCs, policies, buckets, all these different things. Those are managed resources and you do create operations on those things, you update them and you delete them. And so when you install a provider onto your system, it goes and lays down all these different definitions for managed resources and the associated controllers so that you can go and talk to your cloud service from cross-plane. And that's why too, with the provider config in the picture, there needs to be some configuration so that it can authenticate and talk to those APIs. Okay, so let's talk creating just a simple resource in cross-plane. So managed resources are the base building block. We don't suggest that you usually work with these directly. We'll talk about how you should work with resources in a moment, but you can create just a simple managed resource from cross-plane directly. So in this example, we're gonna make an RDS instance which is a database in AWS. And so what this would look like is you have this config file, this EML and you can tweak the parameters of that resource as you would expect if you went to AWS and you click through the portal, those different parameters you can choose as you're setting up your service, you can codify those in the EML file. And then we're also gonna configure it to write back secret information, like the connection string for that database back to our Kubernetes cluster once it's provisioned. So you write this EML, it's as simple as doing a kubectl apply that EML file to your cross-plane instance. Cross-plane is gonna go, aha, I need to go create a resource and it's gonna go and do that. It's gonna go talk to AWS and make that. And then it's going to return that connection secret. And then it's going to continue that continues reconciliation. It will continue monitoring. It's not just a one-shot operation. Cross-plane is now ensuring that that database is gonna be up and it's gonna stay up and it's gonna be configured the way that you expect it to be. And if it goes down for some reason, cross-plane will try and bring it back. If you went into the AWS portal manually and you tried to delete it, cross-plane is gonna go, nah, no, I'm gonna bring that back for you. So it's pretty cool. And then with the app secret, or the Kubernetes secret, now that that's written back to your Kubernetes cluster, well, what can you do with it? You can use it and feed it to your app and then use that as the connection secret to talk to your database. It's pretty cool. So more on that in just a minute. So that's a managed resource. So it's a simple flow for how to go and deploy a managed resource on a cross-plane control plane. But the power of cross-plane really comes in when we start to talk about composite resources. So think about a composite resource as an abstraction of your own making. You get to define your own API to abstract away something that exists in the cloud, whether that's a service or a public cloud provider, and you get to define this abstraction yourself. Now that's a lot of YAML. So just don't try and get stuck on the YAML. It's actually an ISO, I probably shouldn't have put that up there, but it's there. What you can do then is you can create an instance of this composite resource and then connect it back. And so for example, looking at the YAML a little bit, this one says that, hey, my instance is gonna be called myDB. And oh, by the way, it's gonna have 20 gigabytes of storage. This is now an abstraction that sits on top of, this is a PostgreSQL instance that we've now defined. So the power of this, let's talk about why this is so powerful. What you can do with composite resources is you can make your own composition of resource bundles basically. So think about most times a user doesn't want to just go to a cloud provider and just get a database or for on the slide, they don't just want an EKS cluster, but they also want that EKS cluster with a VPC and with these managed at gateways all configured. And so with your composition, you can with your composite resource, excuse me, you can wrap that up altogether so that when a request comes into the control plan is, hey, give me this Kubernetes instance thing, it actually knows to go and provision a bunch of these resources together and tie them all together. That's powerful. That allows you to define your own abstraction for some entity, some thing, some bundle of resources in the cloud. And you can also do things like this. You can have a Kubernetes instance there and you can compose it so that it actually, it's an abstraction that sits in front of all the different Kubernetes instances that you'd want to create across the clouds. And then you could have a label selector that chooses which one you want, but it could go and actually, it's an abstraction that sits above AWS and Azure and Google, which is really, really stinking neat because then you can just have this thing that's portable across these different clouds. So composite resources are your API. We talk about crossplane being a tool teams can use to find their own opinion and platform APIs. Those APIs are made up of composite resources. And when you're interacting with an API that your platform team has defined, you're interacting with those composite resources. So what this could look like is, by the way, a common convention for composite resources is the types they start with an X. So what you can do is you can define your own API and those composite resources of the Kubernetes instance, a database instance, Pub, sub, storage bucket, these different things. And they can span across all the different cloud services and providers that you want, but that's a concern that the platform team now bears. And the app teams who are then building things on top of infrastructure, they're not concerned about it. They only think about the API that your platform team has published. So you get this really cool separation of responsibilities where the platform team now builds this platform with crossplane. They build that API. And then you have the app team sitting up up above who's just talking to it. And they don't have to care about anything under the covers. Really, really stinking me. What this allows you to do then is to make a crossplane instance for an app team, let's say. Provision your platform on it so you'd install your API definition. And then now the app team is empowered to go and self-service that thing. And they can use it to go interact with the clouds, whatever cloud services that they want. And they own that infrastructure that they provisioned through crossplane. Really cool. Allows you to hand off responsibility there. So that's like crossplane in a very, very high nutshell. I wanted to talk about some of the gatchas and things that UpBound is doing with crossplane. The first thing that we get asked is platform architecture with crossplane. And I have to admit, I thought I was really clever with this. This is Sauron from Lord of the Rings. And he's holding the crossplane popsicle as like a, do we have one crossplane control plane for our entire organization? How do we think about architecting with crossplane? So there's a couple of different approaches. And I'm gonna say that there's no single right way to do this. They each have their own pros and cons. So if you were to just say, hey, we want one control plane for our entire organization, it's good because then you're gonna minimize the management overhead of having all these different control planes running. But the downside is that it does not scale at all for bigger organizations. So this is likely only something for small organizations to run with. The isolation boundary in this case, if you have multiple teams interacting with this crossplane would be at the Kubernetes namespace level, which is good, but I think there's stronger isolation to be had by separating into separate control planes. We also see crossplane instances spun up on like a per environment basis. So you'd have like one control plane talking to your dev environment, one to staging, one to production. And there's a little bit more control planes for all, but then you can also tailor the API definitions that you're publishing for each control plane to according to the environment. So that's pretty cool. And then all members of your organization like have the ability to manage resources within the environment that control plane is managing. So that's another way to do it. And the third way to do it, and I think this is actually the one that Upbound would suggest is that you have one control plane per team and then that control plane can talk to the different environments, but it's scoped that team. And so you can tailor the platform that you're publishing onto that control plane according to the team's needs. And then the isolation boundaries, of course, at the control plane level so that another team can't inadvertently tamper with an adjacent team's stuff. The challenge with this is, of course, potentially a lot more control planes get created as a result, so you end up with some control plane sprawl that you need to figure out how to manage. And so that's like three of the ways that we see crossplane deployed into organizations. Each one has their own pros and cons. You pick and choose which one is best according to your team's needs and size. The second thing is that, the second thing to be aware of is crossplane can really push the limits of Kubernetes. So if you took the AWS Azure and Google provider, we estimate there's about 1,800 CRDs. Remember, there's like a managed resource correlates with like a service or resource in that cloud. So when you add them all together, you end up with like over 1,800 CRDs for the big three cloud providers combined is what we estimate, and that's a lot of CRDs. Now, the cost of a Kubernetes CRD, we did some investigation to this from the upside. It's about 4.2 megabytes per CRD. And so what ends up happening is that if you provision the big three cloud providers, because you wanna talk to, you know, the beauty of crossplane is, I wanna pick and choose these different services from these different clouds and then put them all together in this one platform. You want the ability to go and do that, then you need to have those providers all installed in your crossplane instance. You end up with a significant memory usage for those providers. And the challenge is a lot of users do deploy CUBE clusters in a managed cloud provider. And something to be mindful of is when you're using a managed Kubernetes service, the control plane for that Kubernetes cluster is managed by the cloud provider. So AKS, GKE and EKS all manage the control plane. And the things that are owned by the customer is usually the worker nodes or the VMs where your containers get scheduled. So what happens is when you install a crossplane provider, let's say we've got crossplane in this CUBE cluster, then it's going to install all of those managed resources and CRDs onto the control plane. So your worker nodes are not impacted, but the control plane is and the control plane is where the API server for Kubernetes lives. And so what we've seen is when there's a very large number of CRDs that are running, sometimes the control plane goes out to lunch. It takes a break. It becomes unresponsive and that's not good. So crossplane's really pushing the limits of CRDs with Kubernetes, but there's some mitigations that we've done and I wanna tell you about them. So the first thing is upbound did investigate. And we started by installing providers on the different clouds to see how the behavior was. And you can see once we start registering those CRDs in AWS, this is EKS as an example, the API server just, you know, it goes wild with activity. And that's not good. So as a mitigation, we've pushed changes back to Kubernetes that helps defer the update in the API server schema until an API requests that CRD as a mitigation to take off some of the pressure of loading providers in Kubernetes. So that's one way that we're helping push the envelope with Kubernetes and CRDs with crossplane. The second thing is we profiled the memory for an API server. And you'll notice the moment that we start installing all of the cloud providers, remember those three cloud providers, you get the sustained high memory usage of the API server in a way that I don't think the managed Kubernetes service teams anticipated people would be doing. So what happens is the API server goes to scale and sometimes it becomes unresponsive. Users who are using crossplane are like, what in the world? I can't, you know, I can't talk to my control plane. So that's not good. But what we found is that there's an inefficient creation of an XCD logger client causing a 20% memory overhead. And we fixed this in Kubernetes 1.25 upstream. So starting with Kubernetes 1.25, if you go to a managed service, as long as it's that version or later, you'll get this benefit of reduced memory overhead for installing a lot of CRDs. And the reliability of your API server should be much better. Yeah, so on behalf of the crossplane community, Upbound's working with those teams at the different managed Kubernetes services to improve that experience and provide a more stable crossplane experience because a lot of users do run crossplane in AWS, Google and Microsoft. And so we're working with them as well too to try and iron that out. We also found some really interesting client side Kubernetes issues. So this one was when you go and query a control plane, you say, hey, you're using Kube CTL and you're like, get me the CRDs that are on this control plane. You'd sometimes see a return of an error like this where it gets throttled. And we pushed some design changes or we pushed some code changes in the Kubernetes with consensus from the community to up the rate limit so that this is no longer seen. And it's for Kubernetes 1.25 and later. So that's another example where we're helping push Kubernetes on to be better and better. And then we also discovered on Mac OS there was an issue where you do the same thing. It would take like a really long time to return and it ended up being a cache validation issue a specific to Mac. And we improve that by 25 times faster now. So that problem should be resolved too. So that's the end of the CRD issue. So the net net there is CRDs is definitely crossplane is pushing the envelope with Kubernetes but upbound in the crossplane community are leading the way in building Kubernetes better so that that issue does not impact you. And also I do wanna call out this is only for circumstances where someone has deployed the three big cloud providers and they're running at 1800 CRDs. If you're not doing that then you're probably safe from seeing this happen in a managed Kubernetes service on the cloud. And if you're running your own Kubernetes cluster this issue doesn't even apply to you because you control the control plan at that point and you can set it appropriately to be batched by sufficient resources so it doesn't blow up when you try and install a lot of CRDs. Okay, the third thing to be aware of with crossplane is that it does involve writing a lot of YAML but the mitigation here is and the beauty of crossplane again is because it's this thing that's on top of Kubernetes you can use the Kubernetes ecosystem to help solve these problems. So you can use Q, you can use customize these sorts of things. And that applies for any other issue with crossplane. If you think about GitOps integration you can use Argo if you want a policy engine you can use Kiefer and O or OPA those sorts of things. That's the beauty of crossplane is it sits in this Kubernetes ecosystem and when there's advancements made there for Kubernetes generally oftentimes it accrues right back to crossplane. And this is why thinking back to this idea of unlocking this golden age and building a platform that's going to withstand the sands of time. This is why crossplane is so great. It's built on top of Kubernetes. Kubernetes isn't going anywhere. It's going to be a rock salt foundation to build on top of. Okay, and then the fourth thing to call out with crossplane is it is growing still. I mean, it's a pretty young project. It's been in production for a couple of years but I would consider it to be still the new kid on the block in comparison to some of the other IAC tooling that exists on the market. And there's still room to mature in terms of like resource coverage and provider coverage. So the mitigation here is it's an open source project. So I wanna encourage you that you can help contribute to this technology too. You can go and build your own provider. It's not that hard. There's documentation that we have on the crossplane docs that will tell you how to do it. Or if you have a commercial need you can reach out to UpBound to learn about other options and I'll just quickly touch on that one What UpBound is doing is in addition to the community providers that exist and they're owned by the community UpBound offers official providers which are closed source but they're production backed by UpBound and they offer a full API coverage for right now we're focusing on AWS, GCP and Azure. And there's also an SLA for when new services get integrated. So something to think about as you go and build on crossplane is if you need a phone to pick up and call someone for these providers UpBound can be that for you if you need it to be or you can go and build your own provider that's totally an option but it's there for those who want that the assurance and don't wanna go build the provider themselves UpBound offers them. And with that too, UpBound has this thing called the universal crossplane. And so thinking back to the beginning of the talk universal crossplane was the title UXP as we call it it's a turnkey experience for customers to go and build, deploy and manage secure their own control planes. It's an open source, it's fully open source so you can find it on GitHub but it allows you to get access to official providers so you need to be running UXP which is like a downstream distro of crossplane in order to get official providers if you want that. It's fully production supported by UpBound it allows us to get fixes to customers faster if they need something otherwise because crossplane is an open source project if a change is needed urgently we have to work back with the community to make that change happen. It's not something that it's not just controlled by UpBound so we have to abide by the community processes and stuff. And you can just think about it as like UpBound's official enterprise grade distribution of crossplane really. So if you are interested if you believe in the pitch that I've just made that I do truly believe crossplane can help usher in this golden age of cloud consumption where you can go and build on top of whatever cloud service you want and you can stitch it together and make your own abstraction then and you wanna get started there's a couple of things you can do. The first thing is that you can go and join the Slack community it's 6,000 plus members now growing it's a great place to ask questions and get answers. You can also look at the crossplane docs for the get started guide if you want to take it up and running with installing crossplane and I do wanna acknowledge like the crossplane docs were working with the community to improve those two so that's easier to grok so that's something that's happening. And lastly, if you're interested in going pro with crossplane and you're interested in official providers and what UpBound's doing in that space you can also feel free to reach out to me or talk to UpBound. So with that being said, welcome to the golden age with crossplane and that is it. So I'm happy to take questions now. I see there's several questions that came into the chat that I can go through but also I wanna encourage you if you wanna raise your hand and talk on the mic I'd be happy to take questions there too. So starting with the top question from Dior is does crossplane support Oracle Cloud specifically OKE cluster? The answer here is off the top of my head I don't remember if there is an Oracle provider that's available in the community you could go and crossplane contrived is the repo that you'd want to go and look and see there's gonna be the list of the 50 plus or you can go to the docs and you can find it that way but that would be where you would get an answer to that question. And if there's not Oracle Cloud support you could look at building and contributing that to the community we'd love that if it's not there. Okay, another question from Alexander is crossplane able to put the credential secrets in cluster close to the crossplane cluster? So what I think this means and Alexander please feel free to hop on the mic and correct me if I'm misunderstanding but what you can do is you can deploy crossplane into the same cluster where you're gonna be running your apps. And so then the cluster or the secret just gets stuck there in your cluster and your app can easily reach it that way. But you can also, you know you can deploy crossplane into a cluster somewhere else where your app is not running and then you would just have to do the extra legwork to go and transport that secret somewhere else like storing it in vault or something to that effect. Dimitri asks, can you include Istio as part of your composite resource? If so, how would the configuration look like? Dimitri, I actually I don't know the answer to that question but I'd be happy to connect with you if you can find me in Slack and the crossplane Slack and ask me that again I'd be happy to follow up and look at that for you. Cool, Raghavender asks CRDs live on crossplane providers where in any case they will need to live on resource providers too. So when you install a provider it's that package that bundles up all of those managed resources which under the covers are a type of like CRD. Will they need to live on resource providers too? I'm not connecting the dots with what you mean by that. If you'd like to hop on the mic though I'm happy to clarify that for you. Providers have to be installed on a control plane that's how you talk to the different cloud services. Gerald asks, you mentioned crossplane managed resources for the big three clouds can you give other examples of interesting providers? Yeah, so there's like provider Kafka's one provider Datadog is another you can actually use provider Kubernetes to go and talk to the Kubernetes API to do Kubernetes specific things. There's I think just right now over 50 different providers as well too. I think digital ocean might be one, but yeah. I hear somebody on the mic. Right, yeah, this is Raghavender. Maybe I will rephrase the question differently. So the thing is on the crossplane we just create those resources definitions and respectively as you said those replication control I mean the controllers also would be created. And so we will have the resources created and the resources live on those cloud providers. My question was do we have to have some of those resources or the monitoring parts or metric parts? If you have anything to be created on those resource providers also if there is any need to bring the data or something like that. So that is what the question is around. So we create the customer resources definition and those resources are created. So along with those resources do we in any case need to deploy our resources to pull the data out of the metrics or tracing or anything else? Does that work like that? Or it is stay away from all those cloud provider resources? That's what the question is. Okay, sorry I'm still not quite following. Are you asking about how do you monitor and get like logs and telemetry for the different CRDs that you're or the different manage resources that you are building yourself? Yeah, so like with the example that you said RDS and I'm creating an RDS as a resources and that is up and running. So RDS can have so many resource metrics could be available over there. So if I want to bring that from there I just still go with the same resource definitions on my side and then pull those data or do I have to have the parts deployed on those cloud providers as such, you know? And yeah, next to R and D, you know, where I deploy a part. So that can run the data and put the data and then give it to me. Is it something like that? Or no, it's on my control plane and I reach out to those through SDKs or APIs. Alone is not for me. Right. So the controller should be emitting events is one way to do it themselves the controllers associated with that CRD, but as well too, like an additional monitoring service that you wanted to use in a cloud provider you could then use crossplane to talk to it to go and do stuff. Oh, I see. Okay. So we don't need to apply anything on those providers resources. Fine. Yeah, got it. Thanks. Cool. Alexander is asking, is crossplane intended to manage infrastructure resources only or can I also combine infrastructure and application deployment together like we can do with AWS CDK? Example, can I deploy multiple Kubernetes clusters across different cloud providers and then install the same application on those clusters via crossplane? Okay. So to the general question of bundling infra and apps together composite resources are, you can build your own abstraction to do this. Admittedly it is a little bit klutzy. Takes a lot of writing and copy pasting. You could also though, look at bundling things like Kubella plus crossplane is something that you could do too to address that sort of concern. So the short answer is yes composite resources because there's a lot you can do with them. You can do that, but it does take a lot of work. And that's, I think a gap that we had up on acknowledge. Abhishek, you have your hand up. Hello. Can you hear me? Mm-hmm. Like in Kubernetes, can we consider that Kubernetes as an object? You can use provider Kubernetes to then talk to the Kubernetes API from crossplane and then do whatever you want. So I think that's what you mean by an object. So yes. Yeah. Because in Kubernetes, if we host anything in the application, so we can consider that as a container or an object. That's so good. It does. Yeah. So I look into the provider Kubernetes and poke around there. That should, that would be the right tool and to use for that. And how can we join this as lag? Can I look? So I think the slides should be going out at some point after the presentation and then you'll be able to grab the link from there. Yeah. Okay. Cool. Thank you. You're welcome. All right. So we've got one more minute. I will take, if there's one more question from the audience, happy to take that now before we wrap up or I can take one from the Q and A. Okay. I will take one more from the Q and A and I think I'm gonna go with Dior asks another question. Crossplane may throttle cloud provider APIs. Is there an option to set pull frequency? So the answer is yes, you can. By default, a controller is set to every 20 seconds is when it does a polling and you can go in and customize that and set it to whatever value you want. And I think you do that within a provider config. I'd have to double check, but it is on the crossplane docs. And if you want to ping me afterwards on Slack, I'm happy to find that for you and show you specifically. Cool. Okay. I think that's all. 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 and have a wonderful day.