... And Why Do They Matter?

In the earliest days of "the web," a website was: one or more computers. For example, one computer might be running the "web server," while another ran "the database." And, so on. When your website became popular, you suddenly had a problem – and, an expense.

You had to buy more hardware. A machine. And, you had to find somewhere (in town ...) to put it. And you had to drive across town to reboot it anytime it failed. (Trust me: it wasn't pretty ...)

It didn't take long for people to embrace the legendary solution of "time-sharing." A single very-powerful (and, very-expensive) computer could share its time among many paying customers.

But: the traditional simple "log-in to it" models – which this author well remembers – were not good enough. Good enough for university students, maybe, but not for this.

Problem #0: "Isolation"

There were actually two problems, and both of them had to do with isolation. If they were to operate in a "timesharing" (i.e. "Cloud") environment, then the individual applications – which might actually consist of several closely-related applications – needed to be isolated from "the host." And, "the host" also needed to be isolated from them!

"Clients" had their business to run, and "hosting providers" did also. In order to achieve this, the "clients" could not have visibility to "the host." And, the hosting provider could not tolerate the clients seeing, and potentially meddling with, the environments of other clients. The "University time-sharing" model simply did not work.

Solution #1: "Virtual Machines"

The first solution to this problem was derived from one that IBM had originally achieved on its mainframe computers: "Virtual Machines."

A "virtual machine" is exactly that: "bare hardware." You now get to install upon it "your chosen operating system, and everything else that it requires."

The "VM" environment created exactly what you expected from physical hardware, and it imposed upon you exactly what physical hardware required. The host, tasked with simultaneously supporting all of these virtual machines, had no idea what any of them were doing. It could only watch the blinking lights . . .

Even though plenty of production web-sites continue to successfully use "VM" technology today, there are serious problems with it:

• The computers were wasting a lot of time "pretending to be real," running software that would have been necessary (such as "network file systems") if they were real, when the reality was that they are not.
• There was still only one "instance" of each virtual machine, waiting to handle whatever load descended upon it "when it became popular."
• The only tools that website administrators could use, to counter this situation, were those that were available to "real" hardware.
• Every virtual machine – no matter how many there were – had to be installed and managed individually.
• The host machine has no idea "what's going on inside," and cannot help.

Solution #2: "Containers"

Engineers quickly realized that isolation concerns could much better be handled by ... illusions.

What client applications actually needed amounted to four things:

• Visibility of a "[virtual ...] file system" (files and directories) which contained only what they put there. These resources needed to be sharable, but without expense.
• A "[virtual ...] network," that consisted only of the "remote systems" that they specified.
• A "user-id / privilege" system, which defined what resources were accessible, and what privileges they were able to use to override those accessibility limits.
• Constraints on [virtual and host ...] memory limits, and CPU consumption.

Thus: the vitally important notion of "containers."

A "container" could create the illusion of whatever environment a particular occupant needed to see, without the expense and overhead of virtual machines. As long as the application "saw" what it needed and expected to see, the illusion was just as good as reality . . . but considerably cheaper.

Result: "Freedom"

When a host system encounters "a virtual machine," it is faced with an "expensive 'black box.'" It doesn't know what the virtual machine is doing, and(!) the virtual machine doesn't know what's going on outside.

But, if the active scenario is "containers," the host system does know exactly what is going on, because every one of the so-called "guest processes" in question are running directly on the host system itself.

Each of these processes are now entirely visible to the host! The key difference is that all of them are, shall we say: "Wearing rose-colored glasses."

The host knows where (and what ...) they are. The guests don't.

Importantly: The idea of a "host system" can be vastly expanded, without disrupting anything. (As long as the applications have been properly designed.) The host system can now consist of multiple computers, and "guest processes" can now be run on any of them without disruption.

Benefit: "Real-Time Load Balancing"

It is obviously inefficient to have a [virtual ...] machine "just waiting around" for a workload that will never come. But it is also business-prohibitive(!) for a workload to come that cannot instantaneously be handled!

In the "physical world," it was necessary to deploy redundant computers, and to "load-balance" the incoming requests between them.

But, in a "container world," the hosting service can "spin up" new container instances to handle an upsurge in load. And then to "spin them down" when the load has disappeared. It doesn't matter which physical computer does it: only the hosting service will know for sure.

Because a "container" is, in fact, a set of rules that are applied to "a running process, somewhere," to fully define what it "sees," it is now possible to launch a new "container instance" in a fraction of a second. (And to "tear it down" just as quickly.) On any available machine. The running process only perceives its "container environment," and this environment remains consistent. The voodoo magic is invisible.

Benefit: "Provisioning According to Purpose and Need"

Hosting providers such as AWS = Amazon Web Services quickly began to distinguish the services that were needed, such as "computing," "databases," "non-database services," and "internet private networking," and to separate these as individual concerns. The containers (and other available options) can use these services without having to deploy virtual machines or container instances to provide them. This fact builds flexibility and scalability directly into the architecture.

Nevertheless: AWS is by no means the only option that is available.

Side Benefit: "Developers Can Run the Same Containers!"

"Containerization" is not a technology that is confined to "big computers." Developers can easily run container systems on their own machines, and thereby access the same configurations that their software will "see" in deployed environments.

They can also "provision" these development environments quickly. Setting them up exactly as they need to be, without thinking about it.

Benefit to YOU: Flexibility, Scalability, and Reliability

Flexibility: When you need to deploy a web-site and/or an accompanying mobile app, you have options from the outset. Then, you can re-deploy as your conditions change. The environment perceived (and required ...) by your software – if properly designed – will be maintained.

Scalability: As previously described, "container instances" are unaware of their host, and they can be started or stopped very quickly. Hosting services can therefore adjust resource availability in real time to handle changing workloads.

Reliability: These technologies are by now thoroughly proven.

Bottom Line: "It Just Works, Efficiently"

"What you ultimately want" is simple. You want a website, and/or accompanying mobile applications, that "just works." If you anticipate low request volumes, you don't want (or want to pay for) more than you need. But, if volumes increase, you also don't want to have to "re-tool" what you've already paid for. And, you also don't want your users to be waiting.

In Conclusion: This article has now tried to present you with "a look behind the scenes." To show you what your technical options are. And also, to show you what we have already anticipated in preparing – and maintaining – your solution for your business.