Enterprise software infrastructure is going through a renaissance.
Kubernetes has captured the hearts and minds of the open source community. Cloud providers have successfully opened the wallets of even the most resistant enterprises. Vendors of all shapes and sizes are getting their phone calls returned by banks and insurance companies wishing to make progress on digital transformation.
Digital transformation requires an updating of all areas of application management. From integrations to security to logging to monitoring to data management to data access to authentication. Everything is getting upended.
Three years ago, the Docker container became the deployable instance du jour. Enterprises knew that they wanted containers, but they weren’t sure how to deploy and manage the vast quantities of containers. Then came the container orchestration wars, and enterprises were scared to commit heavily to any particular orchestration provider. Kubernetes won, and now enterprises are figuring out who to buy it from.
Enterprise developers are excited, because “cloud native” software is more fun to work with than the software generation prior. But there is mass confusion, as the options for infrastructure proliferate.
Yes, your enterprise is hybrid cloud and multicloud. But what are you putting in the cloud? How many Kubernetes clusters are you deploying? Can you put any data in the cloud, or are you terrified to move any data out of your on-prem data center?
Today, containers are still used under the covers, but it is less clear how we want to be manipulating them. Enterprises are excited about deploying and managing Kubernetes. But they might soon find that the period of time where we operated a Kubernetes cluster is as short-lived as the period of time where the state of the art was to manage your individual containers with scripts.
This morning I spoke with two people who gave me very different (though mutually compatible) visions of the Kubernetes ecosystem.
The first was Ville Aikas, who has worked on Google infrastructure for 11 years and is involved in the Knative project. Knative lets developers deploy serverless platforms on top of Kubernetes. Knative is highly tunable, and allows you to create a serverless platform for both short lived, auto-downspinning, event driven functions as well as longer lived container instances. The former is like AWS Lambda, the latter is like AWS Fargate.
These types of containers are two opposite ends of a spectrum. But along the entire spectrum, no application developer should be caring about any of this. The application developer should be writing business logic and the deployment platform should figure out the most economical way to run that business logic.
That’s what enterprise developers have to look forward to in the near future. Closer to the present tense, I also spoke with Brad Meiseles from VMware today. He told me about VMware’s PKS and gave me some projections on how Kubernetes sprawl might play out.
Today, a bank is figuring out its Kubernetes strategy, and they might be purchasing Kubernetes-as-a-service from multiple vendors. Additionally, different bank departments might be buying different Kubernetes-as-a-service for similar purposes. In other words--a bank is not necessarily purchasing Mesosphere OR Red Hat OpenShift. There might be one part of the bank that prefers Mesosphere and another part that prefers OpenShift. This is even more likely to happen given the increased procurement power of the actual developers (the “bottoms up” sales process).
Assuming the bank does not have a completely centralized procurement strategy, with a uniform, org-wide Kubernetes deployment plan, the bank could buy PKS, Mesosphere, and Platform9 to have Kubernetes for its on-prem servers and EKS, AKS, and GKE to have access to Kubernetes on all the cloud providers. This sounds like sprawl, but I don’t think it’s unrealistic. All of these platforms are developing very quickly. They have divergent feature sets that might make them appealing to different parts of the organization.
Here’s where Brad made a fascinating point: fast forward another 5-10 years, when Kubernetes spend is out of control for the bank, the bank could look to consolidate its Kubernetes deployments onto just a few providers. Since these providers are all running Kubernetes conformance tests, porting these workloads from one provider to another might not be too tough in the limit.
In any case, the developers at the bank hopefully won’t be thinking about containers at all: they will be thinking about applications.
Top comments (0)