If you’ve made it this far, you’ve gotten past the Service Terms and have decided what type of Cloud you want to use (Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS)). The next thing to consider is exactly where you want your Cloud deployed.
The “where” of Cloud deployment involves two considerations: 1) Do you want to share your hardware with other Cloud clients, and 2) Do you want your hardware to be locally or remotely hosted? In an ideal world, with enough time and money for a custom implementation, a private, locally hosted Cloud implementation would be the first choice. However, most organizations do not have the requisite funding, and are not subject to the overriding security concerns of organizations like the CIA, and must therefore take a look at the pros and cons of both sharing hardware in the Cloud, and working with remotely hosted servers.
Let’s look at sharing hardware first. In a post last June, I discussed the National Institute of Standards and Technology (NIST) Definition of Cloud Computing, which described 4 categories of deployment models for Clouds: Private, Community, Public, and Hybrid. These categories refer to whether, and to what extent, a Cloud infrastructure is shared. Sharing infrastructure typically means that clients are assigned a virtual server on hardware that hosts multiple virtual servers. The individual virtual servers are segregated by the virtualization software, but the underlying infrastructure is shared, so resource contention (e.g. “noisy neighbors”) is a possibility, as it is in any virtualized environment.
In Private Clouds, the hardware is exclusively used by one organization, and is typically hosted locally by that organization. As may be expected, this is at the more expensive end of the Cloud price range, but it buys you complete control of your hardware, and the accompanying security and compliance benefits.
In Community Clouds, a group of related organizations share a cloud – for example, the shared municipal infrastructure in Melrose, MA. Community Clouds are much more cost-effective than Private Clouds, but are able to focus more closely on security and compliance issues for specific groups of clients- for example, see the US GSA’s list of approved Cloud Service Providers for a current list of federally approved vendors who are compliant with FedRAMP standards.
The Public Cloud is the most inexpensive model. Public Clouds can span several large scale data centers, and may offer the advantage of being able to geographically distribute your servers. If a natural disaster wipes out an East Coast data center, your traffic could be seamlessly redirected to a West Coast data center. Additionally, the pay-as-you-go model for public clouds can be a mixed blessing – either offering an economical way to only pay for the resources you need with a learn-as-you-go, do-it-youself implementation, or pushing you toward implementation consultants who can navigate the dizzying array of cloud options .
The Hybrid Cloud model is a combination of any of the other Cloud models. For instance, an organizational implementation of a small, Private Cloud for proprietary data, with a Public Cloud implementation for publicly accessible web sites. Or a university Community Cloud implementation that uses Public Cloud based SaaS for fundraising.
The exact model you use will be based on your budget, your organizational needs, and your security concerns. For any remotely hosted resource, make sure that you know exactly where their hardware is hosted, and if at all possible, that they have alternate sites in the event that your primary server instances go down. Yes, they have an SLA obligation to keep your site up, and yes, you will get some money back from them if they don’t, but it isn’t likely to be enough to offset the business losses you’re liable to suffer in the event of an outage.
I’ll wrap up Cloud deployment models on that note. The next post in this series will take a look at NIST’s overview of how enterprise level computing issues are manifested in Cloud environments.
Additional Posts in our Considering the Cloud series: