You Have a Box: The Impact of Containers on DevOps

To continue the discussion from my last blog post, you have a box. Increasingly, you only have to ask, “What do we want to put in it?”

It is interesting to see the growth and change in IT over time. The advent of containers is the focus of this particular blog, but there are many other topics that would be fun to cover in the same manner.

The fact is that containers have become our blank puzzle pieces. We take it, make it what we need and drop it in. They relieve us (for the most part) of the need to worry about deployment issues and allow us to focus on getting the part of the app they represent right.

But those deployment issues didn’t go away, they’re simply obfuscated. Networking, security, storage and even capacity still have to be concerns of IT, just not concerns of a given app or its developers. That creates a separated world of issues, sometimes a split world of issues—such as networking inside/outside the container environment—but these are largely things we’ve had to deal with since the advent of virtualization, just in a larger scope.

The true promise of multi-cloud comes with containers, also. Each cloud vendor wants to lock users into their container architecture, of course, but nothing stops a shop from running containers and container management on cloud instances of their own, maintaining the highest level of portability for the cost of some extra management headaches. In the end, where it is running is even less important in the container world, and that allows what it does to gain more importance.

Management of containers has a bit more overhead; after all, hardware or cloud management needs are the same, and the configuration/management of containers is layered over those needs as an additive. But that’s a worthwhile cost to bear if the result is that tomorrow the container could be thrown to a cloud instance, and the next day for whatever reason—capex versus opex, data accessibility, whatever—could be brought to a local server. Maximum flexibility makes the cost of maintaining another layer of management.

And much of that layer of management can (and usually is, in my experience) be folded into DevOps practices, precisely because a container is 100 percent software. That means the overhead is not nearly as large as it seems. And what isn’t well-covered by DevOps is simply an extension of virtualization.

So with containers, you have a box. The management of the box is handled by DevOps. The only question that really matters is, “What are you going to put in the box?” And that’s pretty cool: Less to worry about during development means more time to make whatever goes in the box rock.

And the innovation around those boxes is just getting geared up, I think. We already see things such as shops/projects with a container life expectancy of less than a minute that are inconceivable in other environments. Not that they’re all good ideas, but the more people doing things in a different manner, the more opportunities for really great discoveries to come along.

And you will be there. Filling boxes with cool new apps. Pretty sweet.

— Don Macvittie