Transforming With Containers: Real-World Challenges

No, this isn't a blog post about the Transformers... well, not the Transformers you are thinking of, anyway. Instead, I will talk briefly about the use of containers in transforming (see what I did there?) your data center.

Right now, everyone seems focused on the benefits of using containers, typically Docker: better efficiency with less overhead, faster startup, greater density, improved consistency, and a DevOps-friendly workflow. These are fantastic benefits, to be sure, and organizations are well justified in determining if these benefits are applicable to their infrastructure and applications. However, it is equally important, if not more so, to understand what else needs to happen in order to realize these benefits. This is because with containers, as with the Transformers, there is more than meets the eye.

That's why I'm thankful that organizations like Shopify are sharing their experiences in leveraging containers. In particular, I want to share some snippets from the Shopify blog. I definitely recommend reading the whole thing; it's full of useful details.

Here are a few things that really caught my eye:

"Transliterating"
Shopify points out that simply re-using existing configuration management probably isn't going to work. Yes, you can run Puppet/Chef/Salt/Ansible in your containers. However, that isn't the most efficient or effective way of handling it, and doing it that way is probably going to negatively impact some of the positive benefits I outlined earlier.

Instead, you're going to need to "transliterate" (yes, this is an actual word) your recipes/manifests/states/cookbooks into whatever your chosen container solution uses (such as Dockerfiles). This is an effort that, while not necessarily difficult, can't be overlooked or ignored.

"Some archaelogy may be required"
This is another phrase taken directly from Shopify's blog, referring to the need to review your current production environment to determine what's really needed. What language runtimes are needed? What build or development tools? On what libraries -- and what versions of these libraries -- are the applications you're going to containerize dependent?

You're going to have to dig into your applications and the history of your applications (hence the use of "archeaology") to uncover dependencies and relationships between components. Again, this isn't necessarily hard or painful, but if you truly want to realize the benefits I described earlier, this must be done.

"So we built a daemon"
Sometimes, the move to a containerized architecture means that things don't work the same way they did before. What happens in a case like that? Well, assuming you have the appropriate resources, you build the solution yourself. In this case, Shopify built a daemon to help with the log indexing process so they didn't have to run 100 log relay agents across 100 containers (which, again, would have negatively affected the benefits that made them choose containers in the first place).

If you don't have the resources to build the technology yourself, things start getting more complicated. Depending on the situation -- let's consider the log indexing example from Shopify -- you could try to change the logging behavior of your application, but that, in turn, affects your log indexing/log management, which affects operational responsibilities, and so on.

"A subtle but major shift in responsibility"
In this case, Shopify is talking about how the responsibility for managing log indexing shifts to the developers. Sometimes, the technical problems are the easiest problems to solve, while the people/process issues can be more difficult.

What sort of people/process issues will containerizing your applications create? Will it shift responsibilities that once fell to your operations team back to the development team? If so, will that have an effect on other responsibilities?

"Things didn't work out exactly as one would expect"
While most applications will run unmodified in containers (and Shopify points this out in the article), there will still be areas where things don't work like you thought they would or should. In Shopify's case, this involved things like process hierarchy, signals, and hostnames.

Once again, your organization might need to be on the hook for building or writing a new solution. Do you have the resources to do that? Can applications be modified to account for these potential changes?

As you can see, there's definitely more than meets the eye to transforming your data center using containers. Again, I'll reiterate: This isn't to say that you should avoid containers. Far from it! Just make sure that if you're considering the use of containers in your data center, approach the process with an understanding that any major shift in architecture is going to have repercussions beyond those that are immediately seen and/or understood, and your organization is going to need to be prepared to address those.

For some organizations, like Shopify, the organization was (and is) prepared, and the benefits of containerization outweighed the drawbacks. As the old saying goes, "Your mileage may vary."