This is the first post in a three-part series that looks at the realities of open source projects versus open source products across the enterprise Kubernetes landscape.

Linux - the foundation of any container platform

Linux, today, remains at the core of open source software development. This is because all applications and computing need an operating system underneath. With the advent of Linux becoming so mainstream and freely available - and thus available to all developers, it’s become the center of technology adoption. Therefore, Linux is driving innovation in enterprise IT today.

Often, extraordinary innovation is iterative. Just as Linux over time has become more powerful to now be a primary innovation engine and operating system driving the datacenter and cloud, so have some of the most notable surrounding open source developed technologies, such as Mozilla Firefox, Apache HTTP Server, BIND and others, which drive the Internet backbone. Most recently, Linux containers and Kubernetes have come to the forefront of a hybrid cloud architecture.

Every Linux distribution is made up of many packages, most of which were developed as open source projects and have their own community of developers. While all distros have a number of these packages in common, with the kernel being the most prominent, each distro makes choices on what packages they are going to include, and what tools to use for everything from installation to development to management. This is why the distros, especially the commercial ones that are provided by companies such as Red Had that run mission-critical environments, all have their own look and feel for both the developers and operations people.

While we wouldn’t even be in a hybrid cloud world today without having taken advantage of this innovation from the open source development process, enterprises actually need software that is supportable, reliable, more secure, and predictable. You are betting your business on this platform.

When Red Hat Enterprise Linux made the first promises about dedicated hardware certification, long-term support lifecycles, and security errata across every platform on which a Red Hat Enterprise Linux application is deployed, it served a market need of consistency and longevity that was critically absent and wholly necessary for enterprise adoption. We took Linux from being a community phenomenon used for development to an enterprise phenomenon used for production workloads.

Thousands of hardware platforms (e.g. servers, networks, storage) and applications are certified to Red Hat Enterprise Linux, making containerized Red Hat Enterprise Linux applications a natural extension of this existing base.

Only by building upon decades of production Linux deployments running millions of existing applications can we move to the next-generation of our applications and architecture, which run the business and extend across multiple footprints of physical, virtual, public cloud, and private cloud.

Given this fundamental role, it's crucial for companies to base their platform choices on long-term supportability as well as enabling rapid innovation. Businesses need to balance the ability to move quickly while maintaining a long-term view of the fiscal, operational, security, support, and organizational commitments their platform requires.

Containers are no different - they require all of the aforementioned needs when used in production-level, commercial environments. Especially given the high potential for proliferation of multi-container applications across an even broader set of scenarios, from a wide range of hardware-based systems through multiple public cloud environments.

Linux containers and Kubernetes are forming the foundation for many of the efforts to build newer, more nimble services as cloud becomes an integral part of enterprise IT architecture, while also driving greater value from existing IT investments.

Every application container includes part of the Linux distribution and sits on the Linux kernel, which is the heart of the Linux host OS. Therefore, choosing the appropriate Linux product with the widest ecosystem and greatest commercial viability is the first and most crucial step in moving to Linux containerized applications.

Any company attempting to create and manage their own Linux operating system for their container-based applications to run on must also build a wide range of hardware and software certifications and staff strong engineering, security and support teams for their Linux version. It is a very large and expensive undertaking for the container platform provider to become a commercial Linux provider.

End customers need to evaluate this aspect of their platform choice when deciding on what Linux container and Kubernetes-based technologies to select. Organizations need to evaluate their own core competencies and the competencies of their container technology provider, and decide if being an operating system vendor is one of them. For most, the answer is no.

The Linux containers which are now the foundation for the various Kubernetes distros have exactly the same attributes and requirements as discussed above for the base Linux OS. We have chosen Red Hat Enterprise Linux as our container base, giving customers a common foundation to operate, manage and safeguard their infrastructure as well as a common development environment. This allows them to consistently develop, run and maintain container apps on premises, in the cloud, as well as across multiple clouds.

Consider this example. Let’s imagine you are using containers to build an application on a public cloud. The default is to use the public cloud provider’s Linux container OS. But after the application is built, deployed and running well, what if you want to migrate that app to another cloud or back on premises, or even to interact with microservices that may be running in another cloud. You are now taking the operating system from one cloud vendor and trying to run it on another. If your application crashes or experiences performance problems, which company will support you? The simple answer is "neither." Your only option is to build, test, and develop multiple versions of your application to each public cloud’s operating environment or use a Linux container base that is supported across all of them.

As public cloud providers start to offer commercial Kubernetes with Linux containers, will they support and be capable of supporting those containers in other public clouds? The answer is: Very doubtful.

As is the case in most enterprise environments, workloads are running on-premises on bare metal and virtual machines as well as across multiple public clouds. To satisfy that, we now even see some of the public clouds coming on-premises with Kubernetes and Linux containers.

Hardware purchases are complex and expensive - how long would it take a new entrant in the Linux distribution market to have the certifications to ensure that they run on that hardware? Will they support and certify whatever hardware the customer chooses to run out of the box?

Will they build a compatible Linux virtual machine from the same Linux base as their containers and bare metal distribution, so customers choosing their container distro can have commonality for both the developers and operators with their applications that require running as VM's? Will they build a common bare metal Linux distro that is compatible with their container Linux distro.

Again, the answer to all of these questions is, most likely, no. Or at a minimum, it would take them a very long time to satisfy these requirements even if they could.

As some of the traditional hardware vendors attempt to also get into the next-generation software infrastructure space, they will run into the same issues as we’ve discussed above with the cloud providers.

The same is true for proprietary infrastructure software providers, who may try to be new entrants into the Linux and Linux container market. They, too, will face the challenges and demands of being a commercial Linux distribution provider in a world that is rapidly moving to a Linux-based hybrid cloud infrastructure.

For all these reasons, Red Hat has intentionally over the last 15 years of Red Hat Enterprise Linux concentrated on securing the largest set of hardware and cloud certifications. Today, Red Hat Enterprise Linux runs on every major cloud, with the widest range of on-premise hardware configurations in the industry.

Organizations need containers and Kubernetes as they move applications to the next generation of computing. They also need these container-based applications to be part of their existing application infrastructure for workloads that may need to run on bare metal and virtual machines for an undetermined time to come. You can’t separate the choices you’ve made for other Linux-based applications, because containers ARE Linux.

The story doesn’t end here - check in next week for part 2, where we explore the open source product versus project debate as it relates to Kubernetes and enterprise needs.