Sunday, July 15, 2007

Classifying the Computing Cloud

Introduction

More and more we see references to the Computing Cloud appear in articles and blogs across the Internet. Just the other day Scientific American wrote and article highlighting the shift away from traditional data centers to the Computing Cloud. You can find that article here.

This article is interesting because it talks about the Black-Box data center strategy being aggressively pursued by Sun Microsystems. In a nutshell these Data centers give organizations the flexibility to place a fully functional Data Center wherever they need it. This flexibility allows companies to realize cost savings by locating their computing power either closer to where it's needed, or in locations with cheaper power costs.


These Black-Box data centers are tremendously powerful and cost effective, but are they part of the Computing Cloud? This begs the question, "What is the Computing Cloud"? How do
OnDemand applications, utilities, data feeds and Black Box data centers all fit under the same definition? Is the term Cloud Computing in danger of becoming overloaded like Enterprise Content Management (ECM). A term so broad as to be unhelpful in helping classify and understand an applications function?

This confusion has led us to attempt to start defining and classifying the broad parameters of the Computing Cloud. This is a work in progress and an exercise in understanding what is, and what isn't in the Computing Cloud.


What is a Cloud Computing Application?

As you look across the spectrum of Cloud, Utility and Grid computing a clear separation in functionality becomes evident. What's more, companies utilize the Cloud for very different purposes.

Some organizations are looking to companies like Google, SalesForce.com and eBay for user level applications; Email, Blogging, Word Processing, Customer Relationship Management (CRM) and the like.


Other companies see value in leveraging infrastructure level components. Offloading storage and computing power into centralized service centers enable them to benefit from the inherent economies of scale in the Computing Cloud. At the same time they can take advantage of best of breed data centers, network management and operational capabilities.


Finally companies look to the Cloud for discreet transactional information and capabilities. Want to know what the temperature is in San Francisco? Just look it up on a Web Service call at XMethods. Trying to calculate the risk associated with the Yen carry trade? Look up the current Yen to Dollar conversion rate at XIgnite.


While these Cloud Computing applications offer very different capabilities, and solve different business solutions, they do share common elements.
  1. Computing Cloud applications are shared between organizations and reside on a common platform.
  2. Computing Cloud applications are accessed remotely across an Internet connection.
  3. Computing Cloud applications are priced using different revenue models than Enterprise and Traditional Software.
There are many other differences between Enterprise/Traditional applications and the Computing Cloud. However the three factors above seem to be common among all the Cloud Computing applications we looked at.

Types of Computing Cloud Applications

Different organizations use the Cloud for different reasons. By compartmentalizing the Cloud we start to understand how and why organizations use it. The natural divisions seem to be; Applications, Infrastructure and Transactions.

Applications encompass all of the services delivered directly to an end user. These are typically web-driven programs that help users with day-to-day business functions. For instance Google Desktop Apps, SalesForce.com, Microsoft Live and Siebel OnDemand CRM are all instances of Cloud computing applications.

Cloud Infrastructure components are services that provide capabilities you would typically associate with physical hardware or application development, specifically storage and computational power. Amazon is a classic example of making infrastructure capabilities available in the Cloud. Their Simple Storage Service, Elastic Compute Cloud and Simple Queue Services are all instances of Infrastructure capabilities. Google's own Data API is also a Cloud Infrastructure component.

SalesForce Apex and Adobe's Apollo application development platforms are another example of Cloud Infrastructure components. Specifically these platforms give developers storage, processing and development capabilities that deploy onto a remote Cloud infrastructure. Developers can create, test and deploy entire applications that run completely within the Cloud Infrastructure which in turn gives companies tremendous flexibility to create value added applications, while significantly lowering the risks and costs associated with large scale Web based deployments.

The rest of the Cloud falls under the Transactional classification. Transactional elements of the Computing Cloud help you perform discreet actions that either retrieve, manipulate or transform data and information. Cloud Transactional capabilities range from the thousands Web Services available from organizations like XMethods and XIgnite to Amazon's Alexa services, encompassing everything from Thumbnail creation to the Webs top sites.

This leaves us with what is not part of the Computing Cloud. I would propose that while Black Box service centers are an attempt to help with some of the same problems that the Computing Cloud solves, it is not by definition part of the Computing Cloud. An organization might use a Black Box service center to deliver a Cloud Computing component but the Black Box itself is not inherently a part of the Cloud. It is just an extension of an existing network.

Additionally not all Web Services are Cloud Computing. At it's core a Web Service is just a way of communicating between two applications. It might be a key mechanism of delivering Cloud Computing capabilities, but is not inherently part of the cloud itself.


Summary

