Why containerization is not always the answer

 March 27, 2018

UPDATE: I’ve then written another post to clarify better my point of view on the future of containers.

When I hear people (and usually those people are salespeople) saying that as soon as you put a Container Platform in your company, all your problems go away, I feel bad for the company they are trying to sell it to.

I’ve seen far too many container platforms (as well as many other technologies) fail at customers because they have been sold as this magical problem that makes all your problems go away. There are many reasons why a container platform could fail in a specific environment. The main reasons in my opinion are:

• Not enough selling of the container platform to the developments teams
• Not enough skills around containers within the company
• Applications are designed in a way that makes containers not very convenient or useful
• The applications are too bound to the infrastructure to be moved

Let’s see more specifically those reasons.

Not enough selling of the container platform to the developments teams

For some reasons, this happens often, way too often. The new shining technology is introduced in the company (in this case, a container platform) but it could be any technology, but no one uses it. Not because they don’t know that is there (usually some internal mailing list is sent, or specific meetings are scheduled), but because the people that introduced it fail to explain the most crucial part for the adoption: the why. Why should the developments teams jump aboard? Which vantages will they get? Which costs or risks will the incur if they don’t adopt the technology?

Not enough skills around containers within the company

Sadly this happens a lot, mainly in particular kind of companies, which are used to buy consultancy more than to hire people. Banks are a typical example of this behavior (obviously not all banks, but in banks this behavior is more widespread than in other sectors, I think). The outcome of this is that the know-how is not farmed within the company but bought when needed. Buying it only when needed add a massive over-cost to it both economical and bureaucratic, shifting the balance when a quick decision about an implementation needs to be done toward choosing without all needed knowledge instead of booking the external resource, wait for it to arrive, pay it and so on. Even if this applies to small choices, a lot of small choices will be the difference between a thriving platform and a failed platform.

Applications are designed in a way that makes containers not very convenient or useful

There are some software architectures which are more convenient than others on containers platforms. Microservices are usually the preferred architecture, but the kind of architecture is not the only thing that is relevant to make an application fit in containers. Back in 2011, Adam Wiggins - the co-founder of Heroku - identified 12 aspects that are needed for Software-as-a-Service (SasS) applications to be scalable and manageable in the modern world. Many lists of application requirements have been created since then with more or fewer points but at the end of the day is clear that various design choices can help or kill your containerization effort.

The applications are too bound to the infrastructure to be moved

One day at a customer site, a guy introduced himself as the person in charge of all operations on mainframes (yes, mainframes are still in the core infrastructure of many companies) and told me he has read “on the internet” that some guy managed to run a COBOL application on OpenShift and therefore wanted to move all their mainframe applications to OpenShift. Sadly that was not possible because it’s not enough that a language can compile or run on a specific platform to make any application written in that language to run on that platform. This is even truer if you are considering old or ancient applications which heavily relied on the peculiarity of the hardware they were designed for.

I think that Containers Platforms have enormous potential, but the key is to sell them for what they are and not try to sell them no matter what the people in front of you need.