Which container platforms are right for your cloud-native strategy?

What are the main considerations when choosing a container platform?

This is a contributed article by Erica Langhi, EMEA Senior Solutions Architect, Red Hat.

When executed effectively, a cloud-native app development strategy can provide a significant competitive advantage for organisations. A cloud-native strategy can increase the speed of application development, make applications more flexible to the needs of an organisation, and allow apps to be scaled up to match any demand profile without significant infrastructure changes.

Containers are part of this strategy, as they enable the advanced automation that make cloud platforms appealing in the first place. It follows, then, that making full use of the potential of containers is one of the keys to a well-implemented cloud-native strategy. To do this, the container platform you choose is essential. Given all the choices that you have, how do you pick the right platform?

The OS matters

A pitfall to avoid when running containers is picking the wrong operating system. Perhaps even more than ‘traditional' environments, the OS that you pick matters a great deal. While it's possible to run containers on other OS, Linux is predominantly the OS of choice. 

There's a good reason why most containers are running on a Linux host. The containers themselves leverage some key Linux capabilities like control groups, namespaces, and SELinux in order to run the applications inside of them. On top of this, Kubernetes was built using Linux concepts and it also uses Linux tooling and APIs to manage containers. 

All of this means that for efficiently using system resources and developer time Linux is a no-brainer as the OS for a container platform. 

Beyond Kubernetes

One thing that is often overlooked in the conversation around containers is what Kubernetes does. We often over-simplify Kubernetes by describing it as an application that runs containers. However, a more accurate view of Kubernetes is as a bundle of APIs and utilities for orchestration and resource management. Nevertheless this doesn't provide everything you need for a container platform. 

A complete container platform also requires container registry, networking, storage, logging and monitoring. The platform also needs an underlying OS, and a way to integrate continuous integration/continuous delivery (CI/CD).

Depending on your organisation's needs, you can build your own orchestration tools or invest in a commercial framework. Adopting a commercial platform can save a great deal of time and resources that would otherwise be spent developing and maintaining the platform. It's also safer, as a commercial platform has already done the incredibly complex work of correct installation and configuration. 

Commercial frameworks can also guarantee features for an organisation that are usable immediately and don't require hefty configuration. One of the most useful of these ‘out of the box' features is cloud-agnosticism, which will allow a container platform to operate the same way and provide the same experience across different cloud providers.

The 4 C's of container platforms

Every organisation's needs are different. That also means that your ideal container platform may not be the same as somebody else's. For picking the best option for you, one idea is to examine what we call the "4 C's".

Code - check what kind and level of code contributions the vendor is making

Customers - ask if there are already real customers using the platform

Cloud itself - ask where the platform runs and on which cloud providers you can use it

Comprehensive - whether it provides a complete portfolio of products and solutions that fit the needs of your entire team (the developers and admins), while also providing the scalability you require

The other elements of cloud-native

One thing we risk forgetting about a cloud-native strategy is that while containers are instrumental to it, they are only one element to the model. There are three other instrumental parts to the formula. 

The first is adopting a service-based architecture, where understandable business activities that are reasonably self-contained are separated out into modules that can be easily updated, replaced, and tested. The second is through DevOps automation, which sees development and operations working with collaborative and unified processes and practices. The third is through API-based communications, which sees processes talk to one another through clean and contract-based interfaces over the network.

How you go about securing each of these elements may affect the functioning of the other elements in your cloud-native strategy. This means that rather than considering these components separately, a successful cloud-native strategy means holistically looking at containers, service-based architecture, DevOps, and API communication and how they work together. 

If a container platform functions well in and of itself, but hinders some other part of your organisation's cloud-native formula, then you should pause to reconsider your initial choice.

Looking towards the future of cloud-native

This leads towards a final thought that applies to choosing a container platform, and also at all the other parts of the cloud-native equation: is your cloud-native strategy prepared for the future?

Going cloud-native is not a one-off decision. Instead, you should think of it as embracing a process which emphasises constant iteration and change. Part of this involves making sure that your cloud-native strategy accounts for current and future developments, and prepares your team for new challenges. It also means encouraging your team to constantly challenge themselves by developing and rethinking their skills. Keeping an eye open for new tools and technologies isn't just about making sure you run the best container platform you can, but is vital for the entire cloud-native strategy.