Containerizing applications, tasks, and even tools is quickly becoming more useful and accessible as Container technologies mature. In this post, I’ll explain how your organization can go from experimenting with containers to full-blown production usage.
1. Map Out The Goals
The first step to introducing containers at your organization is to understand the use-cases and cost-benefits of containers. Get a complete understanding of why containers exist and what problems they solve. Then, identify any potential benefits that directly impact your team.
For example, containers help package up complex dependencies especially when there are both operating system (linked libraries, compiled tools) and application dependencies (standard libraries, modules). Does your team struggle with setting up environments to run your applications? This is an example of a good use case for containers.
Write out the solutions that containers can bring and map them to current problems that your team encounters every day. This is how you can demonstrate the benefits. Moving to containers can be a big change and keeping a clear idea for the value will be important to persuade others to see the benefit to changing.
After mapping out the goals, problems, and benefits, you know have a good understanding of the problem-space. Now would be a good time to take a look at any alternatives to containers that fix your same problems. This helps drive the argument for containers and focus the eventual solution.
2. Use Docker For Your Container Technology
Despite appearances, Container technology is not new or unique to Docker. However, it is one of the more mature and ubiquitous container technologies today. For that reason, it is a valuable and recommended option. Unless you are running on an established infrastructure that already has strong integration with a container runtime (Solaris, for example), it’s best to stick with the popular kids.
Go with something like rkt (a very fine container tech) and you may find yourself struggling to find documentation and engineers to help guide your way.
3. Lay The Foundation
The first things you should tackle when adopting containers is the Operations. Logging, Monitoring, Security, Building, Deploying, Release Management, Versioning, etc. are things best set up in the beginning of adoption. These are things that will be difficult to change later.
Focus this period on reproducible builds, sane versioning, setting up a registry, setting up logging, setting up health checking, and implementing a secret credential solution. Document everything along the way — including the How and Why of decisions made.
Take care of these things up front will pay dividends well into the future.
4. Find A Greenfield Project And Show Value
Now, it is time to start extracting value from your hard work. Ideally, there is a greenfield project (one that does not depend on any prior project work) that fit the vision you laid out earlier. Something that has the same pain points or problems that you determined containers could fix. Use this project to show how containers can be used to the rest of the team’s benefit and work out any kinks in the workflow. Remember to use Systems Thinking!
5. Use DevOps Principles
The last and most important step is to continuously improve your container-based system. Make sure you collect metrics on how the system is running. For example, build and deployment times, failure-rate, and of course, cost. It doesn’t have to be hard numbers either! Collect stories from your Developers and Operators. What could be improved upon?
Remember that DevOps is always about improvements!
Making best use of Container technology requires a good relationship between Development and Operations teams. Any solution that is going to have lasting impact, must have the usability and flexibility that Developers want and the stability and observability that Operations wants. With a strong, healthy DevOps organization, enacting good change is attainable.
Follow the rules I’ve laid out and you’ll be able to make the most of Containers at your organization.