Docker and microservices-based architectures have expanded our horizons with respect to how the industry builds and supports applications at scale, says Corey Quinn, Director of DevOps at FutureAdvisor and an early developer behind SaltStack. Nonetheless, Quinn, in his LinuxCon and ContainerCon North America talk — called “Heresy in the Church of Docker” — will preach caution and present an alternative view of the containerization craze.
In this interview, Quinn shares his perspective on the downside of containers, the possibilities for failure, and why containers cannot fix architecture woes without careful consideration and management.
Corey Quinn: Docker is a fantastic technology, but it’s not one that’s well understood. If we take a look at the lessons of the past, there was more hype than understanding around cloud as well — and before that, around virtualization. I’m seeing the same patterns repeat themselves here, and in some circles this is a far from popular viewpoint.
Linux.com: What is the unspoken truth about containers?
Quinn: The container model works well from a greenfield perspective once you control for a few factors. It’s decidedly less than ideal for a number of existing applications that weren’t written with containerization in mind. Rearchitecting your legacy application to conform with the ideals of a microservices-based architecture is all well and good — but is that (non-trivial) effort worth it? I don’t pretend to have the answer — it’s going to depend upon what your priorities look like. That said, I don’t think it’s a slam dunk either way.
Linux.com: It’s a surprising stance from the Director of DevOps at a cloud-native company. What experience have you had that informs your caution?
Quinn: You’ve said it yourself — we’re a cloud native company, we’re not container native. Our applications were written from a perspective of stateful instances, uniquely identified at times. A number of container-centric concerns (service discovery, configuration management, scheduling) don’t enter into the architecture in quite the same way.
Linux.com: How does configuration management fit into the story?
Quinn: “Carefully!” You don’t want to run a configuration management agent inside of a container, or you’ll find that your “stateless container” just became a very strangely built virtual machine. That said, you need to have some form of configuration management on the hosts that underlie your infrastructure in some form — whether that looks like traditional CM, whether you leverage something like Mesosphere or Kubernetes, or something else entirely is going to be site dependent.
Linux.com: What’s the one thing about containers that you’d like DevOps pros to take away from your talk?
Quinn: The same thing I’d like DevOps pros to take to every architectural decision: “Look before you leap.” There are a lot of shops out there where containers are fantastic — they’re the right decision! The problem is blindly assuming that containers are the fix to your architectural problems without considering what the migration, failure cases, or longer term view look like. Once you’ve given those things reasonable consideration and have a plan, make your decision and act accordingly.
Look forward to three days and 175+ sessions of content covering the latest in containers, Linux, cloud, security, performance, virtualization, DevOps, networking, datacenter management and much more at LinuxCon + ContainerCon North America, Aug. 22-24 in Toronto. You don’t want to miss this year’s event, which marks the 25th anniversary of Linux! Register now before tickets sell out.
