Zen 2.0

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.

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.

[ 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 great pieces from James Urquhart. Any attempt to define something in the clouds will generate a ton of discussion, so I will attempt that here. Let’s define what we mean by workload federation.

Workload is the amount of work that’s performed within some period of time. In many cases workloads are performed by an application, thus sometimes workload and application are used interchangeably.

Workload federation is about dynamically distributing or balancing the workloads as effectively as possible, regardless of physical location and optimizing business and operational goals.

The reality is, workload federation is HARD. It’s a great vision and I am totally onboard with it. But still, this stuff is DIFFICULT to do! It’s not that it’s impossible, it’s just not as simple as “Beam me up Scotty.” In this series of posts, I want to explore this topic from several perspectives: goals, use cases and workloads.

Goals

There are really two types of goals: business and operational. Business goals are what IT and LOB executives care about the most. These goals are generally factors that go into running a business. Operational goals are really technical goals that are related to running the infrastructure and providing the best user experience. The goals are summarized as follows:

• Optimize Cost – The goal is the perform the workload in the most cost effective environment.

  There’s always a cost associated with running an application or performing some workload. There are many factors that go into the cost model, including compute, storage, network, I/O, and potentially some facility costs such as power and cooling. To truly optimize cost, sometimes you will need to better understand your applications. Is your application more compute intensive (like Hadoop type of apps)? Will it require large data set transfers?

  The idea is to be able to build a cost model for your application and set that as a policy for workload federation. Where the workload should be performed depends on the cost of moving that workload to various environments. You should be practical about the whole cost model and don’t lose sight of the other goals you are trying to achieve.

• Optimize Efficiency – The goal is to perform the work in the environment so overall resources are utilized in the most efficient manner.

  The idea here is that if you have a lot of work and you have different resources already reserved/allocated, you should distribute the work amongst the different resources so that all resources are being utilized. This may mean the overall cost is higher because you may be performing work in an expensive environment. However, the benefit is that your work maybe performed more quickly and results are returned to you faster.

• Minimize Risk – The goal is to perform the work in the environment that has the lowest political and/or corporate risk.

  I have written extensively in previous posts on the topic of security and compliance. At the end of the day, it’s all about risk management. Enterprises want to minimize the risk they are exposed to, whether it’s risk of data (IP or PII or others) breaches, non-compliance with regulations or mandates, or potential legal actions. Enterprises want control and transparency of their data and workloads.

  For example, in many EU and South America countries, certain types of data cannot leave the country because of potentially sensitive information. In addition to the issue of local laws, there’s also the question of whose jurisdiction the data falls under when an investigation occurs. In most cases, the government where the data is housed will likely win. A good example of this type of concern is when the French cabinet banned the use of Blackberry devices. Again, the federation policy should include parameters that allows you to specify the location where the data and workload will be moved to.

• Optimize Response Time – The goal is to perform the work in the environment that has the best response time.

  Response time can be defined in may different ways, including the round trip time between the user clicking on a link or button and the data being presented to the user, or the transaction time for database operations. Different workloads may have different requirements on response time. And sometimes workload may not necessarily be performed in the environment that has the fastest response time, as it may cost 10X more in terms of actual dollars spent to process that workload. So the it’s usually a good idea to define an acceptable response time range and optimize another vector in the federation policy.

  There are three major components to response time, including network latency, network throughput, and processing time. Processing time is the amount of time it took the application to process the request and prepare the result set. According to Wikipedia:

  Latency is the delay between the initiation of a network transmission by a sender and the receipt of that transmission by a receiver. In two-way communication, it may be measured as the time from the transmission of a request for a message, to the time when the message is successfully received.

  Throughput is the number of messages successfully delivered per unit time. Throughput is controlled by available bandwidth, as well as the available signal-to-noise ratio and hardware limitations.

  All three of these components determine and affect user experience and perception. A good example of optimizing response time is serving web pages. In general, the best user experience is when the web page is returned the fastest (yes I know it depends on the browser rendering time as well.) To accomplish this goal of serving web pages fast, the request maybe processed by an environment that’s actually physically farther away from the user compare to some other environments.

Note that all these goals are interrelated and all of the examples given above can be dissected in different ways. Enterprises are encouraged to prioritize and weigh all of these goals in creating their federation policy.

In the next two posts, we will look at the vision of workload federation from two other aspects:

• Use Scenarios – what are the different uses scenarios that enterprises are thinking with respect to workload federation?
• Workloads – what are the different workload types that will be running in the clouds and does it make sense for these workloads to federate?

[ Via @yarapavan ]

Stacey Higginbotham over at GigaOM wrote an interesting piece on 10 Reasons Enterprises Aren’t Ready to Trust the Cloud. Even though I agree that some of these points are valid reasons on why enterprises are hesitant in moving into the cloud, I have to wonder whether Stacey meant to be provocative (read: flame bait) on the piece. Also, the piece seems to be quite opinionated and lack support in many cases. Let’s drill down on it a bit.

1. It’s not secure.

I have written extensively on this blog (here and here) regarding the security concerns of SaaS and cloud computing. However, saying that the cloud is not secure is definitely a stretch. I would like to see some supporting evidence on this. The only major “security breach” I’ve seen is probably the Salesforce case.

In addition, none of the regulations or industry mandates, including HIPAA, GLBA, SOX, PCI, FISMA, etc etc, say anything about not allowing data to be outside of the corporate firewalls. In fact, many of the enterprises in the affected industries are already outsourcing some of their critical data. For example, financial companies using credit card processing services such as ViewPointe. There’s also plenty of hospitals using external services. PCI also has a specific section on hosting providers. Again, no regulation or mandate explicitly state that data cannot leave the corporate firewalls.

What CIOs/CSOs care mostly about is that cloud (application or platform) providers must meet their security requirements, there’s transparency in the security and operational practices, and that they can audit the provider or review the appropriate audit reports from the provider. The issue comes down to trust.

2. It can’t be logged.

Again, this is really about auditability, especially for compliance. This is definitely an area that’s lacking and cloud providers would be wise to do more in this area. Again, I wrote about that here: 4. Access Audit – Who has accessed my data and where’s my access logs?

3. It’s not platform agnostic.

Seriously though, is this really an issue? We are still in the world of multiple OS platforms, including different variants of Linux, Microsoft Windows, Mac OS X, Sun Solaris, IBM AIX, HP UX, etc etc etc. Is platform agnostic really that critical? Just like in the on-premise world, enterprises would be wise to evaluate the cloud platforms they plan to use based on a predefined set of requirements. Also, is supporting multiple cloud platforms really a concern that will prevent enterprise adoption?

4. Reliability is still an issue.

Again, I agree that reliability is a concern. However, that’s a concern regardless of what you decide. You have to worry about reliability if you choose to go with your own data center or cloud. You have to worry about reliability if you choose to partner with a data center provider to hose your gears. You have to worry about reliability if you choose to go into the cloud. Heck, you have to worry about reliability even if you just host your gears in your own IT network.

Stacey said “Even inside an enterprise, data centers or servers go down, but generally the communication around such outages is better and in many cases, fail-over options exist.” I am sorry, but by definition, the cloud platforms usually have these capabilities built-in already. A single server or multiple servers failing is usually not going to affect your cloud applications or platforms.

I believe the real issue is service level agreement. Are the cloud providers providing adequate SLAs and do the CIOs feel comfortable with the SLA that they are getting?

5. Portability isn’t seamless.

No disagreement here. Currently there’s not an enterprise version of the data portability standard. That can turn many enterprises away if they have no way of retrieving/migrating their data if they choose to go with another provider.

6. It’s not environmentally sustainable.

Again, a good issue to raise. However, I would like to see some evidence to show that creating and maintaining your own data center is more efficient than going into the cloud. There will always be excess capacity in order to handle spikes, regardless whether you build your own data center or go into the cloud.

7. Cloud computing still has to exist on physical servers.

No disagreement that data locality is an important consideration when moving into the cloud. I wrote about it in a previous blog. However, that just means enterprises should be aware of this issue and make sure that’s part of their requirement for evaluating the cloud vendors. This however does not mean enterprises won’t adopt because of this concern.

8. The need for speed still reigns at some firms.

The increase in bandwidth to home and offices is one of the main reasons why clouds are hot these days. However, I agree with Stacey that speed is definitely a concern for certain types of applications. At CloudCamp, during Jeff Barr’s AWS feedback session, the first hot topic that came up was how do people move a HUGE amount of data into the cloud and back. People talked about shipping hard drives as a solution to this type of problem.

However, this is not going to be an issue for most enterprises in the US, UK and countries with adequate bandwidth. Take for example applications such as Salesforce.com CRM, NetSuite, and many others, these applications do not require the need to transfer large amount of data back and forth so they are ideal for delivering via the web.

So again, a valid concern, but not a show stopper.

9. Large companies already have an internal cloud.

Again, I would like to hear more evidence from Stacey to back this up. I agree that most enterprises already have IT infrastructure in place, but most of these infrastructures are not considered clouds. My conversations with enterprises, including discussion from CloudCamp, is that enterprise IT groups are stretched thin and they can’t respond fast enough to business requirements. When the business require certain applications to do their job, they have to go provision hardware, software, space, etc and that process can take months. Going with the cloud allows them to quickly react to the business requirements and makes it a win-win situation.

Even if enterprises have their internal clouds, does that mean that shouldn’t consider external clouds? Enterprises should, and will, always weigh the cost/benefits to determine what’s the right solution for them.

10. Bureaucracy will cause the transition to take longer than building replacement housing in New Orleans.

Agreed. In big companies that’s ways going to be the case. No one is suggesting that all enterprises will move into the cloud overnight. Many of the enterprises are just starting to experiment with the cloud to see what can and cannot be done. This is healthy and it’s the right approach. A good example is New York Times using Amazon EC2 to convert millions of articles and TIFF image into PDF files.

Again, enterprises are adopting the cloud, just cautiously.

McKinsey & Company and Sand Hill Group recently released a survey called “Enterprise Software Customer Survey 2008.” This report focuses mainly on the SaaS market. The survey received responses from over 850 enterprises and had some very interesting observations. 62% of the respondents believe that innovation is on the upswing 31% of the respondents believe [...]