It is widely recognized that a layered architecture can make a system (of any kind) more flexible, maintainable, testable, fault-tolerant, and scalable.
Currently there is no industry-standard layered architecture for cloud computing platforms. There is a standard layering of services (IaaS, PaaS, SaaS, and BPaaS) offered by public cloud providers, but no standard layering of the cloud platform itself, beyond a very basic distinction between a "physical layer" and an "abstraction layer" in a footnote of the 2011 NIST's Definition of Cloud Computing (PDF). Instead of layers, the primary organizing principle of most open-source cloud computing platforms (such as OpenStack) is the architecture of many data centers, with distinct "Compute," "Networking," and "Storage" nodes. We do not consider this architecture to be optimal, especially for clouds outside of data centers.
Below is a layered architecture that we recommend (loosely analogous to the OSI model for networks):
PetiteCloud is intended, primarily, to be the cloud foundation layer within a cloud platform that uses our recommended architecture. In the table below, the layers are listed lowest to highest. Highlighted rows denote current PetiteCloud services.
| Layer |
|
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Physical (Hardware) Layer |
|
||||||||||
| Hardware Management Layer |
|
||||||||||
| Virtualization Semi-Layer |
|
||||||||||
| Cloud Foundation Layer (CFL) |
|
||||||||||
| Scalable Cluster Layer (SCL) |
|
||||||||||
| Cloud Application Layer |
|
Each layer possesses its own challenges and opportunities for making the layers above it more stable and robust. For example, if the host OS and hardware are constantly crashing, they are clearly not stable or robust enough to build any sort of cloud computing on. PetiteCloud aims primarily to be a stable and robust cloud foundation layer (CFL) within our recommended architecture.
For very small private mini-clouds (several host machines on a network), the scalable cluster layer (SCL) and higher layers are unnecessary. All you would need is a CFL (such as PetiteCloud) plus one or more hypervisors on host machines with suitable hardware. On the other hand, controlling a site like Google (and all its associated sub-sites and services) clearly would require all the above layers.
PetiteCloud can be used not only as a CFL within our recommended architecture, but also beneath cloud platforms with other architectures (such as OpenStack, CloudStack, and Eucalyptus) as a means of making them stabler, more robust, and easier to install. The general theory is by virtualizing the "nodes" (aka hosts) of a cloud platform, they now have the following advnatages:
We will publish a series of tutorials on how to install various cloud platforms on top of PetiteCloud.
A cloud foundation layer (CFL), such as PetiteCloud, should have multiple users only in the context of a very small private mini-cloud, in which PetiteCloud is being used as a stand-alone cloud platform with no higher layers.
In other contexts, a CFL should have only one "user" other than the admin. In our recommended layered cloud architecture, the sole non-admin "user" of the CFL should be the scalable cluster layer (SCL), and that "user" must have API access. Alternatively, when using a CFL to stabilize a different kind of cloud platform, the CFL's sole "user" should be the installer (either human or automatic) of the other cloud platform. In any case, "user" accounts on the CFL do not correspond to user accounts on the SCL, or on the other cloud platform.
Similarly, in our recommended architecture, "users" of the SCL do not necessarily correspond to "users" of the cloud application layer. For a public cloud provider offering just IaaS (Infrastructure as a Service), there is no application layer (other than the provider's own cloud usage accounting and billing software), so the users are (mostly) customers. On the other hand, for a provider offering PaaS (Platform as a Service), SaaS (Software as a Service), or BPaaS (Business Process as a Service), the "users" of the SCL would be cloud applications, with API access to the SCL, whereas customers would have user accounts on the application layer.
The "Virtualization Semi-Layer" is referred to as a "semi-layer" rather than a full layer because the Cloud Foundation Layer (just above the Virtalization Semi-Layer) talks directly to the host operating system (part of the Hardware Management Layer, just below the Virtualization Semi-Layer) as well as to the Virtualization Semi-Layer. In a layered architecture, each layer talks only to the layer immediately below it, and not to any other layer.
The two-and-a-half lowest layers, below the CFL, do not pertain to cloud computing per se. They are included so as to encourage the developers of DIY cloud platforms to be aware of and make use of them. In particular, wherever possible, we encourage the developers of cloud platforms to use various services provided by the host operating system, as these are likely to be much more stable and reliable than any replacements for those services newly written by a cloud platform developer.