Kubernetes has been heralded as the great interoperability point of the cloud era. Finally, development teams can write an application once hosted in a container and run it anywhere, on any cloud, public or private. And this is somewhat true. The industry has been through a lot of frameworks in the past few years, including RedHat’s OpenShift, open-source Kubernetes, Pivotal Cloud Foundry (PCF) running with containers, VMware Enterprise PKS, Rancher, Amazon Elastic Container Service (Amazon ECS) plus Amazon Elastic Container Service for Kubernetes (Amazon EKS), IBM’s Cloud Container Service, Mesosphere’s DC/OS and now Azure Kubernetes Service (AKS). The common packaging in all offerings is containers with an orchestrator.
Kubernetes does deliver portability. Many ONUG Members have real-life examples of migrating dozens of applications from PKS to Rancher, for example. The migration effort takes only a day or two. Migrating from PKS to EKS is even faster. Most have zero fears of moving from AWS to Azure or Google Cloud Services (GCS) at the application/service tier. Portability is a major Kubernetes deliverable, one that OpenStack failed to deliver. Kubernetes is a more mature technology than OpenStack and enjoys being adopted by all public cloud providers. It will play a major role in any hybrid cloud strategy approach if it can solve its tools, complexity, networking and security deficits. In short, Kubernetes has to deliver much more value to emerge as an Enterprise Cloud software building block.
At ONUG, we knew that OpenStack would not succeed its ambitious goals for two reasons: lack of interoperability and application suitability. Kubernetes has these same concerns plus lack of robust security and networking feature sets as well as high complexity and skill requirements thwarting Kubernetes adoption in the large enterprise community.
1) Lack of Interoperability: There are multiple distributions of Kubernetes, all with unique attributions. These software distributions are different and not interoperable, thus IT departments have to choose which distribution they would deploy and be locked into, thus mitigating the advantages of an open/interoperable block of code that provides options and choices.
2) Lack of Application Suitability: As IT architects and developers in the large enterprise dove into Kubernetes, they quickly realized that there are but a limited number of applications that would benefit. In fact, less than 10% of large enterprise applications run in the cloud. Many now realize that more tools are needed to make Kubernetes offerings enterprise ready, particularly tools that abstract developers from its complexity. As such, training and certifications are required for developers and operational staff, adding to its cost and complexity.
The major pain point for Kubernetes is its setup. Both the orchestrator of Kubernetes and the individual worker nodes, where work is processed, still have to be installed/setup, taking knowledgeable people time. When staff are new to containers, they often make mistakes in the setup. This is at the core of the Kubernetes problem. AWS is the only cloud provider that has solved this with Fargate. Fargate does the setup work for teams, but you lose portability.
Yes, some vendors’ paid Kubernetes versions have extensions to ease setup, but they are specific to the vendor and mitigate portability. Teams are forced to make a conscious choice to either skip the setup extensions to keep portability or use them for productivity. So the Kubernetes trade off is: use vendor features to gain speed or forgo to gain portability.
Going back to the limited application use. The fact is that many applications will not run on Kubernetes. Clearly, old, poorly written applications will not run on it; however, they were never intended to nor were they ever the target platform. Older applications blow up when developers try to run them on Kubernetes. However, applications developed on the 12-factor principle run great on cloud elastic infrastructure, which includes generic frameworks like Kubernetes. Running applications elastically requires certain design characteristics with today’s technology. This is where teams talk about the need to “refactor” existing applications before they migrate to the cloud, but this adds cost and time.
Lift and shift is an alternative choice to refactoring old applications and is appropriate for companies with very high internal infrastructure costs. This is, in essence, a “data center in the cloud” as the application is just doing what it did before but now on AWS, Azure, GCP, IBM Cloud, etc. With lift and shift, there are no improvements in design, reuse of PaaS services or agility. Warning, if lift and shift is not done right, security risks increase. This option yields few application benefits for the developer teams, so it should always be a last choice when forced into a corner.
3) The Shift to Microservices is Assumed: As businesses are trying to be more nimble to keep their market share, they are adopting newer architectures. However, mainframes still exist in some businesses. This is not the case for all business operations. The monolithic code structures can take years (five to six years for big companies like Netflix) to migrate to the newer architectures. Many companies have multiple business operations with huge vertically integrated monolithic code structures.
4) Assumption that Kubernetes Will Actually Work: As a functioning business brings large volumes of transactions to a microservices architecture, many are finding that the base open source components need to be ripped out and enhanced with for-profit components. The open source components will be sufficient for startup businesses, small businesses and some medium-sized businesses. However, as a company starts to grow into $10 million or greater revenues, the base components in Kubernetes may not grow sufficiently to meet business operation needs – hardly the scale of the large enterprise.
While Kubernetes does offer portability at the application/service tier level, developer teams have to forgo proprietary extensions that ease setup. But the portability monster is the database. At the database level, there is no portability. Many large companies still use Oracle for their database. But Oracle only has a managed server on AWS. This means to port to Azure or GCP or IBM Cloud, developers have to do everything all over again. There are only three database managed services that run on AWS, GCS and Azure. To really be portable, companies need to consolidate their efforts to one of these three: sql server, mysql and postgres. Teams still using Oracle on the cloud are essentially stuck on AWS.
Moving in Kubernetes’s favor is that the large enterprise market applications are being written in cloud native formats. If Kubernetes can deliver on its promise of agility, portability, choice and options for multi-cloud application deployments, then it will be a key building block for the enterprise cloud market.
Perhaps our industry needs a different model for these grand enterprise cloud projects? We’ve seen enough vendors getting together to pour large sums of money and talent into a foundation that develops an open-source block of software that fails to miss the mark. Without the large enterprises’ use cases and requirements guiding that process, we now have a few examples that show they are doomed to a four-year hype-bust cycle.
To fill this critical industry role, the ONUG Board welcomes the entire Kubernetes vendor community to engage at ONUG with a broad range of IT leaders and DevOps professionals to guide the next generation of multi-cloud software building blocks that benefit all. Become an ONUG Member and join the working groups where we’ll build enterprise cloud software building blocks together. To find out how to engage with the ONUG Community, visit onug.net and send email to firstname.lastname@example.org to request an ONUG 2020 Global Prospectus.