Recently in Cloud Database Category

As the industry announcements on Cloud Storage APIs keep coming, the confusion surrounding what they mean keeps growing.

We have the Amazon S3 APIs, Eucalyptus APIs, Rackspace Cloud Files APIs, Mezeo APIs, Nivanix APIs, Simple Cloud API, along with the standards proposed by the Storage Networking Industry Association (SNIA) Cloud Storage Technical Work Group, and more. 

So what should you do or think about all this? What impact do these Cloud Storage APIs have on your decision-making? Just how important are they, and what's next?

Here's some information to aid your understanding of this emerging and important technology.  Let's begin by answering two basic questions: 

What is a Cloud Storage Application Programming Interface (API)?
    
A Cloud Storage Application Programming Interface (API) a method for access to and utilization of a cloud storage system.  The most common of these are REST (REpresentational State Transfer) although there are others, which are based on SOAP (Simple Object Access Protocol).  All of these are associated with establishing requests for service via the Internet. 

What is REST? 
REST is a concept introduced in the doctoral dissertation of Roy Fielding, and is widely recognized as an approach to "quality" scalable API design.  The actual API design and capabilities are very dependent on the actual capabilities of the underlying Cloud Storage System

One of the most important REST capabilities is that it is a "stateless" architecture.  This means that everything needed to complete the request to the storage cloud is contained in the request, so that a session between the requestor and the storage cloud is not required.  Why is this important?  The Internet is highly latent (it has an unpredictable response time and it is generally not particularly fast (when compared to a local area network (lan)).  Once you get a request, there is no guarantee that you can ask a "qualifying question" of the requestor in a reasonable time period.  So, REST is an approach that has very high affinity to the way the Internet works.  Traditional file storage access methods that use NFS (network files system) or CIFS (Common Internet File System) do not work over the Internet, because of latency.

One other thing we should clear up:  Cloud Storage is for files, which some refer to as objects, and others call unstructured data.  Think about the "files" stored on your PC, like pictures, spreadsheets and documents.  These have an extraordinary variability, thus "unstructured".  The other kind of data is "block" or "structured" data.  Think data base data, data that feeds transactional system that require a certain "guaranteed" or low-latency performance.  Cloud Storage is not for this use case.  IDC estimates that approximately 70% of the machine stored data in the world is unstructured, and this is also the fastest growing data type.

So, Cloud Storage is storage for files that is easily accessed via the Internet.  This does not mean you cannot access Cloud Storage on a private network or LAN, which may also provide access to a storage cloud by other approaches, like NFS or CIFS.  It does mean that the primary and preferred access is by a REST API.  (Here are other terms you will see, RESTful, or RESTlike or RESTstyle, which is geekspeak for how closely the API conforms to the REST approach.) 

Today, there are multiple definitions for Cloud Storage, and the one I prefer is "File Storage accessed through Web Services API's over a network".  This represents the key attributes of file storage that is cloud storage, versus other types of file storage.  Other key qualities of a storage cloud are:

• multi-tenant support (use by more than one unrelated user)
• geo location and geo replication, seamless and real time provisioning of accounts
• seamless and real time provisioning of accounts
  
• availability of "practically" unlimited amounts of storage "on-demand"
• "pay for use", which means that your payment is for actual storage used, over some time frame, usually a month. 
  

There are many who are still arguing about what I have defined above, but what I've said is generally accepted by the industry.  If it is a vendor doing the arguing I would suggest you check under their hood, usually you will find that they do not offer whichever of the above features they are trying to argue out of the definition.

Also, traditional storage vendors continue to proclaim the importance of local network access (like NFS, CIFS or ISCSI) for the purpose of Cloud Storage access by applications that today can only access via the older protocols.   This requires that the application making the request be on the same local network (think same data center) as the storage cloud.  Their reason for this view is that they are only just beginning to see application demand for storage cloud access via REST APIs, versus their traditional business model which serves an enterprise user with their own data center. 

This is why Cloud Storage has generally emerged as a service offering in the IT Service Provider  (also know as the WEB Hosting Industry) space first.  In this space, there is no doubting the importance and future of REST API access to storage clouds, it is only viewed as an adoption speed issue.  Note that within the data center, access to storage using an HTTP based protocol is not necessarily any slower than one of the more traditional protocols. API access has been labeled as being a slower form of access over NFS and CIFS. This view is largely due to the fact that it "may" be accessed over the Internet. In most cases, it is the network that adds the latency, not the means of access. Make no mistake, traditional storage vendors see this coming, and they will make offerings available in the near future.

REST APIs are language neutral and therefore can be leveraged, very easily, by developers using any development language they choose. Resources within the system may be acted on through a URL. So, an API is not a "programming language" it is the way a programming language is used to access a storage cloud.  This is part of the basic understanding of APIs that is required to discuss the dreaded "vendor lock in" and upcoming "cloud lock in" discussions and understand the issues that surround these assertions.

REST APIs are also about changing the state of resource through representations of those resources. They are not about calling web service methods in a functional sense. The key differences between different Cloud Storage APIs are the URLs defining the resources and the format of the representations.
 
The Cloud Storage space is very young and everyone has their opinions on how things should be represented and accessed. Efforts are underway by organizations like SNIA, with their Cloud Data Management Interface (CDMI), to standardize both the resource structure and the representations. However, standards are not developed overnight and customers are demanding programmatic access to Cloud Storage now.

Current Cloud Storage vendors have produced a basic set of APIs that are accomplishing fairly similar things, and other APIs that expose the underlying unique functionality of the Cloud Storage platform supplying the storage cloud.  You should expect that, over time, most storage clouds will provide the basic functions in somewhat similar ways, and further that additional advanced functions will be adopted and expected to be in every storage cloud offering. 

Finally, you should look for a taxonomy of APIs, that includes basic file functions, advanced functions, Provisioning APIs, Billing APIs, and Management APIs.  Storage clouds that become successful will offer all these capabilities, to increase the efficiency of their use.



 
Several efforts have been made to simplify the transition between vendors by providing an abstraction layer on top of the vendor's APIs. In this approach, a program library is created, for use in the application that needs cloud storage access, and this API translates (for the given program language) a single API into the API that is specific to a Cloud Storage offering.  So, the application, which is using this library, writes their APIs once, and achieves portability between storage clouds that are supported by this approach.

This approach has been largely programming language specific and may take advantage of the language it was designed for. Good examples of this are jClouds, an open source cloud storage abstraction library written in Java, and Simple Cloud API, a collaboration of vendors including Microsoft, Rackspace, Nirvanix, IBM and Zend which provides a simplified Cloud Storage interface for PHP developers. While extremely useful for developers, these abstractions tend to expose the lowest common denominator relating to Cloud Storage functionality and may omit critical features, for example only providing namespace object access as opposed to ID access.

So, let's discuss lock-in, the term used to express concern that once a vendor has gotten you to exploit their architecture and technology, they will recognize that you are committed to them and cannot easily move away.  As a result, they will then raise their prices and take advantage of your lock in status, keeping their price just below the amount that would encourage conversion away from their technology and towards a more "open" set of capabilities.  Let's look at all the "dreaded" examples that have been surfaced around cloud storage and as a reason to slow it's adoption:

1.    API lock in, which means your interaction with a storage cloud uses the APIs of that storage cloud, and suggests that you cannot easily move to another providers cloud with their own, different APIs.

2.    Vendor lock in, which means that since you are condemned because of your application development activity with specific APIs to use only a cloud from a specific supplier.

3.    Device lock in, meaning that you developed a cloud storage based program utilizing the APIs of that specific cloud, for a specific device (generally a PDA) that has specific functionality.  This is double lock in, both the device programming methodology and the API selection.

4.    Browser lock in, meaning that programming to specific APIs can also be rendered unique based on the Web browser that is selected.

5.    Programming language lock in, which means that you have written the APIs in a language like Python, or JAVA, or .NET, or whatever.

6.    API wrapper lock in, which means that you incorporated libraries into your application that allows your application to write generic APIs, which are then translated by these APIs to the correct API for the desired storage cloud (this is what Simple Cloud API is).

So, as you can see here, utilizing cloud storage could ultimately have you locked in on at least six levels! 

With this much opportunity for vendor abuse, why are developers rushing to write Web based applications that utilize cloud storage services via API access?  Are they simply uncontrolled, unthinking rebels who will shortly learn the error of their ways?  Have they made a fatal error?  Or do they know something you don't?

First, learn about Cloud Storage APIs.  What they do is make storage programmable, and they abstract storage from the application.  They offer advanced functionality (the programmable word) that makes it faster and easier to write the applications that are scalable versus the traditional storage access approaches.  When you add these two capabilities to the storage cloud offering of low cost, availability in multiple locations, seamless provisioning, ease of adding additional storage, and the pay for use model, the case for the cloud has become compelling.

Where are we seeing early adoption:  at service providers, because they host Web based applications and SaaS (usually Web based) applications, and this is where the developers who recognize the opportunity are focused. 

What is coming: the introduction of this technology into the enterprise, complete with the adoption of the RESTful API technology.  This will ultimately lead to a level of cooperation between service providers and the enterprise that has long been predicted.  Enterprises will move to an IT modeled on an OPEX model, and expect their applications to be provisioned and interacting with service provider clouds, via APIs.  IT Service Providers are racing to build the clouds to provide for this emerging business opportunity.

So, what about the lock in mentioned above.  Sit down with your developer, they will show you why they don't feel "locked in".  They will show you that you can quickly recraft your current APIs, in the programming language of your choice, to utilize the new APIs of the desired cloud.  For this reason, Simple Cloud API will likely be a short term measure, which precedes base case APIs that are extremely similar, and goes through a market led process to identify "best practice" APIs for both base case and advanced function, as well as all the other API led capabilities as mentioned above.  In short, vendor lock in is not the problem for this technology that it has been for others.  Also, the ingenuity and resourcefulness of all the suppliers, standards groups, and market adoption scenarios will continue to mute your ability to be lock in free. 

Your real challenge is not lock -in, but rather how to adopt this new set of capabilities, and solve problems and create opportunities with your IT solutions as rapidly as possible.  Standing on the sidelines waiting for this one to resolve will keep you out of a great opportunity, because we still have several meaningful years of rapid change associated with this technology adoption cycle. 

One of the interesting side effects of the rapid adoption of Cloud Computing by the enterprise is the impact this adoption will have on the design and delivery of IT service processes.

In his article Assessing cloud providers, Frank Ohlhorst reminds us that "moving to the cloud is primarily a business decision" dependent on the metrics of ROI (Return On Investment), performance, sustainability and suitability to task.

Managers, writes Ohlhorst, must be prepared to do the following:

- audit the target applications and business processes impacted to create a cost-benefit-risk analysis that compares a traditional client/server solution to a cloud-based solution.
- audit the cloud services provider, including an assessment of geographic redundancy, packet transport performance, latency and service guarantees.
- audit the business's own ISPs, including performance at connecting points, failover capabilities and guaranteed throughput rates to and from the cloud services provider.
- monitor and frequently evaluate service and performance elements.

Thus, Ohlhorst tells us, "one of the first steps for choosing a cloud service provider is to evaluate the level of service offered and the guarantees behind that service." His view is that the Service Level Agreements (SLAs) must be scrutinized under three specific lenses: data protection, continuity and costs.

While this is a traditional IT view, and seems quite logical, we disagree with his suggestion that IT Managers can turn to the Keynote Internet Testing Environment (KITE) and Internet Health Report to measure performance.

Why? Because these are uptime measures, not measures of service performance.

If you're familiar with ITIL V.3, you'll recognize this service model overview:



In the ITIL world, service management can be broken into the following components:

- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement

Traditional IT systems management thinking leads us to associate systems availability with service availability, so that if a network component is running normally, we assume that the services running across that network component are also running normally.

This is largely the view being taken by the traditional systems management companies. It is what we are seeing in announcements like this one from BMC Software and Amazon.com.

But the cloud service model is different, and - while it's great to see BMC extending its enterprise systems management platforms to incorporate Cloud infrastructure - Cloud computing brings about a different measure for service performance, best exemplified by a new breed of cloud computing management vendors like Nimsoft. Their view is as follows:

The "pay-as-you-go" nature of cloud computing breaks the link between component and service performance: typically, organizations pay for capacity or throughput, rather than specific components. Plus, the highly dynamic nature of the computing infrastructure that exists in the cloud makes traditional CMDB (or simple list) based systems management virtually impossible to implement. All the traditional server and network reporting that shows 99.999 up-time will become secondary and probably irrelevant for future service level management and reporting. What this means is that synthetic transaction monitoring--that is, generating, monitoring, and reporting on simulated service requests--will be of paramount importance.

This perspective puts an interesting twist on ITIL's IT Service Management model. Since there is no way to predict which cloud computing infrastructure components are accessible at any point in time, service delivery processes in the enterprise - and SLAs from cloud computing service providers - need to be all about service reliability rather than component reliability.  This is a paradigm shift. 

As we have written previously, cloud computing is unleashing the potential of SOA (Service Oriented Architecture) applications.  In a world of SOA applications running on Cloud infrastructure, the concepts of IT service delivery in the enterprise and SLAs from service providers will rest upon services and processes that can run on any infrastructure components within the cloud.  The notion of using discrete infrastructure components as the basis for measuring service quality goes away.  This is the philosophy of the new breed of cloud systems management providers: the focus of availability and performance measurement moves toward measuring the user experience.

And, as this transition comes about, what happens to CMDB-based systems management? How do we think about the CMDB when the management of these infrastructure parts is abstracted even further away from application peformance?  Does anyone see a new "cloud edition" of ITIL service delivery on the horizon?

Once again, there is an opportunity here for service providers to seize the initiative.

With the Sun acquisition, Larry "what's a cloud?" Ellison has once again changed the game. Here are a few key points to think about:

1) Oracle becomes the end-to-end IT enabler - from apps to disks; that's the party line.

