Containers are hot stuff right now, so it’s natural that you’re here wondering what the business case and benefits of containers could be. If this is you—if you’re looking to assess whether containers would make sense for your company—then you’re in just the right place. Because by the end of this article, you’ll not only have a good understanding of what containers are and what they’re good (and not so good) at, but you’ll also have some decision making criteria to help you decide whether they’ll work for you in your unique situation. We’ve got quite a bit of ground to cover, so let’s get to it.
Firstly, What Is a Container?Before we get into pros and cons, we need to have a basic understanding of what a container is. We need to understand how containers operate and what areas of our company could be positively affected by the implementation of containers. Docker, the current most popular container software on the market defines a container as:
A standardized unit of software.Sounds pretty vague to me. Anyone working in software will have heard phrases similar to this, such as component, module, or app. Aren’t these all standardized units of software? What makes a container unique? According to Docker:
Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging.Bingo. This is the real value of containers: isolation. Containers are pretty much isolated processes running on a host machine. I say pretty much since there are some instances when a container isn’t truly isolated. But we’ll get into that a bit later on. Why is isolation important? Because isolated software runs with the same behavior no matter where you put it. This is useful when:
- Moving the software between environments, e.g., for testing purposes.
- Moving the software to a different running location, e.g., from on-site servers to the cloud (or even between cloud providers).
- Scaling the software to run compute power concurrently (horizontal scaling), e.g., to achieve high availability or performance requirements.
Container AlternativesThose who’ve been in tech a while might balk at the previous statements about containers allowing us to create isolated software. Why? Because there are other methods for achieving this isolation and portability. Let’s take a quick look at these options.
Alternative 1: Manual ConfigurationManual configuration is essentially the antithesis to containers. Rather than having your code run in the same way on all machines, you become susceptible to the most fickle errors of them all: human ones. Manual configuration is simply using an individual, a human, to manage servers or applications. Servers that are manually configured (in what is often now considered a fairly old-school way) are maintained by an operations team or a systems administrator. Even though it may be old school, we must consider manual configuration as an option because often, especially for small companies, it can be the most pragmatic solution. As we’ll soon see, containers can help companies looking to achieve scale, and without the right conditions, adding more complexity to a new project might come with additional risk beyond which makes sense to undertake.
Alternative 2: Virtual Machines (VM)Next up, virtual machines. For a long time, the tech industry standardized on the idea of virtual machines as a way to create the aforementioned isolation and combat the inconsistencies of manual configuration. Simply put: virtual machines are small, isolated machines that run within another machine (called the host). I think it’s easiest to think of this like a computer within a computer. For a long time, I couldn’t discern the difference between VMs and containers. The penny finally dropped when I understood containers aren’t magic, nor are they just boxes, as they’re often drawn. Instead, they’re a protected process running on a machine. And because containers are processes, they can share the system resources of their host, unlike virtual machines that require an entire operating system within each virtual machine you want to run. This creates a trade-off between the near-perfect isolation of a virtual machine and the speed and lightweight benefits of a container.
Alternative 3: ServerlessLastly, the newest entrant in the getting-code-onto-a-server market, serverless. Serverless tackles the difficulties of matching application and infrastructure in a different way: by removing infrastructure from the equation completely. But how does this work? Surely there must still be a sever? In serverless, there are still servers that run our code, but this responsibility is passed to a cloud provider. Instead of putting applications into the cloud as containers or virtual machines, we send small functions of code. These are then run individually based on demand. Serverless can be great for scaling and achieving lower costs, but it also comes with added complexity.
Benefits of ContainersHopefully by now you have a good grasp of what a container is and what the alternatives are: manual configuration, VM’s and serverless. With this base of knowledge, let’s move onto looking in more detail at the specific benefits of containers.
Benefit 1: FlexibilityContainers don’t have to just work for applications such as websites. Since they are simply processes, it’s easy to scale them and use them for different purposes. Containers also work for other ad-hoc and operational tasks, such as database schema updates and performance testing. For instance, recently I launched a performance testing suite on a fleet of containers. Each container had a performance profile, and I could easily scale it up and down to mimic load for testing purposes. These containers could just as easily be run on a local machine as they could on AWS, GCP, or any other cloud provider.
Benefit 2: Cloud Agnosticism (Portability)When it comes to architecture decisions, there will always be a stakeholder who will ask…
“What if we want to move cloud providers? How hard will that be?”With containers, the answer is: not too hard. Containers themselves can run on open source software, such as Linux. They’re shipped with a run file, meaning that you’ll find their packaging instructions contained within the software, not the cloud provider. So if you do choose to move your application to a different set of servers, you can do so with relative ease. Alternatively, a solution such as serverless by its very nature is highly coupled to the cloud provider. This is worth considering if portability is a concern for you.
Benefit 3: Architectural IncentivesOften a container-based solution for an application goes hand in hand with a microservices-type architecture. In microservices, a large application is broken down into smaller parts that are typically worked on by separate teams and deployed in isolation. When separated in such a way, you can scale them horizontally, which simply means that rather than making the machine bigger, you run two of them side by side. This can then give you a fine level of granularity when performance tuning an application, allowing you to scale up and down only where needed. Microservice-type architecture brings additional advantages, as teams can work independent, drastically increasing velocity and speed of implementing change (at least in theory). On the other hand, microservice architectures are difficult to get right and require expertise and team communication. Split them in the wrong place and you have a very complex, distributed application. But with containers in place, you have the option of whether to run one giant monolithic-type architecture or break your application down into pieces. You can even put it back together again if you split up your application in the wrong way.
Benefit 4: ResourcingA pragmatic—albeit slightly dry—reason to choose containers: resourcing. Containers are hot technology in the market right now. Most technology companies struggle to find good developers to work on their products and services. So it makes sense to ensure that the technologies we run are desirable by the market and that we can find good staff to work our software.
Drawbacks of ContainersOkay, so now we’ve talked a lot of the merits of containers. But to make sure we get a complete picture, let’s take a look at all the ways containers can let us down, or worse: actually hurt our performance and ultimately, our company.
Drawback 1: Additional ComplexityContainers don’t come alone. Unfortunately, oftentimes running containers means additional overhead in setting up systems to facilitate them. We will need somewhere to store our container images and likely, we’ll want what is called a container orchestration tool. On a practical level, container orchestration:
- Chooses how many containers to run at any given time.
- Tells our containers on what hosts they need to run.
- Starts, restarts, or destroys containers.