Zen 2.0

Been going through quite a few videos from Cloud Slam ‘09 today to see if there’s anything interesting. Haven’t gone through them all yet but so far I found the following sessions to be interesting/informative. I’ll add them to the list here as I find more.

Ivan Casanova: Self Service Application Provisioning – A Developers View into the Cloud

Abstract: Self-service application provisioning enables application developers to set up application infrastructure, such as Java application servers, databases, and messaging servers, without any help or assistance from infrastructure teams. Self-service application provisioning hides the complexity of the enterprise cloud from application developers and empowers them to set up and configure complex application infrastructure with the click of a button. This presentation will look at the advancements and best practices in self service application provisioning as a front end to enterprise cloud projects.

Nimish Radia: Business Models and Needed Technologies for Cloud Computing

Abstract: Is Cloud Computing the next technology industry hype or there is a money to be made? With EC2 and S3 Amazon has shown one way to monetize cloud computing. Is this is the only model? Is cost saving the only driving force for cloud computing? Fortunately the answer is no. We expect that there will be various realization of cloud computing as the commercial, education, and government businesses will pose different requirements for the cloud computing. These requirements will range from simple pay as you use and self provisioning of the infrastructure driving the EC2/S3 type cloud to HPC cloud to public and private clouds for enterprises to highly secure clouds for personal and private information and associated computation for healthcare and government industries. Then there are the clouds defined based on the level of abstractions, i.e., infrastructure, platform, and service/applications. These different types of clouds will have different business models driving overlapping technical requirements. This session will categorize the cloud computing space, describer associated business models, and identify ensuing technology requirements for these clouds. It will also identify key open source standards and technologies that will help build and operate such clouds as well as the areas that will need innovations and standardization.

In a previous post I looked at Cloud Computing from many different angles. In this post, we will take a look at it from the angle of cloud consumers and why they care about clouds. On a high level, there are probably six types of cloud users.

• Enterprise IT
• Independent Software Vendors (ISVs)
• System Integrators (SIs)
• Web Developers
• Community Developers
• Consumers

Enterprise IT

Enterprise IT teams are the ones that manages and operates corporate IT infrastructures. They are responsible for delivering applications and infrastructure to support the lines of businesses (LOBs). They are the ones that care most about enterprise features such as security, manageability, reliability, availability, etc etc.

However, they are also the ones that are under huge pressure to innovate and accelerate the solution delivery. Gone are the days that IT can take 3 months to provision servers to support a new business application. LOBs want their solutions and they want them now!

Clouds are appealing to the enterprise IT teams because it provides seemingly infinite resources at their fingertip and the IT teams can provision the resources on-demand. So instead of requiring the LOBs to wait 3 months, IT teams can now do that much quicker.

Independent Software Vendors (ISVs)

ISVs are users who develop products and solutions for enterprises. Traditionally they have delivered their products as software or hardware appliances. The ISVs will need to support multiple versions of their software as most of their customers will not likely upgrade as soon as new versions come out. They may support 2 versions back or 10 versions back, depending on the size of the customers, how much influence the customers have and the maturity of the ISVs. Government entities are notorious in their slowness in upgrade as each version will need to go through rigorous testing process. For ISVs who deliver products as software, they have to also worry about the runtime environments such as the OS, application stack, etc. There are ISVs that have hundreds of combinations they have to test for each version they release. Last but not least, some ISVs simply don’t have the resource to acquire a TON of hardware for test and development due to load/performance testing requirements or the number of environments the have to worry about.

Supporting existing versions and testing for hundreds of runtime environments take a huge amount of resources and limits the resource available for innovation. So clouds are appealing to the ISVs as they can now deliver their software as a service (SaaS). By going the SaaS route, the ISVs can largely eliminate the runtime environment concerns as they can have much better control of the infrastructure they use to run their SaaS. The ISVs can also have better control over how and when they upgrade their products as they generally only have one environment to upgrade, instead of potentially thousands of different environments. And with the cloud, the ISVs can provision additional resources as needed to test their products and not have to worry about paying huge capex upfront.

System Integrators (SIs)

