About a decade ago and it’s still true for many applications being deployed today, Apps were usually monolithic, they were contained in one large blob of binaries and libraries, they were usually built in a single stack such as .NET or Java. They were usually long-lived, as well some patches and new functionality usually took a long time to develop. Mostly they were deployed to a single server as well so it looks something like this:
You would then have a monolithic architecture behind that load balancer, and you would store data somewhere.
Compare that to today and how applications are created. Applications are constantly developed, you will not see patches and functionality updates to a huge blob of a specific application usually, but you would see updates and security patches and things like that for each part of the application.
This is a big change from the monolithic application structures. New versions are usually being deployed often and the entire application is built from loosely coupled components instead of tightly coupled components in a monolithic application. Usually they are deployed to a multitude of servers and the pieces of the application talk to each other. So your application might look something like this:
How do you handle all these parts?
Let’s start with a useful analogy. Let’s say you’re a shipping company and you’re really good at shipping pianos. You’re the best piano shipper in the world, and then you have a customer of yours come up and say can you ship some potatoes with those pianos as well? Then you say, “Yes of course, they’ll fit right next to the pianos”.
Then you have another customer that would like you to ship some whiskey as well with the potatoes and the pianos. So it starts to get a bit cramped and they’re starting to fight about space and functionality as well. Things start to break when you see that the whiskey is starting to spill all over the piano.
Your crew is starting to wonder how to handle all these differences between the goods, looking at the size of the goods, look at the form of the goods also looking at the requirements to keep it safe and stable during transport to make sure that nothing falls overboard or that nothing breaks, and you also want to be able to transport it using different transport methods.
So what to do?
This was solved about 50 years ago when something called the intermodal container came into play. With it you can ship everything from piano, potatoes, whiskey, cars motorcycles, you name it. Not only can you ship everything, you can ship it at the same time and they can actually be on top of each other.
You can also use different transport methods. It doesn’t have to be a large container ship. You can use the same container to continue the transportation of the goods on the road or on the railroad.
What does this have to do with software?
Well, it’s similar. Remember, your application is built out of a lot of small parts. All these small parts are called micro-services. So you have a web server, you have some sort of database server, you have a shopping cart service, and maybe some big data analytics.
You can install this in a production data center, but would it look the same if you run it in your development environment could you set it up exactly like you would in a production environment? Or what about in a lab, can you set your production environment up in a lab so you can test out few things? Could you deploy your application just like you have it in a production environment in the cloud somewhere either private or public?
Enter the Container World
Containers make your application portable it looks the same everywhere you run it, no matter where you run it or how you run it. It looks the same if it is in a lab, if it is in your dev environment, or if it is in a cloud. It looks exactly the way it should do and the way it does in your production environment.
Another benefit of containers is that you don’t need to install the application dependencies on your host. This is where the whiskey and piano analogy works, because if you have different dependencies of your different application parts, they start conflicting with each other. Consider that you have different versions of Ruby or Python or Java that you need to have installed to have your application up and running. That’s really hard if you don’t have containers.
Today, Containers are very popular, and due to them being so popular, they have built a large ecosystem around them. They are used by millions of individuals and professionals. There are hundreds of case studies on containers from companies such as eBay, Rackspace, New Relic, Spotify, Cloudflare, Yelp and more.
When you look at a container it makes your application very shareable. The entire needs of an application are defined in a text file. A container file is very simple and actually easy to read. This is an example container file where we build a container based on the binaries and libraries that you get from a “ubuntu” distribution.
After we have that base we want to install an application called a “redis-server”. Then we want to open a port which is the port “6379”, and then we have what is called an “Entrypoint”, which is the application that we want to start in this container which is the “redis-server”. These four lines equal an entire container that is actually production-ready. So containers contain everything your application needs. It contains all the binaries that you need and all the dependencies of them, all the libraries that you need and all the dependencies of them in addition to the file system.
Containers use the host for certain things like networking, and of course it needs a Kernel to actually run applications. There is no real need to run an entire Operating System (OS), like you would have in a Virtual Machine (VM) to just run an application.
With containers you start your applications in a fraction of a second. You have no Bios or OS boot-up to worry about. With containers you can run pretty much any application that’s out there. If it is not already out there you can build your own.
Summary
Containers are pretty awesome. You can use them for your next application that you’re developing; you can use thousands of already existing apps. You will find exactly what you’re looking for already. They will always look the same no matter where you deploy them. They are always portable so you can always use the same image, the same container on your laptop, in your lab and in production, and they leave your host OS clean. You don’t need to worry about all the dependencies like Java, Ruby and Python between your application parts.
