If you’re only now hearing about containerization, it won’t be the last.
As more companies shift to a cloud-native or hybrid cloud environment — where containers can coexist with virtual machines (VMs) — containers promise more speed and flexibility to iterate with ease. Yes, VMs will continue to exist to accommodate existing monolithic infrastructure, but the migration to containers as the primary architecture is all but a sure bet.
“As adoption of cloud-native development methodologies mature, it’s now really a case of when — not if — containers will become the de facto standard for application delivery,” D2IQ, a San Francisco-based cloud-native application management software, predicts.
Al Cushon, the senior director of infrastructure engineering at Axon, a Seattle tech company that develops an ecosystem of cloud software and devices designed to enable safety leaders to protect life, agrees. Though the transition to containers might be time-intensive, the payoff is worth the upfront effort, he said.
“We’ve made it a priority to re-engineer our legacy services to work well in a containerized environment,” Cushon said. “While this re-engineering does take time, the benefit of simplified operations makes the effort easy to justify.”
To give other infrastructure engineers a glimpse of how they could apply containers in their environments, Cushon shared the best use cases for containers, what advantages they have over other architectures, and how his team deals with some of the shortcomings of containers.
What are the key advantages of using container clusters over virtual machines or other types of architecture?
Containers are much more efficient than VM or physical architectures. With containers, you define and create the container once, and then it’s usable everywhere. You can, essentially, stamp out services and clone them without having to take time to recreate that same systems and environments over and over. Things that used to take hours now take minutes.
This is especially critical at Axon, where we’re migrating all of our services to containers. Axon’s site reliability engineer (SRE) team maintains a fleet of thousands of VMs that are in continuous service that is very expensive to maintain. Moving to containers will reduce the expense and toil associated with maintaining Axon’s service health by eliminating much of our VM infrastructure. In the end, we’d love to create an environment where all services live in containers and all state lives in a limited number of virtual machines or Azure services.
Moving to containers will reduce the expense and toil associated with maintaining Axon’s service health.”
In your experience, what is the best use case for container technology?
The best use case of containers is anything that doesn’t require state. For Axon, that means we have dozens of opportunities to containerize our services to reduce the cost of serving our customers with the added benefit of delivering functionality faster. Axon’s dozens of services will result in hundreds of containers. In order to manage the containers, Axon uses Kubernetes to orchestrate the lifecycle of all of our containers.
What are the limitations of container architecture, and how do you work around or mitigate them?
Containers are great for stateless operations, so service designs need to be adjusted to account for this limitation. We’ve made it a priority to re-engineer our legacy services to work well in a containerized environment. While this re-engineering does take time, the benefit of simplified operations makes the effort easy to justify.
Going forward, Axon is focusing on cloud-native development. Once we get to cloud-native as the basis of our work, our SRE team can go from doing reactive tasks to proactively building monitoring tools, analytics dashboards, error budgeting, etc. to increase the productivity of engineering at Axon.
