This is the last of my series of posts on the NIST definition of cloud computing. As you can see from this Wikipedia definition, calling anything a “cloud” is likely to be the fuzziest way of describing it.

In meteorology, a cloud is a visible mass of liquid droplets or frozen crystals made of water or various chemicals suspended in the atmosphere above the surface of a planetary body. These suspended particles are also known as aerosols and are studied in the cloud physics branch of meteorology.

Not that there is anything wrong with the label “cloud”--it’s a shortcut that allows us to quickly convey an idea. But for anything beyond that, when talking about functionality, we would be well advised to define and describe “cloud” in as much detail as possible so that all people involved have the same picture in their mind, and not whatever it is they think of when they think of “cloud”.

The NIST definitions help us narrow down features, functionality and models, but those are still only broad categories that leave certain gaps in which misunderstandings can easily sprout. I encourage you to use these definitions, but also to go further and describe cloud architectures by using terms that are as precise as possible.

In recent posts, I talked about the five characteristics of cloud, as well as the three service models. In this final installment of the series, I will discuss the four cloud deployment models.

Public cloud

The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.

Of the four deployment models, this one is the easiest to grasp. A public cloud is simply a cloud that you rent out to others. Essentially, if you build it (physically) and you charge money for others to use it, then you have public cloud. The typical providers of public clouds include Amazon Web Services (AWS), Microsoft Azure, Rackspace, Google Cloud.

Despite the name, the public cloud resources you are renting out are not necessarily accessible to the general public.

Private cloud

The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.

This deployment model is a bit more challenging to describe. The “private” in “private cloud” does not imply any more “privacy” or “security” than a public cloud would, but instead means “your own private use”. Another term you may hear is “corporate cloud”, a cloud used solely by a corporation, not by its customers.

For example, a private cloud may be set up within an organization so that different divisions have access to a shared virtual computing environment, for a variety of purposes:  development, testing, training, demos.  These are typically resources that are not accessible to anyone outside the organization.

Some organizations will decide to build an on-premises cloud using physical servers and software such as OpenStack. Others will opt instead to rent out the required resources from a cloud provider like AWS. Regardless of the choice, both of these fall under private cloud.

Private cloud environments are usually thought of as server configurations physically running on-premises. However, if the organization decides tomorrow to replace all these servers with Amazon instances running in the AWS cloud, it would still be considered a private cloud.  This is because, once again, it would be used for internal purposes, even though it is physically off-premises.

In doing research for this blog post, I came across numerous articles on the internet that seem to confuse private cloud with either “on-premises” or “secure access”. For example, many people consider AWS’ VPC offering to be a private cloud. As others have pointed out, it is not inherently a private cloud. It is a more secure way of accessing public cloud resources.

Community cloud

The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.

If tomorrow, I decided to start my own insurance company and create a new public cloud dedicated to only insurance companies, this would make it a community cloud. I could host it myself or have another public cloud provider manage the back-end for me.

There are few examples of these, and I have not worked with any of them myself. A good example of community cloud is GovCloud. It is created, hosted and managed by AWS. But it is addressed to all the branches of the US government. There is also the NYSE Capital Market Community Platform, which is sort of a financial-industry cloud.

Hybrid cloud

The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

I have to admit that this definition confuses me a bit. I may just write to the NIST to ask what they meant!

The distinction between private and public is not a distinction of location of the processing, but more of the type of processing that you do. So, to me, needing more resources and bursting to the cloud does not change the type of processing that you do.

I would expect that what makes for a hybrid cloud is the use of differing cloud technologies together. So you could have an on-premises OpenStack Cloud for baseline processing and obtain (burst to) AWS instances for peak usage. This would also mean that a hybrid cloud (made up of different cloud platforms) could then be either private, public, or community.

Parting words

The NIST definitions I have shared in this series of blog posts help us narrow down features, functionality and models so we can be more accurate when talking about the cloud.

In my opinion, they provide a solid base of understanding, and general classification, but they also don't go far enough along the branches of choices when it comes to cloud computing. The five characteristics, three service models and four deployment models are more than just marketing buzzwords. They are the foundation on which the detailed technical cloud architecture should be built. They are the start of the cloud discussion, they are not the whole discussion.