 Hi, I'm Tobias. I work for Vision and I live in Zurich, Switzerland. Vision operates managed services for the customers all around the world, even in Australia for the Australian government. Usually, the customers have high security requirements and some of them are in highly regulated areas like banks, insurances or telecommunication companies. About a year ago, we decided to base our next-generation managed services offering on Kubernetes and discovered Crossplane as a potential control plane to achieve that. With our open-source tooling called Project Syn, we created the basis to orchestrate configuration on a huge fleet of Kubernetes clusters, including the deployment and configuration of Crossplane itself. Our first implementation is Crossplane as the orchestration control plane together with Project Syn is made for the biggest Swiss telecommunication company called Swisscom. At the beginning, Swisscom offers Redis and Mariah de Vigalera in their internal services marketplace as a managed service, running on Kubernetes at massive scale. The amount of expected service instances is so high that it's not possible to run them all on a single cluster of their internal Kubernetes offering. These services are currently consumed by applications running on Cloud Foundry and the services need to be available as a full-sales service offering in their internal marketplace. It is planned to extend the offering to users of the managed Kubernetes offering called iCube using the Kubernetes Service Catalog. All these services are running in Swisscom's own data center and infrastructure with high security measures. For matching Swisscom requirements, we had to implement an open service broker API application which maps Crossplane concepts to the concepts of the open service broker API specifications. As the ideas behind Crossplane matched the ideas behind the open service broker API very well, we were able to write a translator between these two worlds called the Crossplane Service Broker. In this diagram, you can see that the service offering maps to the composite resource definitions, service plans map to compositions, and service instances map to composite resources. All are integral concepts of Crossplane. The Crossplane Service Broker operates solely on Crossplane objects and no other state is needed. Let's have a look at how this looks like in a live demo. We'll see already this instance provisioned on the service cluster which was requested by a user via the service catalog. The demo environment consists of three local K3D clusters and this architecture represents a real-world example. The Crossplane cluster in the middle of this diagram exists once and runs Crossplane and the Crossplane Service Broker. The services itself are provisioned via the Crossplane Helm provider on the service cluster from which many of them could exist and in reality a lot of them exist. The end user is using the services from the consumer cluster by using the Kubernetes Service Catalog. Now let's dive into it straight away. In the middle you see the control cluster. This cluster is running Crossplane and we will now have a look around what is available in this cluster. First, we will have a look at the composite resource definitions. You see there is already this instance defined. This composite resource definition also has a lot of metadata available which is then consumed by the Crossplane Service Broker to be presented to the user of the broker. When we look at the compositions which map to the service plans on the Open Service Broker API, you can see that there is one plan defined which is called ready small and this is represented by this composition. Also this composition has metadata which again is used by the Crossplane Service Broker to be presented to the user of the broker. Carrying the cluster for ready instances shows us that there is currently no ready instance provision. Let's change that. We will switch now to the consumer cluster and check what brokers are available on this cluster. The only broker configured at this time is the ready broker which is ready. Carrying this broker for available services is returning us just one service. It's the ready service and one plan, the small plan which we can now provision. This is very easy with the Service Catalog command and at this time the service is getting provisioned what we can see with this cat instances command which shows us the state provisioning. Going back to the control cluster, now we can see that there is now one ready instance object available. This has been created by the Crossplane Service Broker on the call from the consumer cluster. This is now being provisioned by the Crossplane Helm provider and we can see that there is already a release object created by Crossplane and this actually instantiates a Helm chart on the service cluster and this is already done here down on the bottom of this window in the service cluster. Also this service is provisioned into its own namespace which we can now have a look into. And see what ports are available in this namespace. So you can see the ready service is already up and running and if you go back to the consumer cluster we can see that the status is in this time ready. So the service is available for the end user to be consumed. For that we are now creating a service binding which returns us all the needed information to actually connect to this service. This is now done. The status is already ready and this created a secret on the consumer cluster ready to be used by the application. This secret contains information like the server, IP addresses, ports, usernames, passwords and all other parameters which are needed to contact this service actually. That's the end of the demo. Let's go back to the slides shortly. If you want to try this out yourself it's hosted on GitHub. The full demonstration is available on the URL displayed on the slides. The Crossplane open service broker API is open sourced on GitHub and it's already being used in production and will be gradually improved over time. We have some points on the roadmap already. So the first thing we will do is implement authentication with bear token which could contain meta information for example for access control or for filtering plans which are available to this particular user or team whatever information is stored in the token. This will allow us also to as mentioned implement the plan filtering on the broker side. We will also implement asynchronous binding operations and last but least we have plan upgrades on our plate so that we can operate for example from small to medium plans and so on. We work on these features over the next weeks and months. Some of these features are depending on features in Crossplane which will be hopefully available very soon. If you want to know more about what we did please reach out to me at my email address or on Twitter. Thanks for listening and enjoy the Crossplane community day.