Over the next few episodes I want to introduce a number of technologies from modern Software Delivery. These are: There are "hot" technologies within Software Development at the moment. They are helping Software Teams: These are technologies that your Development Team may want to use or may even be using. In the last episode I explained Virtualisation; a technology that makes the other possible. In this episode I will introduce Containers and the Docker Container format - possibly one of the most useful advancements in recent years in providing repeatable and reliable software distribution.
Or listen at:
Published: Wed, 20 May 2020 15:13:06 GMT
Transcript
To recap from the last episode;
I introduced Virtualisation.
A technology that has allowed us to gain greater utilisation of physical resources by splitting them down into virtual representations.
A technology that allows us to get more from the investment in physical computer servers - thus providing a better return on investment.
A technology that allows us to reduce the time to provide Computer Servers for our key projects - thus reducing the time to market.
A technology that provides the foundation for other technologies - such as Containers.
And that will be the focus of this podcast.
Containers are largely another form of virtualisation - just one that allows for much greater density.
Containers are designed to share more than the previous virtualisation methods, allowing for less overhead per each one.
Thus the ability to fit more into same physical footprint than virtual servers gives us even greater ROI from our investment in physical equipment.
However Containers as a technology has much more to promote its use than just that. And Containers have become a staple of the IT industry.
Much of the current success of Containers has come from a company called Docker.
In themselves, Containers where not particularly new. They has much the same history as virtualisation.
Docker in 2013 however helped containers enter the mainstream by providing them with standardisation.
Docker developed a container format that made them easy to create, use and distribute.
They turned this technical concept into something akin to a shipping containers.
If you've ever looked at a shipping container, you will notice that they are all of the same size with a standard fitting in each of the eight corners.
This simple design allows for those shipping containers to be handled, stacked and transported with a great deal of efficiency.
It doesn't matter what you are transporting in them - anything from pillows to supercars - they can be handled in the same manner using the same logistics equipment the world over.
This makes them exceptionally versatile. This is why so much of the worlds freight is moved using them.
And in same way, Docker makes Containers very easy to use - whatever you put inside it.
It quickly became popular with developers who found that they could use them for a variety of applications.
As a developer you would package your application up into a Docker container and then you could send that container anywhere for it to be run.
This allowed a general level of confidence that if the container ran on the developers machine, then it would perform exactly the same in the production environment.
Previously, this was always a massive risk during the release of software.
Previously, the software would have had to be installed onto the production server - much the same way as you would install Microsoft Office onto your laptop - but generally with much more customisation.
Thus is was easy for mistakes to be made during the production release.
Only a single configuration step had to be missed for the entire release to falter.
What would then follow would could be hours or days while the fault was identified and rectified.
Docker containers provided a level of standardisation that allowed the developer to "bake" much of that into the container.
Thus all you needed to do was ship it and you'd expect it to run as expected.
As an illustration of this, Docker provide a website called Docker Hub.
Think of it like the Apple App store for containerised applications.
They host over one hundred thousand containerised applications from big business like Microsoft, Oracle, SAP - and from the opensource community.
This makes it easy to "pull" down a product like Oracle database and spin it up.
Again this has made it popular within the software development community.
Not only did it allow software developers to package and distribute their applications easily and reliability - it also allowed them to run the tools they needed easily.
I've been in software development for almost 30 years - with a broader range of technical experiences and skills than most - and it would take me considerable time learning how to correctly install Oracle database directly onto my laptop.
With Docker, I can download from Docker Hub and run it with a single command.
And when I'm finished with it, I can remove it just as easily.
Containers has also helped to promote the growth of the Microservice architecture I talked about in episode 17.
Containers provide a great platform for building, distributing and running the modular structure that comes with Microservices.
While it is certainly possible to build Microservices without using containers; and its certainly possible to run monolith applications from a container; the pairing of Microservices with containers is largely becoming a industry standard.
The downside to this however is a level of complexity brought by having so many small "parts" to manage.
While it is considerably easier to think about and develop at a small scale ... Linking them together correctly brings additional overheads to the big monolith on a single server setup.
To make this practical we need a Container Orchestrator - something I shall talk about in the next episode.
So, not only does Docker Containers allow us to achieve greater ROI from our physical servers due to greater density; greater even than virtualisation.
It also improves our developer productivity;
Both in increased simplicity to access the tools they need,
And the reliability and ease of shipping their software to production.
Thank you for listening. See you next week.