freshidea - Fotolia

Docker on AWS: It's not you, it's me

When AWS developers weren't feeling the love for Docker, they dug deeper and discovered that the container service wasn't the root of the problem.

I was never sold on Docker. I was contrarian at work meetings and local Meetups regarding the technology, noting the additional complexity that Docker brought without seeing any immediate benefits. But during all of this, I still had a nagging suspicion I might be wrong about Docker.

At a recent Boston Amazon Web Services Meetup, I finally had an answer.

I had never disputed the power of Docker's configuration encapsulation; being able to run the same configuration on my MacBookPro as on our racked hardware -- or even the cloud -- was useful. My concern was about runtime performance.

Our product relied on a suite of 12 services operating together to provide a platform for a Web application. These services had been configured into 12 Docker containers, running on our single box hardware. The configuration established fixed utilization of CPU, disk and memory between the services. In practice, this left the services at constant risk of resource exhaustion.

Because we had a single machine deployment that didn't require scaling, we wondered if it might be best to let the services run as processes and let the OS handle resource-sharing. And this worked, until we began a cloud deployment project and wanted to run Docker on AWS.

The problem, of course, was that we didn't end up with 12 services; instead we had 12 highly coupled balls of entangled yarn. When we started to build a scalable version of the system, we saw that most of the services had intimate knowledge of each other and could not come close to running in isolation from one another. In addition to that, those "services" that could have been provided directly through PaaS were so closely tied to our actual value-adding services that they could not be easily extricated.

This wasn’t just a code entanglement issue; it was a resource utilization issue.

Very few of the verbs of our system could be satisfied by a single "service." They all seemed to need a tight orchestration among a set of the services, which was causing the resource utilization issues. The resource utilization patterns that caused us to doubt Docker on AWS were in fact the result of simple bad design on our part.

The bottom line: Container services are designed to hold services. If your container is misbehaving, maybe you've asked it to hold the wrong thing. Architect carefully so you don't do your container a disservice.

Another powerful argument for Docker on AWS is the Container Service and the associated marketplace. Our company had started to consider using a graph database such as Neo4J but lamented that it wasn’t a hosted AWS product like Relational Database Service. If we used the Neo4J container from the Container Marketplace, we could have spun up a fully configured graph database system in a single click. 

Next Steps

What's the best application for Docker?

Following Docker's sudden success

Companies see scalability advantages with Docker containers

Dig Deeper on AWS architecture and design