2) Oracle begins the journey to the Cloud, and begins to develop the end-to-end Enterprise Cloud experience.

3) Oracle embraces the open source movement by attacking  Microsoft with MySQL.

4) Oracle's gain is clearly SAP's loss. Exadata + Sun = the new business intelligence?

5) Oracle owns Java, period. Ellison described Java as "the single most important software asset we have ever acquired." BONUS: they get the JMX API thrown in with the deal, which allows them to monitor all manner of resources.

6) Oracle delivers Peoplesoft-as-a-Service or Seibel-as-a-Service with credibility. Maybe they won't buy Salesforce.

7) Oracle pushes Open Office as a cloud offering to further disrupt Microsoft.

8) Oracle makes Sun hardware profitable.

9) One stop shopping for all your IT, from Cloud to your own data center - is where we are headed. The period of détente is over - Cisco, HP, IBM, and Oracle are racing to go to end-to-end environments, which HP and IBM have proven as a viable business model. What happens to Dell?

While the rumors fly all over the cloudsphere, what's important in the days ahead is how Oracle chooses to embrace the cloud - will it be an open or closed embrace?

With IBM, we all knew it would have been an open cloud, with Oracle the story is not so clear at all.  The silence on Jonathan's blog is deafening.

And for those of us who said that Ellison was kidding about the cloud, let's remember who said "the network is the computer!"  Today's netbooks are cloud devices.

