Why Kubernetes will deliver on the hype and avoid the OpenStack pitfalls

In 2014, the hype around OpenStack suggested it was set to become the de facto standard platform for “Infrastructure as a Service.” Six years later, OpenStack is a valuable niche player, but nothing like the dominant force that was suggested it would become.

In the container age, Kubernetes is the new darling platform of the industry. Will it follow OpenStack’s pattern, with a gulf between initial hype and actual impact, or will it go on to dominate orchestration of applications for years to come?

OpenStack and Kubernetes, two technology development projects that garnered a great deal of industry attention, have many similarities. The buzz came because they took on a very ambitious task, one that companies large and smaller were grappling with: They were formed to create a standard, next-generation application development, and management platform.

Another similarity is they are both open source projects. While historically vendors often preferred to establish de facto industry standards, increasingly open source has become to craft such specifications.

The two initiatives were based on development work done by some of the world’s largest and most technically advanced businesses. So, their consortiums were lifted off the ground through the backing of powerful companies.

Yet, their paths diverged quite dramatically. OpenStack gained limited, niche market acceptance; Kubernetes is evolving into the needed next-generation platform. Why the difference?

What Need is Being Filled?

In the last fifteen years, delivery models for software applications have changed dramatically. Virtualization and then containerization came to the x86 world, having been part of the mainframe world for decades. Enterprises looking to deliver services from outside their datacenter could go beyond traditional out-sourcing and hosting to take advantage of API-driven public cloud services.

The IT industry needed tools to automate, orchestrate and alleviate the complexity of managing application delivery in this rapidly evolving environment.
First OpenStack and later Kubernetes tackled aspects of this challenge, aiming to provide a consistent platform for application delivery and management, lofty goals indeed.

Similarities Between OpenStack and Kubernetes

The OpenStack project began in 2010. Rackspace Hosting and NASA provided the technology foundation used for the specifications. Established vendors, like VMware, Hewlett-Packard, IBM, and Oracle, backed the initiative.

Google created Kubernetes from its internally developed Borg container management platform. The vendor worked with the Linux Foundation and the Cloud Native Computing Foundation to garner more support for the work.

Major Differences

Many of OpenStack’s backers viewed it as a vehicle to push back against the traction being gained by AWS and other major public cloud solutions. Public cloud was perceived as a threat to enterprise hardware and software sales, but OpenStack could be positioned as a way for enterprises to gain the advantages of flexible cloud deployment on their own private OpenStack platform, running on their own hardware.

Kubernetes concentrated on container management. This programming approach was new and modern. Kubernetes does not have any legacy system baggage, and its focus was not blurred by backers with a protectionist agenda. In fact, Kubernetes is infrastructure agnostic and designed to run on top of any type of legacy or cloud system.

OpenStack’s design goal was to provide a common set of interfaces for delivering infrastructure as a service. The platform tried to provide consistency among a series of projects that were built autonomously by OpenStack contributors. This was a significant challenge addressed over multiple releases, and as a result, customers were faced with a steep learning curve as they digested the nuances of each OpenStack component and its associated APIs.

Kubernetes concentrated on building a container management ecosystem. The backers created robust, consistent APIs. When writing code, this makes for rapid adoption and easier automation.

OpenStack is not easy to deploy or maintain. While it provides an abstraction layer, IT staff still need to be familiar with computer plumbing. Enterprises typically need to dedicate teams of technologists whose only jobs are keeping OpenStack running. Such individuals are hard to find. A shortage of professionals with the unique skills necessary to deploy and manage these solutions became a significant problem. The operational challenges sidelined many enterprise OpenStack initiatives and prevented early proof of concepts from being converted into production deployments.

Kubernetes is an orchestrator for modern microservice based applications running in containers. This solution is designed with the needs of developers as well as IT operators in mind. Crucially, Kubernetes is equally effective in customer data centers and in hosted or public cloud services. All the major public clouds offer Kubernetes based container services, and use of these dramatically simplifies its deployment and operation. These benefits mean that companies have found it easy to cost justify tests and system deployments.

OpenStack garnered niche acceptance. The technology is used by a number of large enterprises and telcos, who had the resources and long-term commitment required to succeed. The platform has matured, and with the support of backers such as RedHat providing packaging and support, is now more manageable, though it remains a significant undertaking for customers wanting to deploy in production.

Kubernetes has been marching toward mass market appeal. Many different types of businesses are embracing it. It is becoming the de facto standard for container management, and containers are becoming the foundation for next-generation applications. Its future is quite bright.

Conclusion

OpenStack was born out of a real need to offer an open source alternative to the perceived cost and vendor lock-in of major public cloud offerings and proprietary cloud software. Its broad umbrella of services and tangled roots of the contributing projects led it to be too complex to deploy and to limiting a solution for most enterprises thinking about their hybrid cloud future.

Kubernetes was born out of a need to provide automation and orchestration for containers at scale. Incubated for years at Google, it already had sufficient maturity and unity of vision ensuring rapid, successful adoption when delivered as an open source project.

Kubernetes simplifies managing complex container-based applications whether running locally, in public cloud or both. Its clarity of purpose and relevance across all deployment models gives Kubernetes attributes that OpenStack never had. The adoption of Kubernetes has become entwined with the adoption of cloud-native applications themselves, both public and private, all-but ensuring its prominence for the foreseeable future.