Currently browsing author

Jian Zhen

The Thousand Faces of Cloud Computing Part 4: Architecture Characteristics

In this post, I will describe somewhat of a revised set of architecture characteristics that define Cloud Computing.

Abstraction

A key characteristic of the Cloud is to provide an abstraction layer for the lower level resources, including compute, network and storage components. Users are strongly discouraged, or disallowed, to think in terms of the physical hardware, but instead consider in terms of the resources required. The users don’t need to worry about whether the underlying hardware is from IBM, HP, Cisco, Juniper, NetApp or EMC. What’s presented to them is a homogenous set of resources. This removes the users from having to worry about the differences in hardware or software configuration. The resources may be shared amongst many different users, or dedicated to a single user; and maybe presented as a set of virtual machines or a set of APIs.

On-Demand

The set of resources presented by the Cloud can be provision or de-provisioned as needed by the users. The term “on-demand” also conveys a notion of speed. When resources are requested, they are provisioned within minutes, not days, weeks or even months. In most enterprises today, hardware procurement is a multi-month long process that can slow down projects and frustrate employees. One large system integrator has recently trimmed the process of provisioning environments from 8 weeks to 3 days. However, to truly meet the business needs, they must go from 3 days to hours, if not minutes.

Elasticity

Elasticity is probably the most defining characteristic for Cloud Computing. In addition to the need to provision on demand, enterprises are increasingly required to scale for anticipated or unanticipated resource requirements. For example, one top university that we recently talked had a housing application that gets HAMMERED two weeks before the start of the school year, EVERY year. Traffic dies down and there’s very little activity after the initial period. A large financial services firm has 30 servers dedicated to handling a 15-minute job every day. These are examples of anticipated resource requirements. Enterprises know when they will need the additional resources, how much resources are required and the duration of time they will need the resources for.

An example of unanticipated resource requirement is when the market department rolls out a huge campaign and drove 10 times the traffic to the enterprise website, and the IT department was never informed. This is a real life scenario that I am sure many of you have experienced. The question at that point is not to point fingers, but to figure out how to rapidly provision 10 times the resources to handle that traffic. Another example that we have heard from a large software vendor is their need to periodically spin up anywhere from 50 to 500 servers for software testing, and then quickly spin down when finished.

Elasticity, or the ability to rapidly provision and quickly scale up and down the resources, is an architecture model that affects not just infrastructure, but also the application design. In addition, given that most of these scenarios, whether anticipated or unanticipated, do not happen often, so it’s unrealistic financially for enterprises to provision enough resource to handle these spikes. The Cloud would allow enterprises to rent the additional resources in any quantity at any time.

Self-Service

The traditional process of application owners or developer asking IT to procure and provision resources is arduous and long. Consider the software vendor scenario we described earlier where developers need to spin up 50 to 500 servers for software testing. The developers need to modify this environment often to test different configurations and application architectures, and they need to have these modifications done in real-time so they don’t miss their delivery schedule. IT organizations are not resourced to handle this type of scenarios. The best resolution would be to provide the developers a pool of resources that they can do their own configurations. The self-service model not only works for these developers, but more and more business users are asking for similar capabilities as they are asked to be more efficient.

Ubiquitous

Ubiquitous access, or the ability to access from anywhere, using any device, is one of the great promises of the Web. This promise will become real as smart phones, netbooks and laptops become the prevalent way of access information. Ray Ozzie, Micrisoft’s Chief Software Architect, described his vision of “3 Windows in the Cloud,” where the 3 Windows included Windows on PC, Windows on mobile devices, and Windows on TVs. As you can see, one of key messages in this vision is ubiquitous access.

The Thousand Faces of Cloud Computing Part 3: Business Benefits

Where the Cloud Architecture camp is focused on how to create the best architecture to handle the business needs, the Cloud Business camp is zeroed in on translating the architectural benefits into financial terms. It’s great that enterprises can have ubiquitous access and elasticity, but if it costs them 10x more in investment for a 2x return, that’s not going to fly. In this section we will look at some of the business benefits of Cloud Computing:

  • Reduce Cost
  • Minimize Risk
  • Increase Agility
  • Maintain Focus

Reduce Cost

