Anthony Kesterton is a Principal Solution Architect at Red Hat.
The world’s leading CIOs, enterprise architects and DevOps teams know that container platforms have become a necessity for dynamic companies seeking portability across multiple environments. If they haven’t already started implementing containers, then they are certainly planning to do so. And if they have started then the usage will increase. In a recent Enterprise Open Source Survey, 67% of respondents plan to increase their use of containers over the next year.
Containers are handy units of software that carry application code across computing environments - from dev to prod; on bare metal machines or on virtual machines; on premises or in the cloud. Containers help make application delivery faster, because they make it easier for the development and operations teams to work together.
Two keys ways containers help - the ops team can provide container base images with the right content and settings (including security settings), and developers can ensure their carefully crafted and tested application code is exactly what gets deployed into production. By building effective testing and security into the container pipeline, containers are reliable, scalable and trusted.
From an IT infrastructure perspective, one of the more impressive aspects of container technology is the improvement in machine utilisation you can achieve. As a rule of thumb, if one physical machine can support the deployment of 10 virtual machines (VMs), a containerised workload could support 100 containers on the same platform. Practically, this improvement in machine utilisation can fund a business containerisation effort simply on hardware savings alone.
The popularity of containers means there are a number of ways to deploy and manage containers. Vendors such as Amazon, Google, Azure, Docker, and Red Hat all provide containers platforms. Many of these vendors use the Kubernetes container management software, originally developed by Google, open sourced with help from Red Hat and others, and donated to the Cloud Native Computing Foundation.
Not everyone uses Kubernetes - for example, Docker (Swarm) and Pivotal (Cloud Foundry) originally developed their own container management systems, but even these vendors have now adopted the Kubernetes project as their core container management platform.
With all these vendors providing Kubernetes-based container platforms, and with various degrees of engineering maturity and operational experience, what do you need to consider when developing your evaluation criteria for the right container platform for your business?
Ticking off essential features
Container platforms can cause large amounts of disruption to the typical IT departments’ “business-as-usual”. Not all infrastructure, operations, security or development staff will have relevant experience with container technology and the task of migrating existing or legacy applications is not insignificant. Some businesses work around any lack of skills in their teams by using container platforms run and managed in the cloud. This is a viable option, but the use of cloud-based container platforms still require the following from their staff:
- Infrastructure teams which understand the underlying container platform and its nuances,
- Operations staff able to understand how to monitor and operate the container platform,
- Architects and developers who can create or refactor applications that have the right architecture,
- Security staff who can recognise and help mitigate vulnerabilities in an environment that changes some of the fundamental principles they know and understand on bare metal and virtual machines.
IT leaders are still accountable to the business for the performance, stability, security and reliability of the applications that run the business.
Firstly, it is important to understand that while Kubernetes is in widespread use as the core of a container platform, Kubernetes is not the only component needed to create a container platform. Each vendor, or you, has to make component choices and decisions for the rest of the container platform. The container platform as a whole needs to be examined to avoid vendor lock-in. Plan your escape route from the vendor before you make the decision.
Considering the rate of today’s rapidly evolving technology, it is also necessary to ensure that your platform does not stagnate and become a source of technical debt. While your developer might be clamouring for new capabilities in the container platform, operations prefer stability and longevity of the container platform.
You can satisfy the developers and the operations team by choosing a container platform that offers the ability to automatically update the entire stack: operating system, container runtime, and the container platform. Look for a container platform that allows you to update at your pace - offering long-term support if you do need to stay on a particular release for a little longer than planned.
With so many horror stories in the press around poor default security options, look for a container platform that has the appropriate security settings as defaults. As an example, running containers as root on a poorly secured container platform grants root access to the underlying infrastructure, and the other applications running on the platform.
Look at how the container platform can offer role-based access control (RBAC), with an appropriate selection of options that give users the freedom to do their job, so the platform does not get in the away. Don’t underestimate the power of the existing security features in the operating system and infrastructure. Make sure the integration of these underlying security features are properly integrated into the container platform.
Balancing developmental and operational needs
The saying goes that a business needs order to survive and disorder to evolve - and in the world of DevOps, this cannot be emphasised enough.
Business cloud apps and operations need to be smooth, efficient and orderly. A platform container should be heavily secure for operational functions to be carried out at optimum performance levels. On the other hand, for a business to continually push the boundaries of excellence and innovation, software settings must not be so limited or restrictive that developers cannot experiment with latest ideas and integrations.
With this need for balance in mind, IT leaders will be looking for scope for innovation. While many options are offered as out-of-the-box, some vendors intentionally do not ship products as production-ready, and place the burden of responsibility on you.
The open source community: many hands make quality work
One of the most significant choices is whether to go for a fully open source or significantly closed source container platform. Even if a vendor claims to be using the upstream Kubernetes component, if you don’t have access to the source, it is harder to validate and resolve issues when they arise. A pseudo open source platform is one of the more insidious forms of vendor lock-in. Fortunately, today, IT professionals are becoming increasingly aware of the open source revolution and its benefits.
Open source projects (of which Kubernetes is a significant open source project) are a source of innovation as well as reliability and security. A good community that builds up around an open source project means that the level of security, the level of testing, the rate of enhancement and defect fixes goes beyond that of a closed source product. The active involvement of individuals, end-user, organisations, and vendors, ensures that problems are found more quickly, and resolved more quickly - giving you a better quality application.
Container platforms based on Kubernetes already have some of these open source advantages. Start by looking at the rest of the platform and see how much of it is open source.
Your next step is to consider the experience of the vendor. If your vendor works with a large range of clients, from small-medium sized businesses through to major corporates and public services, if they have experience in different regulatory environments or other constraints, they are much more likely to understand and solve the problems you might face when deploying a container platform. They will have the experience to configure your container platform to meet your needs, and offer you the guidance and training required to run it efficiently.
Security and ensuring it works throughout your stack
There is no use in having a stable, productive platform for your containers if you cannot be confident that all capabilities are secure. A platform should provide automated deployment of container images, proper lifecycle management of applications running as a set of images, and secure network segregation.
These are just a few examples of the features that enable the smooth running of your container platform. However, in addition to a stable platform foundation, effective security comes from an integrated, secure full stack.
Choosing a platform that will be secure throughout your stack is essential, but taking simple precautions across the enterprise IT ecosystem should not be overlooked. This means layers. Every layer must be secure, starting with the underlying hardware and the operating system.
Operating systems optimised to run your container platform, with immutable file systems and the bare minimum of features offer a much smaller attack surface. First, look at the built-in security features of the operating system. Secondly, check the security of your container runtime - check it’s simple and secure, and with default settings and behaviours that start with a high level of security, with the option to tweak settings as your teams gain experience.
At the container platform level, look for user interfaces that guide the user to the right path, and make it hard to do the wrong thing. Look for comprehensive and secure APIs that allow you to plug into your existing and future automation tooling. Finally, consider the security of the containers themselves.
Check the platform can track when container images get updated via a secure pipeline, and that updates to those images can be deployed automatically in a controlled fashion. This will help ensure the right application builds are always running on your container platform.
Add to basket
Choosing a container platform is like looking for furniture in IKEA. Each of the many options and alternatives provide slightly different form and function, and one might be more suitable for a business than another.
What is important for every enterprise, however, is that a platform is integrated, secure, updated regularly, and has room for configuration, appropriate to the business, without compromising operational functionality or security. Looking at the characteristics we have described here will help you make the right choice.
Anthony Kesterton is a Principal Solution Architect at Red Hat.