System integrators, such as Accenture and Cap Gemini, are almost extensions to the enterprise IT teams. Their solutions are generally developed as consulting projects. They develop and deliver solutions to clients who have engaged them to solve specific problems. The solutions they develop sometimes are large scale projects that can take months or years to deliver. For years, SIs have been creating best practices from the custom solutions they developed so they can speed up the development of delivery of other projects (but charge the same regardless.

Clouds are appealing to them because they see clouds as one way to help them accelerate the development and delivery of solutions to their clients. They clients will see quick turnaround for solutions and the SIs can easily replicate some of the solutions they developed for one client to another. It’s a win-win situation for both of them.

Web Developers

Web developers are the early adopters of the clouds. They are the ones who are developing Web 2.0 sites such as Smugmug and others. AWS highlights many of these web developers on their blog. These web developers care about time to market and usually don’t have the expertise, desire and/or capital to provision and manage large infrastructures. They are focused on solving a specific problem and the less they have to worry about infrastructure, the better it is for them.

Clouds are appealing to the web developers because of these exact reasons. Clouds deliver to the web developers on-demand and elastic resources, thus removing the concern of infrastructure provisioning. The clouds allow web developers to focus on their problems.

Community Developers

Community developers are individual and open source developers who just wants to have their own playground but don’t want to concern themselves with hardware provisioning. They are very similar to the web developers category but they are not developing a business in the cloud.

Consumers

The consumers in general loves the clouds. Consider the number of users there are for cloud applications such as Yahoo! Mail, Gmail, Google Apps, Salesforce.com, Qualys, NetSuite and many others, then you will start to see the scale and reach of cloud applications. In many cases, consumers don’t even care whether you call these “cloud applications.” To them they care about the ease of use and access, and that they don’t have to worry about any software installation or configurations. The wide spread of cloud applications is one reason why Netbooks are so appealing these days.

It’s amazing that people are still arguing over what cloud computing is and what is a cloud. I am certainly not immune to such naive arguments. Claims such as “EC2 is NOT a cloud” just makes my head spin and wonder what the heck people are thinking. But if I taking a step back and try to understand why people are so passionate about this subject, I start to realize why there are so many definitions for Cloud Computing and why people continue to passionately argue over these definitions.

The short of it is that cloud means different things to different people. The Cloud has different characteristics to people coming from service provider backgrounds than people from a developer background; it has different meanings to people who care more about architectures than people who are more business-oriented; and it certainly .. to people who are building the clouds than the consumers of the cloud.

So instead of creating a single definition for Cloud Computing, let’s look at it from

• Two perspectives
• Five architecture characteristics
• Three delivery models
• Three deployment models
• Three consumption models
• Two pricing models

Two Perspectives

There are passionate discussions on the definition of Cloud and Cloud Computing. If we summarize the arguments, we can see that there are really two camps of people: those who looks at Cloud as an architecture and those who looks at Cloud as a business model. In many cases they agree on many of the characteristics but there’s usually one topic that really heats up the discussion and that is whether pricing and billing should be a defining characteristic of the Cloud.

The Cloud Architecture camp usually argues that how the Cloud is priced and billed should not be a defining characteristic of the Cloud since that’s a business decision. And they are absolutely right about that.

The Cloud Business camp also passionately argues that how the Cloud is priced must be a defining characteristic, otherwise how else can the user be billed? And they are absolutely right about that as well.

At the end of the day it’s about perspectives. Here are the characteristics again and where I think they fall:

Five Architecture Characteristics

• Infrastructure Abstraction
• Resource Pooling
• Ubiquitous Network Access
• On-Demand Self-Service
• Elasticity

I am going to refer you to the write ups in Guidance for Critical Areas of Focus in Cloud Computing from Cloud Security Alliance, as well as the Draft NIST Working Definition of Cloud Computing. These folks have done an awesome job of writing these up so I won’t elaborate here. Notice that these five are architecture characteristics so I didn’t include the utility-based pricing characteristics here.

Three Delivery Models

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

Again, I am going to refer you to the write ups in Guidance for Critical Areas of Focus in Cloud Computing from Cloud Security Alliance, as well as the Draft NIST Working Definition of Cloud Computing. This is generally referred to as the SPI model.

Three Deploy Models

I found that the distinction of public, private, managed, community and hybrid clouds in both the NIST and CSA documents somewhat difficult to comprehend. I don’t mean that they don’t make sense but you really have to think through them before you can understand them. In most cases, the follow three seem to be easier to understand.

• Internal Cloud

  An internal cloud lives within the 4 walls of the enterprises (like their data center.) It’s fully built, operated, controlled and managed by the enterprises themselves. It has all five of the architecture characteristics of a Cloud. It may or may not have the pricing model required for external clouds since some enterprises may not care about chargebacks.

• External Cloud

  An external cloud lives outside of the enterprises and it’s usually built and operated by service providers but the resources maybe controlled and managed by the customers. The external cloud can either be shared (multi-tenant) or dedicated (single-tenant). It has all five of the architecture characteristics of a Cloud. The service provider will usually dictate the consumption and pricing models of the external clouds.

• Private Cloud

  A private cloud is a combination of internal and external clouds. In most cases enterprises have more than one cloud just like they have some infrastructures inside the 4 walls and some outside. Even though there’s both internal and external clouds, enterprises will want to control and manage all of the resources that belong to them, potentially through a single pane of glass. The cloud resoures are private to the customers, thus the name private cloud.

Three Consumption Models

• Allocation-based
• Resource pool-based
• Usage-based

I’ve previously written about the consumption models so please use that as reference.

Two Pricing Models

One of the interesting debates out there is whether Clouds must have utility-based pricing, that is, consumers are only billed for what they used/allocated. I’ve generally seen the following two pricing models from service providers who have cloud offerings.

• Utility-based

  This is the pay-per-use model that most people associate with cloud infrastructures. Amazon and Google App Engine are based on these models.

• Subscription-based

  Most people tend to forget the subscription model is very popular in the cloud as well. For example, Salesforce is based on a per-user-per-month charge, so is Google Apps Premium Edition (per-user-per-year.) In fact, most of the cloud applications (SaaS) are based on this model. In addition, we are seeing some of the traditional service providers who are launching clouds also offer this pricing model as well.

So what is Cloud Computing and what is a Cloud?

Well, many combinations of the above can likely be considered clouds. I am not going to add another definition to the mix and hopefully this blog post will point out the reason why everyone has a different definition of Cloud Computing.

A couple weeks ago Rajen Sheth, Senior Product Manager for Google Apps, wrote an interesting blog post titled “What we talk about when we talk about cloud computing.” This week, Network World wrote an piece on “Google, VMware argue over private clouds,” essentially comparing the Google blog and an upcoming blog piece from Dan Chu, VMware’s VP of Emerging Markets. In this blog I want to share some of my thoughts on this topic.

Enterprise IT

First of all, Google has lost grip on the reality of enterprise computing. Or maybe Google never really got it since it never truly was an enterprise IT provider. Remember, in 2008, Google got 97% of its revenues from web advertising. Even though Google does probably run one of the biggest enterprise IT shops in the world (their own,) the applications they use and maintain are vastly different than 90% of the enterprise IT shops out there.

Secondly, enterprise IT teams will never run EVERYTHING in the clouds, and that goes for Google’s cloud offerings (GAE, GMail, etc) as well as any other external cloud. There are plenty of applications and data that have very strict regulations that will prevent them from ever going to external clouds. At May 7th’s Churchill Club CIO Agenda event, Karenann Terrell, Corporate VP & CIO of Baxter, talked specifically about some of the applications that are under HIPAA regulation and cannot move to external clouds. Some of the comments on the Google post also pointed to the same issue.

Thirdly, for many of the applications that enterprise IT want to move into the cloud, they will not want to rewrite them to fit Google’s cloud requirements. Enterprise IT teams have invest many person-years in selecting the best application components (frameworks, message bus, etc), developing and testing their applications. They want to move these applications into the cloud with as few changes as possible, preferably with no changes at all. In this case, I am not even talking about ISV applications like Exchange and SharePoint. I am talking about custom built corporate applications that enterprise IT teams built for their LOBs.

Last but not least, with respect to the section about Google can innovate faster, enterprise IT teams would much prefer to innovate on their own terms instead of Google dictating innovation. When was the last time someone or some organization can influence Google in their product direction?

Enterprise Workloads

Google’s cloud offerings (GAE, GMail, etc) are definitely good for some enterprise workloads, assuming they are not mission critical and do not contain any sensitive data. If businesses depend on the applications or the data contain sensitive information such as credit card or PII, Google’s likely not the best option. Let’s look at some common enterprise use cases that Google cannot support with the “supercomputer.”

1. Applications such as SAP, Oracle Financials, and Microsoft Exchange are business-critical core IT applications that many IT shops are consider virtualizing and moving into the cloud. These are applications that Google cannot handle.
2. Enterprise IT teams have strict guidelines on what application frameworks and components they will support in production environments. So developers must develop an application using enterprise-proven and enterprise-approved software components. Google’s “supercomputer” does not provide any type of options for enterprises to be able to use their own components such as their own message bus or database.
3. To extend the previous example a bit, enterprise IT teams would love to be able to develop and test applications in the cloud and eventually run in their own production environment. Again, given the strict guidelines to software components, Google will not be able to handle this.
4. An interesting scenario is that many companies want to have their DR site in the cloud so they can reduce DR costs. Again, nothing Google can do about this.
5. Many enterprises are interested in the ability to overflow additional capacity requirements to the clouds operated by service providers. For example, a company might be expecting to run a huge marketing campaign and need extra capacity. What they don’t want to do is buy new servers and software and only run them for the campaign period. In this case, moving some of the workload into the cloud makes perfect sense. Again, nothing Google can do about this.

Enterprise Requirements

Notwithstanding the fact that Google cannot handle most of the enterprise workload, Google also cannot support some of the key enterprise requirements.

• Manageability - Google does not provide enterprise IT teams much in the way of manageability. You get to drop your code into Google and that’s about all you can do.
• Security and Compliance - Please read my previous blog on this topic
• Interoperability - What you write for GAE is pretty much locked in. You will need to at least rewrite portions of the application in order to work outside of GAE.
• Integration - GAE can only execute calls from an HTTP request and (pls correct me if I am wrong) can only integrate with other web/cloud services via HTTP requests. This definitely limits the type of applications that can be developed.

Summary

Google’s cloud offerings have their places and they obviously work very well for Google in many cases. For example, GAE is great when you need to develop a brand new web-based application that doesn’t require enterprise-class features. Gmail and Google Apps are awesome as well (I use both) but they just can’t replace the enterprise products at this time.

It’s great that Google can claim hardware and software infrastructures as their true differentiators. I have no doubt that they probably have the most efficient infrastructure. It’s just that for majority of the enterprise workloads and requirements, Google is just not a good fit. Enterprise IT wants to have their own private cloud that potentially can span both internal cloud built by the IT teams and external clouds hosted by service providers.

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.

[ See bottom of the post for #workloadmob related discussions on Twitter ]
There, I covered my *aaS by listing all of the terms that people use for moving or distributing workloads around the clouds. Throughout this article I will use the term federation. There’s been quite a bit written on this topic already, including several [...]

Ever since RSA 2009 started, there’s been a ton of conversations spun up around the topic of security and compliance in the cloud. First, there were ~20 sessions on cloud security and compliance. I was on one of the panels that focused on cloud security and whether the cloud is secure enough for the enterprises. [...]

Yesterday I had the crazy of idea of reviving my long dormant blog and tweeted that. Immediately Rich Miller (@rhm2k) had a great suggestion.

Unfortunately, after looking around a bit, I couldn’t find any existing solution to do this. So I decided to hack my own. This hacked up solution is based on a slightly modified [...]

During RSA 2009, Cloud Security Alliance released its Guidance for Critical Areas of Focus in Cloud Computing (pdf). Below are the comments I made on twitter (using hashtag #csaguide). Later on George Hulme (@GeorgeVHulme) also posted his comments to #csaguide as well as written a blog post on it.
My Twitter Comments

Page 19, not sure about [...]