Containers were designed to focus on one single application inside each and every container one single application at a time, and a very important benefit of a container technology, energy such as Docker is standardization, just like shipping containers right on the like the ones on this picture right here. Find out more by watching our video demo below:
[Video Transcript]
And the reason behind this statement is the fact that containers were not designed as a replacement technology for virtual machines.
In fact, Containers were designed to focus on one single application inside each and every container one single application at a time, and a very important benefit of a container technology, energy such as Docker is standardization, just like shipping containers right on the like the ones on this picture right here.
Document a nurse are just a standard box quote on quote box, right that behaves in the same predictable fashion predictable manner all the way from the developers laptop to the customers private cloud or to public Cloud, which of course means that the container is it supposed to be portable very easy to distribute. Right. And by packing just Bare minimum amount of configuration files dependencies libraries, whatever you need to run a specific application.
They can be lightning fast to spin up to destroy to restart to move from one host to another to update all the daily operations. Right, all the Ops in the Devops.
Those operations that used to take minutes or tens of minutes went with, you know, booting up or restarting virtual machines or migrating virtual machines can take as little as as sometimes even under a second when running an entertainers and speaking of the fact that they are easy to distribute.
In fact, a lot of open source applications nowadays and you might have noticed this as especially the past few years. A lot of the open source applications nowadays are shipped over the internet and distributed over the Internet directly as containers.
Actually I've encountered on several occasions a lot of software. Software pieces software, you know, not only libraries but actually software tools out there that when you go to the installation page and their official documentation, the first thing they show you is how to run it in a container and then if you really want to if you don't have a containerized environment then okay.
This is where the source code lives and GitHub. This is how you pull it on your machine. This is how you run. It may be from Pilot and so one but for the most part a lot of the new tools that emerge nowadays are designed to run.
Final containers from the beginning, and long gone are the days when you run into dependency or library version issues when running multiple apps with different requirements of the same VM.
Each container is now a completely separate and minimal environment no more dependency hell right, where specific applications require specific library versions that at some point are going to clash with the one another with other applications and their requirements on the same VM, right?
Also being so fast and lightweight containers are designed to be ephemeral. Disposable.
You should design your containers so that you can destroy and rebuild them at any time on the same host or and another host or from your local environment to the public cloud and being so lightweight makes them play very nice with orchestration tools like Kubernetes, but that's that's a topic for a different webinar.
If you want to learn more about Docker, register now for one of our courses!
share this on:
