3 Intriguing Questions About The History Of Containerization
ProScala Podcasts
Tech show targeting both business and developer audiences focusing on the benefits of Functional programming and Scala.
Containerization has been with us for a while now. Still, you may ask why wasn't it there earlier. Since when do we have this concept at all? An intriguing topic worth a discussion.
As promised in my earlier article, I started researching a software history topic, more concretely, #containerization and Docker.
The questions that I've found interesting enough to go into detail in my tweet row were as follows:
As said before, #software history helps us understand the structure of existing solutions, and by examining what Docker does, comes the question: what qualifies as a container, and what such solutions we had before Docker?
If you're into #DevOps, this may sound familiar: a container should qualify for three isolation levels, like a filesystem, process level, and resources isolation. So it is much more than the chroot command, though the inception of containerization is closely related to the latter.
The basic building blocks of containerization originate back in 1979, with the appearance of the chroot command in Unix V7
So we have one milestone date, but what are the others? You can read from my tweet row, but here are all summarized:
DevOps newbies may ask, but what is Docker?
Docker is a containerization tool that encompasses all imaginable features related to creating and managing a container.
领英推荐
We have arrived at the point in examining software history when we can add more details to our question about #Docker's success.
As we can see, we have had to wait for Docker for a long time since 34 years passed after the appearance of the chroot aiming application isolation (at least on the file system level).
We can extend our question like what caused a tipping point that a tool standardizing and enriching containerization features could appear and go viral?
According to my research, there are at least three factors behind it:
The synchronicity of 3 events or factors considering Docker helps us understand why we had to wait till its 2013 inception.
Aha moment factors considering containers: 1) VMs come with overhead 2) public cloud requirements 3) scripting the 3 isolation levels plus file system issues required unification.
As you can see, I mention fallback options for Docker and their pitfalls, shedding light on why it was the right time for such a tool to appear and become successful as it addressed various pain points.
I'll go into more detail about the fallback options of Docker in the past in the next article.
Thanks for reading; I'll be back with more articles, meanwhile follow me on Twitter to interact with tweet rows about software history: https://twitter.com/kincsescsaba