My prediction: Oracle becomes one of the "Big Four" for the Enterprise, and quickly changes it's tune on the Cloud.

What's next? Anybody think Microsoft/Dell is an interesting combination? 

In his introductory post, Steve mentioned that when we were at VeriCenter we became aware of a new sort of challenge facing our industry - from outside entrants like Amazon.com who were beginning to grow their cloud storage and cloud computing businesses, leveraging internal web-based infrastructure. We knew then that cloud storage, as a significant part of an overall cloud computing strategy, was going to change our business and yes, our entire industry. Now we see new entrants like Google and Microsoft, as well as veterans like IBM and Sun, EMC, and Cisco are all delivering cloud-based offerings that are redefining the hosting and SaaS markets.

So here’s the question we’re asking: how will cloud computing disrupt your business model?

To answer this question, we start by defining a basic yet useful framework for understanding business models; this framework applies to businesses of all types and is adapted from Wikipedia:

Let’s look at the nine components of the business model framework, and describe each one briefly.

Infrastructure

• Core Capabilities: The capabilities and competencies necessary to execute a company’s business model. These include your key people, processes and technologies.
  
• Partner Ecosystem: The business alliances which complement your capabilities.
  
• Key Processes: The key activities (sometimes proprietary) which create the product or service you offer.
  

