Containers in enterprise: where the pilot ends and the platform begins
Docker and containerisation have moved from hype to real deployments. I look at what it takes for a pilot to become an infrastructure platform.
Docker launched in 2013 and for about a year the story was about how convenient it was to run applications in isolated environments on a developer's local machine. Then orchestrators arrived - Kubernetes, Mesos, Docker Swarm - and the conversation changed. Containers started reaching production at larger companies.
Now, in mid-2016, I increasingly see the same situation: the pilot is done, the team is happy with the results, but the organisation does not know how to move forward. A pilot and a platform are different projects.
What distinguishes a pilot from a platform
A pilot is one application or a few, running in containers, driven by enthusiasts. It demonstrates that the technology works, and usually looks like a success.
A platform is something different. It is infrastructure on which other teams can deploy their services without thinking about the details. That means standardised build and deploy processes, centralised logging and monitoring, secrets management, network policy, update and rollback procedures.
Moving from pilot to platform requires answering questions that the pilot ignored: who is responsible, how is it monitored, what happens when something fails, how does it integrate with existing security and compliance processes.
Common transition traps
First - the technical team carries the full load. In a pilot that is fine: two or three enthusiasts do everything themselves. In a platform that does not scale. Explicit roles, processes, and documentation are required.
Second - an orchestrator is deployed but not mastered. Kubernetes is a powerful tool with a high learning curve. Companies put it into production after a superficial introduction and discover that when something fails, nobody understands what is happening.
Third - security is added after the fact. Containers are not magic isolation. Images need to be scanned for vulnerabilities, container privileges need to be controlled, network traffic between containers needs to be restricted. All of this is easier to build in from the start than to add to a running infrastructure.
Fourth - stateful services. Databases and other stateful services in containers require a separate approach to storage, backup, and recovery. This is not a solved problem out of the box.
What a successful transition requires
Organisationally: a team that owns the platform, with explicit responsibility for its operation and development. Not "the people who ran the pilot" but an official role with resources.
Technically: a minimum set of operational standards - how images are built, how logging is configured, how monitoring works, how deployments and rollbacks are performed. This is unglamorous documentation, without which the platform becomes the private knowledge of a few individuals.
Process-wise: decide which applications migrate first. It is better to start with new services or those with no legacy dependencies, rather than trying to "containerise everything at once".
Questions to assess readiness
- Do we have a team that will own the platform - not just the people who ran the pilot?
- Do we understand how to recover when the orchestrator or a cluster node fails?
- How do our security and compliance requirements map onto container infrastructure?
- Which three applications will we move to the platform first, and why those?
Containers in enterprise are not a question of "should we or not". The question is whether you have everything needed to turn a pilot into a platform, rather than a well-executed experiment that goes no further.