Over the past few days, I have seen a lot of articles, tweets and commentary about how the recent failure within Danger (who was purchased by Microsoft about a year ago) of data for the T-Mobile Sidekick was “the Cloud’s fault,” and this really bothered me. As Microsoft is poised to do something with the Danger brand (“Project Pink“) as well as soon release their Cloud Computing Platform called Azure, this could not have come at a worse time for them. There is obviously a lot of attention being paid to the cell phone market place as the Android platform is trying to make a positioning move to attempt to dethrone Apple’s iPhone. The Danger (now Microsoft) Sidekick was a device that provided great functionality “back in the day” (I actually went through quite a few generations of Sidekicks – from the B&W version up to a few color ones a few years ago). The Sidekick has a tiny market share and the user demographic is really much younger (e.g., teens) than the iPhone/Android/Blackberry crowd.

Last week, the Danger data network started experiencing some degradation of service where users were unable to access their data. A quick side note about the Sidekick, unlike other data-containing cellphones, the Sidekick stores all of the data (contacts, appointments, pictures, etc.) in a network datastore and not within the device itself. Most users rely solely on this service and don’t back up their data to a local computer. Other “smarter” phones like the Blackberry and iPhone rely on data synchronization with a physical computer or an Exchange Server to reliably back up their data. In my opinion, this is where the failure of the Sidekick started – single remote source of data only.

