Dec 30, 2022 10 min read book

2022/2023

2022 is a challenging year for me to describe. I met so many amazing people from all over the world, and the rewards and experiences I got through the year were unimaginable back in January.

2022 is a challenging year for me to describe. I met so many amazing people from all over the world, and the rewards and experiences I got through the year were unimaginable back in January. 2022 was when I did my first keynote presentation with my friend Whitney Lee in front of 8000+ people at KubeCon NA (Detroit, USA). And while that is definitely one of the highlights of the year, and it is very difficult to compete against that, I am more than proud of the live and interactive demo we did with Thomas Vitale at KubeCon EU (Valencia, Spain) for 1000+ people. And while I didn't do my best presentation at KubeDay Japan (Tokyo) I had a fantastic time visiting and exploring Tokyo with my father, so at least in my head, this year will be difficult to top.

Technology-wise, in 2022, I've focused most of my energies around Knative and Platform Building for Kubernetes (Crossplane, ArgoCD, Tekton, Knative Functions, Kratix, VCluster, Buildpacks, etc.). While I didn't manage to finish my book this year, the experience of collaborating with projects and different initiatives has been fundamental for me to understand better the industry trends and what's to come next year. I wanted to start this blog post with a quick summary of the projects I found interesting this year and what I think I will focus on in 2023.

Community-wise, I look forward to going deeper into the Dapr community and keep working as a member of the Steering Committee of the Knative project, as well as the Knative Functions Working Group Co-lead. I do feel the need to engage with CNCF TAGs, and Working Groups specialized in bringing projects together both for platform building and also for developer experience and tools.

Projects in 2022

Already in Valencia (KubeCon EU), it was clear that both the ArgoCD and Crossplane communities were gaining much momentum. More and more companies sharing their internal platform stories keep referring back to these projects or the way that these projects are building core features for teams that are trying to build platforms on top of Kubernetes. When using tools like Crossplane and ArgoCD, it becomes quite clear that sooner or later, you will need a Management Cluster(s) where you install all these tools and Worker Clusters where teams will run their applications. While platform engineering is not a new topic, seeing the Kubernetes community push these topics forward makes different Open Source projects and initiatives reevaluate their role in such platforms.

Interestingly enough, Management (or "The Platform") cluster(s) don't run workloads; they just run tools, and that makes a lot of sense because you don't want to run your customer-facing applications in the same clusters where your CI/CD tools are running. Another common pattern is to use this Management cluster to host what is known as the Platform APIs. These APIs are becoming increasingly important, as their main objective is to hide away from teams using the Platform in which tools are used to perform different jobs. Most of the time, teams creating features are not interested in knowing the specifics of which CI/CD tools are being used or which Identity Manager provider is being used. As soon as their software gets built and delivered, and they can create users with different permissions, they can do their work.

And while multi-cloud is not a reality for most companies, there is a clear trend in companies designing for it on their platforms from day one. Having platforms that can span across multiple clouds, regions and consume services from different Cloud Providers seemed futuristic from a developer's point of view earlier in the year. Still, more and more tools are maturing to a point where these scenarios feel closer. I've spent some time this year writing these four blog posts about the challenges of building these kinds of platforms ([1], [2], [3], and [4]), where I concluded that:

Platform teams/Platform Engineering emerged as new teams that take the responsibility to provide platform services as products. The platform's customers are the application development teams building business value (new applications and delivering new features to our customers).
We need better tools to create Platform APIs, as they are fundamental to abstract away the complexity and reduce the cognitive load required to use all the tools that the platform is adopting. Extending the Kubernetes APIs to expose higher-level concepts is one alternative to building Platform APIs that leverage the declarative power of Kubernetes while automatically integrating with all the tools available in the Kubernetes ecosystem. Tools like Crossplane Compositions and Kratix play a big role in this space.
Building platforms on top of Kubernetes is hard, but it should become less and less painful. If you look at the CNCF landscape, tons of projects are constantly added, and existing projects are always evolving. If you build a platform that, let's say, uses 10 of these projects, your platform team now has tons of integration challenges. Once those integrations are done, they will still need to maintain and keep updated on all these projects and integrations. I've seen again and again that this can be done and one of the tricks to manage all this complexity is to get involved in the projects that you are using. CloudEvents, CDEvents, and similar standards/interfaces will play a big role in the future.
Focus on Developer experience is required to ensure that development teams don't need to be experts on cloud providers, Kubernetes, containers, or tools that are not directly related to their tasks. Having a powerful Platform API is only one step to enabling teams with a self-service way to provision the infrastructure and tools that they need. But more is needed. I've demonstrated several times these year tools like Knative Functions func CLI, which promotes a polyglot way to create functions and deploy to Kubernetes without the need to write Dockerfiles or YAML files. Using tools like Buildpacks to automatically detect your application's stack and then enabling platform teams to define how these applications should be containerized. Tools that include, by design, the Platform Engineering persona will become popular in organizations building their internal platforms. Tools like VCluster, DevSpace, and GitPod play a vital role here, too, as cheap and fast provisioning development environments that are fully Kubernetes compliant is a big step forward.

In 2022, I had a lot of fun working with:

