
Why everything will end up in a container
May 9, 2018
A couple of months ago, I wrote a blog post about why containerization is not always the answer and I’ve received quite a few comments about it. This article has the goal to analyze an aspect in favor of containerization which I believe to be true but was not mentioned in the previous post: the time aspect of the phenomenon.
In the ICT sector, we are used to new technologies, or at least we should be. Speaking of architectures, I still remember when I started in the ICT sector that VMWare had just introduced ESX (not ESXi) and there were two ways of looking at it:
- people that were preaching virtualization affirming that in 5 years everything would have been virtual
- people that were scared by the insecurities and performances of virtualization that were claiming that in 5 years no one would have used virtualization since it was only a fad
Needless to say that both groups were wrong, in fact, we still have some bare-metal environments, but we have a lot of virtualized environments.
A few years later Amazon launched its Cloud (Amazon Web Services, or AWS) and the two factions started again to take sides.
Now we see a discussion around containerization with similar points of view.
My point of view around those changed in the various iterations.
In the bare-metal vs. virtual-machine one, I was on the side of “everything will end up virtualized, very soon”. When the virtual-machine vs. (public) cloud arose, I was way more skeptical affirming that some loads were ideal for public-cloud and therefore was reasonable to find in the public clouds after few years and then some loads that were just not cost effective to run in clouds.
This time I have the feeling that containers are a much more significant step than virtual-machines and clouds. Virtual-machines were a technological change, but system administrators mostly perceived it since the application does not know or care if it’s running on bare-metal or a virtual-machine. The cloud, in my opinion, has been an even less impacting change, since at the end of the day, the cloud (computing service) is just a virtual-machine system on steroids (i.e., better API) that is managed by someone else (within the company in internal clouds or a third party for public clouds) and that is billed by the hour (or minute, or second) instead of by the month.
Containers are much more impacting on applications because they often require application changes to run in a container, and more changes are required actually to exploit many container advantages. My prediction is that containers will slowly (5-10 years) take over the vast majority (>90%) of applications if no newer competing technology appears in that timeframe. Containers might have an even brighter future, due to the fact that many companies that are running mainframe/COBOL systems are having more and more problems doing so and probably many of them will consider re-writing or modernizing those systems in the next few years, and they will probably jump straight to the latest technology, and that would be containers if done today.