Zen 2.0

For the Infrastructure-as-a-Service market, there appears to be three models of consumption today:

1. Allocation-based
2. Usage-based
3. Resource pool-based

First it’s allocation-based consumption. Example would be EC2 where you allocate a VM with a certain amount of CPU/memory and you pay for that allocation. No need for a lot of explanations here since this is the model that most people are familiar with.

The second model is a usage-based consumption. This model does not require any allocation or resource pool and the cloud would simply allow you to use resources as needed. For example, your application may only use 300 MHz of CPU and 200MB of memory during normal operations and that’s all you pay for. If the application spikes to 1 GHz of CPU and 3 GB of memory for a period of time, you pay for that also. This model is a lot more unpredictable but could potentially be a lot cheaper than the previous two. Terremark’s Enterprise Cloud allows you to burst into this model once you have used up your resource pool. This model is much more of a true utility model since you pay for what you use. As far as I know no service provider is offering ONLY this model.

The third model is a resource pool model, which is a combination of the previous two model. In this case, a resource pool, say 5 GHz of CPU and 10GB of memory, is allocated, and you can spin up as many VMs as you like to consume that pool of resource. This model is a combination model because it’s still based on allocation but still gives you the advantage of granular metering. The advantage of this model is that you have much better control over the resource pool and if you know your applications well (e.g., the amount of CPU/memory they consume), this will be much more cost effective. Terremark’s Enterprise Cloud is based on this model.

Both second and third require very granular and accurate resource utilization monitoring. An important factor to consider for all these models is “burst capacity.” That is, if your VM needs additional capacity, can you “burst” or do you need to allocate a new VM and move your workload to the new VM? Which model you should choose depends heavily on how well you know your applications’ resource utilization pattern. If you know your applications well and can predict the usage pattern, then a resource pool model or true utility model might be better. If you want predictability and fixed pricing, then either the allocation model or the resource pool model will suffice. If you know you will be running many VMs and know your application usage patterns well, then a resource pool model may be best.

One thing to note here is that all these are consumption models and not cost or billing models. The service provider may charge you per hour or per month based on your allocation or resource pool. There may also be minimum resource level commitment. The service provider may bill you weekly, monthly or quarterly. It’s important to understand the differences of consumption, cost and billing models.

As described in a previous post, the infrastructure layer of the whole setup is about space, pipe, firewalls, VPNs, routers, switches, physical server and storage. In order to maintain such infrastructure, a company must employ a whole team of network, security and storage engineers. Even with hosting providers such as Savvis and Rackspace providing professional services, the amount of work companies must do in order to setup and maintain this type of infrastructure is still tremendous. To scale this infrastructure, the companies must monitor the usage and acquire new servers as needed. In addition, space and pipe are usually the biggest cost factor when it comes to hosting. That’s why the dotCom hosting providers such as Exodus were such high flying companies during the boom days.

The announcements of Amazon’s S3 and EC2 service in 2006 changed this whole game. Instead of provisioning for all the stuff that’s required before a single OS is installed, companies now have an option of simply provisioning for resources in the EC2 cloud and use S3 as storage. This also eliminates the need to staff teams of network, security and storage engineers. Amazon, in fact, is providing “infrastructure as a service.”

“Infrastructure-as-a-Service” or IaaS is essentially new fancy marketing term for “utility computing“, which, according to Simon Wardley, is “the packaging of computing resources, such as computation and storage, as a metered service similar to a physical public utility, This system has the advantage of a low or no initial cost to acquire hardware; instead, computational resources are essentially rented”.

So to summarize:

Infrastructure-as-a-service is about replacing critical data center resources such as space, pipe, firewalls, VPNs, routers, switches, physical servers and storage with scalable and highly-available resources in the cloud. It is about having a data-center-in-the-cloud.

So what are the characteristics of an infrastructure service? In my opinion, the following list are must-have requirements:

• On-Demand Must be able to rapidly provision or de-provision resources as necessary. One of the main advantage of having the data center in the cloud is that you don’t have to go provision your own servers, storage and bandwidth. You should be able to simply request more as you need them, and remove them as you are done. The IaaS provider should simply charge you for what you have used and nothing more. Remember, one of the keyword here is “rapid“.
• Scalable Must be able to scale infinitely if necessary. Ok, maybe not infinitely but the service should be scalable enough that you can quickly add tens or hundreds of servers as needed.
• Self-Sustaining or Self-Healing Must be able to self-sustain without end-user intervention. Some folks call this self-healing and that’s fine too. The point is that there should be enough redundancy and high-availability features built into the service that a physical servers going down must not affect the virtual servers running on that infrastructure.
• Multi-Tenant Must be able to share this same infrastructure with multiple end customers.
• Customer Segregation Must be able to segregate the data by end customers. Security and privacy is one of the major obstacle for companies in adopting cloud services, so it is critical that proper security measures are put in place to segregate customer data. Some of the definitions also listed “Virtualization” as one of the requirements for IaaS or cloud computing. To me, that’s not really a requirement per se. It is a technical solution to the problem of data or customer segregation.

The poster child of IaaS is undoubtedly Amazon. Their EC2 and S3 service have more or less defined the pricing and service in this market. Some of the posts listed here have listed other vendors such as EngineYard and Joyent. However, I consider these vendors to be more Platform-as-a-Service providers, rather than IaaS, as they provide the OS and the whole application stack, rather than just space, pipe, storage and servers.

Remember from the above illustration, once you have all the data center infrastructure, you still need to install the OS and application server stack, etc. So what IaaS does not help you with is the ongoing maintenance of the operating system, the stack and your application. So you still have to deal with patches, securing your OS, etc. These areas are where Platform-as-a-Service (PaaS) providers can add value.

We will discuss PaaS in the next post.

So why are we defining all these terms here again when everyone else has already defined them here, here, here, here, here, here, here, here, here, etc? Heck, there’s even a definition for Web 3.0 and beyond. Wait, let’s not forget the authoritative definitions from Wikipedia on Cloud Computing, Software-as-a-Service and Platform-as-a-Service! Whew…are we there yet? Of all these different definitions, the one that made most sense is by Kent Langley over at ProductionScale.

So why are we defining these terms again here? The reason is that all these different postings and definitions is making the view a bit cloudy and I just really needed to get them straight in my head. At the same time, I want to be able to explain these concepts to my grandma. Ok, maybe not my grandma, but definitely my executive management team.

As I see it, the market today really has 3 different as-a-Service (aaS) offerings:

• Infrastructure-as-a-Service
• Platform-as-a-Service
• Software-as-a-Service

To illustrate these 3 different offerings, let’s take a look at the traditional deployment of a web application. Whenever a piece of software is to be deployed, we must acquire the server hardware from companies like HP, Dell or IBM. The server will likely come with built-in storage; or if additional storage is required, the server can connect to a NAS, SAN, CAS, or other types of storage. If we are deploying this web application for external use, we will likely need to acquire routers, switches, firewalls, VPNs, load balancers and other type of data center equipment in order to ensure uptime and security. We will then need to acquire some space and bandwidth in order to host the equipment and allow external users to access the web application. In the “Web 1.0″ days, companies such as Exodus (acquired by Savvis) and Rackspace were providers that offered such space and pipe for enterprise companies who want to have a web presence.

Once the server is available, an operating system such as Windows or Linux must be installed. Once that’s done, depending on the language of the web software, an application server stack must be installed. For example, LAMP for languages such as Perl, Python or PHP, Ruby on Rails for Ruby, Tomcat for Java, etc. In almost all cases, a piece of database software, such as MySQL or PostgreSQL, will be required.

Once the hardware and the application server stack are in place, the actual web application can then be installed or developed.

In these three steps, we have essentially installed and configured the “infrastructure,” the “platform,” and the “software.” The following image hopefully illustrates what we just described.

In the next few posts we will explore the definitions for each of the three services.