One large enterprise has outsourced their test and development environments to an outsourcer, and paying approximately $10,000 per environment per year, regardless of whether the resources are virtual or physical. They have 3000 such environments, so they are essentially paying $30 million per year on just test and development environments. They did a user survey to find out the utilization of these environments, and all the developers responded saying that these environments are heavily utilized and there’s tight handoff from one team to another. An audit, however, revealed that overall, the environments are utilized < 10%, and that 70% of the environments are logged into once per year by developers.

Another large financial services firm said that their infrastructure is utilized less than 2% overall.

Enterprises can lower CAPEX by not having to procure additional hardware and software but to use cloud providers and their pay-per-use utility pricing to handle resource spikes; they can lower OPEX by abstracting the hardware differences, and providing self-service capabilities to the end users so IT don’t always have to be the middle man; and they can lower their CAPEX and OPEX by increasing utilization of these expensive resources, or reduce the amount of resources required to accomplish the same tasks.

Minimize Risk

It still shocks me that in this age, companies are still running some of their mission critical applications on servers sitting under a IT administrator’s desk. But more often than not, when I talk to enterprises, this very scenario always comes up. IT administrators do this for different reasons. Some just don’t want to give up control; some don’t want to go through the arduous procurement process; some don’t have the time; and some simply don’t see why it’s a problem. In majority of these cases, if enterprises can provide these IT administrators the ability to quickly migrate these servers into the Cloud, they are more than willing to do so.

The Cloud, by design, is architected to be highly available and fault tolerant. Any one component going down should not affect the availability of applications. The Cloud is one way for enterprises to reduce risk of mission critical applications going down.

Another way that Cloud helps enterprises reduce risk is it can give IT more control over the resources. Imagine a large organization that allows their end users to procure their own hardware and software because IT simply doesn’t have the cycles to manage that. Soon enough there will 100 different hardware suppliers and 1000 different software suppliers. IT will have no idea how these resources are being used and what the utilization levels are. In addition, this scenario presents a huge security risk to the enterprises, as there’s no control of the procurement process.

The Cloud centralizing the procurement and management of hardware and software, IT can maintain control but at the same time provide users the resources they are looking for. It will be a win-win situation for both sides.

Increase Agility

Joe Weinman, AT&T’s VP of Strategy, said that “an on-demand service provider typically charges a utility premium — a higher cost per unit time for a resource than if it were owned, financed or leased.” Joe is absolutely correct here, and the recent McKenzie report validates this as well. To determine whether Cloud Computing is the right approach, enterprises must look at other business benefits in addition to hard cost.

What is it worth to an enterprise when they can respond faster to business requirements and enable businesses to bring products to market quicker? For example, going from 8 weeks to 3 days to 10 minutes in provisioning of resources to run enterprise services or spinning up 500 servers in minutes to test an application.

The global economy is forcing companies to be global as well. One such company has 10’s of 1000’s of developers/consultants spread all over the world, all requiring quick access to test and development environments. It’s impractical for this company to build and operate data centers around the world, and it’s also not the company’s core competency and strategy to have all these data centers. One of the things they are looking to do is build a “cloud abstraction layer” on top of multiple clouds, and allow developers to request resources. Depending on the developer’s location and resource requirement, the software will automatically provision the right resources and inform the user when ready. The ability to distribute the workload onto multiple clouds gives this company the flexibility and speed to respond to business needs. How much does this worth?

Maintain Focus

Like the company described above, most enterprises do not consider building and operating data centers as their core competency. These enterprises consider it to be more of a distraction to their core business. By utilizing the service provider clouds, the enterprises can maintain their focus and accelerate innovation on their core business.

The classic example here is the New York Times case study, where the developers processed 4TB of data in matter of minutes to convert scans of 15 million news stories into PDFs for online distribution. Instead of worrying about taking months to procure hardware for this one time task and spending much more money, New York Times took it to the Cloud and completed the task in less than 24 hours and with much less money.

The Cloud allows allow IT organizations to focus on providing the best infrastructure possible, and developers to focus on their applications instead of the infrastructure.

The Thousand Faces of Cloud Computing Part 2: Users

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.

The Thousand Faces of Cloud Computing

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:

Characteristic Architecture Business
Infrastructure Abstraction
Resource Pooling
Ubiquitous Network Access
On-Demand Self-Service
Elasticity
Pricing Model
Consumption Model

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.

Google Lost Grip on Enterprise Reality

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.

