Introduction to Containers

3 min read
Introduction to Containers

The application is King. Everything we do within IT is to support the application as this is central to driving business value. The way we develop and support these applications has evolved over time. You may have heard that containers are the future, but what is a container? 

Physical Servers 

At the early part of the millennium hardware became cheap enough that a single application was installed on a single server. This looks something like this: 

Physical Servers

From a business perspective the lead time to get a new application operational was pretty significant. Every time a new application was required, a new server needed to be ordered which came with the associated capital expenditure and lead time. Due to any number of reasons, the server you ordered was also typically over specified for the task required. Then once the server arrived there were the operational costs associated with running the server – power, cooling, support, administration etc. 

The result of this was that there was a significant amount of compute resources (and money) in an underutilised data centre.

Enter Virtual Machines 

Around the mid-00’s hypervisor technology was starting to infiltrate the data centre courtesy of a company called VMware.  

Virtual Infrastructure


What this mysterious hypervisor allowed was for the physical server to be shared amongst many servers. Each server’s operating system believed it was a physical server and owned all the resources that were presented to it. If we take our earlier diagram and add virtual machines in, it would look like this: 

At first it was test and development environments being virtualised before underutilised production servers. Before long a “virtual first” policy became the norm, where purchasing a physical server for a single application needed to be heavily justified. 

While this was a huge change in the way new applications were brought on-board, there were still some of the same problems as with physical servers. All these Virtual Machines still needed to be fed and watered – i.e. they still needed Operating System patches, Anti-Virus etc, except there were now (usually) more of them! 

Containers – the next step? 

At this point you’ve got plenty of virtual machines, that are all completely separate. Each virtual machine is running its own operating system which requires CPU, memory, disk and (probably) a license. These probably all have various pieces of software installed to support both the application that they’re hosting, and the operational needs of the business (backup agents, monitoring agents, Anti-Virus software etc). They take anywhere from 2-3 minutes to 20-30 minutes to restart. 

Can you reduce the number of operating systems that you’re currently supporting but still maintain application isolation? 

Yes, this is where containers come in. When the server is patched, the application isn’t affected or every time a developer pushes a change through the development pipeline it all goes smoothly right? Right?! 

Ok, so that last part probably happens most of the time. When it doesn’t work, everybody questions why the software worked on the developer’s laptop, in the development environment, in the test environment but failed in production.  

What if there was a way of making sure that the application could be self-contained and would run anywhere? 

There is – with containers. The application is encapsulated with the binaries and libraries that it needs to run. Making sure that it will run everywhere from the developer’s laptop to your production server or the cloud should you wish it. As they don’t contain an entire operating system they’re much smaller and start much, much faster. Making them ideal to be started when you need them and torn down when you don’t. From an administration perspective, there’s only a single Operating System to maintain and all the applications are still isolated from each other. Changing our earlier diagram to include containers makes it look something like this: 

Containerised

Conclusion 

Containers are changing the way modern applications are developed. Each application is broken down into smaller, independent pieces, making it more resilient and easier to scale. While this isn’t suitable for all applications, expect a similar wave of change to when we moved from physical to virtual servers. Containers are definitely here to stay.  

As an independent cloud consulting business, Xtravirt have been designing and delivering cloud and digital transformation solutions for many years. If you are looking to extend your capability with containers and cloud native applications, we can provide advisory, design and implementation services to create the right solution for your organisation. Contact us to find out more.

share
Table of Contents
Subscribe to the Xtravirt Newsletter

Receive updates from the Xtravirt team, including information on new technologies and the expert analysis of cloud trends and strategies you should know about, unsubscribe anytime using the link included in every email.

Former Xtravirt Consultant