Offering

• Value Proposition: The compelling benefits your customers receive from buying your products and services.
  

Customers

• Customer Segments: The target audience for your products and services.
• Distribution Channel: The means by which a company delivers products and services to customers. This includes the company’s marketing and distribution strategy, and may involve a chain of intermediaries, each passing the product down the chain to the next organization, before it finally reaches the consumer or end-user.
• Customer Relationship: The links a company establishes between itself and its different customer segments.
  

Finances

• Cost Structure: The nature of the expenditures required to run your business, particularly considering whether costs are fixed or variable in nature, and whether they are capital of operating expenses.
  
• Revenue: The way a company receives payment from customers.
  
• Profit: The degree to which your revenue exceeds your costs, of course!
  

 It seems like there is a lot of concern over the Open Cloud Manifesto. Some people are up in arms over the way things are being handled. Apparently, a number of people have offered up their time (and willingness to fly to NY) to help with this meeting and been flatly denied any possibility of a voice. One of the former "instigators" of the Cloud Computing Interoperability Forum  (CCIF) has been temporarily banned (whatever that means) and has taken a pretty hard stance against the way things have been handled. Rueven also made a statement today with a bit of an apology.

The much-heralded "Open Cloud Manifesto" produced by the CCIF is nothing more than a few pages stating the obvious.  