[ Full disclosure: I work for VMware and Dan's my boss. However, this is my personal blog and the opinions expressed in this blog are my views and do not necessarily reflect the views and opinions of VMware. ]

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.

Three Cloud Resource Consumption Models

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.

The Reality of Workload Mobility, Federation, and Distribution

[ 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?

Security and Compliance in the Age of Clouds

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. (Great discussions there and huge thanks to Asheem Chandna of Greylock for organizing it.) Then Cloud Security Alliance released its Guidance for Critical Areas of Focus in Cloud Computing (my initial comments.) And now there’s a VERY active discussion on the Cloud Computing Group mailing list on this very topic.

If you look across all of the regulations and mandates out there, like SOX, PCI, HIPAA, COBIT, ISO, etc etc, they all require essentially two things: transparency and control. Transparency is an absolute must. You need to know who’s accessed what data, when and where, and maybe why based on some documented evidence. That’s why you see big sections in these regulations/mandates requiring audit reports. PCI requirement #10 is a good example of this. (Ok, spare me the discussion on how PCI is useless. It’s not!) Control is also a must but transparency sometimes can be used as a compensating control. For example, a company MUST ensure that no shared IDs are used. Well, sometimes that’s not quite possible. So companies implement monitoring of all access to ensure IDs are not shared. Sometimes auditors will let that pass as a compensating control.

Then if you look at what you need to protect from a high level, at the risk of oversimplification, it generally comes down to data, applications and identity.

identity.pngIdentity information is what attackers are first after in order to penetrate the application and get to the data. This is why Identity and Access Management (IAM) is one of the top 3 security priorities for enterprises (source: Gartner) and they are spending ~11% (~$3B) of their IT security spending on IAM.


data.png Then you have the applications which are being attacked left and right. The web application security market is red hot these days because of the prevalence of SaaS and other type of online applications.


identity.png And finally the attackers will get to the data. And there are a ton of different type of data. Data such as personal identifiable information (PII) are extremely valuable to some attackers and can be sold for anywhere between $25 to $100 per. You then have other type of data such as corporate financial information, intellectual properties and others that are invaluable.


cloud_control_transparency.png


What enterprises are looking for, regardless of in the cloud or on premise, are control and transparency on their data, applications and identities. Enterprise customers always need to make sure they are compliant with whatever regulations/mandates they are responsible for. In their own environment, they can do many things (defense-in-depth and other principles) to ensure they are “as compliant as possible.” However, in the cloud, they lose that control. In fact, it’s worse, in most cases, they lose transparency. They have no idea where their data is (in GAE, e.g.), or who’s accessing their info (most clouds), how their data’s protected (most clouds), and what data’s accessed for what reason (most clouds.) GAE is probably the worst offender in this case. During an interview with cloudsecurity.org, their GAE lead essentially said they cannot divulge ANY information around security. AWS is doing a slightly better job now in explaning. Though still, neither AWS nor GAE are providing ANY type of transparency through reports or logs (well, you could kinda get S3 logs.)

So in most cases, it’s not that AWS or GAE are less secure than most enterprise environments. They sometimes are probably more secure. However, the thing that most enterprise IT groups fear are losing control and transparency. They want to extend their audit controls into their cloud environment to ensure they are still compliant. Service providers need to step up to the plate and offer the reports enterprise customers are looking for.

As one of the former customer used to say, “you can outsource responsibility, but you can’t outsource accountability.” At the end of the day, the customer is still accountable for being compliant. If they fail the SOX audit, it’s not the outsourcer’s (or cloud provider’s) CEO that goes to jail. It’s the customer’s CEO.

Combining Twitter and WordPress Comments

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

rhm2k_twitcomment_suggestion.png

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 version of Twitpress and a new module I hacked up called Twitcomments. The basic idea is to have Twitpress tweet the blog post as it was designed to do, but adding a unique hashtag to the end of that tweet. Then add a section to the blog post to display the Twitter search results of this unique hashtag. For me it’s right below the blog post but before the normal blog comments.

So below is the steps to recreate what I have on Zen 2.0.

  1. Modify Twitpress to add a parameter for [postid]. The line I added to Twitpress 0.3.2 is line 250.
    $proto = str_replace( "[permalink]", $post->guid, $proto );
    $proto = str_replace( "[postid]", $postID, $proto );
    $proto = str_replace( "[link]", get_option( 'home' )."?p=".$postID, $proto );
    

    This essentially allows me to put “[postid]” (without quotes) in the Twitpress configuration. Mine looks like this

    New blog: [title] [permalink] #zen[postid]

    So when Twitpress post to Twitter, the actual tweet will look like this:

    zen284_tweet.png

    Note the “#zen284″ hashtag? That’s hashtag that I will later on use to search for any comments related to this post. The hope is that people would carry this throughout the conversation.

  2. To allow a bit more flexibility, you can add a few more lines to Twitpress so it will add additional hashtags based on the meta information associated with the post. To do that, add the following lines (for me this starts at line 254 below all the str_replace calls):
    $hashtags = get_post_meta($postID, "Hashtags", true);
    if ($hashtags) {
    	$proto .= " " . $hashtags;
    }

    And in the blog post, you can add a custom field with the name “Hashtags” and some value. For this blog post, I added “#csaguide”. The value of “Hashtags” will be added to the Twitpress tweet.

  3. To add the twitter search to each of the blog posts, you need to download my hacked up plugin Twitcomments and put it under the directory “wp-content/plugins/twitcomments”. Make sure you rename “twitcomments.txt” to “twitcomments.php”.

    In addition, you need to download SimplePie and copy “simplepie.inc” in the same directory. SimplePie is used for parsing the twitter search result, which is in ATOM format.

    You will also need to update twitcomment.php and change “#zen” to whatever you set your unique hashtag prefix to be.

    Once you have done all that, make sure you go into WP’s plugins page and activate Twitcomments.

  4. The last thing you need to do is add a function call to your theme’s single.php.
    <?php twitcomments(); ?>

    Add this to wherever you like your twitter comments to appear. Once you do that, you should see something like the following when you go to your post.

    WP_Twitcomments.png

    You can go to this post to see an example of this in action.

That’s it. I know it’s not pretty the way I’ve written it up. If someone wants to take this, modify it so it’s configurable through WP, and package it up nicely, please feel free to do so. You can consider my hacked up plugin to be New BSD licensed.

Enjoy!

Review of Cloud Security Alliance Guidance

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 the tie of “private clouds” and “single-tenant (dedicated). For example, multi-tenancy is important even for the on-premise cloud within the enterprise. Also, the off-premise cloud piece (essentially an extension of the customer’s on-premise cloud) could be on a multi-tenant cloud. Other than that, i am kewl with the definition of “private cloud”..or maybe i am just not reading correctly..

There seems to be some font size issues with the Governance portion of the doc…or maybe it’s just my adobe reader.

Domain 2 on Governance reads like a list of things that’s designed for an outsourcing check list…and maybe it should be…but i wonder how likely a customer will get that from like google. Apologies to @jsbardin in advance, but seems like this domain is rushed…there’s a lot more context that can help readers. Domain 2 should really be “IT Governance” and not Governance in general. For example, it doesn’t cover corporate governance.

Wassup with the domain 3 with copyright to Francoise Gilbert? Domain 3 on legal issues is quite well written i think…covered a lot of the issues folks have been talking about.

Domain 5 on compliance and audit is a bit light as well…good stuff in there…but i think there’s a lot more can be said.

There seems to be quite a bit of overlap from domain 2 to domain 6…especially around data/information mgmt. Not necessarily a bad thing to keep hammering it in..but i wonder if there might be a better way to structure these.

Surprised at the shortness of domain 7 on portability and interoperatility…there’s pro’ly more to it i am sure..good start. Pro’ly at least 3 layers to portability…data, app, and server image (in the case of IaaS)…i think only the first 2 are covered.

Domain 8 covers some of the same issues as b4..but good list…can def’ly be expanded..good stuff tho.

A bit perplexed bout domain 9…not sure what the goal is for this write up…maybe i just need more brain cells.

Good issues being raised in domain 10…not sure if there’s a lot of guidance…must re-read another time.

Domain 11, page 65, “In an Infrastructure as a Service (IaaS) cloud platform”?? is it a cloud platform or cloud infra? Top of page 66…”local data storage is not persisted across machine restarts”…HUH?! wah? seriously? EC2 only maybe. Page 66 under “IaaS Impact”, “comparable controls do not exist by default..” again…says who? too limted of a view. Think domain 11 author should be diligent in how they use the word “platform”…could be confusing. Top of page 68, Figure 4, actually in many cases dev & test are outside and production is inside. So while figure 4 is valid for some, def’ly not for all. Again..lots of good stuff in domain 11…not sure i agree w/ everything…good start and write up nonetheless. Paas and saas section somewhat light.

Skipping domain 12 [for now]

Scanned domain 13…raises many good issues. [Re-read later]

Domain 14 again raises issues…but seems to be short on guidance. [Again, re-read later]

Not sure what to think of domain 15…must re-read later.

Web X.0

Summary

  • Web 1.0 is about 1-way information sharing.
  • Web 2.0 is about bi-directional participation and collaboration.
  • Web 3.0 is about the semantic web and ubiquitous computing.
  • Enterprises always lag behind consumer adoption on all leading web technologies.
  • There’s a long overlapping period between each of these phases due to the laggards.

Long Version

Web 1.0 is about information sharing. Web sites are built and information are put up. Usually web 1.0 has the “build it and they will come” type of mentality, and it’s mostly a one way communication. The poster children of Web 1.0 are companies like Yahoo, Ebay and Amazon.

Web 2.0 is about participation and collaboration; it’s about bi-directional communication. Social media such as blogs, wikis, and forums are huge in the Web 2.0 era. Post children of Web 2.0 are Wikipedia, Facebook, and MySpace. Web 2.0 has the “build it and encourage others to come and participate” mentality. The expectation of “they will come” is not as prominent. Most of these sites work hard to create a core community and get others to join.

Notice how both 1.0 and 2.0 are both about users going to these sites. These sites require users to fill in their profiles, browse around and understand what the site is all about. In essence, these site require the users to understand the web and go to the web.

Web 3.0 is going to change that. The notion of Semantic Web, which was first described by Tim-Berners Lee, is about having the web understand its users and go to the users, wherever they are and whatever they are using (Ubiquitous Computing). The web will carry enough meta data so that it’s self-describing. The web will know where its users are (by communicating with the devices that the users are carrying wherever they go.) The web can go to the users and present/share the relevant information and allow the users to collaborate and participate with the web as well as other users.

The technologies behind Web 3.0 are quite long, including different ways to describe the web (RDF, OWL, etc), different ways to connect and locality awareness (cell phone, portal computing devices, etc), cloud or web services (cloud computing, SaaS), etc. The piece that’s not as well understood and developed is the Semantic Web. It will be a while before websites will start describing their information in a structured manner.

Like most trends, leading edge technology will first be used in the consumer space, then slowly migrate to the enterprises. So there’s usually a pretty long overlapping period between the X.0 phases. For example, universities and consumers started building websites way before the enterprises realize the benefit of using the web to communicate. Same as Web 2.0, the collaboration tools such as blogs, wikis, forums, communities are first popularized in the consumer world, and it’s just now that enterprises are starting to adopt them. This enterprise adoption trend is referred to as Enterprise 2.0.

This again will happen with 3.0. The consumer space is now attempting to to do a lot of mobile computing, which is the start of ubiquitous computing. Cloud computing and SaaS have also been more prevalent in the consumer space. For example, Facebook, Google and others have been offering web-based services for sometime now. The enterprise space are just now starting to wake up to it. Some of the key obstacles to enterprise adoption are data governance, SLA and integration issues. However, companies like Salesforce.com are trying to change that.

Google Group Discussion on “Private” Clouds

I asked a totally unrelated question on the Cloud Computing google group a few days ago and triggered a very active discussion on where “private” cloud is an oxymoron or not.

[ Please let me know if I am taking any of the quotes blow out of context. ]

Ben Yamin called “private cloud computing a paradoxical phenomenon” and Ray Nugent called it an “oxymoron.” But even Ray agrees that many of his customers are asking about it,

Correct me if I’m wrong but most, if not all, of what I’m hearing from customers is around how to take AWS like services and tuck them within the four walls of their enterprise to somehow get economies of scale, lower costs and quicker scale/customer service to their constituents. Therein lay the Foggy part…

Rich Wellner agrees that we should “not care so much what things are called as much as what they do,” so he explained that “private” clouds does exist based on the list of attributes he’s compiled:

1) Multiple vendors accessible through open standards and not centrally
administered

2) Non-trivial QOS (see the gmail debate thread)

