Edited - I had a robust discussion with the folks at VMware and Redhat. If you read my Nirmata sponsored eBook, you’ll note that I’m a fan of the OpenShfit approach to K8s. However, the industry at large isn’t approaching K8s in the same way as IBM. I interviewed VMware yesterday and walked away thinking they have a completely different opinionated approach to K8s than IBM. IBM and presumably VMware with Tanzu and Project Pacific will be the leaders in K8s. And they both have very very different messages. Oh yeah and the rest of this post. <\edit>
Remember the dreadful old days of cloud computing? The days in which you were limited to consuming services such as S3, RDS, and Lambda to create a serverless application? Remember when we had well-understood concepts such as DevOps to manage these applications at scale? Teams leveraged these backend services and processes to build micro-services based applications that disrupted entire industries? Those were ancient days, and we developed like cave dwellers. Thank the Googlers that Kubernetes (K8s) was created to remind us that computer science is hard, just as it was always meant to be.
Don't get me wrong; I love the concept of Kubernetes. Developers take something like Minikube to install a microcluster on their laptop. Developers have all of the essential providers and services needed to build and package an application that will run on any Kubernetes compliant infrastructure. All the major cloud providers now have a K8s compliant offering. Hand the packaged applications with the correct description files to deploy the app, and by magic, you have a webscale app!
Yeah, I know. It's not that simple. And you start to get to the why of my disklike for K8s as it stands today. Building webscale apps is hard. More so than I know. K8s doesn’t make it easier. Even if you consume it as a managed service, unlike Lambda, consumers must have someone who understands how K8s works on staff. Of course, it helps that you know how Lambda works. However, it's not a hard requirement for building production-ready Lambda applications. If my job depended on building a next-generation solution that would power my business for the next 10-years, I wouldn't develop it on K8s. Not today at least.
I've spent the past two decades in the large enterprise. I value a balance of stability, agility, and ease of management. Today, if I needed to build a mission-critical application, I'd select one of the legacy cloud platforms or OS-based options. I'd want to limit the amount of infrastructure my team needed to master to run the application in production. When I talk to CTOs that are all in on K8s, they tell me that I'm missing the beauty of the platform. They tell me K8s is more complicated than existing options, but it's worth that complexity.
Before sending this post out in newsletter format, no one could articulate the value of K8s vs. native cloud services. I got a good number of responses to the post. The most consistent answer mentioned the consistency that K8s brings to the development process. CTO's told me that the popularity of containers and K8s provided a mechanism for application hygiene that never took root in other approaches.
It reminds me of a time when K8s filled me with promise. I love the NetFlix Cloud Journey story where they used container orchestration to prepare their JAVA-based monoliths for public cloud. I even based an eBook on the idea. My frustration is the gap in what NetFlix accomplished/the vision in my ebook and the reality running Kubernetes.
I sat down with NetApp's NetApp Kubernetes Service (NKS) team as part of the vBrownBag Build Day Live event. NetApp explained their take on Kubernetes and hybrid Cloud Infrastructure. NetApp will be at Cloud Field Day 6, where I hope to ask deeper technical questions about Kubernetes.
I also talked with HPE during VMworld 2019 where they broke down the integration of their disaggregated Hyperconveged Infrastructure (dHCI) solution and Google Kubernetes Engine.