Here’s why you should use containers


In just a few years containers have risen from obscurity to become the way we deliver software. But just why are companies making the move? Let’s go over the basics.

First and foremost, with containers you can run more application instances on a server than you can with virtual machines (VMs). By their very nature, VMs eat up system resources. You need a hypervisor, such as KVM, Microsoft Hyper-V or VMware vSphere, to create and run a VM. And each VM runs a full copy of an operating system and a virtual copy of all the hardware the operating system needs to run. This adds up to a lot of RAM and CPU cycles.

All a container needs is just enough of an operating system, supporting programs, libraries and system resources to run a specific program. Instead of a massive hypervisor, they use a skinny operating system daemon to initialize and run containers. Containers also share the host operating system kernel and some standard programs, so containers are “light.” They can be as small as megabytes and take just seconds to start, versus VMs that are gigabytes in size and take minutes to start up.

So, how many more containers can you run on a server than VMs? Well, one answer that pushes the limits of practicality, is Canonical found it could run 536 Ubuntu Linux containers on a laptop with 16GBs of RAM, versus just 37 KVM VMs. For practical purposes, a good rule of thumb is you can run a dozen containers per VM on your servers.

This doesn’t just save compute time and system resources, it saves you cash because, for the same amount per server, you can run far more applications.

While that’s important, it’s far from the only reason to use containers. For example, as explained on StackOverflow, containers are great for testing. Ken Cochrane, a Docker software engineer, wrote, “Docker gives you the ability to snapshot the OS into a shared image, and makes it easy to deploy on other Docker hosts. Locally, dev, qa, prod, etc.: all the same image. Sure you can do this with other tools, but not nearly as easily or fast.”

He continues: “Let’s say you have thousands of tests that need to connect to a database, and each test needs a pristine copy of the database and will make changes to the data. The classic approach to this is to reset the database after every test either with custom code or with tools like Flyway. This can be very time consuming and means that tests must be run serially. However, with Docker you could create an image of your database and run up one instance per test, and then run all the tests in parallel since you know they will all be running against the same snapshot of the database. Since the tests are running in parallel and in Docker containers they could run all on the same box at the same time and should finish much faster. Try doing that with a full VM.”

This also adds up to savings. A Forrester study found companies saved 70 percent on dev/test costs while using 80 percent fewer servers.

Another Forrester paper found 73 percent of companies deploying containers found containers gave them a more consistent deployment process. It does this by helping companies use DevOps and cloud orchestration tools to quickly and easily deploy consistent images.

These container images are only used as long as they’re needed. VMs, in stark contrast, may sit idle as “zombies.” A few years back Gartner analyst Tom Bittman proposed that “perhaps 30-50 percent of the VMs in the public cloud are zombies (private clouds have zombies and life cycle management challenges, too – just not as bad).”

That’s an enormous waste of resources and corporate IT cash.

On the other hand, according to Sysdig, “95% of containers live less than a week:” That’s because containers are spun up and down as needed.

Containers aren’t perfect for every job. Scott Lowe, a VMware engineering architect, suggests you look at the “scope” of your work. That is, if you want to run multiple instances of a single app, say MySQL, use containers. If you want the flexibility of running multiple server applications, you use a VM. It’s not quite that simple, but it’s close.

That said, in many cases containers will not only improve the quality of your code and how quickly you can deploy it, but save you a pretty penny in the bargain.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: