Dear Family: a letter about software, pt II

Since posting part I of this letter, I’ve long-since started my new job. Obviously I need to hurry up with my explanation of what I do if I stand any chance of getting where we’re going before I see everyone at Thanksgiving.

A brief recap of what we’ve discussed so far:

1. You get internet when your computer asks another computer for content (in Dad’s case, Business Insider click-bait).
2. When you visit high-traffic sites the “other computer” is probably not a specific computer, but a group of computers with the same information that could all fulfill your request. Your request goes to the one that makes the most sense at the time.
3. This increases the availability of the website. (Profit).

I also alluded that the pool of computers might not be strictly physical. In all likelihood they are virtual machines (VMs) running on physical machines.

You may have encountered someone using a VM to run software designed for Windows on a Mac (or run software for Windows 95 on XP or something). I’m describing a similar setup, but with the end goal of allowing multiple machines their own access to the CPU and memory and operating system of a single machine, so that it can service your request as though it were more than one server.

Both physical and virtual machines can be further divided into ‘containers.’ Like a VM, a container imitates a physical machine, but it’s lightweight because it does so without its own operating system (OS). Instead, containers share the OS of the machine they’re on (but we fool them into thinking they have one of their very own). If that doesn’t mean much to you, that’s okay. Just know that our uses for VMs don’t always require a full reproduction of a self-sufficient machine, and excluding the dedicated OS reduces cruft and improves portability.

So, from the perspective of a software provider, what’s the benefit of serving a website’s content from a group of virtual containers?

• Flexibility: Containers are easy to create and destroy. You can add more when you need them, kill them when you don’t, and rebuild them when they’re not working right.
• Redundancy: All manner of events can slow down or take down a server. At a large enough scale, even improbable failures happen occasionally. Redundant coverage means that if one server has problems there will be another to answer requests.
• Availability: Apps need to load and deploy quickly and consistently. A combination of flexibility and redundancy promote high availability, improving the predictability of the site for users and creators alike.