I don’t care too much about containers. They’re just a means to an end. What I really care about is documenting and versioning my infrastructure. Docker, especially with Compose, is practically Infrastructure as Code, and code is versionable. Which is great. But for me there’s more to it. I think Docker reduces the gray area of responsibility between software development teams and system operators.

Let me illustrate what I mean with this gray area. Over the past years I’ve had several discussions with system operators about who is responsible for what. Whenever a webserver or database was misconfigured the development team reported this to the system operator, expecting a fix or improvement. Usually the system operator on duty responded with a question: “What should I change to make it work with your application?” Being part of the development team, this confused me and often led to the discussion of who was responsible for this configuration. Why would a professional system operator ask the development team how to configure the software that they operate? The development team usually couldn’t even view, let alone modify the system configuration. The system operators were responsible to run the software from the development team and keep it running. While the development team was responsible for making the software. This made no sense to me back then, and it doesn’t make sense to me now.

I think Docker (and Compose) clarify the boundaries of the two. When you utilize Docker in your software stack, your webserver, database and their configuration automatically become part of your software, not of the operational layer that sysops work on. This is really exciting from multiple perspectives, and suddenly it becomes clear who is responsible for what: the development team becomes responsible for building and (keep) running the software, while the system operators have to make sure there is a scalable and stable hosting environment for the software to run on.

My first impression of Docker was that it would be just another way to automate the configuration of the servers for my software. But it’s more than that. Just the ability to instantly replace one application server (container) with another makes a development team more agile. Want to switch a PHP app from Nginx to Apache HTTPD or vice-versa? Just change the Dockerfile and deploy. The iteration will be super short. Before Docker we needed to swap an entire server taking at least a couple of hours to do just the deployment. Same for adding new software services to your stack, that is so easy to do these days.

Because it is so easy to build, configure, and host a software component, software systems will automatically become more complex. This sounds counterintuitive as until now non-complex software systems are easier to manage even though they are sometimes harder to design and develop. But if we split up a software system into subsystems that each specialize in solving a certain problem, things usually become easier to design and develop but not harder to manage.

While these insights are very valuable to me, the next step is to have a way to document and automate how software services behave on hosting environments. Auto-configure scaling triggers, load balancing and the likes. At Egeniq we use Rancher with Rancher Compose to manage our software services. While it serves us well, it can not define the aforementioned behavior. That’s definitely something I want find a solution for this year.