There are real fundamental issues that IT organizations are struggling to solve today. The explosion of information, connectivity and user expectations are rapidly increasing the demands put on MIS departments. Add to this the drive for cost containment present in every modern company and you have a real pain point.

Cloud Computing is beginning to offer viable solutions to these problems. By using Cloud Computing solutions companies can stop spending time on commodity Application, Infrastructure and Transactional capabilities and focus on adding real value and differentiation through their IT departments.

IT departments will use Cloud Computing for three reasons - Cost reduction of commodity application deployments, management of peaks in infrastructure demands and delivering to business segments that demand linear or exponential growth in computing power, storage and delivery.

Through the next two to three years we will see companies begin to experiment with Cloud Computing in test or pilot applications. After that companies will start to adopt Cloud Computing wholeheartedly. However, companies will not abandon their data-centers. Instead Cloud Computing will become an integral part of delivering a companies value, sitting right alongside and integrated directly into their existing network and data center.


Sunday, July 8, 2007

The Big Switch

While doing research today on other blog's and sites talking about the Computing Cloud/Utility Computing I ran across a link to the book "The Big Switch" by Nicholas G. Carr. The topic, covered here, seems to be right on.

Mr. Carr seems to be covering exactly the trend we here at eCloudM are exploring.

I also ran across a great Blog written by James Urquhart covering the topic of Service Level Automation.

Service Level Automation in the Datacenter: Agile Computing Catches Up to the Data Center

There are some interesting correlations between Service Level Automation, Utility Computing and the Computing Cloud.

I wonder if using the Term Service Level Automation (SLA) causes confusion when presenting the ideas and topics into the business community. I have most often seen SLA refer to Service Level Agreements. While similar in concept, they are very different in implementation.

Tuesday, July 3, 2007

eCloudM the beginning

In mid-2006 I was starting to get that entrepreneurial feeling again. One year earlier, in August of 2005, we had completed the sale of the company I helped to found. All the way through the summer of 2006 there was tremendous focus on integrating our product lines. However that effort was coming to an end and I was starting to wonder about what was next.

About that time Mike Hill and I were re-introduced by a mutual friend, our lawyer David Steigerwald. Mike Hill had recently left the COO position at XAware, an XML Integration company he helped start. During some initial meetings Mike and I realized that we both had a passion for technology, entrepreneurship and good Irish beer.

We both knew that we wanted to start another company sometime in the future. Mike had done two successful startups and I had done one and been involved in another. That said we also knew that we did not want to do another startup similar to our previous companies. We started the process of figuring out where to look by creating a list of what we didn't want to do.
  • We had no interested in trying to sell complex and expensive software to enterprises.
  • Trying to create another Open Source version of a successful software product and charging some combination of service and support fees did not seem like our bag of tea.
  • If possible we wanted to avoid the typical software company path of Idea --> Seed Capital --> Angel Investors --> Venture Round 1 --> Venture Round 2 --> Debt Financing --> Merger --> IPO/Out of business/Sell out.
We also had a few ideas that we did want to do.
  • Explore the feeling that something, we were not sure exactly what, but something was happening out there on the Internet that seemed ... different.
  • Get a better feel for how low the barriers to entry for software products was becoming due to technologies like AJAX, GWT, Web Services, OnDemand software, and better development paradigms.
  • Work with new media technologies like Blogs, Online Advertising and Community Networks to gain a better understanding of what it takes to build value in today's Internet.
  • Figure out if it was feasible to create a relatively virtual organization using the mushrooming set of online communication applications like Skype, Google Talk, GMail and Google Desktop Apps.
It ended up that the exploration and discussion around exactly these topics led us to that "something different" we thought was happening on the Internet. Our discussions generated a few conclusions.
  • The barriers to entry in the Enterprise Software space were becoming gigantic. The up-front capital needed to start a company and compete against established vendors was moving upwards of the $50M mark.
  • The ability to create good Internet software was becoming incredibly easy
  • Much of the software market was becoming commoditized. The availability of cheap debt was financing a huge M&A spree, consolidating the Enterprise Software market down to a few Tier 1 players, and a slightly larger set of Tier 2 organizations.
  • Companies like Google, eBay, Amazon and Yahoo were bringing an incredible array of platform capabilities into the On-Demand/Software as a Service (SaaS) space at very low price points (typically free).
All of this discussion and talk made us realize that the "something big" we were sensing was nothing other than the shift away from Enterprise Software products toward the adoption of On-Demand applications and community focused software. The term we found to describe this new computing platform was the Internet Cloud.

We had found what we were looking for, that shift in the status quo that destroys existing business plans and creates new opportunities. The next question was obviously "what do we do about it".