VCluster plugins with Fabian and Ishan from Loft
Kratix with Chris, Paula and Abby from Syntasso
CDEvents with the CDEvents Working Group especially Andrea
Crossplane with Viktor, Dan, Jared, Nic, and the rest of the gang
Java + Spring and Kubernetes Controllers with Cora

I was lucky to get advice and help from amazing people like Duffie, Cheryl, Gerhard, Michael, and Steffan. I will forever be grateful for all the introductions and wise words you shared.

I hope to keep all these collaborations in 2023 as

What am I looking forward to working on in 2023?

In 2023

First, I must finish and publish my book Continuous Delivery for Kubernetes for Manning this year. There is still a lot of work to do. Still, now that I've finished all the chapters' drafts, I feel confident that I can close the first edition before the first half of the year. As soon as I return from holidays, I will start the reviewing process for all the chapters, improving all the linked step-by-step tutorials you can find in this repository and including a couple of new projects that fit really well with the topics I am currently covering. If you are interested in collaborating, reviewing the content, or helping me improve the examples, feel free to drop me a comment or message on Twitter/Mastodon.

Looking at how platforms (and platform engineering on Kubernetes) evolve, I expect to see more and more tools in this space. Still, I expect to see more around measuring platforms' performance. If we are building platforms to solve problems and reduce our teams' complexity and cognitive load, we need to measure how effective these platforms are. If we cannot measure how our platform is helping our internal teams to deliver more software, we will run into trouble justifying the funding for more platform initiatives. I see a clear path forward where we can use the DORA metrics to measure our platform performance. I've created a very simple PoC (proof of concept) using CDEvents which you can find here, and I hope to have time to move forward next year.

I look forward to seeing more projects pushing back on creating Kubernetes Operators (Custom Controllers) and more service providers implementing the Service Provider pattern following the lines that projects like KubeBind and KCP are promoting. Projects like KCP feel very close and aligned with my current line of thoughts I hope to get involved more closely with that community and contribute there too. Making sure that we have a clear separation between Compute (running workloads) and APIs (exposing declarative APIs for more than running workloads) in the Kubernetes ecosystem is becoming not only a hot topic but a requirement for many organizations.

Joining the TAG App Delivery in the CNCF is something I haven't had time to do yet, but I should, as those folks are awesome, and I see Dapr as very relevant in that space.

But if you ask me today, what are the trends that I am expecting to see in 2023, here are two that I am personally interested in:

Building modern developer-focused stacks: now that we have defined the responsibilities of platform teams, I am expecting to see the next iteration on full-blown developer stacks, and by this, I mean a set of tools that enable more complex development experiences for developers to focus more on writing code, and the tools focus on enabling developer with complex workflows so they can deliver software with more confidence. To be a bit more concrete on this trend, what I am expecting to see is how tools like VCluster, Knative, Dapr, ArgoCD, Buildpacks, Dagger can be used to define developer workflows that can be enabled by platform teams. So far, Kubernetes-based platforms have been focusing on provisioning infrastructure and wiring things together, so the conversation is ready to move forward to our developers' laptops. Once again, this is nothing new. Cloud Providers like GCP provide a gcloud CLI which allows developers to locally obtain all the tools needed to interact with Google Cloud services. We need the same for Kubernetes, maybe kubectl plugins can deliver that experience, but I would expect more high-level tools that abstract away the complexities of interacting with Kubernetes. Imagine a multi-cloud multi-cluster version tool that allows you to get the right kubectl version for different clusters running on different cloud providers. Developers should be able to download a single tool that can consume platform interfaces to download other tools that might be required in the environment. Alternatively, Cloud Environments are also promising in this space. They are a valid alternative when they allow platform teams to customize how these environments are created and which tools are included.
CNCF Project cross-pollination: today, building platforms is quite complicated and time-consuming because we haven't defined workflows across different projects. With more and more projects graduating in the CNCF, we will see a push for projects to work together and more interoperability. I would like to see projects evaluated based on how many other projects in the ecosystem they integrate with. More integrations across different projects will mean more advanced workflows implemented out of the box for platform teams to consume. I am sure I will be bringing projects together as I did in 2022 (for example, Crossplane + VCluster + Knative, or Knative + Dapr), and I hope to see more formal project initiatives around this too.

Finally, and the main reason why I am so happy to be part of Diagrid and the Dapr community is that it feels like Kubernetes + Crossplane + ArgoCD + KCP + KubeBind + Tekton + Dagger and other projects are coming together to provide a solid core of capabilities at the platform level. Tools like Dapr, Knative, OpenFeature, and VCluster, among others, focus on what I consider modern developer stacks on top of Kubernetes.

This modern stack enables developers to consume infrastructure by relying on stable APIs, enabling Platform engineers to define underlying implementations and the required configurations. I see tools like Dapr and the Dapr building blocks APIs as the right abstractions for a multi-cloud multi-cluster data plane for application developers to focus on writing features against solid APIs. At the same time, enabling Platform engineers to make decisions that span across different cloud provider services and infrastructure.

Thanks a lot for reading, and I wish you a happy 2023! 🥳 Now it's time to disconnect a bit and recharge 🏖️