 Hello, my name is Bessam Tabara and I am the CEO and founder of UpBound and one of the creators of the Crospine project. I thought a good way to kick things off today is to start with the origin story of Crospine, which goes back to 2017. This was the year that Kubernetes won the Container Orchestration Wars. While Kubernetes is known for being the gold standard in container orchestration, I don't believe managing containers is its true superpower. Nor do I believe it's the primary reason that it won. I believe Kubernetes won because it defined a new operating model for managing applications and infrastructure. And it did so with a strong ecosystem and a community-driven approach to open source. We were inspired by this approach and I wanted to walk through each of these from a perspective of Crospine. Let's start with the operating model. There are several properties of Kubernetes you probably take for granted today, but have played a critical role in the project's success. The first property is that you interact with Kubernetes through a RESTful API. This seems so obvious, but it's a far departure from other tooling in this space, especially infrastructure as code tooling that expects templates or programs. The Kubernetes API exposes an independent RESTful endpoint for each resource it manages. Authorization, access control, and other policies can all be enforced centrally and at a granularity of a single resource. Because it's an API, users can pick any language, tool, or framework to interact with it. APIs offer the greatest levels of interoperability and have fostered the largest of ecosystems. The second property is how the Kubernetes API was designed for two personas. Platform engineers who have an intimate knowledge of infrastructure and application engineers who have intimate knowledge of their applications. This separation of concerns leads to organizational efficiencies and scale. Application teams use simpler abstracted APIs like POD and persistent volume claim, while platform teams use full APIs like nodes and volumes. Both teams use human workflows to arrive at their configuration. Storing configuration in Git has become an industry standard, and doing so enables teams to use pull request flows and source management tools for collaboration. With Kubernetes, configurations can be authored via YAML, programming languages, or templates. It really doesn't matter because they all result in the same API calls. All automation, operational, and business policies live behind the API line. Kubernetes APIs follow a thin crud approach and merely manipulate declarative configuration within the config store. These API calls do not perform any synchronous provisioning or deployment acts. Once the declarative configuration is updated, this marks the end of human-based workflows. From this point onwards, controllers are activated asynchronously to read the declarative configuration and act autonomously to implement it. These controllers are rooted in control theory and are in a continuous loop, reading declarative state, observing actual state, and reconciling the two. This is why we call it a control plane. Importantly, human operators are not involved in this Reconciliation Act, a major departure from other approaches that require humans to approve plans, handle drift, and require other systems for monitoring and observability. With this new operating model, organizations can achieve a high degree of automation, once reserved for hyperscale cloud providers. This democratization and implementation of control theory is the reason Kubernetes won the container wars. We started cross-plane because early on we saw the power of this operating model and wanted to take it beyond container orchestration. We believe containers are simply the first use case of this operating model and that this operating model is applicable to the management of all applications and infrastructure. Cross-plane makes that happen. It extends Kubernetes by adding APIs and controllers that enable it to manage resources and services from multiple cloud and infrastructure vendors. Platform teams and application teams can now simply author configurations for databases, caches, networking, and other services. Configurations are continuously reconciled by cross-plane and day one and day two automation is handled out of the box. With Kubernetes and cross-plane, we see the industry moving off of infrastructure as code tooling and onto control planes. While projects like Terraform have been wildly successful, we are starting to see their limitations. Organizing teams around templates has not proven effective. Templates are a much weaker form or much weaker contract than APIs or data. IAC tooling focuses on initial provisioning and requires humans to approve execution plans and that does not scale. The lack of access control has also proven problematic, requiring organizations to create artificial templates to represent team boundaries. Lastly, the lack of API and the vendor-driven nature of these projects has limited the ecosystem around them. Within the cross-plane community, we are starting to see many companies replacing their IAC footprint with cross-plane. Some of these companies will be speaking here today. Control planes offer a declarative API that promotes interoperability and results in a much larger ecosystem. The separation of concerns enables self-service and controllers enable full automation scenarios and avoid the drift. We see cross-plane and Kubernetes ushering a new era of application and infrastructure management that will lead to a much higher degree of self-service and automation. These are the prerequisites to increasing the pace of innovation within most organizations. To usher in this new era of automation, we are investing in formalizing the underpinnings of cross-plane in the same way that Kubernetes has formalized the Kubernetes resource model or KRM. Cross-plane defines a strict extension of KRM that we empathetically call the cross-plane resource model or XRM. It captures the lessons learned within the community in managing external resources. It deals with mixed external naming, identity, adoption of existing resources. It includes cross-resource references, handling connection secrets, and credentials. Composition is the popular feature that enables platform teams to define new self-service APIs for their application teams. And finally, a package manager designed for cross-plane scenarios. Building all of this takes a village and we have been humbled by the ecosystem we're seeing emerge around the cross-plane project. Part of this is due to the fact that if your tooling works with Kubernetes, it will automatically work with cross-plane. But we're starting to see tooling emerge, which relies not just on the KRM, but also on XRM. In terms of cross-plane providers, the community started by bootstrapping the major cloud providers ourselves, but have now transitioned to working directly with the cloud providers and other infrastructure vendors. Our approach has us generating cross-plane providers from their back-end SDKs, and we are doing that successfully right now with AWS and Azure, with more coming on the way. Vendors like IBM Cloud have authored their own native cross-plane providers and are maintaining them. Finally, we've recently added support to generate cross-plane providers from Terraform providers, bringing the entire Terraform ecosystem to cross-plane. To ensure the ecosystem remains healthy as it grows, the cross-plane community applied to start a conformance program for cross-plane. This program is still subject to the CNCF governing board approval and will be run by the CNCF. There are two levels in this program. The first is for distributions of cross-plane. This level is for vendors that plan to incorporate cross-plane into their commercial offerings. Certifying distributions ensures consistency across different vendors. The second level is for cross-plane providers and ensures that infrastructure vendors are compliant with the XRM. If you're interested in the conformance program, please reach out today. The conformance program comes at a time when cross-plane is growing faster than we've ever seen. Organizations of all different sizes are adopting it in production. They are augmenting their existing Kubernetes deployments, while some companies are using it as a centerpiece of their cloud-native transformation, moving off of IAC tooling entirely. All this momentum in the community has led us to apply for promoting cross-plane to incubation status at the CNCF. The TOC will vote on this shortly, but we are extremely excited by the progress. Finally, I wanted to throw in a word from UpBound, one of the companies sponsoring this event and the company that started the cross-plane project and donated it to the CNCF. We are on a mission to bring cross-plane to organizations of all sizes and have a number of product offerings around cross-plane that we will be announcing later this month. Please stay tuned. If you want to be part of our mission or want to learn more about UpBound, please visit our website. Thank you and have a wonderful cross-plane community day.