Welcome to Part 4 of The Cloud Understood series. A quick recap: in Part 1, I defined “Cloud” and described many of the most common XaaS (Anything-as-a-Service) offerings. In Part 2, I discussed the interaction of Cloud Providers, Consumers, Service Owners, and Service Consumers and mentioned the features and benefits of the Cloud. In Part 3, I discussed the benefits and risks in Cloud design. In this edition, I will explain the four primary Cloud Deployment Models.
Please keep in mind that the following descriptions are generalized, that the edges and borders of Clouds are blurred and change often, and—as stated in Part 1—“the true definition of Cloud Computing is as unique as the individual or entity consumer.”
A Public Cloud such as Amazon Web Services (AWS), RackSpace, or Microsoft Azure is an interconnected collection of geographically disparate, very large data centers. The compute, storage, and network resources contained within are connected and combined with each other and code-based services to emulate servers and platforms from the very simple desktop to the most complex multi-core servers and networks of servers and IT resources. The consumers of a public Cloud do not typically have anything in common other than their Cloud provider. Multi-tenancy in a public Cloud demands that encapsulation and segregation of each tenant’s compute, storage, and networking resources is thorough, resulting in complete architecture isolation.
A Community/Membership Cloud is generally much smaller than a Public Cloud in terms of the number and size of interconnected data centers and the total compute, storage, and networking resources that are maintained and managed within the Cloud. The consumers of a community Cloud typically have many things in common; they may be Business-to-Business related entities or Parent-Child related entities such as State to Local Governments. Many SaaS Cloud products like Workday or Salesforce can be considered a Community Cloud since the consumer tenants all share a common code-base for the software application and subscribe to the service. Multi-tenancy in a community Cloud is primarily focused around the client’s configuration and data storage. Unlike the public Cloud model, complete architecture isolation is not realized. Application code is typically defined as a shared resource to avoid redundancy in storage, management, and maintenance.
A Private Cloud is owned, managed, maintained and consumed by a single entity (e.g., corporation or institution) or individuals within that entity. The primary difference between a Private Cloud and an on-premise data center is how the individual departments and individuals interact with the IT department when requesting, provisioning, using and de-provisioning compute, storage, and networking resources. Instead of IT personnel being involved in every step of the process, the IT personnel develop appliance templates with specific configurations and options, pool these pre-designed IT resources, then make them available to the departments/individuals who are enabled to manage the need and usage of those Private Cloud resources. Private Clouds typically have very tight security boundaries restricting the entity consumers from any interaction with each other’s virtual servers and storage as well as all other IT supported internal and external systems.
A Hybrid Cloud is the encapsulation via APIs (Application Programming Interface), networking and security boundaries, of two or more of the above Cloud deployment models. Simply being a consumer of various public communities or Private Cloud offerings is not considered a Hybrid Cloud. Instead, it is the conjoining of these Cloud models, allowing them to share data stored in one with processes provided by another that creates the hybridization. For example, using a Cloud-based SaaS (Community Cloud) recruiting product to solicit new potential employees including personal bio/demo data and attachments such as résumés and forms, which integrates via APIs to an on-premise document storage and imaging system; simultaneously integrated with an HCM system running in a Private Cloud, again via API; and allowing maintenance and management of the attached documents using Office 365 (Public Cloud) while avoiding the redundancy of storing multiple copies of the data and maintaining its integrity and security. An Enterprise Service Bus, as provided by tools such as MuleSoft, provides the overall design, management, and control of the various APIs required to connect the Clouds and the applications within.
The first three Cloud Deployment Models present many distinctions to their consumers; the fourth, Hybrid, is simply the homogenization of two or more of the first three. The distinctions among the Public, Community/Membership, and Private Cloud Deployment Models include overall physical size, geographic disparity, IT resource offerings, and service offerings.
A Public Cloud such as AWS or Azure has seemingly unlimited bare-metal and storage physical resources located in dozens of data centers around the world. They offer hundreds of pre-configured, virtual appliance templates, supporting various combinations of CPU, RAM, storage, networking, and operating system capabilities. They also offer a wide selection of pre-defined Cloud Services to support security, authentication, encryption, compression, monitoring, backup/restore, disaster recovery, high availability, etc. Almost all of the offerings in the Public Cloud Deployment Model are provided to the consumer in an “à la carte” fashion. The consumer only has to use and pay for the Cloud-based IT resources and services that are needed, and can then add or remove these resources and services as dictated by its business requirements.
In a Community/Membership Cloud, the overall size of the underlying infrastructure, the geographic disparity, and the resource and service options presented to the consumer are much more limited than the Public Cloud model. The pre-configured, virtual appliance templates are based on the common application(s) and “scale-out” methodology is utilized to accommodate differing consumer requirements for CPU, RAM, storage, and networking. While Cloud Service options exist to support security, authentication, encryption, compression, monitoring, etc., the consumer may only have the option to enable or disable these. The consumer’s subscription cost for a Community/Membership Cloud is based on the application(s) lease and the metered usage of the IT resources consumed.
The Private Cloud by design is a closed system in regards to the applications, data, and supporting IT resources and Cloud-based services available to its consumers. A Private Cloud is not defined by the size of underlying infrastructure or geographic disparity—companies such as G.E. and IBM have vast amounts of resources available to their consumers of their Private Cloud. Instead, a Private Cloud is more defined by the relationship of Cloud Provider and Cloud Consumer and also by the available and/or mandated virtual appliance templates and Cloud Services. Although the entity that provides the Private Cloud also consumes its resources, a metered costing model is typically used to more accurately spread the expense of establishing and maintaining the underlying infrastructure and IT overhead to the consuming subsidiary, department, or individual.
Now that we have an understanding of the Cloud’s fundamental building blocks, next time I’ll present a business scenario for which we can start creating life-like use cases.