What problems do Containers solve and when to use them

For most standard enterprise organisations using applications in a traditional manner, they will continue to be consumed in the current standard virtualised way, as a Service.

Containers address some very specific challenges around mass scale. To understand this in more detail it’s worth considering why they were developed in the first place.

Today the use of data-rich media has never been in greater demand, coupled with more devices, greater speeds and more demanding users. In addition, applications are getting more features, with more processes, coupled with the need for faster development.

Traditional virtualisation technologies are struggling to deliver such dynamic and elastic scale and in an optimal way. They require virtual environments with an OS and Application layer to be built and deployed, in separate packages, directly linked to underlying infrastructure, such as CPU, RAM & Storage, assigned to a host.

The need to develop and deploy quicker, be more elastic, more dynamic, more robust and resilient, more global and more portable, led to the development of containers. In essence, the old world saw the virtualisation of hardware, the result of that was Infrastructure and Platform as a Service. The new way, with containers, is operating system level and application level virtualisation, where the application and application dependencies (such as its libraries) are broken down into processes or micro-services and virtualised. They are decoupled from the underlying infrastructure and exist as an isolated container where everything that’s needed to run that micro-service is ‘contained’ within it.

This flexibility allows containers to be small and fast. One micro-service or application can be packed into a single container image. This makes containers lighter and more flexible. A container can be deployed when it is needed, rather than at boot-up like in a traditional application stack.

A container’s micro-service is generally more transparent and easier to manage and they are incredibly resilient. If a container fails it is destroyed and a new one built. It also means that if a container needs to scale due to demand, only that individual container will do so (by deploying more containers), reducing the impact on the entire environment. Traditionally this would have meant scaling up or out Virtual Machines; slower and more costly.

Containers don’t need to be composed with the rest of the traditional IaaS stack, so they can be given release times and schedules based on demand. This moves the environment from being ‘host centric’ to be container-centric which means that a container can be deployed almost anywhere at any time. This makes it highly portable, between different platforms and different providers, ensuring true scale. It also means that containers can be deployed close to users or to where the workload makes the most sense.

Containers also have a significant change on development. The challenge with a traditional application is the amount of code that needs to be developed, maintained, tested and documented. With containers, the development can be broken down into micro-services, with a reduced footprint and more focused development. It also means new containers can be created (such as a new feature or process), internally or by third parties in isolation. This reduces overall development and testing time.

Who should use containers?

Containers are already widely used by big data and rich media environments, many technology-based organisations and application developers. Only traditional DevOps teams and companies will continue down the traditional route, the vast majority of forward-thinking DevOps teams will already either be widely using containers or certainly looking to utilise them.

It is unlikely that the average enterprise application stack will be deployed in containers any time soon. They are in reality still struggling with basic virtualisation and cloud adoption and a big cultural and awareness gap exists.

What are the challenges around containers?

There are a number of clear challenges, as there always is with an updated approach and technology. The summary of challenges includes:

Awareness, education and strategic plan

To move towards a containerised world, an organisation needs to have a clear understanding of what, why, when, where and how. Containers bring opportunity and challenges and a different mind and skill set. Clearly, a supporting business case is also a good thing to have.

Selecting the right technology

There are a number of container technology products and services, covering container architecture, cluster management, storage, security and deployment. Container technology affects all users, from developers and testers, to operations and support.

Architecting and re-architecting applications

Taking a conventional application that was originally designed for physical use of virtual machines and deploying them in a container will not work effectively. Traditionally an application contains a number of co-existing processes. Now a container can be a stand-alone process that can be executed when needed. This re-design means that applications become processes which are much faster to run and as individual processes or micro-services.

Container Security & Complexity

Generally, containers will exist as micro-services and many will be layered meaning that a container effectively has the same security challenges as an OS or application. The delivery of a containerised environment must therefore consider the security of every single container. Currently, security controls are lagging behind traditional virtual machine tools, with some services using plan text for holding sensitive information by default.

Containers are smaller and highly dynamic so understanding a security breach and shut-down a container can be quite a complex task. Additionally, ensuring access controls and user privileges to containers and their complex inter-relationships can also be a significant challenge.

In Summary

Security in most enterprises will not understand containers and therefore how to monitor and manage security incidents.

Some applications are not suited to containers, especially relatively simple applications. They will likely become more complex and more challenging in a container environment and yield no meaningful benefits.