Cloud Computing on Ulitzer

As a preface to the series of articles I will be writing on the Value Proposition and Business Cases for Cloud Computing, I wanted to discuss the layers below and within the cloud. It is important to understand what each of the layers is composed of, what the intended function of that layer is, and how these layers interact with each other. By simplifying the cloud computing concept into layers, it is easier to define the roles within the overall structure and explain where your business fits into the model.

Let me start by introducing a graphic I whipped up real fast. In the diagram below, you see that the cloud is basically a pyramid of technologies stacked in a certain order.

I believe that a pyramid best illustrates the conceptual ’size’ of each layer and it also conveys the message that each layer is based upon the previous layer. So conceptually, you understand that the hardware is the foundation and the widest layer. Software as a Service (SaaS) is the capstone and consequently the lightest layer. Note that this view is from that of an end user who would purchase SaaS from a vendor. For a very large enterprise who develops software internally, the Platform as a Service (Paas) layer would be the capstone for the enterprise. The internal departments that use the internally developed software would see SaaS as their capstone. Also note that the size and position of a layer does not necessarily equate to importance. If you read my previous article on ‘Cloud Servers,’ you would see that the hardware layer is probably the least significant as it is all commodity beyond a certain point.

The Hardware Layer
There isn’t much to be said here that I have not covered in more depth in my previous ‘Cloud Server’ article. I will summarize by saying that the hardware is expected to be inexpensive commodity hardware with no fault tolerance. Redundancy and fault tolerance are handled within the software layer, so hardware is expected to fail. This is completely counter intuitive to most people in the IT field as they are used to procuring fault tolerant servers with multiple power supplies, RAID disk arrays, etc.

The Virtualization Layer
I don’t want to call this the Operating System (OS) virtualization layer despite the fact that this is what is essentially going on at this layer. The physical hardware is being sliced into virtual machines that each have their own small (usually Linux or Unix based) operating system installed. These virtual machines are then collected into pools based on the resources they have. These pools of resources are the key to providing elasticity with respect to server architecture. These virtual machines can be brought online and assigned to a resource pool on-the-fly when the demand on that pool increases. They can then be destroyed when they are no longer needed. The ability to provision and destroy virtual machines on the fly allows a vendor to provide Infrastructure as a Service (IaaS). There are many major players in this commodity layer such as VMware, Citrix, Sun Microsystems and even Microsoft.

The IaaS Layer
The IaaS layer extends the virtualization layer by providing the mechanisms to provision and control the virtual machines in a utility computing manner. By this I mean that a common interface, such as a web portal, or an exposed API allows the end user to build and configure virtual machine templates as needed. The end user can also control when to turn on or destroy virtual machines and define how the virtual machines are networked with each other. If the IaaS is provided in a utility computing model, then the end user is also able to control cost by knowing exactly how much each virtual machine instance costs per minute/hour. Some vendors in this layer also provide storage and database services which are controlled via an exposed API as well. These services are typically billed in a utility computing fashion too. A lot can be done at this layer with respect to automation and orchestration (topics I will discuss in later articles) but the bulk of it is left up to the end user to handle. A good example of a major player in this space is Amazon Web Services with the EC2, S3 and Database services.

The PaaS Layer
The PaaS Layer extends and abstracts the IaaS layer by removing the hassle of managing individual virtual machine instances. This layer seeks to minimize the hassle and complexity in deploying an application in the cloud. A programming platform is presented to the end user, typically a developer at this point, which leverages and API and programming language. Two good examples of this layer are Google’s App Engine and the Force.com platform. With App Engine, Google exposes an API for storage, platform and database and leverages the Python and Java programming languages. Developers are able to write an application and deploy it straight into the cloud in this layer. Back end scalability is handled entirely by Google and the end user does not have to worry about managing infrastructure. The Force.com platform is similar but utilizes a custom programming language called Apex. If you are a large enterprise looking to deploy internally developed applications, this is your capstone.

The SaaS Layer
If you are a Small or Medium Enterprise (SME) or a large enterprise not wishing to develop your own application, the SaaS layer is your capstone. In this layer, even the platform has been abstracted away from you as and end user. You are simply interested in procuring a service, such as email or CRM. The vendor has developed an application and deployed it to the cloud. They handle scaling on the back end, infrastructure, etc. You simply authenticate to the application and use it as needed. Billing can be based on utility or a flat monthly fee. Either way, it is a simple way to get the application functionality you need without incurring the cost of developing that application. More and more enterprises are subscribing to SaaS offerings like Salesforce.com and Sugar CRM.

Putting it all Together
I hope that I have shed some light on the layers that comprise the cloud in cloud computing. Understand that the lines can blur between the layers as vendors within each layer add functionality and features to differentiate themselves from competitors in the space. This model is not concrete, nor does it illustrate every possibility with respect to layering. I am sure as time progresses, these layers will shift, blur or disappear entirely. This is meant more as a guide to understand a concept. In the coming series of articles I will publish on cloud computing, I will delve into greater detail within each layer, show the value proposition, and show how your enterprise can leverage cloud computing to provide a product and service portfolio that aligns with business goals. IT will have to shift from a sunk cost center to a value add business unit that innovates and provides measurable value to the company. Cloud computing makes that transition easier and more structured.