This year I traveled to Detroit, Michigan to join two of my co-workers for KubeCon and CloudNativeCon. While this was not my first trip to Detroit, it was my first time attending KubeCon. As I write this, I think I am maybe running on about 12 hours of sleep. It was not just the time zone shift that contributed to my lack of sleep, it was the excitement.

Highlights

In no particular order:

• Meeting Kelsey Hightower, getting his autograph, and having a chance to thank him for his part in writing Kubernetes: Up and Running.
• Meeting Nigel Poulton, also getting his autograph, doing poorly at his quiz game (still ranked in the top ten), and learning about using WASM in Kubernetes.
• Learning about Crossplane and having to pick Nic Cope’s brain not once, but twice on how it can be used to provision resources from Kubernetes rather than using Terraform.
• Learning about how to use Crossplane with tools like Open Policy Agent or Kyverno in conjunction with ArgoCD to create a well governed self-service infrastructure as code platform.
• Learning about how Knative uses build pack to bring serverless architecture to cloud native.
• An absolutely top notch presentation on NATS.
• The Henry Ford Museum is just as awesome as ever.
• Getting to know my co-workers better and learning about the things that interest and excite them.
• Receiving no fewer than ten compliments from total strangers about my mustache, including a TSA agent who described it as “glorious” and congratulated me. I would like to thank my Barber.

Key takeaways

Crossplane

I am bullish about Crossplane replacing Terraform for many teams. As I mentioned in my highlights, I had an opportunity to speak with Nic Cope in depth about how I can use Crossplane to take Terraform’s place for the engineers my team supports. Why Crossplane? In short, it looks and feels like Kubernetes, because at it’s heart it is Kubernetes. Crossplane offers escape hatches to enable adoption. The implementation of Terraform can be hidden by a Crossplane API object. Additionaly, Crossplane can be extended with containers that pipe from stdin to stdout. With the introduction of Web Assembly (WASM) support in containerd it is possible to create small and lightweight functions to extend Crossplane in programming languages capable of producing WASM binaries.

It is important to note that Nic did explain that such escape hatches are alpha features and their functionality may be deprecated in the future. Nic was very clear that Crossplane’s API be as conservative as possible. I had the opportunity to speak with Nic after his presentation and suggested that common trends in custom composition functions could be used to inform the Crossplane developers where to expand Crossplane next. I think there is also an opportunity for a composition function and provider marketplace for users looking for more functionality. Currently, composition functions are off by default. It is probably best to see how far you can get without them.

NATS

I have known about NATS for some time, but it is better than ever. NATS is (by the description of it’s maintainers) a message oriented middleware. It can be used in many ways, including a message queue, KV and object store, and temporally decoupled streaming server. NATS can be used for connectivity over multiple clusters across multiple clouds. It has the ability to automatically route messages to the closest responding server and automatically failover between clusters and clouds.

The presentation I attended demonstrated the capabilities of NATS in an interactive demo. The presenter asked each of the attendees to visit a URL on their phone or computer. We were prompted with a short survey and then the results where displayed in real time. Afterwards, the NATS CLI was demonstrated and used to redirect each of the participants to a new URL where we could all draw on a shared whiteboard. All of this was done on NATS.

Knative

Knative offers serverless computing in a cloud native environment. It uses buildpacks to abstract away the need to create a Dockerfile to produce a container. Buildpacks are able to produce containers by evaluating the application and it’s dependencies. Knative offers the func CLI, which automates the generation and publication of Knative applications. The func create command can produce new Knative function projects in a number of languages.

Knative also abstracts away the typical considerations for building an application for Kubernetes. Ingress rules, horizontal pod autoscalers, and even the need to understand the HTTP framework in your language of choice is abstracted away with Knative functions.

Knative has some interesting features that make it a compelling alternative to cloud provider serverless platforms. For example, Knative functions can be tuned to handle a certain number of requests before terminating to avoid connection spikes to database servers. It also integrates with event sources such as Kafka and NATS. I had the opportunity to speak with a couple of the Knative maintainers and they said that Kafka support is generally available, while NATS is in beta. They are looking for users of NATS who wish to connect with Knative functions to gain feedback on how the NATS broker should evolve.

Self-Service Governance

Self-service infrastructure has been at the forefront of my mind for some time. How can it be made easier? How can it be made safe? How can it make security and compliance easier? I think when you describe a process where developers can assemble an automated cloud platform people tend to imagine an absolute free-for-all where everyone gets to do whatever they want. Inevitably, they demand to know how such a process will be governed. From my perspective, there are three pillars to self-service cloud governance. Individually, each is inadequate. Together, they compliment the strengths and weakness of the others.

1. Infrastructure as Code: This sounds pretty obvious, and it is. Infrastructure as code enables organizations to place controls on what types of changes are accepted through the approval and delegation of approvals via code ownership of different domains of the organizations as code. The weakness of this pillar is that it isn’t scale-able on it’s own. If your requirement is to only create resources in certain regions or availability zones it will be very difficult to manually review each pull request for compliance. Additionally, it will never scale if applying changes is a manual process.
   • Enabling CNCF Project: Crossplane
2. Infrastructure Automation: Automating the application of changes to IaC enables self-service. This should happen immediately after a change to IaC is accepted without further intervention from a human. While this pillar frees teams from manually applying changes, it does not free them from manually accepting them.
   • Enabling CNCF Projects: The Argo project (argoCD, workflows, and rollouts).
3. Policy Automation: This pillar persist through each layer of a self-service platform to enable governance in a scalable way. Ideally, situations where a humans need to accept a change should not exist, but I’m not sure we are quite there yet. However, this pillar can free us from needing to review every single change. Policies on their own are not enough. They have to be automated wherever possible. Going back to the example of where resources can be created, an allow list can be created to allow developers to select from one of the one of the approved regions. The policy automation ensures the policy cannot be violated. No further human review required.
   • Enabling CNCF Projects: Open Policy Agent (OPA) and Kyverno.

Each pillar must stand on a foundation of simplicity from the perspective of the end user. Buildpacks and Knative make it easier to deploy code by making it more simple. Providing a homogeneous API for creating and governing the creation of resources makes IaC simple. This is why I think tools like Crossplane and Kyverno should be preferred to tools with their own domain specific language such as Terraform and OPA.

Conclusion

My experience and what I learned at KubeCon was driven by what was important to me, yet there were many avenues to take. I walked away with a framework for getting to my north star, an intuitive to use and automatically governed self-service infrastructure platform. I am looking forward to paving the way in my own career with what I learned at KubeCon this year.