Containers: The Tracking Problem

Version 2
    Share This:

    Screen Shot 2019-02-26 at 11.53.50 AM.png


    451 Research updated their yearly study of the "Application Container Market" and expects it to reach $4.3B USD in revenues in 2022.   They attribute this explosive growth to enterprises driving initiatives which containers help them "move faster, manage infrastructure more efficiently and meet digital transformation goals."


    Last November, Antonio Vargas, asked the question, "Do Containers Belong in the CMDB?" in his blog.  So I'd like to revisit it now and ask for you to weigh in:


    Container adoption is increasing because the technology is well-suited for our multi-cloud world. Containers make your workloads more dynamic and are often noted for the portability they enable across different environments. They also make these workloads ephemeral: You can spin up a new instance quickly, use it for as long as you need, and then effectively throw it out. Wash, rinse, repeat.


    These dynamic, ephemeral workloads also pose challenges for IT teams, particularly around discovery and service management. Tracking each one of these containerized workloads could quickly become unmanageable. On the flip side, tracking nothing is a recipe for failure; the benefits of containers will get wiped out if you’re running them in the dark.


    The fast food of compute

    How do you ensure you’re maintaining full visibility in your environments in an efficient, scalable manner? What should you be populating and maintaining in your CMDB?

    Let’s consider an analogy that might help: Think of containers as the technology equivalent of fast food. You order it, the order gets filled almost immediately, you consume it, and you move on. It’s fast, it fills a need, and you simply dispose of everything when you’re done. There’s no cleanup, no dishes, no maintenance required. And it’s pretty much always available when you want it again.


    The analogy extends to IT service management. One reason why people eat fast food is that they know pretty much exactly what they’re going to get when the order arrives.

    That’s not because they’re keeping a record of every cheeseburger they’ve ever eaten, though. Rather, they remember where and how they ordered it. They remember that they like how one chain prepares and delivers its burger more than another, and they like that it’s consistent. A Big Mac is a Big Mac, regardless of when and where you order one.

    That’s how you should approach containers: Don’t try to track every single instance you spin up and down. Instead, track its configuration—how the burger was prepared, so to speak.


    Focus on the details

    Instead of the bun, condiments, and cook time, substitute the build, the service this workload is a part of, and the deployment tool used. And track all of this as it changes, too.

    Don’t think about the container itself. The intricacies and dependencies of the configuration that governs that container are what you want flowing into your CMDB, so that you can track them in their present state as well as when they change.


    The dynamic, ephemeral, and scalable nature of containers is part of their growing appeal to enterprise IT. Just remember that you want to track how the burger gets to the table—not the burger itself, or the packaging that gets tossed when it’s gone.