Amongst the top predictions for 2020’s tech scene, experts are forecasting huge growth in the implementation of containerisation. To quote DZone’s 2020 Predictions article: “In the future, every data technology will run on cloud containers and, in 2020, Kubernetes will continue to see rising adoption as more major vendors base their flagship platforms on it.”
With cloud containers tipped to be a pretty big deal as we move into a new decade of technological advancements, it makes sense to get the basics drilled down. Let’s begin.
A cloud container is a unit of software which packages up an application’s code and its dependencies, providing an isolated environment on which the app can run.
Containers sit on top of the server, its operating system and the ‘container engine’ – software which allows the containers to communicate with the host’s OS and use its resources. Each container you spin up shares the resources of the host OS, which often includes libraries and binaries. This virtualisation at the OS level avoids the need to replicate the underlying computer or OS code every time you want to spin up a new container, like a virtual machine (VM) would. Therefore, your server can run multiple workloads with a single OS installed, making them lightweight and able to deploy in seconds.
With Kubernetes, each container is also surrounded by a pod which contains its description, ports and internal IP address – the labelling system which allows the container to be identifiable, much like a postal envelope.
The birth of containers can be dated all the way back to 1979. But when Docker launched in 2013, providing the first complete ecosystem for container management, containers really started to gain popularity. By 2016, the tech world was seeing significant adoption of container-based applications and in the years to follow, hundreds of tools were developed to make container management easier and more accessible – a container engine was included on some versions of Windows.
From this rapid development of cloud container tools, some names have come to define certain functions like Ceph, GlusterFS and REX-Ray for container storage and Jenkins in DevOps’ CI/CD processes. In particular, Docker and Kubernetes have emerged as clear front-runners with many using Docker’s container platform and Kubernetes container orchestration in tandem.
Containers are particularly useful for business and development for several reasons, which brings us onto the main advantages of containers:
Containers offer a package of software that can be shipped and coincide well with the way DevOps automate and innovate the virtual process. The use of containers supports the three pillars of DevOps practice: flow, feedback and continual learning and can teach teams the fundamentals of DevOps. For more on this topic, check out our previous blog on containerisation in DevOps.
There are several myths surrounding container security, but the bottom line is that containers are very secure if done correctly. This is an entire post on its own but, to cover a few factors; containers provide enhanced isolation for applications and faster, safer mechanisms for security patching. They also support policies to lock down applications and mitigate attacks, and container platforms like Kubernetes often have security modules built in with the option to add more, like Linux Security modules and kernel security features, easily.
Containers are lightweight and built for speed. Given that the container image doesn’t have the overhead of its own OS, ita small memory and CPU footprint – which allow applications to be started almost instantly and uses less server resources.
One of the principles of Kubernetes is to allow cloud containers to be shifted between platforms, allowing the DevOps build process to be used to build out the environment with minimal modification from platform to platform. Thanks to this, containers can operate almost anywhere you wish to run your software – on Linux, Windows, VMs, a developer’s machine, an on-premise data centre or a public cloud.
Containers allow apps to be split into modules rather than running an entire application inside a single container. This is known as the microservices approach and helps developers reduce the impact of changes to the application, allowing services to grow on demand without the overhead associated with the operating system.
Developers can create predictable environments isolated from other applications, guaranteed to be consistent regardless of where the application is deployed. This translates to productivity as IT operations teams and developers can spend more time shipping new functionality for users, and less time diagnosing differences in environments.
In the years to come, the question for many businesses who operate in the cloud will be whether to work with containers or virtual machines. And while containers are undoubtedly more lightweight, responsive and faster to create than VMs, you’re likely to implement a mixture of both in your solution rather than just one. Here’s why:
VMs each have their own internal IP address, differentiating one VM from another, and thanks to their pod layer the same is true of containers. Using containers within a virtual server allows you to further isolate your applications and thus provide an extra layer of security for your apps. Orchestration tools like Kubernetes also let you control which container clusters can speak to one another via namespaces if you’re planning on having multiple teams or projects in your environment.
We’ve already mentioned that cloud containers allow for greater scalability due to how fast they can be deployed. But there is a caveat: there is a limit to the number of containers that can be built on a server (physical or virtual). (The exact number is dependent on the configuration of the underlying hardware, but your cloud services provider can assist with this.) So, if you chose to use a physical server and put your containers directly on top of that you may be limited to less containers than you need. But deploy your containers within VMs and all of a sudden you have a near infinitely scalable solution – depending on the underlying hardware.
VMs are necessary for managing many different operating systems on your server and unlike containers, apps housed on VMs have access to the entire OS resource which is vital in some cases. But while this virtualisation is great for keeping your apps separate even down to the OS layer, it does make VMs heavy and therefore slow to deploy when compared with containers. Therefore if you have many apps using the same OS, it would make sense to consider containerisation to save yourself the hardware space and maximise on speedy deployment.
The conclusion? Well, most of us will use containers which reside on VMs. The containerisation process requires us to re-think how an application functions due to the way it interacts with the OS and most importantly how developers interact with the underlying hardware. VM’s will always have a place because there will always be applications and services used which haven’t been redeveloped to use containers. Containers and VMs will enhance one another’s most useful features, working in tandem to create a solution that is truly scalable, secure and resource efficient.
Explore UKFast’s Dedicated Container Platform.