Sometimes, and this is one of those times, the obvious does need to be stated. 

The manifesto is "intended to initiate a conversation that will bring together the emerging cloud computing community (both cloud users and cloud providers) around a core set of principles."

Although Microsoft's Steven Martin is right to protest that the process was not open enough, it should be noted that Microsoft will join the the group on Monday and participate in future discussions.

Amazon has decided it won't play for now.  We've alluded to the rivalry between Microsoft and IBM/Sun earlier on this blog, but now it seems like Amazon is taking umbrage as well.

It seems as though the process was not open enough, or inclusive enough (which is the one thing I am sure of at this point) which gives rise to the suspicion that the manifesto is driven by self interest of a few rather than the needs of the many.

Let's look at the core set of principles set forth in the manifesto:

1. Cloud providers must work together to ensure that the challenges to cloud adoption (security, integration, portability, interoperability, governance/management, metering/monitoring) are addressed through open collaboration and the appropriate use of standards.

2. Cloud providers must not use their market position to lock customers into their particular platforms and limiting their choice of providers.

3. Cloud providers must use and adopt existing standards wherever appropriate. The IT industry has invested heavily in existing standards and standards organizations; there is no need to duplicate or reinvent them.

4. When new standards (or adjustments to existing standards) are needed, we must be judicious and pragmatic to avoid creating too many standards. We must ensure that standards promote innovation and do not inhibit it.

5. Any community effort around the open cloud should be driven by customer needs, not merely the technical needs of cloud providers, and should be tested or verified against real customer requirements.

6. Cloud computing standards organizations, advocacy groups, and communities should work together and stay coordinated, making sure that efforts do not conflict or overlap.

