Software becomes much easier to manage if we split it up into smaller chunks before using it. This approach is used by lots of larger services today where they split whatever it is they're providing into lots of small microservices.

To explain what a microservice is let’s imagine we’re using a site like Netflix, every time we perform some small action on the website like skipping forward, logging in, paying a bill, all of these functions are handled by different dedicated microservices, a concept that Netflix actually pioneered and all of them are held in virtual containers.

We see the traditional way for a site to handle tons of users at once was to run lots of separate instances of the same code in virtual machines or VMs. 

A VM is a separate session of an operating system running inside another OS and a typical physical server can run many VMs at once which helps a great deal when many people are accessing a site and also improves the overall resource utilization.

But running a full VM and the associated software that we need typically requires millions of lines of code and often a user wanting to complete just a simple task might require the server to spin up full-sized VMs which is pretty inefficient and it can end up hogging CPU cycles and other resources.

Microservices in containers by contrast only contains the code for a specific task so we could be talking about just a few thousand lines of code instead of millions. Going back to our Netflix example, we might have one container for credit card authentication, another for the review system, another for the volume slider, and so on. So, if lots of people are using certain microservices the system can just create more instances of that specific container instead of having to open up more full-fat VMs.

In fact, Google runs about two billion containers at any given time because they’re so easy to scale thanks in part to a system called Kubernetes the Greek word for Captain which Google developed to manage containers automatically and although this seems like it might only be relevant to DevOps Engineers it actually has real benefits for us the end consumer.

If there’s a problem with a service or if the developers want to add a new feature, they don’t have to search through 10 million lines of code to find the issue and then possibly break the entire thing in the process. Instead, they can just change one or two microservices that they want and leave the others untouched meaning that fixes and new features can be pushed out quickly with less risk of causing other problems.

The container paradigm also offers speed enhancements as servers can run smaller microservices much more easily without tons of VMs slowing them down. This has backend reliability implications too because it usually takes mere seconds to deal with a problematic container meaning that the potential for lengthy amounts of downtime is lower.

So, all this means that containers are being used for tons of applications. Online games like League of Legends and Fortnite rely heavily on containers to reduce lag by easing the load on their servers and Pokémon Go also used containers to fix issues shortly after the game’s launch and add new features without disrupting the millions of users who were playing the game at the time. 

Banks and eCommerce sites are also using containers with Kubernetes to handle loads of transactions at once without slowdowns and even IBM’s AI supercomputer Watson which has been heavily utilized in the healthcare industry has transitioned to using containers instead of monolithic virtual machines. 

So, it turns out that small containers have actually made life a lot easier.