It’s not a coincidence if the word ‘container’ likely makes you think of Tupperware. This fast and lightweight software solution is named after the hermetically-sealed environment occupied by its contents. Everything required to run a particular program or application – from the code and system tools to libraries and settings – is contained within an enclosed space. By running at the operating system level, containers represent a stripped-down alternative to a virtual machine, historically a popular option despite potentially requiring a full OS and several gigabytes of hard drive space.
A container’s imperviousness to wider environments underpins the growing popularity of an IT process whose origins can be traced back to the early 1980s. However, 2013’s launch of Docker finally propelled containers into the mainstream. Docker remains by far the best known example of this phenomenon, with scalable standalone software capable of running on Linux or Windows. Because each application is inaccessible by any other programs, it effectively operates in a void with no exposure to wider software or hardware. Containerized apps or programs always run in a predictable and stable way, irrespective of what’s going on elsewhere on their hard drive or server.
Despite being highly regarded by many people, container software isn’t suitable for every situation or process. Their drawbacks might be outweighed by their advantages, but security concerns and a potential lack of suitability have to be borne in mind. WestHost has investigated the pros and cons of isolated runtime environments, and our findings might surprise you:
Pros of Containers
The main advantage of containers (and the primary reason for their existence) provides an obvious place to start in any analysis of benefits and drawbacks. Quite simply, a container is a self-contained runtime environment, hosting everything required to enable that program or service to operate. Nothing else is included, which means the software effectively operates in a vacuum. Changes beyond the container’s walls are irrelevant – as long as an operating system can power up a device, the container should be able to run just as efficiently. There’s no risk of instability or conflict with other software, and patches or updates to the OS won’t affect the behavior of any contents.
Rapid operation and minimal footprint
Eliminating conflicts and stripping out bloatware ensures applications within a container download and run very rapidly, something welcomed by anyone familiar with the often sluggish nature of virtualization. The footprint of containers is also measured in megabytes, compared to VM’s gigabytes. Taking up less space than virtual machines results in quicker booting times, while copy-on-write mechanisms are simpler and less resource intensive than traditional methods of file backups. It’s also worth noting that containers require fewer resources than VMs, adding less load onto a server and reducing spikes in user activity.
Cloud hosting often revolves around microservice applications. Having a program capable of running across numerous platforms reduces overall costs, particularly since container software occupies very little space; you can fit hundreds of containers onto a single server. The robust nature and streamlined footprint of a typical container slashes development and testing time, as well as eliminating IT costs that might otherwise be incurred trying to resolve conflicts with other software.
Once a container’s contents have been configured, it should run for many years without being affected by environmental factors like a patched operating system or resource-hungry rival programs. There’s no need for extensive beta testing or refinements in deployed environments, and it’s safe to assume the container’s contents will dovetail with a different OS. If software works on Ubuntu, it should work on CentOS, Debian, etc.
Cons of Containers
Lack of Apple compatibility
Look down any list of container specifications, and you’ll see numerous examples of Linux compatibility. Some also work on Windows, while a few are Windows specific. What you won’t see are containers suitable for use with Apple products. Docker launched a Mac toolbox fairly recently, but only by using Microsoft’s virtualization technology Hyper-V to simulate a compatible platform. This inefficiency is unavoidable on Apple devices, even though containers are integrated into the core of OS X. However, the closest Apple users normally get is moving data between applications without sharing it with untrusted applications. For example, Sandbox limits access to sensitive resources to prevent hijacking, corruption or deletion.
Creating a container effectively detaches its application or software from the wider hardware or network. This means that any protections provided by the hardware and network are also decoupled. Furthermore, there are concerns within the industry that if hackers are able to access one container, they could quickly invade its neighbors. This is particularly pertinent since containers are usually given root access in Linux environments, which means contagion could spread into the OS. Ironically, the Hyper-V solution discussed in the previous point can prevent contamination progressing beyond that virtual machine.
Although it’s designed to be supremely efficient, by its nature container software performs a limited number of tasks. Any expansion in its duties requires additional containers to be bolted on, quickly leading to a daisy chain of separate processes. At this point, the efficiencies discussed above become less compelling. The sheer number of containers on a server may start to damage its performance and it’s easy to lose track of these volumes, in the same way a WordPress website might become bloated with plugins without its administrator noticing a drop in performance.
Not always suitable for large-scale work
Containers are great for microservice deployment, but they’re not well-suited to applications on a larger scale. Virtual machines remain far better for GUI-driven tools or applications that are still being developed and refined. It’s also worth noting container management tools are in relatively short supply, though the likes of DockerUI and Logsprout are belatedly addressing this issue.