Tag Archives: Amazon

The Cloud is Dead! Long Live the Cloud!

The last few months have presented several large “black eyes” for cloud computing. In March, access to Google Apps (including Gmail) was interrupted for over 136,000 users. Last month, 13% of Amazon EC2 and RDS customers in the US Eastern Region had a complete service outage, affecting a range of well-known companies.

As a result, the cloud computing pundits have brought out the knives, attracting a lot of questions regarding the readiness of enterprise cloud computing. The gist of all of these arguments is that cloud computing is not something for mission-critical enterprise applications.

Many cloud computing advocates have countered these attacks by citing reliability statistics. For example, Google’s outage affected 0.02% of users for five days. This equates to 99.9997% up-time on an annualized basis—a statistic far better than that achieved by nearly all enterprises.

The Cloud: Dead or Alive?

Sunrise or sunset?
Sunrise or sunset?

So who is right? Is cloud computing “dead” for important use? Or is cloud computing better than anything enterprise management teams can provide?

They are both right… and both wrong.

How can this be true? A simple reason: enterprise (or business) computing is not simply provision of processing cycles or storage; it is a provision of a full range of computing services: systems engineering, processing, storage, customer service, technical support, backup and recovery, etc. It not simply a commodity transaction, but instead an ongoing business relationship managed by a human being and bound by service level agreements.

Those that view cloud computing solely as remote provision of computing resources are missing “The Big Picture.” Cloud computing is a service model for delivery of computing infrastructure, platforms and/or software. Those who wish to be successful providers of cloud computing for business need provide everything an internal enterprise computing provider would provide: computing resources and managed computing services—at higher quality and lower price.

The Cloud is Dead

This is why “The Cloud is Dead!” Companies who only provide remote processing cycles and storage are not providing enough for mission critical business use. They are simply providing the asset side of the equation—minus the controls critical for enterprise survival. Many of these providers—especially after the last two months—will soon be “dead” to enterprise buyers.

The Cloud is Alive

However, this is the very reason I say, “Long Live the Cloud!” The recent cloud computing problems highlight the huge market demand to add systems engineering, customer service, technical support, backup, recovery, and other human-oriented services to the cloud. (Imagine the benefits that businesses can gain by being able to “rent” the entire range of services and infrastructure their Internal Computing departments currently provides—but working from a more efficient, higher reliability infrastructure.) Cloud providers who meet the combined demand for lower-cost/higher-reliability computing AND managed services will make cloud computing a reality for big, mainstream enterprises—and do so very successfully.

The New, Complete Cloud

The nice thing—for business enterprises and cloud providers—is that there are so many ways to do this. Cloud computing providers can augment themselves with professional services teams, becoming “all in one” providers. Or they can remain focused on what they do best and partner with IT service providers who already have staff on hand and established procurement relationships with enterprises. Just imagine the ecosystems of cloud provision we will see arise over the next few years, competing with each other to provider better technology and service at a better price.

The Old Cloud is Dead! Long Live the New Cloud!

Look! Is it an ASP? Is it SaaS? Or is it a Cloud? Two Simple Acid Tests

look_up_its_a-200pxTen years ago, ASPs (application service providers) were the rage. Five years ago, SaaS (Software-as-a-Service) exploded. Lately, everyone is talking about cloud computing. Countless companies claim to provide one, some, or all of these. Some aspects of ASP, SaaS and cloud computing are very similar; some are very different. How can you tell the difference? I use two simple “acid tests” to figure this out.

That “blurry” starting point

ASP, SaaS and cloud all provide some basic common attributes: management of resources for you, broad access to many from location you do not need to own or manage, provision of service without needing your own IT teams, purchase without capital investment. However, from here the similarities end. Those differences that emerge greatly affect items of critical business importance: responsiveness to change requests, access to new features, and ability to scale quickly in response to increased demand.

Culling out ASPs from SaaS and Cloud providers

ASPs build, configure, host, and support applications on your behalf. One word, Self-service, separates SaaS and Cloud providers from ASPs:

The Self-Service Test: If a company needs to have software engineers modify code and provide a new build to provision your service, it is an ASP, “plain and simple.”

Many people who claim to provide SaaS and cloud computing are simply ASPs. Their software does not allow customers to pick, configure, and deploy the service without the intervention of software engineers. As a result, their teams (or partners) will need to commence (slow and costly) projects to make changes on your behalf. As a customer, this translates into: 1) higher service price, 2) slower implementation timelines, 3) slow response to changes, and 4) lack of automatic access to upgrades and new features (available to newer customers).

Culling out SaaS-based delivery from “True Clouds”

The line between SaaS and cloud providers is hard to see at the start. However, the line becomes clearer as you use the service more. One word, Elasticity, separates true cloud computing from basic SaaS-based delivery:

The Elasticity Test: A company is only a true cloud provider if it lets you scale capacity by 10x or more, without noticeable performance changes, with 1-2 days’ notice.

Many people who claim to provide cloud computing do so with software that only distributes some of the resources you need to scale. (True clouds distribute all of the resources). As a result, they need to commence an IT project, such as migrating data to a bigger database server, when one of their customers needs to support a dramatic increase in volume. As a customer, this translates into: 1) slower performance during peak demand, 2) downtimes for maintenance and upgrade, 3) cost spikes or delays to support things like big advertising campaigns, and 4) ability to only grow so big before you need a bigger provider.

Ask these questions, the next time you are looking at a “cloud-based” service

Then next time you are looking to procure a “cloud-based” service, apply these acid tests by asking the following:

  • Can I implement this myself? If so, how long will it take me to do this?
  • When you upgrade your service do I get the changes automatically (and for free)?
  • Can I change [X, Y, or Z] myself? Does this cost anything? Can I do this without whenever I want and see the changes immediately?
  • Can you provide a performance SLA for high and low usage periods? Do I need to do anything if, I am running a project or ad campaign that increases traffic by 10x, 100x or more? How does my cost [per X] change when this happens?

You don’t need to be a “geek” to ask these questions. However they will tell you very quickly what you are truly buying.

Additional resources and references:

  1. NIST’s cloud computing definition highlights the importance of self-service and rapid elasticity. It also highlights the importance of scaling all computing resources (e.g., networks, servers, storage, applications, and services)
  2. Amazon Elastic Compute Cloud demonstrates this in action.
  3. Scaling everything on-demand is not a trivial exercise. Here are posts on scaling dynamic data and future-proofing architecture.