 So, hi, I'm Basam, I'm the CEO of Oppen, and I'm also a maintainer on the cross-plane project and the Rook project. I try to spend most of my time here talking about cross-plane and kind of its importance to, I think, the multi-cloud maturity model and how we open up the cloud. I want to start with this dynamic around hyper-clouds and the commercial open source, where commercial open source companies and kind of where we see a lot of the platform and infrastructure innovation happening these days. I don't want to talk about licensing, I think that there has been a ton of coverage about how people are licensing and re-licensing, but I do want to explore essentially and motivate a technological approach to the problem. So, let's start right at the top. Let's actually look at a typical hyper-cloud. In this case, I mean, you can pick your favorite one, but just speak behind the scenes of how most hyper-clouds or these hyperscale clouds are built. Every single hyper-cloud offers a buffet of managed services. They are typically proprietary services or they could be based on open source. If they're open, so if you take the case of Amazon, you have things like RDS, which offers MySQL and Postgres, and they've done all the wrapping around it to integrate it into their platform. And you have things like DynamoDB, which is proprietary service and is their own database. These services are typically all integrated and offered as, you know, you can pick any one of those, they can mix and match them, and they offer integrations between them as well. At the heart of every hyper-cloud is a control plane. This is the component that is responsible for serving the API when you ask for an RDS instance, when you ask for an EC2 instance or you're talking to the control plane. It's the thing that offers the API. It's the component that is essentially doing the initial provisioning and the ongoing lifecycle management of the resources that you're deploying in the cloud provider. It's a very central piece. If you want to think about the architecture of every hyper-cloud, control plane in the middle, a set of managed services live around it. There are typically a set of integration services that are built around the control plane, things like billing, metering, authorization, authentication, essentially things that make it look like a singular platform, an integrated platform. When you go to one of your cloud providers, you get all of that. It's all integrated. At some level, you can argue that the companies, the cloud providers are master integrators. They bring together a lot of disparate technologies and offer them in a way that's really well integrated and save you from having to do that. You, as an enterprise, consume the hyper-cloud by essentially just calling an API or using the management consoles or any of the CLI tools. You get a single surface area that is fully integrated. It's nice that they also offer an SLA on these services. It's a really fantastic and incredible thing that has emerged over the last 10 years around essentially large-scale cloud providers that offer all of these features. Let's switch gears and talk about this from a perspective of a company that has some really great innovation in platforms. You can think of a database company like Yougobiter Cockroach or Redis or all of those companies that have built fantastic technology but are not themselves a large cloud provider. Typically, these companies start with open-source or open-source technologies that they build communities around those. Their path to cloud could start with them offering a service in a given cloud provider's marketplace. Essentially, they can put their software in AMIs or VMs or maybe in these days there are now container marketplaces and they offer them in the marketplace of the cloud provider. In this model, they have limited integration. They're not featured as deeply as the other managed services that the native cloud services that the cloud provider offers. Limited business model, so they're basically stuck to some markup on top of hosting fees. They have limited access and visibility onto what their customers are actually doing on the cloud because it's back to essentially running software. If they wanted to go beyond that, the next step up is to actually build their own managed service. That's a big step because what they have to do is they have to build essentially a cloud, their own cloud, a cloud of one managed service. Typically, they layer on top of hyper-clouds. You'll see things like Redis Cloud or Cockroach Cloud or Yugo Byte Cloud or all of those things essentially offer their own cloud offerings that run on AWS, GCP and Azure. But they have their own control plan. They have their own API, their own automation, their own CLI. If they're essentially, it's a completely independent cloud with a really great best-of-breed offering. And they have to do this work for every hyper-cloud they support. And increasingly, if you think about companies that are in the infrastructure space or the platform space, their customers will demand that they run on multiple clouds. So they're actually one of the early examples. People like these, the commercial open source companies are really good examples of multi-cloud offerings themselves. And so now if you switch gears and talk about it from a customer standpoint, from the perspective of someone in an enterprise that's attempting to adopt or integrate technology into their own stack. The world there looks like essentially a set of heterogeneous services, whether it's multiple cloud providers or even if you're just a one cloud provider. And if you wanted to actually use just one cloud outside of, one cloud service outside of your, say, AWS account or outside of your GCP account. The cost of doing that is you have to add a new vendor. You have to create a set of custom automation to deploy and manage that service. You have to probably go through security and compliance. You have to do your own monitoring integration. You have to do your own logging integration. You basically, and then of course go through education and training. So you're essentially to the cost of bringing in just one additional service is quite expensive. And imagine if you're doing that for multiple. Everyone of those looks like has a different API, has a different off story, has a different monitoring story. And it becomes quite complex. And so that's a real problem if you want to venture outside of a single cloud provider. And there have been some partial solutions to that. So things like essentially infrastructure automation tools, which help you manage whether it's the, you know, terraforms of puppets or chefs or all those things that help you essentially do your own custom engineering. Or trying to run everything on Kubernetes, which is a newer trend and essentially moves you away from a managed service offering where, you know, how many here run databases on Kubernetes? Okay. How many use managed services and cloud providers? Okay. So, so a very different consumption model. And then of course most of these solutions are either closed or vendor driven approaches. And so if you kind of summarize the dynamic, you'd say, like think about it as you're the person inside an organization that's trying to make a decision on some database or some platform infrastructure that you want, you want to adopt. Would you pick the good enough service that's offered by your cloud provider of choice where it's completely integrated, it's a click away or an API call away and no need to set up a new vendor, no need to, it's all there. No need to go through your infrastructure teams. You just use it. Or would you venture off into, you know, essentially picking an independent boutique cloud that offers us really best of breed service. But you have to take on all the integration work. So that's a real integration hurdle that that dynamic becomes a real integration holder in terms of adoption of heterogeneous clouds. So we believe the solution is essentially similar to how cloud providers are structured themselves. We believe there needs to exist a universal control plane. Essentially a control plane, not unlike the control planes that are running in cloud providers, but one that is open source and driven by a community. It becomes the point of integration for the community. We bring a set of services, including the cloud hyper clouds themselves on a common control plane that enables us to essentially consume all their services in an integrated fashion. So it has it offers a standardized API for the cloud and is a host of standardized automation for the cloud. So things like why doesn't Kafka cloud and elastic cloud talk to each other where if you were to make them integrate. Just like say that happens between two services inside a hyper cloud. Where would that automation logic live today? How do I set up multiple services? Typically it is if it is happening today, it's happening in a one off way in every cloud provider and sorry in an enterprise itself. There is no standardized way of arriving at automation today across cloud services across heterogeneous services. This control plane would definitely need to be extensible. Everybody's first class on this control plane. There isn't a native versus marketplace third party. You can think of it as all a marketplace or all essentially a level playing field. And it would need to offer shared services, including billing, metering, off, monitoring, logging, all the things that make it feel like a singular platform. The things that you like about going to a single cloud provider today and trying to stick within the wall guidelines. And obviously, like I said, this has to be open source and has to be community driven. Otherwise it will become a shell game. We're going from one proprietary solution to another. So that was the motivation for Crossplane. That's why we started the Crossplane project. We started Crossplane because we think that it actually levels the playing field and cloud computing. We're focusing mostly on the control plane. We're not looking at solving a compute issue or a database issue. We're basically just trying to bring these disparate and heterogeneous services under a common control plane. So that an enterprise customer could actually consume them as a single offering, if you will. We launched it just like Jared talked about. You guys saw it in action today, which is fantastic with GitLab. We launched it in December last year. It's open source. It's community driven. It offers a single declarative API for a set of services. And it's based on the Kubernetes API. So the whole CRD controller model is what we adopted. And essentially, it looks very similar to Kubernetes API model. So it's a single control plane. It can span clouds. It can span regions. It can span vendors. It can span hybrid boundaries. It's essentially you can configure the control plane to work with your own deployment, whether you're a single cloud provider or you're multiple or you have multiple vendors or you're in hybrid solutions. You can attach this control plane to any of your environments. It's a host for automation. So it actually runs the automation logic and offers a point of integration and the ability to standardize on this automation. And we separate between the concerns. So what infrastructure owners do and admins versus what application developers do and in terms of how they self-service. So we earlier, Jared talked about, showed how we've integrated cross-plane into the GitLab ADO offering, which is fantastic and it's less than 24 hours old. There's something else that we did as well. Like we showed this off in Barcelona and we're still working on essentially a production ready version of this. But GitLab itself is a prime example of a portable application. So GitLab proper, when you want to run GitLab, it runs 50 plus. The GitLab folks, please correct me in the room now, it might have changed. 50 plus microservices that run on a Kubernetes cluster. They use Postgres, Redis, Object Storage and Plethora of other things that run on this. And if you think about it, you know, GitLab, because of the way they're architected, it can run on Google, can run on Azure, can run on AWS. In fact, it can also run on premise. And so one of the things that we did with them early to validate cross-plane was to write a stack for cross-plane for GitLab and run that on multiple clouds. And when it comes up on each of the clouds, it uses their managed services of the cloud provider. So when GitLab is deployed through cross-plane on AWS, it's using EKS. It's using RDS. It's using S3. It's setting up security groups and IM rules and everything else that's required to bring up GitLab. And so if GitLab can be a portable application, I think you can do it too. So let me step back for a second and kind of talk about what this all means. So kind of summarize, I think if we had a universal control plane, one that's owned by community, I believe, and to borrow from Andy Grove here, that we can tip the market today from the cloud computing market from vertical integration, where we have essentially three, maybe four or five, if you count the other cloud providers from being these vertically integrated solutions where they sell you every part of the stack, they own the entire thing from infrastructure all the way up to applications, to more of a horizontally integrated market. We saw this happen in the PC industry in the 80s. The main frames of the old days were essentially similar to how the cloud providers are today. You can think of, it's ironic, but you can think of AWS as a mainframe company. And so we believe that essentially if there was a universal control plane that levels the playing field where the customers are using this control plane to access both their existing clouds and anyone's cloud that it levels the playing field and it essentially enables folks to differentiate on services, which is critical to the continued innovation in this space. And so that's kind of why we're doing crossplane. And I want to just finish by saying it's going to take a village. This is not something that one company or one group or one individual will do. It has to be a community effort. So super proud of the work that we're doing with GitLab and Yugabyte and others that have now joined this party. And I hope that you guys can help us too. So feel free. There are links here. Definitely engage with us. We'd love to talk to you. Thank you. Awesome. Do you want to take questions? Yes. All right. Questions, anybody? I'll be over. So the question is, what's the roadmap for GA maturity of any of your stacks? So we've had a few stacks just go into V1, beta one. We work on CRD versioning. So some of our APIs turned beta as of 0.4. We're turning more APIs into beta, mostly database APIs have turned beta. And we're on a we just released 0.5. We're on a path to essentially turning all of the APIs beta in the next few months, the ones that we support on the core base. It is an open and extensible platform. We're hoping that there are more people that kind of bring in their stacks and essentially help us with maturity around them. All right. Thanks. No offense to our sponsor, but this was a very GitLab focused approach of how crosspoints used. Is there a roadmap or thought about how this would integrate in other CIC pipelines or code repositories? Yeah. I mean, cross-plane works with, I mean, cross-plane is essentially you can install in any Kubernetes cluster. There is nothing that ties it specifically to GitLab. We've just done a lot of really good work with GitLab folks to integrate into the experience. In fact, yeah, I'm sure there are others you could look at that are on the cross-plane blog that all should work. As long as your CICD pipeline of choice supports Kubernetes clusters, cross-plane slots in really nicely. Yeah. I believe there is some work around that, but I'm not sure... What was the question? Sorry. Any direct integration with Spinnaker? I believe that they're involved, but I'm not sure if I know the status. Thanks. That's really good stuff. One question would be, how has cross-plane been integrating or interacting with the SIGs around multi-cluster or cube-fed? I mean, these concepts are great. I'm interested to see how it maps into the broader community. Yeah. Good question. At this point, so we actually... I'll address the Federation one first. That one is interesting because I think there's definitely... It feels like there's... From a workload scheduling across clusters, there's overlap. But the approach that we take is a bit different. So we looked at it early as could cross-plane itself use Federation. And I decided that that was actually not the right starting point for us. And went down a path of essentially defining a concept of a workload. We call them Kubernetes applications, looking at it from a scheduling problem as a scheduling problem onto clusters and managed services and essentially going down that path. And it didn't take much for us to kind of essentially diverge from architecturally. And we realized that the starting design points are quite different. From a cube-fed standpoint, they see the world as a set of Kubernetes clusters and they're essentially trying to propagate Kubernetes API to API objects to each of the clusters. We're creating an abstraction for workloads on top of clusters and not clusters and other stuff. And so it wasn't a great match for us. Your second question about SIG cluster and others. My understanding is most of the work on clusters is focused around managing the cluster internally. We're quite early in that work where we'd love to figure out how to integrate that. At this point, we support API to deploy clusters, mostly managed clusters, EKS, GKE and AKS. But we're not in the business of, say, growing a cluster or adding things to a node pool yet. And so that's what I think that collaboration will be very meaningful. One more. I'm still trying to understand how cross-plane fits in architecturally. Is it an application that is orchestrated by a cluster? Does it extend a cluster by adding its own custom resources and controllers? Is it some combination of those things? Did I miss the mark? Yeah, it's the latter. So think of it as like, if you were to bring up your own Kubernetes cluster, let's say it's mini-cube or whatever your choice is, right? You have APIs for pods. You have APIs for deployments. You have replica sets, volumes, all that stuff. When you install cross-plane, you now have APIs for Postgres and MySQL clusters themselves and other things that are part of the thing. And when you run, when you create YAML for Postgres database and you configure a class for it, RDS comes up in Amazon or Cloud SQL comes up in GCP. So essentially, it looks like a set of extension APIs to a Kubernetes cluster. All right, one last. Can you comment on the relationship to Service Catalog in Kubernetes? Yeah. So Service Catalog is from a perspective of, say, enabling a Kubernetes cluster to interact with managed services. That is similar in terms of what we're trying to do. I think the differences are substantially around, you still need a Service Catalog outside of a Kubernetes cluster and that's kind of, you'd have to run your own service broker, which can be quite an undertaking. And then the other thing I'll say is that I don't think there's any attempt to create a set of abstractions in Service Catalog. It's essentially like thin wrappers to just provision. And also there is no kind of lifecycle management. So Crossplane attempts to do both of those in a Kubernetes native way. And that's also my understanding that most cloud providers now are deprecating their Service Catalog offerings. So I'm not sure what the status of the project is. Awesome. Thank you. Lots of questions around Crossplane. You're on to something, Masam. And for folks, if you want to talk more on conference.