Do I Still Hate Kubernetes as Much?

According to the Kuberati, vendors bullish on Kubernetes, I’m a server hugger. I think much of that perception is due to my reputation within the VMware community. I’m a former vExpert and VMware certification holder. After all, my old twitter handle is @Virtualizedgeek. I’ve made a conscious effort to embrace the public cloud without abandoning the data center. It’s not out of affection for servers; it’s from the fundamental belief that the data center is core to most enterprise IT operations, at least for the foreseeable future. A year after writing “Why Do I Hate Kubernetes so Much,” what are my thoughts on Kubernetes today?

I’m a big fan of knowing what problem a technical solution solves before building or deploying the solution. We took on the CTO Advisor Hybrid Infrastructure (CTOAHI) due to the gap in the market. We didn’t see an independent voice answering how the enterprise data center embraces hybrid infrastructure. We wanted to help fill that gap. So, we invested our money into building the CTOAHI. Our study on the major VMware cloud public cloud solutions represents an early result. I know the study’s topic doesn’t dilute my server hugger persona.

When I look at Kubernetes, I look at it from my perspective as a server hugger. What are the enterprise IT customers I talk to doing? What problems are they trying to solve? Let’s discuss the issues these customers are trying to solve.

What problems exist in enterprise IT

With all the hype around the Kubernetes, plenty of my audience still run VMware vSphere 6.0. To put that into context, VMware vSphere 6.0 end of life was March of 2020. These customers are overwhelmed by technical debt. Keeping up with the pace of VMware vSphere releases have caused a bit of frustration. These pods host traditional monolithic retail applications dependent on Windows Server, Oracle, SQL, and IIS. I believe the Kuberati are too quick to dismiss this landscape of applications.

Then there’s the challenge of cloud applications built before the Kubernetes hype cycle took hold. These are applications that helped the organization go fast due to the public cloud’s democratization of technology. Business units and departments were able to bypass the sloth that IT can build applications that impacted the bottom line.

Most of the customers I talk to are operationalizing these applications. The original sponsors of these applications are learning the difficulty of supporting mission-critical apps regardless of where the apps are hosted. As a result, these applications are falling into the laps of IT infrastructure groups to support. Anywhere from Salesforce SaaS to AWS Lambda make up the category. Us server huggers are solely responsible for ensuring these applications remain up.

Building apps faster

Last, there’s the business challenge of improving the discipline of building apps at business speed. I spoke with a logistics company last year that attempted implementing CI/CD. IT provided virtualized development environments for each development silo. The short is that they broke their existing integration testing. The result was more defects and a slower development process.

Faster application development falls into the center of Kubernetes’ hype. Much of the marketing message is the ability to build applications faster. That is due to the ability to abstract the infrastructure via the Kubernetes API. I love the concept. Instead of application owners and developers worrying about server configurations, the infrastructure is abstracted to a set of YAML files.

Infrastructure as code becomes real. As long as the application owner describes what they need in the YAML file, operators take care of the deployment’s technical details. In theory, if you are running the infrastructure on Kubernetes clusters in AWS, tomorrow, you can run it on Kubernetes clusters on Google Cloud. It’s the modern-day JAVA but for cloud infrastructure.

It worked on my laptop

Experience after experience, it’s been shown that Kubernetes is a more massive lift than expected. The results from users sharing their experience drive home a consistent message – Know what problem you are solving and that Kubernetes is worth the effort. Kubernetes at scale is challenging. It takes operational changes along with a team of brilliant people managing the underlay. For example, merely going from one version of Kubernetes to another isn’t yet a standard process.

Does this complexity make me hate Kubernetes? The short answer, no. I don’t dislike Kubernetes. If you are a cloud provider and need to build an IaaS platform or a development platform Kubernetes enables an operating model that’s not otherwise available. If you are Twitter and want to move to a microservices architecture that works across multi-cloud, Kubernetes is very appealing.

The difficulty I’m encountering in the field – Customers with little to no application development or no significant infrastructure scale are looking at Kubernetes. This audience falls in the first group. These customers run retail applications that don’t leverage any of the abstractions Kubernetes enables. It’s an unnecessary level of complexity for all but a very few enterprises. However, that hasn’t stopped my customers or audience from adopting the platform. So, I’ll take that journey alongside them.

I’ll continue to challenge customers looking at Kubernetes to answer the real questions. What problem are you trying to solve? If the problem is speed of development, I follow with the question, how does Kubernetes change your company’s culture? Are you trying to solve a people and process problem with technology? How will you avoid Kubernetes from breaking processes that work well today? I’ll do what the CTO Advisor does, advise.

I no longer hate Kubernetes. I do still hate deploying Kubernetes just for the sake of Kubernetes.