3) On demand provisioning

4) Virtualization

5) The ability for one company to use anothers resources (e.g. bobco
using ec2)

6) Discoverability across multiple administrative domains (e.g. brokering to multiple cloud vendors)

7) Data storage

8) Per usage billing

9) Resource metering and basic analytics

10) Access to the data could me bandwidth/latency limitations, security,

11) Compliance – Architecture/implementation, Audit, verification

12) Policy based access – to data, applications and visibility

13) Security not only for data but also for applications

Now here we start to see some things that aren’t applicable to enterprise clouds (i.e. 1, 5, 6). But the bulk of the list still works. And it’s worth noting that EC2 fails on more than three of those things (i.e. 1, 11, 12, 13), but people don’t hesitate to allow them the use of the term cloud.

I think Jim Starkey from NimbusDB summed it up best,

As I understand it, if you use Amazon EC2, it is cloud computing. But if Amazon itself uses EC2, it’s only fog computing. Or maybe (shudder) internal cloud computing. This is, of course, utter nonsense.

Laurent Therond also brought up an interesting point,

Amazon and Google would love for external entities to cofinance their clouds, because they own the infrastructure *and* they actually use it to run their own affairs. On the other hand, if you were to offer them to migrate their mission critical systems to some other Cloud Computing vendor (let’s assume you could find one up to the task), they would laugh at you loudly.

I am quite happy to see this level of discussion on this. My stand on this is quite clear and explained here.

The Rise of Cloud Privatization

The world of clouds these days is full of definitions and counter-definitions. There are many posts that try to define the concept of cloud computing; many that try to distinguish utility computing, grid computing and cloud computing; many that try to define public vs private clouds; and many that dismisses the notion of private clouds.

Jonh Foley, in his article “The Rise Of Enterprise-Class Cloud Computing“, referred to private cloud as an oxymoron,

That’s an oxymoron since cloud computing, by definition, happens outside of the corporate data center, but it’s the technology that’s important here, not the semantics.

But by whose definition? The industry as a whole haven’t even been able to nail down a concrete definition of cloud computing. Given that there’s no concrete definition, then by definition, private cloud is not an oxymoron. But I do agree with John, let’s focus on the technology and not the semantics.

Geva Perry, chief marketing officer at GigaSpace Technologies, did just that. By focusing on the technology and architectural aspects of cloud computing, he wrote in a GigaOM blog post,

Cloud computing is a broader concept than utility computing and relates to the underlying architecture in which the services are designed. It may be applied equally to utility services and internal corporate data centers, as George Gilder reported in a story for Wired Magazine titled The Information Factories.

Cloud Attributes

But instead of everyone trying to create their own definition of clouds, let’s look at the list of attributes that clouds have and compare public and private clouds.

  • Elasticity: The ability to dynamically provision (expand) or de-provision (shrink) the computing capacity as needed.
  • Utility: The ability to be charged by the amount of resources used. Great examples would include Amazon Web Services’ charge model. In an enterprise setting, sometimes business units are charged by the internal IT groups for the resources they requested. The utility model would allow IT groups to perform chargebacks in a similar model to AWS.
  • Scalability: The ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added. [ via wikipedia ]
  • Reliability & Availability: No failed whale! The cloud infrastructure and platforms must be reliable and available to the applications that are using them. There’s probably a lot of technology involved here to make this happen. For example, the ability to transparently migrate a virtual server when the running node has failed.
  • Manageability: The ability to effectively manage (start/stop/migrate/expand/shrink/etc) the different server and application instances in the cloud.
  • Security: The ability to secure the data and access to the cloud. Public clouds still have a trust issue with many of the enterprise customers, which is why the ? is there.
  • Performance: The ability to execute and complete tasks within the acceptable timeframe (defined by the SLA).
  • API: I consider this to be a desired attribute. This refers to the ability of doing resource management via some type of documented programming interface.
  • Virtualization: Applications are decoupled from the underlying hardware. Multiple applications can run on one computer (virtualization a la VMWare) or multiple computers can be used to run one application (grid computing). [ via GigaOM ]
  • Multi-Tenancy: The ability to house multiple customers using the same infrastructure and still be able to segregate the data.
  • SLA-Driven: The system is dynamically managed by service-level agreements that define policies such as how quickly responses to requests need to be delivered. If the system is experiencing peaks in load, it will create additional instances of the application on more servers in order to comply with the committed service levels — even at the expense of a low-priority application. [ via GigaOM ]
  • Support: The ability to smack someone upside the head when something fails.