Details on the data issue are still being revealed (recently, there is a discussion about “dogfooding” or even “sabotage” where Microsoft may have wanted to replace the existing technology with their own – I will let the conspiracy theory experts battle that one out) but my understanding is that Microsoft wanted to upgrade the SAN (Storage Area Network) that powered the Sidekick data network and contracted with Hitachi to get the job done. Unfortunately for reasons unknown, no backup of the data was performed prior to this upgrade attempt (Failure #2). The upgrade of the SAN proceeded without a backup in place and the data was “destroyed” resulting in thousands of Sidekick users stuck without their data. As of this writing, some users have actually been able to recover data (e.g., if they didn’t power off their device or if they did a “reverse sync” from their Sidekick back to the Danger servers – I don’t have details on this so please don’t try anything without doing any research first).

This brings me back to the title of this post: this fiasco is NOT a failure of Cloud Computing, it is simply a failure of not following standard IT practices, ones that even an average computer user knows. Back up your data, your servers and your infrastructure regularly and store it securely in different locations.

It is somewhat understandable (and unfortunate) that mainstream media and even the tech community jump so quickly to the conclusion that the Cloud is at fault here. Cloud Computing is relatively new and as with any new technology or service, people are looking for any and all holes therein. The same could be said about the launch of eCommerce back in the mid-1990’s. There were failures, fraud and other issues associated with it and the naysayers were quick to point out only the negatives of the movement. Today, people use eCommerce for everything and could not live without it (there are still issues with fraud and security but the technology has evolved and stabilized). Cloud Computing is now going through a similar hype-cycle and we are in the phase where many are adopting and using it wholeheartedly but others are sitting in wait, hoping for some sort of a failure to point out the disadvantages of it.

With recent Gmail failures, users were quick to blame the Cloud. Gmail is a great example of a SaaS application (which many, including me, call a “Cloud Application”). However, Gmail has been around longer than the term “Cloud Computing” so have we simply compartmentalized it into a Cloud Application category? It is not a huge issue if we have. However, what DOES bother me is when a failure happens therein and people simply say “oh, it’s the Cloud’s fault”. Sorry, but what would we have said if a similar failure happened 4 years ago? “Oh, it’s a failure of SaaS” and “SaaS is evil”?

(more…)

I just read an article in ITworld titled “P2P bill could regulate browsers, cloud computing” by Grant Gross that got my brain churning a bit. Is Peer-to-Peer really considered “Cloud Computing?” And, if it is, how would it be classified? Cloud Application? No. Cloud Platform? Nope. Cloud Infrastructure? Uh…No.

After reading the P2P Bill, what concerns me is the extremely broad and loose definition of a “peer-to-peer sharing program”. H.R. 1319 (otherwise known as the “Informed P2P User Act”) does not seem to clearly define this term. (You can view the full text of the Bill here.) The definition of a “peer-to-peer file sharing program” is defined within the Bill as proposed as:

(2) the term ‘peer-to-peer file sharing program’ means computer software that allows the computer on which such software is installed–
(A) to designate files available for transmission to another computer;
(B) to transmit files directly to another computer; and
(C) to request the transmission of files from another computer.

In a response delivered to Representative Bono Mack, the sponsor of H.R. 1319, the CCIA (Computer & Communication Industry Association), the NetCoalition, TechAmerica and the Internet Commerce Coalition stated:

“As currently drafted, however, H.R. 1319 would broadly apply to many different applications and Web sites that appear to be beyond the intended scope of the bill.

(more…)

The recent McKinsey report “Clearing the air on cloud computing” has caused quite a bit of stir within the cloud community, and I can see why. While it definitely brings a good deal of analysis to the table, I feel it is somewhat generalized, makes assumptions and does overlook some key points.

First and foremost, this article is NOT going to be an analytical discussion of the cost of running or setting up a datacenter vs. an Amazon EC2 Windows instance. I’m not a financial analyst. Honestly, calculating the Total Cost of Assets (TCA) or Total Cost of Operations (TCO) causes my eyes to roll back into my head leaving me gasping for air. Don’t get me wrong, it seems like some good effort was made analyzing data and formulating conclusions. The problem is, I feel that they were on a jetliner, shooting through the clouds with the shades 1/2 down.

Before I start with my own analysis and commentary, I would like to reference a few responses I have read that somewhat chastise McKinsey.

Three “Rebuttal” Articles to Read

The first comes from CIO IT Drilldown’s Virtualization site. In his article “McKinsey Cloud Computing Report Conclusions Don’t Add Up,” Bernard Golden does the major lifting for me in terms of analysis. I have highlighted some key points from the article that I viewed to be particularly important (my highlighted version of the article is here). I particularly enjoyed Golden’s rebuttal to the analysis of cost calculations, namely use of EC2 Windows instances, headcounts that don’t add up and other “less visible” capital expenses for facilities and other assets. Also as Golden points out, McKinsey proposes that better efficiencies and savings can be realized through virtualization within the organization. To me, the McKinsey recommendation seems a bit counter-intuitive: “Don’t go with a vendor whose expertise IS virtualization, hardware, infrastructure, et al. Instead, DO try to do it yourself, with tremendous CapEx & OpEx expense.” Hmmm, makes sense to me, NOT! Lastly, I particularly liked Golden’s 3 recommendations (quoted from article):

1. Review your portfolio of applications to understand what cloud computing means to you.
2. Create a viable financial model for assessing the true costs of internal hosting.
3. Evaluate the potential for an internal cloud even if the numbers don’t work with an external cloud provider.

(more…)

Over the past year, I have written about the various primal layers of Cloud Computing. Typically, my role is to “over simplify” in order to make the Cloud a bit more palpable by “the masses.” My colleague, Randy Bias, is the resident über-tech, so I usually leave the more complicated developer and sys-admin posts to him. As we all know, the Cloud is hot and becoming increasingly complicated as new products, services and vendors throw their hats into the ring. But is this over-complication confusing and saturating the market? I think not, in terms of the latter, but it is truly becoming more confusing.

First, we at GoGrid, broadly define Cloud Computing as such (latest definition):

On-demand self-service Internet infrastructure where you pay-as-you-go and use-only what you need, all managed by a browser, application or API.

Even that definition I feel is a bit skewed toward Infrastructure. Probably more aptly defined, it would be:

On-demand, self-service Applications, Platforms, Services or Infrastructure dynamically consumed on a pay-as-you-go basis using a browser, application or API.

(more…)

This morning we announced that Appistry EAF Community Edition has been released within the GoGrid cloudcenter infrastructure. The press release can be viewed here. Full contents of the release are below.

Appistry and GoGrid Announce Commercial Availability of Joint Cloud Computing Solution for Delivering Highly Scalable and Reliable Server Applications

Cloud Computing Infrastructure provider GoGrid and Cloud Application Platform provider Appistry announce the release of Appistry EAF Community Edition within the GoGrid cloudcenter.

San Francisco, CA February 26, 2009 — GoGrid, the Cloud Computing division of ServePath, LLC and Appistry today released new tools for developers, architects and administrators designed to ease the pain associated with developing, deploying and managing applications in the Cloud. Appistry’s Cloud application platform, named Appistry EAF, helps businesses and enterprises efficiently manage and scale their applications within the GoGrid infrastructure. With this joint solution, larger companies are able to take full advantage of the Cloud’s unique value proposition of elastic scalability, solid reliability, automated management and CapEx economies.

Appistry EAF Community Edition 3.9 is now available for Red Hat Enterprise Linux 5.1 users. Additional EAF-enabled GoGrid images will be rolling out in the near future. Appistry EAF Community Edition allows developers, system architects and administrators to take advantage of Appistry’s Cloud application platform for free on up to five GoGrid Cloud Server instances. Appistry EAF functionality and benefits include:

• Transparent and instant linear scalability
• Application-level fault tolerance
• Broad support for Cloud-enabling software components
• Adaptive, software-based load balancing
• Fully-distributed, fault tolerant memory cache for objects and data
• Fine-grained, hierarchical security model
• Efficiencies in CapEx and administrator time
• Ease of use

(more…)

By now, many in the Cloud Computing space have heard about (or even read) the University of California Electrical Engineering & Computer Science’s (EECS) study on Cloud Computing titled: “Above the Clouds: A Berkeley View of Cloud Computing.” Published on February 10th, 2009, the EECS’s paper provides a seemingly academic study of the Cloud Computing movement, attempts to explain what Cloud Computing is all about, and identifies potential opportunities as well as challenges present within the market.

The 20+ page study is authored by Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy H. Katz, Andrew Konwinski, Gunho Lee, David A. Patterson, Ariel Rabkin, Ion Stoica and Matei Zaharia who all work in RAD Lab. (Interestingly, several of the companies mentioned within the study are also Founding Sponsors and/or affiliate members: Sun, Google, Microsoft, Amazon Web Services, etc.).

There has already been plenty of discussion and analysis of this study (by James Urquhart, Krishna Sankar and has even appeared on Slashdot.org). Needless to say, I felt compelled to get my two cents in, especially from the perspective of a Cloud Computing Infrastructure vendor.

From an academic standpoint, this document definitely has some legs. It is complete with carefully thought out scenarios, examples and even formulae, as well as graphs and tables. Some of the points that are brought up even got me scratching my head (e.g., using flash memory to help by “adding another relatively fast layer to the classic memory hierarchy”). Even the case analysis of a DDoS attack from a cost perspective of those initiating an attack to those warding off an attack on a Cloud was interesting to ponder. I commend these group of authors on undertaking such a grand task of not only writing by committee but also overlaying a very business school vs. mathematics and computer sciences approach to the writing and analysis.

Unfortunately, however, as I read through the document, I started scrawling madly in the margins with commentary that is somewhat contrary to what was written within the study.

(more…)

This insightful post on the RightScale blog recently got me thinking. The term “Cloud Computing” is much too vague. People want and need “slots” or “segments” where they can group things. This is how the mind operates through categorization and ordering. So, to possibly help with this, I would like to propose a “Cloud Pyramid” to help differentiate the various Cloud offerings out there.

There are other ways to display this hierarchy, however I elected to show it as a pyramid. For example, if one were to weight the graphic by the number of providers within each segment, the pyramid would be upside-down. The point here though is to show how these cloud segments build upon and are somewhat dependent upon each other. While they are directly related, they don’t require interdependence (e.g., a Cloud Application does not necessarily have to be built upon a Cloud Platform or Cloud Infrastructure). I would propose, however, that Cloud trends indicate that they will become more entwined over time.

Cloud Application

Within this part of the pyramid, users are truly restricted to only what the application is and can do. Some of the notable companies here are the public email providers (Gmail, Hotmail, Quicken Online, etc.). Almost any Software as a Service (SaaS) provider can be lumped into this group. Most retail consumers use the services within this Cloud. You get pre-defined functionality and you cannot much further than that. Applications are designed for ease of use and GTD (getting things done). SalesForce, a huge Cloud Application/SaaS provider that has led the way for hosted software, falls into this category as well, however, their force.com product does not. Even online banking offerings could be lumped into this group.

Characteristics:

(more…)