The Future Is Containerized

Industry

Reading Time: 3 minutes

This article was originally published on Container Solutions by Adrian Mouat, and with their permission, we are sharing it here for Codeship readers. We have edited the opening paragraph slightly to reflect changes in the industry.

It would be fair to say that Docker has taken its fair share of criticism, with debates on both technical issues and governance. I don’t remember the last time a technology caused so much controversy and heated debate. In this article, I won’t address any specific issues, but I will try to explain why Docker — or at least some form of containerization platform — is here to stay.

Actually, having thought about it, I do remember the last time a technology was this controversial — Linux in its early days, back when the ever-eloquent Steve Ballmer was comparing the OS to communism.

A reasonable definition of a container is “a portable store for a single component and its dependencies.” In this sense they are like VMs; both containers and VMs can be used to wrap software in an isolated and complete environment. However, it is the significant differences between VMs and containers which open up new use cases that threaten to revolutionize the IT industry. Compared to VMs, containers are:

  • Much faster. Containers can be booted in under a second and add minimal overhead compared to running on bare metal.
  • Significantly smaller and easier to share. Containers are built up from layers, which can be shared between containers. When downloading a container image, only the layers not available locally need to be transferred.

Of course, VMs can do things containers can’t — most notably, no virtualization occurs in a container, so it isn’t possible to run Linux containers on a Windows machine (without putting a VM in the middle) for example. Also, VMs offer a much stronger security guarantees, which is particularly important in multi-tenant platforms. For these reasons, expect to see VMs and containers commonly used together, at least in the short to medium term.

Perhaps the greatest single promise of containers is the creation of a consistent environment from development through testing and into production.

At the moment, countless hours are lost chasing bugs that occur when software is moved between environments. The code works perfectly on one developer’s machine but breaks for the next developer, as they have a different version of a library. By moving to a containerized workflow where the same container image is used in development, testing, and production, we can significantly reduce or eliminate the overheads and pain caused when moving code between environments.

Sign up for a free Codeship Account

There are other significant advantages and use cases opened up by containers. It becomes much easier to move between cloud vendors such as Google Compute and AWS — if your code is in a container, it should run the same everywhere. Configuration worries can be vastly reduced by shipping applications in containers; there’s no need to worry about the end user’s OS if you ship the OS with the software. Microservice architectures find a natural home with Docker, where each service can be given its own container without worrying about overhead.

All of these advantages come directly from the speed and portability that containers have over VMs.

I also believe that Docker will be the main container platform for years to come. The reason is that they have built the Docker Hub, a public repository holding container images for programming languages, databases, enterprise software, and practically everything else that it makes sense to put in a container. At the time of writing, there are around 45,324 images available. Any newcomer to the container space will have an uphill struggle to build another community resource of this scale.

Having written this, I then found out that Rocket now supports Docker images. This is an important step as it allows users to try out Rocket without the pain of redeveloping all their images. It does however strengthen the dominance of the Docker image specification, which is still a strong advantage for Docker.

None of the criticism I’ve seen has come remotely close to convincing me that the advantages of containers aren’t real and achievable. Docker does have its problems — I’ve even talked about a few of them. But they can be fixed. The truth is, the advantages containers can provide are so compelling that they are here to stay.

The future is containerized.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • pricees

    All of the above are great. I also would like to load enough containers on my AWS instances to get the CPU, memory, and i/o humming at > 80% utilization. We waste an awful lot of resources with our current 1:1 app-to-instance configuration.

  • jhenning

    I clearly see the pros of using containers, but for dev I’m still with Vagrant atm. Docker plain sucks for a development workflow. Here’s why: https://gist.github.com/joerx/56e266448b4c2519dd66

    • Miku

      Not true. Docker Compose solves nearly all problems described in that gist.

      • jhenning

        I wrote the gist before I learned about docker-compose (which was still called fig back then). But right, with docker-compose it makes a lot more sense.