Attributes Public Private
Elasticity
Utility
Scalability
Reliability & Availability
Security ?
Performance
API
Virtualization
Multi-Tenant
SLA-Driven ?
24×7 Support

So if we are looking purely from a technology perspective, private clouds can absolutely exist. In fact, given the questions for the public cloud, enterprises are more likely to experiment with private clouds for mission critical applications.

Market and Vendors

According to Merrill Lynch, the public and private cloud infrastructure, platform, applications and advertising together will be a $160 billion market by 2011, or roughly 12% of the total worldwide software market.

The total $160bn addressable market opportunity includes $95billion in
business and productivity apps, and another $65 billion in online advertising.

IBM and Sun have comprehensive solutions for ‘internal Clouds’. Dell targets large scale data centers, and HP provides ‘everything as a service’, making their solutions attractive for ‘external Clouds’.

So who are some of the private cloud infrastructure/platform startups that are taking advantage of this $160 billion market? (Feel free to leave a comment if I missed anyone.)

Company Product
3Tera AppLogic
Arjuna Agility
Cassatt Active Response?
Elastra Elastra Cloud Server
Enomaly Enomalism
GigaSpaces XAP, EDG, and Community Edition

Private Cloud Links

The Rise of Cloud Platforms and Why the OS Doesn’t Matter

