Platforms at Kubecon 2022
Kubecon on October 25 was a great chance to meet people and discuss emerging ideas for making cloud computing easier and more efficient for practitioners and enterprises. Cloud platforms and platform engineering were a popular discussion item and seem poised to finally offer a path for enterprises to maximize dev/ops cooperation and efficiency. In the interest of better understanding the requirements of such platforms for my role as lead of CNCF’s Platforms working group (WG), I spent time talking to leaders and project maintainers developing building blocks for them. The WG plans to provide a guide on capabilities and requirements of typical platforms by the end of 2022.
In particular, the Platforms WG held an “unmeetup” (slides here) where several platform component providers introduced themselves and shared a brief technical introduction to their projects to facilitate awareness and cooperation. Crossplane, Score, Dapr, Rukpak, VCluster, Kratix, kcp and servicebinding.io were all represented and discussed as we seek to categorize functionality and increase compatibility to ultimately reduce complexity for platform engineers and help them succeed.
I shared in our meetup an early attempt at categorizing some of the required functions of a cloud platform, come discuss it in our Slack channel:
Notable trends
Following are some trends I noted at Kubecon relevant to platform builders:
Projects are emerging to aid in composition and abstraction of collections of Kubernetes resources. Most platform engineers are happy using Kubernetes APIs via YAML manifests as the foundation for provisioning and managing services and capabilities from their platform; but most desire to provide a reduced abstraction over these resources for their product developers, exposing only those parameters relevant in their environments. While Helm and its values.yaml files have provided such a paradigm for a while, several more advanced projects have emerged that allow platform engineers to curate reduced APIs: Crossplane’s Composite Resources, Kratix’s Promises, and Google’s kpt are examples.
It would be helpful to compare these composition patterns as well as related models from Terraform, AWS Cloud Formation and Azure Resource Manager and iterate forward together.
Service catalogs are emerging to gather and advertise curated services. Modern digital products and services depend on many capabilities and services from a platform, from block and object storage to databases, identities and monitoring systems. These digital products may also use other line-of-business services. Projects like kcp and kubectl-bind make it possible for platform engineers to offer self-managed and provider-managed services via Kubernetes APIs just like pods, volumes and network gateways. Internal service catalogs like Ortellius can collate line-of-business services. And portals like Backstage can be used to make all these services easy to find, provision and observe on demand. Developers can choose services they require from catalogs and create reproducible environments, perhaps even in a virtual cluster like vcluster.
Service binding patterns are proliferating. As it gets easier to provision additional services and capabilities via Kubernetes, users need ways to retrieve “binding” info once a service is ready. Service “bindings” could include a URL for dataplane access, credentials for authorization and endpoints for logs and metrics. Hashicorp’s Vault Agent and its secrets engines are one way to get such bindings, but other mechanisms also exist like Crossplane’s secret stores and servicebinding.io. Many tools write connection details to a resource’s status or a named Kubernetes Secret or ConfigMap and require users to read the docs and learn each tool’s conventions.
It would be helpful to converge towards a standard set of bindings generators and standard locations to put this information in resource descriptors and runtime environments.
Bundlers and deployers based on OCI are popular. Several projects now offer to bundle container images alongside infrastructure descriptors in OCI (Open Container Initiative) packages; these packages are then retrieved, unbundled and applied by custom controllers running in Kubernetes clusters. Examples include porter, acorn, Carvel’s imgpkg and Operator Lifecycle Manager bundles. Valuably, the rukpak project aims to offer a package manager which supports many different bundle formats via Provisioners.
It would be great to see unbundlers and provisioners for several different formats in one controller like Rukpak.
Conclusion
Cloud platforms and platform teams promise to make cloud-native application development more efficient; and lots of tools and patterns are emerging to make platform builders’ jobs easier.
Our next work in CNCF’s Platforms WG aims to support these builders by defining key components of a cloud-native platform. We’ll also bring together providers of similar component types and seek conventions and patterns to increase compatibility and make usage easier for platform engineers. Join us!