I’m just returning from the Kubecon Austin event and I must admit that the vibe, and the amount of innovation, around Kubernetes reminded me of the good old OpenStack events. Now that Docker Swarm seems to be dropping behind, it definitely feels like Google and Kubernetes are killing it.
During the event we announced our latest Cloudify release with a spotlight on the new Go-based Kubernetes provider that gives Cloudify the ability to be used as a Kubernetes infrastructure provider and cements our position as a first-class citizen in the community.
The event gave us ample time to meet many friends and customers and hear their take on all this. A common thread I noticed in all of these community events is the general feeling that once a platform reaches peak momentum we all feel that there is nothing else in the world but that platform.
This general sentiment - that kubernetes is killing it - was followed by a question that I kept hearing: “Why do I need ‘*’ if I use Kubernetes? Where you could replace ‘*’ with a long list of technologies starting from Virtual Machines, Networking, Configuration etc. Interestingly enough, we can now add Docker Swarm to that list!
In this post, I want to address this question specifically, and hopefully give some much needed perspective. I’ll start with a quick historical recap to refresh our memories.
I know I’ve heard this before
I remember when Java came into the world it also felt that the world would run on Java only, and the other technologies would be hung out to dry.
Technologies that changed the landscape
I heard the exact same thing when AWS, OpenStack with Heat, and CloudFoundry came out - and the list goes on. In retrospect, it’s clear that, while each of those new technologies changed the technology landscape, none was ever the platform to rule them all. I found it surprising that, over and over again, we seem to keep coming back to the assumption that the next big technology will be the only platform you will ever need and replace everything else. To answer that question let’s examine the most recent event with Docker and its Kubernetes alternative, Docker Swarm.
Remember Docker Swarm?
Until very recently Docker and Docker Swarm have been the darlings of the cloud-native world. Docker gained huge adoption in record time, and at the time it seemed that they would rule the world - and that essentially, VMware, Redhat, etc would wilt away. Docker’s challenge, however, was that it was too successful for its size. When the company tried to take too much ownership over its technology the industry responded with Kubernetes which united all the rest of the world around the platform, and basically marginalized Docker into a small container niche. That entire move, from being at the top of the heap, to now moving to the bottom of the stack in roughly two years is a lesson that we should all learn from.
So, what is this lesson exactly? The only constant is change!
Some things never change - the Disruption Cycle returns
The speed of innovation has accelerated significantly over the past century and reached the point of singularity. The speed of adoption, however, has remained fairly constant due to the fact that the adoption cycle hasn’t changed much over the years.
The speed of innovation exceeds the speed of adoption which leads to companies building a hybrid stack comprised of the old stack, current stack, and “must-have” stack.
This inevitably leads to organizations adopting new technologies without leaving sufficient time to transition from their legacy businesses. Over time, this means lots of silos are created per technology such as programming languages (i.e. Java, Python, Ruby, Go), Cloud Infrastructures (i.e. VMware, OpenStack, AWS, Azure, Google), and Application Platforms (i.e. Docker, Kubernetes).
Our recent 2017: State of Enterprise Multi-Cloud Report provides many interesting insights that highlight this issue as can be seen in the infographics below:
How fast do organizations adopt new technologies?
This difference between “speed of innovation” and “speed of adoption” leads to what I called, in one of my previous posts from 2015, the Disruption Cycle. Back then the trigger was the Dell/EMC merger - does anyone still remember that? Unlike what most people tend to think, the disruption cycle doesn’t distinguish between legacy companies and new startups; it can, and will, hit companies of all sizes and ages.
The Disruption Lifecycle (circa 2015)
Moving everything to a single (new) platform is not a strategy!
If one of your architects tells you the best strategy is to move everything into a new and promising single platform, with the argument that the world will be cupcakes and rainbows and all your problems will go away - fire them!
This was true for Docker Swarm and CloudFoundry, and there is no reason it wouldn't also be true for Kubernetes as we are already starting to see the next wave of disruption on the horizon with Serverless etc.
Instead of trying to continually jump on the bandwagon of the next big platform, a more robust, thoughtful strategy would be to assume that the world will always change, and it will be comprised of multi-site, multi-cloud, multi-stack environments. We need to design our strategy with that assumption in mind. This is true for Kubernetes just as it was true for other platforms.
Kubernetes in the hybrid stack and multi-cloud world
Automation-first approach
Generic orchestration platforms such as Cloudify, Terraform, and others provide automation frameworks that can integrate with all these different platforms and thus supply an end-to-end service automation approach by calling the right platform at the right time without the need to move everything to the new platform as the first step.
Cloudify orchestration enables automation of multi-stack, multi-cloud, on multi-site
Interestingly enough, this approach also helps to indirectly smoothen the migration process into the new platform as it allows the organization to move each service, one at a time, making the transition more gradual and less risky. At the same time, there will always be cases where it wouldn’t make sense to move certain services - some will simply retire over time - so the effort of transitioning them doesn’t always makes sense which again leaves us with a hybrid stack situation that will remain hybrid for a long while.
Summary - Benefits of Orchestration First
In summary, the key takeaway I am trying to make is that we need to assume that change is inevitable and we have to plan our strategy with that assumption in mind. Automating first allows us to integrate the new platform with the existing environment rather than replace or migrate everything, at least as a first step.
The automation- / orchestration-first approach comes with the following benefits:
- Faster time to value - don’t migrate first; automate first, then migrate!
- Gradual and less risky transition to the new platform - one service at a time.
- Faster adoption of new technologies - The ability to integrate and add any new technology without breaking what’s already working allows significantly faster adoption of new technologies.
