I had the pleasure to start working on Kubernetes very early on in 2015, before 1.0, working for Mesosphere building Kubernetes-on-Mesos. Shortly after in 2016, I moved to Red Hat to work in their upstream/kubernetes/control-plane team, with lots of upstream contributions — eventually becoming #7 of the top-contributors to the main k/k repository. For several years, I was leading the OpenShift apiserver and auth team at Red Hat, working on making the OpenShift control-plane enterprise-ready for production critical workloads.
Early on during my time at Red Hat, I started focusing on kube-apiserver, and within that eventually on CustomResourceDefinitions. I had earned my doctorate in mathematical logic, doing research on type systems for lambda calculus so consistency and type safety was always near to my heart. Consequently, lots of my contributions in Kubernetes were about that. Both in code type safety, but also in enforcing sane type structures in CRDs (schemas), with OpenAPI validation, pruning, defaulting and structural schemas. Today taken for granted and used by a whole industry, at that time, I didn’t dare to think CRDs would play the role they play today in the cloud native landscape, lifting so many products off the ground and leading to a flourishing ecosystem.
There is the immediate, more superficial and obvious answer: Upbound is heavily basing all product offerings, and with that the future of the company, on CRDs — trying to use the established kube-apiserver as a foundation to build an orchestration system that goes beyond just containers.
There is a deeper motivation though. There is a strong alignment of vision. A former colleague of mine, Derek Carr, Senior Distinguished Engineer at Red Hat, wrote in an old promotion doc about me:
“[...] at his core, Stefan wants to build platforms for others to leverage”.
Derek is right. My passion is and always has been building platforms. Clearly, this led me into Kubernetes in the first place and made me stay in that project for 8 years by now, still excited by what we have built and what we are building for the future.
Kubernetes is a platform for container-based workload orchestration.
Yet, the ecosystem has not found a similar, unified platform beyond that. Outside of the actual container workloads, the world is fragmented. Cloud management is fragmented. Hybrid Cloud is a reality for many enterprises. But Hybrid Cloud is hard, very hard. Crossplane has a giant potential role to play in unifying how cloud resources are managed, across the cloud and with the learnings from Kubernetes.
No non-trivial application consists of containers alone. There is nearly always infrastructure around it that must be deployed. Be it the Kubernetes cluster itself to run on, but also other resources like databases, S3 storage buckets or monitoring infrastructure. That’s where Crossplane shines.
The TAG App Delivery working group has been working on a whitepaper to define what we mean by a platform built using tools in the CNCF landscape. Crossplane is at the core of that definition, a tool to provide resources and environments for applications.
The term of an Internal Developer Platform (IDP), as the CNCF whitepaper describes it, is gaining a lot of momentum currently in the community. Everybody talks about IDPs. Every larger organization wants to have an IDP. KubeCon talks have long queues in front of the rooms when people talk about IDPs. This seems to be the next kind of platform thing everybody is rallying around. Maybe it will lead to a de-facto standard platform architecture beyond containers, beyond Kube. Exciting times.
An IDP inherently contains a user interface — to developers using the platform and the admins operating the platform. With Backstage a prominent Developer Portal is developed in the open, originally donated by Spotify to the community. Backstage is a portal to visualize existing systems, integrate different tools and kick off the creation of new system environments. A portal alone is not enough though, nicely summarized by my former colleague and TAG App Delivery chair Josh Gavant in his blog:
“customers asking for portals really want a portal with a backing platform”.
What is a backing platform? It’s that thing that orchestrates the environments and applications visible in the portal. It stores their existence, tracks related resources, and orchestrates their life-cycle behind the UI of the portal. This sounds a whole lot like what Kubernetes does for container deployments. But environments and applications are more than just container deployments. This closes the loop where Crossplane can shine as a machinery to orchestrate all the resources on-prem and in the cloud in a unified way, leading to control planes that are more than just for containers, but to control planes that are universal and scalable for the future ahead.
When I met with Bassam, Upbound’s CEO, at KubeCon Valencia in April 2022, it was obvious to both of us that we speak the same language. Bassam was trying to pitch what they were doing, and I was pitching the work on kcp, why we were building it and why control planes are the future. We were saying essentially the same things. We kept in touch and have been talking ever since up to today.
Hence, I am super excited to finally join Bassam with Upbound on the mission of democratizing control planes beyond containers. The opportunities ahead are huge. Upbound has formed an awesome team. Upbound originally started off from Seattle, but by now spread over many countries and time zones, building a remote first company. I am beyond excited and happy to be here and part of that journey.
If you want to see how we are accomplishing this mission of democratizing control planes, you can try it out for yourself in a free trial of our latest product.
Subscribe to the Upbound Newsletter