It is hard to miss: DevOps and Docker/Containers are here with a vengeance. But at its heart, Containers are a challenge for many people, especially those who already work in tech because they are a different paradigm. Containers help DevOps achieve its full potential when done right. But to really understand Containers, you need to realign how you think of your services. They bring to the world a new ephemeral way of doing things, and this is good.

If you find yourself struggling to understand Docker/Containers, it might be that you need help realigning your perspective.

Imagine

Consider the legacy world of server automation as a factory for airplanes . . . but when a repair is needed, the plane is returned to the factory. This works fine if only one type plane is made, but the real world demands all shapes and functions of flying machines—not just one type of plane.

Some have two wings and a single engine. Others must hold 300 passengers, with four engines to make sure it stays in the air. To make things even more complicated, there is also a team that wants the wings made thin and spun in circles from the top and they call it a helicopter (there always has to be somebody different).

Servers, in this metaphor, also have a wide variety of sizes and shapes. To deal with this, an assortment of software has matured to automate the changes, like Puppet, Chef, Salt, and Ansible. All of this software is excellent at what it does, which is to create run books, robots and a variety of processes for each type of server, or for each type of airframe.

But these systems are fundamentally flawed. They run the factory by sending automated robots out to each individual plane parked in neat rows throughout the factory, the robot makes the repair, then returns for the next required change.

These tools struggle with the challenge of having many different shapes of planes, let alone planes at different points in their lifecycle from new to well used.

What this scenario has missed, is next door to the server factory lies the application factory, full of software developers. This factory takes the variety of airframes coming from the server factory and adds more than just cushy seats and a new coat of paint. In some cases, it replaces the wings, avionics, and engines—putting out an entirely new flying machine based on their own needs.

The Assembly Line

The application factory has also learned something very interesting. Through tool and process efficiencies in assembling and testing the flying machines, they have made a system that automatically creates and tests a new flying machine, regardless of the customer, and it does it as an assembly line.

With this system, a developer can easily make a change to their design, create a new machine, put it down the assembly line of tests and validation and then run it for a test flight. If the machine crashes at the end of the runway, that is okay because they can just make a new one.

This is the important difference which defines the purpose of Ephemeral services.

Rather than bringing back the old flying machine for an update and retrofitting it to meet the changed design, they get a new one from the assembly line and discard the old one.

This brings up a problem for the server factory because it still wants to bring the old flying machine back for updates. The server factory is wrestling with all of the constant changes introduced by the application factory, and they are frustrated at having so many different types of planes and helicopters.

In their world, they have a regular process to update the planes, and they find it extremely challenging to bring back a plane that has been delivered to the passenger airline for an engine update, only to find out the controls have changed such that the engine update no longer works.

The Future

Fundamentally, things would be much easier if there is only one factory. The automated testing system (assembly line) used by the developer factory should be brought into the server factory. It is not necessary to bring a flying machine in for updates when we can just make a new one and throw the old away.

Virtual Machines were the start of this, but then people started treating VM's the same as servers--because fundamentally that is what they let you do--your VM was still a stateful image.

Ephemeral Containers

Docker brought us easy to use Containers. A container is simply a process, which has isolated disk and networking for a specific purpose.

With these Containers, it is easy to create a special type of polymorphic airframe. With this, it no longer matters if we are making planes or helicopters, let alone the complexity of trying to maintain both a plane and a helicopter in the same factory—the factory simply focuses on the polymorphic airframe, which is disposable, so it never has to update anything.

What next?

To make this work well, we need to stop treating our containers like servers. We need to think about services, not servers or containers.

Over the next few months, I will be continuing a series of posts on getting into containers, with a focus on simplicity, security, and reliability. Containers are here, and they are ready for prime time.

Additional topics:

I also suggest taking a look at Reflex. It is a new type of service, secret and configuration management designed for Containers — bringing all three of these into one powerful tool.

If you want to learn more about successfully making changes like Containers in an organization, look into Activator.

Image courtesy of Ross Findon