This is a follow up to earlier post on container market.
“Companies need to integrate across the interfaces in the value chain that drive the performance of what is not good enough”
Clayton Christensen’s Value Chain Evolution theory suggests that companies ought to control any activity or activities within value chain that deliver value to customers. Tight integration gives companies ability to push the boundaries of whats possible and meet customer performance requirements. Container orchestration falls into this category. For a cloud provider to become a full platform, they must reduce interdependence and increase the control over these activities. while containers have been around for a while, deploying them at large scale for production workloads is still an emerging technology. Relying on a third party or an opensource, foundation led alternative increases interdependence and would affect cloud provider’s ability to deliver performance their customers need. A modular, non integrated strategy would produce an under performing product/service.
Keep in mind that customers come to Cloud vendors to run their workloads, they rarely come in search of a container orchestration engine solely. Think about what is the Job to be Done for customers. Container orchestration is a component in a larger value chain. It is well documented that a modular architectures that permit choices ( for ex: replace Docker with Rocket ) tend to sacrifice raw performance. They do allow many participants to improve their speed to market, convenience and responsiveness by creating a large community around it. However, this may not benefit customers at this time, when they are working to move their workloads to Cloud and expect product to perform well.
when we talk about value chain evolution, Christensen reminds us to think about conservation of Integration.Conservation of Integration states that whatever is being optimized must be surrounded by modular stuff. How does this map to the container market — my prediction is that this is how it will play out in next few years.
So, containers will become modular, multi-cloud deploy options will be modular, however, container orchestration will remain an integrated offering.
So, would Microsoft join Kubernetes and adopt it as their primary orchestration engine?. Its unlikely to happen. Microsoft may work on Kubernetes but it will be to learn from it and be good citizens in opensource. However, Microsoft will end up building/acquiring their own orchestration engine that can be optimized for their customer use cases to meet expected performance. Microsoft does have early versions of its own.
Lets say that Microsoft does indeed decide to adopt Kubernetes, what would happen? Customers will provide feedback that Microsoft should optimize Kubernetes to make it easier to use it with Azure. Microsoft product managers, being excellent at listening to “current” customers, will start adding these custom features to their own Kubernetes distribution. In couple of releases, Microsoft would end up with their own orchestration engine.
What would Google do? Google will keep pushing Kubernetes with limited short term success and will wait it out till such time that orchestration starts overshooting customer performance requirements and hope to offer a more flexible, modular product. Thankfully for Google, there are other strategies that are working better ( BigData, Machine Learning with TensorFlow etc ).
Lets say customers start telling Google to make Kubernetes easier to use with Google Cloud Platform. Google guys would tell customers that they should become smarter and learn skills that Google SRE team has. They would say “it works for Google, so it ought to work for you”.