In our Cloud Native Practice, we run workshops for our clients covering topics ranging from the basics of containers or the cloud to analyzing deployment processes and migration strategies. These workshops are customized to clients’ needs and generate interesting discussions in the context of their portfolio. With varying knowledge of cloud-related topics, it’s helpful to first provide clients a baseline and review the fundamentals.
The first question we typically get is “What are the benefits of containers and how do they differ from virtual machines or native cloud instances?” then followed by “Can you give me a quick overview of containers?” We should first start with understanding what a container is.
The definition of a container from Docker.com is “a standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another.”
So what does that really mean? Let’s give it some context using analogies, and we’ll follow this up with more technical explanations in upcoming posts.
A house is like a server – You purchase a house that you can grow into. You have a family over the years and use more of the house. If you outgrow the house, you move to a bigger house. You are responsible for the electricity, heat, maintenance, and all repairs.
A multifamily house is like a Virtual Machine (VM) – there is more than one per physical building. Part of the infrastructure is shared like the foundation, roof, etc., but you are also responsible for your part of the building and everything inside including walls, pipes, wires, furniture, etc.
Apartment buildings are like containers – You share most of the infrastructure and are only responsible for what you put inside (like the furniture). Containers only comprise of what you need to make it work for you.
Renting a house is like a cloud instance – If you need a server for an hour, a week, a year, you ‘rent it’ from a cloud provider. You’re responsible for what’s inside the house like furniture and locks.
AirBnBs are like serverless – You only rent as long as you need it, which is typically a very short duration and a shorter time period than renting a house. In this scenario, you’re only given the bare essentials to be comfortable (like a bed and bathroom).
Now let’s talk about apartments, large apartments for student housing. These aren’t as simple as just a bunch of small units to live in, this is a complex living environment. There are elevators to route you to apartments, directories to find people, intercoms/mail/cable channels for internal communications, registries to sign up for events, you get the picture. The bigger the apartment building, the more complicated this becomes. Then, if you create a complex of large apartment buildings, it’s even more complicated. Those directories for discovery and communication mechanisms are container services that are required in any containerized system.
Now imagine there’s an overflow of students or visiting parents to those apartments. You don’t have permanent space for them but there is a hotel next to the apartments you can move them to temporarily. Now you’re scaling elastically. The mechanism that schedules overflow housing (scaling up and down), where to send people, and when to send them is known as ‘orchestration’ in the container world. When people talk about Kubernetes, that’s what they are talking about (usually). Scheduling, load balancing, scaling, that’s all part of orchestration.
We’ll get into some of the technical differences between containers, VM’s, serverless, etc. in the upcoming posts, but for those of you who are new to containers, I hope this added clarity.