Nothing controversial here, except for IBM's fingerprints on this site.

Earlier on this blog I wrote:  Cloud Storage, like any other emerging technology, is experiencing growing pains. It is immature, it is fragmented and it lacks standardization. Vendors are promoting their particular technology as the emerging standard. While a standard doesn't exist yet, we are confident that one will emerge soon. We believe that a set of Web Services API based capabilities, accessed via non persistent connections on public and/or private networks, provides the fundamental frame of reference and definition for cloud storage.  The definition allows for both public service offerings and private (or enterprise) use, and provides a basis for expansion of solutions and offerings, versus a limitation.

Hopefully all of this back and forth will ultimately focus on more important topics, and we will make some progress.  We are committed to two things, giving realistic input to promote standards which drive cloud adoption, and implementing these standards once they are agreed on.  It will be far more productive to focus on these issues versus the intrigue and "spy versus spy" comedy that the current "Manifesto" launch is promoting. 

If I could offer one complaint, it is this:  if you want to achieve a standards-based approach, make it technical and philosophical if you like, but most of all, make it open and inclusive.

The trust issue will not go away.

In a bit of a publicity stunt, the Electronic Privacy Information Center asked the Federal Trade Commission to investigate Google's Cloud Computing Services, specifically concerning:

a. the adequacy of Google's privacy and security safeguards regarding storage of personal information on its Cloud Computing Services; and
b. the sufficiency of Google's privacy and security safeguards in light of the company's assurances to consumers regarding its Cloud Computing Services.

The official document filed with the F.T.C. states:

This complaint concerns privacy and security risks associated with the provision of "Cloud Computing Services" by Google, Inc. to American consumers, businesses, and federal agencies of the United States government. Recent reports indicate that Google does not adequately safeguard the confidential information that it obtains. Given the previous opinions of the Federal Trade Commission regarding the obligation of service providers to ensure security, EPIC hereby petitions the Federal Trade Commission to open an investigation into Google's Cloud Computing Services, to determine the adequacy of the privacy and security safeguards, to assess the representations made by the firm regarding these services, to determine whether the firm has engaged in unfair and/or deceptive trade practices, and to take any such measures as are necessary, including to enjoin Google from offering such services until safeguards are verifiably established. Such action by the Commission is necessary to ensure the safety and security of information submitted to Google by American consumers, American businesses, and American federal agencies.

P.R. stunts aside, where do we go from here?

Clearly, encryption, effective data anonymization, and mobile location privacy are "must-haves" in the cloud.  Hosting providers who deal with this issue will keep their customers' trust. And as I mentioned earlier, part of being a trusted service provider includes a commitment to how you will serve the customer, and positioning your business for success in your offerings.  It means a robust offering, with appropriate availability, backup, and of course, security.

Coming on the heels of the Cisco-BMC announcement, the news of an IBM/Sun merger and the simultaneous announcement of Sun’s Open Cloud Platform are not mutually exclusive events.  They’re all part of the ongoing race to capture the Enterprise Cloud. The elephants are dancing.  

The announcement continues the pattern of rapid marketplace adoption of Cloud Computing in general and that includes Web services API based storage access that began with Amazon and continued with Rackspace.  This space is really heating up.  More and more players are stepping up to challenge Amazon.

This tells us that IT hosting providers are running to get in the cloud storage and cloud computing game sooner rather than later. Having come from that space, I can tell you that this issue is top of mind in the hosting space. Amazon, Google, Microsoft and now Sun want to be the cloud for every customer. 

The hosting industry is ideally positioned to deliver cloud computing and cloud storage solutions to their existing and future customers.  Cloud Computing (see previous post on Cisco and BMC) is a service offering for which both hardware and software technology is rapidly developing.  Management tools are also coming online from many vendors.  The ability for the IT hosting industry to effectively compete will quickly be enabled by a new market segment, “Cloud Infrastructure Providers”.  When you combine the availability of solutions with the effective service oriented relationships that IT hosters have enjoyed with their customers, a significant opportunity is emerging.

