Kubernetes is cool, but not for the reasons you think. For a time people glommed onto Kubernetes because it promised to be a great new cloud technology—something like OpenStack (without all its problems). But Kubernetes wasn’t. Nor was it a magical cure for lock-in that offered unbridled portability. Not even close.
Instead, Kubernetes has become the new Linux, as I’ve written. Or, perhaps more accurately, it’s a new app server, as Weaveworks CEO Alexis Richardson suggested in an interview. Rather than enterprises trying to build their own clouds, he argues, “Let your development teams run short-lived Kubernetes clusters that are like app servers.”
What does this mean, exactly?
Technobabble and gobbledygook
Richardson and I were supposed to talk about multicluster Kubernetes on bare metal with microVMs powered by Firecracker. Five seconds in, my eyes were glazing over, which was a problem since I was driving. “Besides being fit for the edge scenario, mixed mode enables significantly greater efficiency in managing bare metal Kubernetes clusters by moving control plane nodes from dedicated bare metal servers into microVMs, thus significantly reducing the overall number of nodes required in a bare metal pool!” he intoned, citing the company’s blog post on the topic.
I was trying desperately to care, given that my employer released Firecracker as an open source project. But I couldn’t. I couldn’t get excited about telco operators rolling out “5G applications where ‘network function’ (5G workload) can be run alongside signaling functions, management functions, web and customer applications in the same hardware with strong isolation and resource control.”
Someone cares about this. I didn’t.
At this point Richardson said, “Am I making sense? Are you there? Hello?” and I thought of hanging up and pretending my signal had dropped. But then he said it was all about “a hyperefficient way of starting up fleets of Kubernetes clusters on minimal resources” and my eyes began to deglaze just a little.
Kubernetes as an app server
When it really made sense, however, was when he likened Kubernetes to Linux or an app server. This was a world I knew, having grown up in tech during the JBoss/BEA era of app servers. An app server is a collection of generic functionality that you can use to run an application, either by embedding it in the application, or running it first and then running the application on top. Although we don’t talk much about them anymore, they’re very common in the enterprise.
In the app server model, the application life cycle is associated with the life cycle of the stack or the cluster of the application it’s running on. When you don’t need the infrastructure anymore, you just shut it down and throw it away. Cloud is different; it’s permanent, even if the resources running on it may not be. The idea of a cloud is one where somebody looks after the cloud and it persists beyond your requirements to use it. Instead of companies building their own clouds, Richardson says, “let Amazon, Google, and Microsoft run clouds, and let your development teams run short-lived Kubernetes clusters that are like app servers.”
Implicit in Richardson’s thinking of Kubernetes-as-app-server is a powerful principle for enterprise IT: Set your development teams free. “It’s actually much better to let individual application teams set up their own infrastructure using Kubernetes clusters instead of procuring enterprise cluster resources from central IT,” he notes. Rather than some massive Kubernetes cluster from which individual development teams are forced to borrow, a better strategy is to encourage “single-use applications or groups of applications that can be managed by a small group of people—or even as few as one. The best practice for using it is to have lots of Kubernetes clusters, lots of Kubernetes-backed applications, rather than trying to manage it as a cloud.”
This flies in the face of establishment thinking that Kubernetes is complicated and hard. Well, maybe. But that difficulty often comes from trying to treat Kubernetes like some centralized cloud, rather than enabling app-serverlike functionality for smaller teams. It’s about autonomy, Richardson explains:
“Dev teams will be productive when they are allowed to own operations. They need to know they can fix things when they go wrong. Otherwise, they cannot take responsibility for security and performance. We are empowering that at Weaveworks. Kubernetes and GitOps absolutely helped that because the dev teams can make the infrastructure, the cluster, the stack, something they can start and stop at will. They can procure it on demand. In the old days, developers would start and stop Tomcat at will. They wouldn’t ask someone else’s permission to do it, right? That is how Kubernetes is going. It works in exactly the same way in the enterprise.”
This is an incredibly liberating vision for modern IT. It’s also a great way of making sense of the technobabble that kicked off our conversation. “In the blog post that I shared with you,” he says, “We’re just showing that we can do this more efficiently with a wider class of use cases, including edge workloads.” Oh, well, why didn’t he say so at the beginning?