We constantly read about "The Cloud™" these days. But, what is it, and why might such a thing matter to your business?
- Please notice that there is not a sales-pitch for cloud services at the end of this article! (Yay!)
It Is Not – "Co-Location = Real Iron"
"The Cloud" is not co-location – or, "co-lo" – which is a service that is sometimes offered by the same companies. With "co-lo," you do own the hardware, and you merely pay to house it at the secure data center. Or, the company might rent you exclusive use of one of their big, beefy, expensive machines. (And you pay for everything, even the power bill.)
It Is – "Time-Sharing"
"The Cloud," in all of its various manifestations, is ... (guess what?) ... time-sharing. In other words, you purchase a well-isolated portion of the hardware capabilities of one or more "very big, very 'beefy,' and of course very expensive" digital computers. You do not own these computers and you aren't responsible for maintaining the data-centers in which they are housed. (You just do your part to help pay for them ...)
Your contract with the service provider simply specifies a service level: the results that you are entitled to obtain. But there are, as we shall see, "several ways to do it." A general feature of all cloud strategies is that the physical resources are allocated in a way that provides both isolation and efficiency. But please notice how one of these two goals is achieved, in various ways and degrees, at the expense of the other.
A virtual machine, or VM, is a software simulation of a real computer. In this environment, which is created by a specialized form of operating system called a virtual-machine monitor or hypervisor, the environment that is being simulated is literally that of "a bare machine." Each virtual machine operates under an operating system – or "supervisor" – such as Microsoft Windows®, Unix®, or Linux® – exactly as it would do if it were a real machine.
Virtual machines are surprisingly efficient these days because modern microprocessors routinely contain hardware support that is used by the hypervisor to efficiently maintain the illusion. VMWare® is the undisputed king of this hill, although Oracle® Corporation offers VirtualBox™ (for free!), thus enabling you to create your own virtual-machine environment on any computer. The virtual machine runs on a "host machine" and employs host-machine resources, as managed by the hypervisor and/or the host's own operating system. (The two may be the same.) But it does not perceive the host system: the illusion is complete.
The primary advantage of a virtual machine is complete isolation. Software running in the virtual machine runs under the control of the virtual machine's operating system, which might be different from the host's. (So you can, for example, run Linux on a Windows box, or vice-versa.) The downside is overhead, and the obligation to separately maintain both the host environment and the virtual environment of every individual VM that you run. Perhaps this is more isolation than you actually require.
The best-known "federated environment" – almost, the only one – is [sales]force.com®, a vendor of Customer Relationship Management (CRM) software. A federated environment is an application server that runs a single system. That single system might have many different "skins" to allow it to be customized in various ways and to appear to the user to be "distinct," when in fact under the covers it is all the same.
A federated system is run simultaneously on many different (real or virtual) machines, all of which are aware of the total system and which contribute directly and simultaneously to different aspects of that system. Federation is a specific-purpose architecture, not a general-purpose one. But it is extremely efficient and scalable.
The remaining options that we will now discuss are "general-purpose."
The essential idea behind containers is "rose-colored glasses." Software that's running "inside a container" is running in an isolated environment that is, once again, "an illusion." But it is a different kind of illusion, and generally a much more efficient one.
The software inside of a container is, in fact, running directly on the host's operating system, and this is the key to its efficiency. Its isolation, then, comes from the fact the software doesn't see the truth of that host environment, nor does it know the truth of its own state. An application that's running, say, on a Linux-base container might perceive that it is the all-powerful root user, and perceive that it is indeed able to "exercise rootly powers," when (from the host's truthful point of view ...) it actually is not. The software might perceive that it has some amount of memory at its disposal when the host in fact possesses more, or less. It might perceive that "the entire file system" contains certain directories and that the contents are owned by certain users, when in fact both the file system and its permission structure are illusions. (That file system is likely to be of a specialized type designed for containers, and which quite possibly is not used at all by the host.)
Containers are both a "lightweight" and "efficient" concept, and one that allows for fine granularity of hardware deployment. Since all containers are running directly on a host – and cannot perceive which host – it is possible to create and to destroy containers on-demand. If many users start to use your web-site or a mobile application that is served by cloud containers, new containers can appear on-the-fly to handle the increased load, only to disappear again when the demand subsides. Your applications, running as they are in a dynamic pool of container environments, cannot determine which machine(s) they are now running on, and they don't care.
Because applications within a container are in fact running directly on the host environment, the only thing that a container host actually has to do is to properly maintain the illusion. A container's perceived user-id (including root) is mapped to another, actual, user-id on the host ... but the container can't see what it is. Containers have individual controls of main-memory use and the consumption of CPU time, and can be assigned "affinity" to particular CPUs or CPU cores, exactly as a virtual-machine operating system would do ... but without the virtual machine or its separate operating system.
If your application is capable of running in a container environment, this is generally the most desirable scenario. To meet the varying requirements of various types of applications most efficiently, containers can be further subdivided into system containers and application containers.
A system container emulates a computer system in the sense that it is a collection of possibly-unrelated processes that perceive one another's existence. A single container might, for example, run a web server process and a database process at the same time. A commonly-used container architecture of this type, for the Linux® operating system, is called lxd™. You might choose to deploy such a container where you would ordinarily use a virtual machine.
An application container runs only one instance of a particular application. It is designed to be launched (and destroyed) very quickly, and to be able to start serving requests almost instantly. A commonly-used container architecture of this type, again for Linux, is Docker®. This type of container is very similar in principle to federated execution, but it is general-purpose. A production application might consist of a constantly-varying pool of application containers of various types – user or application interfaces, database servers, and so on – all spread out over an unpredictable number of physical machines.
(It may well be said that "application containers" are the most-likely successor to "federated environments," since they are general-purpose.)
"Maestro, If You Please ..." (Container Orchestrators)
Because they are efficient and lightweight, while very-effectively concealing the particulars of the hardware environment on which they run, containers offer unprecedented flexibility both to the application designer and to the hosting service. Specialized file systems and mechanisms for information sharing and cooperation, all very specific to containerization, have appeared rapidly. Many hosting companies now exist that support only containers. They are able to leverage containers' inherent scalability to utilize their hardware investments very efficiently while providing noticeably-faster responsiveness than other alternatives could provide. They do this while at the same time minimizing costs to the client, since most resources are deployed (and so, billed-for) only when they are actively being utilized.
When you employ a container environment, you often find yourself dealing with thousands of containers, scattered among a large number of computers. (Or, you might be working with a specialized vendor, such as RackSpace.com®, which does this for you.) You need fast, dynamic scaling and centralized control. An ever-growing variety of ancillary software systems, with fanciful names such as Kubernetes®, have appeared to answer this call, and new contenders are appearing almost every day.
So, are there containers for Microsoft Windows?
Hey, no one ever accused Microsoft Corporation from missing out on a piece of any revenue-producing action! Yes, Microsoft Windows supports containers, "in typical Microsoft fashion." (That is to say, tightly and seamlessly integrated into their total system and its comprehensive built-in infrastructure management schemes.) Microsoft's primary technology for doing this today is based on Docker – a fact that the company explicitly acknowledges.
"Software as a Service (SaaS)"
An ever-growing number of cloud providers, such as Heroku®, take a more holistic approach to the process of devising and deploying a web-based application. Their systems are designed to be instantly scalable, adding new computational resources on-the-fly to handle "black Friday" without breaking your budget on Tuesday afternoon. They provide specific support for the development processes leading up to deployment as well as the system management duties that occur thereafter. You don't have to "build-out your environment." It's already done for you.
Amazon® has leveraged its powerful server-farms with offerings such as AWS®, and Google® of course has done the same. (Ditto IBM® ... the list goes on and on and on.) Their offerings include not only front-end (web and app-support) services, but an ecosystem of integrated offerings which can be deployed in myriad ways.
- The term grid computing is sometimes used to reflect this bringing-together of resources from multiple sources for specialized purposes. Very large-scale deployments can be handled in a way that "scales up" and "scales down" quickly and dynamically.
The presence of SaaS-specific providers has, of course, shaped the emerging path of web-based software development, by encouraging applications and associated business processes which leverage their specific strengths. Some SaaS providers focus on particular market segments while others are more general. This is a very emerging technology that is still, in some ways, discovering its own path and place(s) in this world, but clearly it is here to stay.
See? We Promised: "No Sales-Pitch for Cloud Services!"
... but we do "know the Cloud," and we can therefore assist you in evaluating your various alternatives for cloud deployments. We can look at your application as it stands today and provide a blueprint for moving it to the cloud in a way that is most cost-effective and performance-effective for your business. We'll be happy to assist you in making your selection from among an ever-increasing number of high-quality vendors, and you know that we are un-biased. We don't represent any of them nor receive any sort of promotional compensation from them. Your business, and its present and likely future requirements, is our only concern.