The first act in Cloud Computing is underway.  Another character has entered the stage and received a round of applause.  They lend additional credence, and a call for more standardization, and less vendor lock in.  The key to the cloud will be ease of use, reliability, security, and of course, cost. 

With so much negative news on business and our economy, I find that Cloud Computing, and its new technologies and opportunities are very exciting.  This is how it has always felt in our industry, which we can change for the better, innovate like no one else, and create significant businesses and new opportunities.

Let’s dig a little deeper into the real story here: Sun’s open source vision and stated commitment to interoperability and its extension into Cloud Computing:

Ideally, users of cloud computing would be able to move their applications among a variety of standardized providers who offer open-source interfaces to common services. Today, most clouds are proprietary, and even where the components offered are open source, cloud operators cultivate significant lock-in through their underlying services, such as storage and databases.

Jonathan Schwartz explains on his blog:

This morning, Dave Douglas, the SVP of our Cloud Computing business, announced we’re building the Sun Cloud, atop open source platforms - from ZFS and Crossbow, to MySQL and Glassfish. With more than 4,000 developers hard at work on these enabling elements, and a twenty year history of network scale software innovation, we’re very comfortable with our technology lead. By building on open source, we’re also able to radically reduce our costs by avoiding proprietary storage and networking products.

Second, we announced the API’s and file formats for Sun’s Cloud will all be open, delivered under a Creative Commons License. That means developers can freely stitch our and their cloud services into mass market products, without fear of lock-in or litigation from the emerging proprietary cloud vendors.

Third, unlike our peers, we also announced our cloud will be available for deployment behind corporate firewalls - that we’ll commercialize our public cloud by instantiating it in private datacenters for those customers who can’t, due to regulation, security or business constraints, use a public cloud. We recognize that workloads subject to fiduciary duty or regulatory scrutiny won’t move to public clouds - if you can’t move to the cloud, we’ll move the cloud to you.

So where does IBM come in? 

If you read about Schwartz’s three strategic imperatives, you learn they are as follows:

1. Technology Adoption
2. Commercial Innovation
3. Efficiently Connecting 1. and 2.

Notice too, that Schwartz is brutally honest about Sun’s challenges with imperative #3:

With Sun’s current products, we could be selling to twice the number of customers we currently serve - our products appeal to an audience far greater than our customer base. But we’re limited by our size - our sales and partner force has a tenth the resources of our biggest peers.

So let’s review, Sun’s doing well on 1. and 2. with widespread adoption of “free” products like MySQL and Open Solaris, but lacks the sales and service firepower to execute on 3..

Did anyone say “IBM Global Services”?

And now, with the Cloud being touted as the future of IT, we see why a merger between IBM and Sun becomes a value creating proposition for both concerns.  Sun becomes the “low-cost” open-source provider, while IBM gets to feed its highly profitable (and nowadays hungry) professional services division.

Which leaves Microsoft’s Azure out in the cold. Small wonder that Bill Gates used to say that IBM, not Google, was Microsoft’s real competitor.

On a more technical level, the rationale behind this merger can be seen more clearly if you take a look at Troy Angrignon’s wonderful Cloud Computing Ecosystem Map v1.0. Scroll down and zoom into the map; the merger seems to make more sense at this level. When you combine IBM and Sun, the resulting “tessellation” of competencies is very impressive.

For more on this story, take a look at these columns by James Urquhart, Reuven Cohen, and Matt Asay.

As an end note, I’d like to state that this merger does not mean the race is over.

Far from it.

What we’re seeing is a new strategy developing across the IT industry. Hosting  companies, MSPs, and SaaS providers will still have to provide clouds of their own to compete against Amazon, Microsoft and Google. There has always been room for a number of providers for hardware, software and services, competing on price, value, and support. No one player need dominate the cloud computing space. Choice and competition always drives value and innovation.

And that’s where we’d like to help.