Platform-as-a-Service (PaaS) is one of the buzzwords that’s mentioned often in the cloud computing space. I’ve written a blog post describing IaaS, PaaS and SaaS. In short, PaaS is a platform for delivering applications, similar to a pre-built system with hardware, OS and application stack all built in. In the PaaS case, this system is hosted. All you have to do is “upload” the application code and it should take care of the executing and scaling of it.

A quick survey of the land (by no means comprehensive, I am also including ONLY application platforms, not service-specific platforms such as DabbleDB) shows that there’s a plethora of PaaS players out there, each with their own target audience. Some provide more of a raw execution platform, some provide a full suite of tools for creating applications online. Unfortunately, most of these vendor approaches will lock you into their proprietary platform. If you ever want to move to another platform, you have to rewrite at least a portion of code using the new vendor’s API. Phil Wainewright has written about this in his blog post “A plethora of PaaS options.”

Company Application Type
Bungee Labs Web applications
Coghead Web applications
Google App Engine Python web applications
LongJump Business applications
NetSuite NS-BOS Business applications
Ning Social networking applications
Joyent Web applications
Mosso Web applications
Rollbase Business applications
Salesforce Force.com Business applications

In one of the CloudCamp SF sessions in July, one of the guys from Microsoft asked whether the OS matters in cloud computing. My answer to that was it depends on the type of application. If it’s a web centric application that has a web front end, uses a database for storage, and doesn’t use any of the low level file IO, then really there’s no need to know what the OS is. In that case, the OS doesn’t matter.

All these vendors have targeted applications that are delivered over the web, and almost all of the vendors listed above try to abstract the OS from the developers so that they don’t have to worry about the underlying infrastructure. As Mosso’s slogan claims, “Code, load and go.”

Even though cloud computing is still in its infancy; however, as it matures, cloud providers will move upmarket to provide additional business value to customers. We will see a rise of cloud application platforms appear on the horizon. Specifically, we will see more domain-specific cloud platforms for different verticals or application types. For example, I can imagine there are developers working on a MMORPG cloud platform (maybe it’s here already if you consider Metaplace to be that) that will provide execution and management (of virtual goods, zones, accounts) for MMO developers; or a data analytics cloud platform that provides all the basic OLAP functions.

Will BGP and DNS Exploits Affect the Future of Cloud Computing?

Recently we seem to be hearing more and more security exploits aimed at core Internet protocols. In July, Dan Kaminsky revealed a critical exploit aimed at the DNS protocol.

A couple of days ago “[t]wo security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency.” See Revealed: The Internet’s Biggest Security Hole | Threat Level from Wired.com for more detailed reporting.

According to Wired.com,

The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination.”

. . .

Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed to target addresses, not from them, and it can’t always vacuum in traffic within a network — say, from one AT&T customer to another.

The clever trip the researchers have done is to

use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients.

All these core protocol exploits have direct impact to cloud computing as the nature of cloud computing is that computing will happen out there on the Internet somewhere. According to the article,

The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs.