Cloud Computing 101

Editor's Notes

• #5: NIST, itself, has actually come up with the definition of cloud computing. And, again, focuses on these essential characteristics-- of on demand self-service, having broad network access, and-- on the equipment side-- resource pooling, so that now data centers are being built as a pool of resources that can be allocated now to different applications of the different tenants as they are needed. From the service model perspective, this is also talked about. Three major classes of services here. The first is software of the service. This is what most people think of when they think of, for example, salesforce.com. You're able to get the application delivered to you and you're using the application, even though it's hosted from a different service provider. The second is in terms of platform as a service. This is the model that have been followed by, for example, Google App Engine and Heroku and Microsoft's Azure, where you now have a higher level platform in which you're deploying and developing your applications. At the base of all of these is infrastructure of the service. This is where you're taking that pool of resources, virtualizing them, and then making them available on demand as the applications of different services needs. There's different ways now to think about how you deploy these models. The first is most usually exemplified by Amazon's Web Services. That is a public model. Where you'll be able to go and you'll be able to get access resources, along with many different companies that are acting as distant tenets in that public cloud. The second is private. And this requires a little bit of explanation. In a private cloud, we're really talking about that the control over those resources is by single entity, or single company. This is most often expressed as an on-premise solution, but it's important to realize that this is also now a model being able to provided by some of the manage service providers, where they're providing the resources that are under the control of a single entity. The third area is that of hybrid. And this is much more of a usage model. How an individual corporation may use a variety of public and private services to deliver the applications they need for they're internal usage. The last area is one of the more interesting ones, in my view. And that is what's known as community or community of interest. And it's best explained from the point of view of what we see evolving in the class base itself.It’s composed of three main sections:Essential Characteristics – These are the characteristics that make a virtualized (or non-virtualized) data center operation into a cloud serviceService Models – These are the types of cloud services that can be offered under the cloud modelDeployment Models – These are the models in which cloud services can be operated
• #11: Level I: Ad Hoc/CustomThe first level of maturity is similar to the traditional application service provider (ASP) model of software delivery, dating back to the 1990s. At this level, each customer has its own customized version of the hosted application, and runs its own instance of the application on the host's servers. Architecturally, software at this maturity level is very similar to traditionally-sold line-of-business software, in that different clients within an organization connect to a single instance running on the server, but that instance is wholly independent of any other instances or processes that the host is running on behalf of its other customers. Typically, traditional client–server applications can be moved to a SaaS model at the first level of maturity, with relatively little development effort, and without re-architecting the entire system from the ground up. Although this level offers few of the benefits of a fully mature SaaS solution, it does allow vendors to reduce costs by consolidating server hardware and administration.Level II: ConfigurableAt the second level of maturity, the vendor hosts a separate instance of the application for each customer (or tenant). Whereas in the first level each instance is individually customized for the tenant, at this level, all instances use the same code implementation, and the vendor meets customers' needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users. Despite being identical to one another at the code level, each instance remains wholly isolated from all the others.Moving to a single code base for all of a vendor's customers greatly reduces a SaaS application's service requirements, because any changes made to the code base can be easily provided to all of the vendor's customers at once, thereby eliminating the need to upgrade or slipstream individual customized instances. However, repositioning a traditional application as SaaS at the second maturity level can require significantly more re-architecting than at the first level, if the application has been designed for individual customization rather than configuration metadata. Similarly to the first maturity level, the second level requires that the vendor provide sufficient hardware and storage to support a potentially large number of application instances running concurrently.Level III: Configurable, Multi-Tenant-EfficientAt the third level of maturity, the vendor runs a single instance that serves every customer, with configurable metadata providing a unique user experience and feature set for each one. Authorization and security policies ensure that each customer's data is kept separate from that of other customers; and, from the end user's perspective, there is no indication that the application instance is being shared among multiple tenants.This approach eliminates the need to provide server space for as many instances as the vendor has customers, allowing for much more efficient use of computing resources than the second level, which translates directly to lower costs. A significant disadvantage of this approach is that the scalability of the application is limited. Unless partitioning is used to manage database performance, the application can be scaled only by moving it to a more powerful server (scaling up), until diminishing returns make it impossible to add more power cost-effectively.Level IV: Scalable, Configurable, Multi-Tenant-EfficientAt the fourth and final level of maturity, the vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer's data kept separate, and with configurable metadata providing a unique user experience and feature set for each customer. A SaaS system is scalable to an arbitrarily large number of customers, because the number of servers and instances on the back end can be increased or decreased as necessary to match demand, without requiring additional re-architecting of the application, and changes or fixes can be rolled out to thousands of tenants as easily as a single tenant.