Kubernetes is being hailed as the next big thing for managing cloud-native environments. Everyone is building their own version, including AWS (with multiple versions), NetApp and HPE. By 2025, will we care about Kubernetes as a platform or will we just look at container orchestration as a feature?
The information technology industry is renowned for creating hype around the “next big thing”. Look back over the past decade and you’ll see all-flash storage, Docker, OpenStack, HCI, CI, Ceph and many other solutions that were expected to displace the incumbents and transform the industry.
- NetApp buys into Kubernetes Orchestration with StackPointCloud
- VMware Project Pacific – First Impressions
- Cloud Services – Build, Buy or Fork?
In reality, enterprises take time to adopt new technologies and a single architecture or platform is rarely eliminated overnight. Businesses are invested in technology and hardware, through assets and skills. Moving away from those investments introduces risk and complexity that simply isn’t needed. There’s no greater example than the US Military when it comes to this paradigm – look at the continued use of 8-inch floppy disks as an example.
However, in the continual need for improvement, technology increases at a super-fast pace. To paraphrase the Six-Million Dollar Man, we can always go “better, stronger, faster”. At the turn of this decade, we were using 1TB drives. Today we have 16TB drives, with all-flash displacing all but the lowest-level of data archives. Look at any component in the IT infrastructure and we can identify exponential improvements in processors, memory and interconnects. Look at software and we see new techniques, algorithms and programming languages exploiting these hardware advances.
IT is in a continual Yin/Yang process of new solutions and product development that then has to translate into adoption by businesses. The hubris of creating a new platform eventually gives way to the practicalities of implementation.
The first step in the process of using new technology is the Discovery Phase. At this point, the technology is a “thing” not a process. We play with the thing, develop it further and go through rapid iterations of adding features and functionality. We may have a few competing “things” to try out – Kubernetes vs Docker, Hyper-V vs ESXi, Rust vs Go, Oracle vs anything else.
Eventually, one (perhaps two) win out and we have a de-facto standard going forward. What happens next?
At some point, adoption becomes widespread. The “thing” is now a process – think server virtualisation rather than ESXi, or containerisation rather than Docker/Kubernetes. Cloud providers and infrastructure providers move to support the new standard. Inevitably, especially in the public cloud, the specific implementation starts to become obfuscated from the end-user.
This is where things become interesting. Vendors need to add value to their specific implementations of “the thing” because we’ve seen time and time again that building a business as a support model just doesn’t scale. So, we end up with forked variants that deviate from the main platform. Just look at the divergence of Linux distributions from the main kernel to see how that played out.
Of course, that divergence isn’t a problem as long as we have some degree of interoperability. In storage and networking, we have many standards that are set independently. Across the rest of the industry, most are de-facto rather than being established through an industry body. [As a side note, that’s one challenge for object storage – S3 has become a de-facto standard owned by AWS. NFS however, is independent (as are block protocols iSCSI and NVMe). SMB sits somewhere in between.]
As Kubernetes becomes more important and widely adopted, I believe we will care less and less about the specific implementations and more about interoperability. As long as the container runtime, interfaces with container registries, and APIs remain open, then the specifics of the underlying implementation of Kubernetes aren’t as important.
At this stage of development of Kubernetes, it’s easy to say “of course the details are important”, but this aspect is another of the traits of new product adoption. We care about the details until we trust implementations that “just work”. This is the entire premise of the public cloud. No-one questions whether AWS or Azure are reliable any more.
The Architect’s View
So today, we do care about the specifics of how Kubernetes is built and deployed. In five years, I think we will have no interest in the detail because the technology will have either been fully integrated into existing platforms or the deployment process will be slick enough not to care. The whole process of how applications are deployed will have much more value than the ability to spin up a Kubernetes cluster. I will be focusing on what implementations of Kubernetes can do, not the detail of how they do it.
Copyright (c) 2007-2019 Brookend Ltd, no reproduction without permission, in part or whole. Post #13b2.