Everywhere you go these days you hear about containers, and Docker, and Kubernetes, and microservices, and so on and so on. In this article I’m going to attempt to do a little introduction to Docker, which is a company that introduced some containerized services as well as services that go along with containers. I plan on writing a few of these articles and I’ll basically be taking you on my journey to learn about containers. There are some great resources out there. I know vBrownBag has several videos available as well as PluralSight, with many courses by Nigel Poulton.
So let’s get started!
Why do we need containers?
Let’s think back to the early 2000s when we were using bare metal servers and generally only loading one application per server. This was the right thing to do back then, because you wanted to create some isolation among your applications, but it was problematic because it was so expensive. We only ended up using a bit of the server’s resources, not to mention all the power, cooling, and maintenance for which we were also paying.
Then along came virtualization. We were able to put multiple virtual servers on one physical server, utilizing all the hardware resources and reducing cost. While also probably providing better redundancy for our applications. Of course, VMs still require a separate Operating System for each VM. So, you’d have Windows VMs, Red Hat Linux VMs, etc. Each VM needing licensing and maintenance for just the operating system installed, as well as the disk space it might take up before we even install the application. This is where we talk about one of the main benefits of containers.
What’s a container?
Multiple containers can be created on one operating system. So, instead of the model where we have a physical machine, with multiple VMs that each have an OS and an application, we have a physical machine, with one operating system, and then multiple containers which hold applications. Again, this saves on resources used by the OS as well as licensing costs and administrative costs. Containers are also able to spin up more quickly because there’s no OS associated specifically with that container and there’s only one place you have to patch the OS. You no longer have to go to each VM to patch the OS.
How to install a container?
There will be an operating system on which you are working, and likely it will be Linux at this point though Windows is certainly stepping up its game here. On that operating system you will deploy what’s called a Docker Image. Granted we’re just talking about Docker here, not any of the other container engines. A Docker image will have a container as well as the application you’d like to deploy. For example, if you want to deploy MySql you would go into the Docker Hub which contains many repositories for Docker images already. You’d find the MySql image that’s appropriate for what you would like to do, download it and use that as a template to deploy a new container on your Linux OS. If the image didn’t already exist, you could actually create it and store it in the Docker Hub or on your local machine and deploy it that way as well. I should note that I’ve been referring to physical machines and local machines, but you could also deploy containers in the public cloud, such as on AWS or Azure.
What is Docker?
As I said above, Docker is one of the container companies. However, that’s not totally accurate either. Technically, The Docker Project is an open source project so anyone is able to contribute to it. However, Docker, the company, is highly influential with the Docker Project. Docker has also made a few acquisitions to offer services and support around container based solutions. It’s almost a little like the Red Hat Linux model. Red Hat obviously figured out how to make this model work for them. Though, in my opinion, it will be interesting to see how Docker will start really making money around containers, since the main thing people are using in this case is all open source.
Why should we use containers?
Containers probably won’t completely take away the need for virtual machines, or even physical machines in some cases…at least not any time soon. However, they can handle both stateless and stateful data. Meaning, they’re great for things like persistent applications much like what we use virtual and physical machines for now. What they’re even better at, though, is being spun up in a time where we just need more resources and then spun down again really easily. Again, they are very quick and efficient because we don’t have to worry about bringing up an operating system and an application every time we spin up a container. This may also mean that we’re not always storing a lot of persistent data within the container. However, I should also note that stopping a container (think of it like stopping a service) does not actual delete the date. In fact you can even destroy a container, and as long as you have it setup correctly, that date will persist. That way it doesn’t matter when we spin one up or down, the persistent data is stored somewhere.
What kind of apps?
This brings us to the discussion of what kind of apps we can run on containers. Well, we can run pretty much any app, including legacy apps that were meant for physical and virtual machines (meaning persistent data most likely). But that’s not where we see the full power of containers. They’re better suited for modern apps that were developed with containers in mind. So, there will be tiers within the app most likely, and not just database/app/web tiers, but getting even smaller. Likely an app may consist of containers that are meant to be more persistent and other containers that are meant to be stateless. This will not only make it more scalable, but also make it easier to deploy one complete application in multiple places. So you might have some containers running in the public cloud and some on premises, but they’re all used together to make one application work. All the while, this is all behind the scenes to the actual end user. You might hear the term cloud-native apps thrown around to describe these modern apps and while that’s probably a pretty accurate buzzword, it’s not all that Docker containers, or containers in general, can handle.
So containers are basically a more efficient way of delivering apps to our end users. They’re quick, they’re lightweight, and they really don’t have too bad of a learning curve. Stay tuned for more articles from me on containers. If you have any comments or questions, feel free to reach out to me @malhoit on Twitter.