For me, in the context of this blog, the explosion of the cloud into mainstream information technology has been undeniably exciting and overwhelming. In the last several weeks, we have seen key announcements and rumors revealing the goals and aspirations of current cloud superstars, as well as the well executed introduction of a new major player. As the dust settles from this frenzy, it becomes clear that the near term cloud mindshare will be dominated by four major players.
(There are, of course, many smaller companies addressing various aspects of cloud computing, and at times competing directly against one or more of these four. However, these are the one's that have the most mindshare right now, and are backed by some of the most trusted names in web and enterprise computing.)
Below is a table that lists these key players, and compares their offerings from the perspective of four core defining aspects of clouds. As this is a comparison of apples to oranges to grapefruit to perhaps pastrami, it is not meant to be a ranking of the participants, nor a judgement of when to choose one over the other. Instead, what I hope to do here is to give a working sysadmin's glimpse into what these four clouds are about, and why they are each unique approaches to enterprise cloud computing in their own right. Details about each comment can be found in the text below the table.
Without further ado:
| Provider | "On-Premises" Option | Development Technology | Portability | Reliability |
| Amazon AWS | Bring Your Own | Whatever you can get to run in an AMI | Code is easy to move. The rest...? | Reliability by Spreading The Wealth |
| Google App Engine | Sure...for your dev environment | * Hip coders love Python, right? | Are you kidding? | Trust the Magic |
| Microsoft Azure | Absolutely! The future is hybrid. | * If you love MSFT, you already know it. (.NET) | You mean between Microsoft products, right? | Promises, promises |
| Salesforce.com (force.com) | Absolutely not! The future is pure cloud | It's new, it's improved, it's APEX! | Heh. That's funny... | We Got Magic, Too. |
Amazon AWS
- Amazon does not now provide, nor do they show any interest in the the future of providing, an "on-premises" option for their cloud. However, the EUCALYPTUS research project is an example of an open source private cloud being built to Amazon's API specifications for EC2 and S3. Whether this will ever see commercial success (or support from Amazon), is yet to be determined.
- Amazon pretty much provides servers and storage, with a few integration and data services thrown in for good measure. The servers are standard OSes, with full root/Administrator access, etc. In theory, you should be able to get any code running on an Amazon machine image (AMI) that you could run on a physical server with the same OS, bar certain hardware and security requirements.
- As the AMIs are standard OS images, moving applications off of Amazon should be easy. However, moving data or messaging off of S3/SimpleDB and SQS will probably take a little more work. Still simple, but there is no standard packaging of data for migration between cloud providers today.
- Reliability in AWS is primarily provided by replicating AMIs and data across geographically distributed "availability zones". The idea there is to isolate outages to a zone, so by cloning services and data between zones, one should always have at least one instance handy should others go down.
- Google provides an open source development kit that allows developers to create App Engine apps and test them on local systems before deploying them into Google's cloud. There is no true replicate of App Engine itself that can be used in a private cloud, not are their plans for one that I know of. To be frank, I'm not sure why you would want one.
- Google's SDK has started with open sourced, but Google specific, APIs in the Python scripting language. Other languages have been promised, but this is what you need to know today.
- Given the unique nature of the Python APIs, the Big Table-based data architecture and the lack of partners exploring clones of the environment, portability is not an option at this point. Nor, it seems, are Google encouraging it, though they are always quick to point out that data itself can be retrieved from Google at will, via APIs. Mapping to a new infrastructure, though, is on the customer's dime.
- For high scale-dependent web applications, Google App Engine is the winner hands down. They know how to replicate services, provide redundant architecture under the covers and secure their perimeter. All the customer has to do is deploy their software and trust Google to do their thing.
- Microsoft makes a point of defining their cloud platform in terms of a hybrid public/private infrastructure. Their mantra of "Software-plus-Service" is an homage to having parts of your enterprise systems run in house, and other parts running in Azure. In many ways, Microsoft is letting the market decide for them how much of the future is "pure cloud", and how much isn't.
- The first platform that Microsoft supports is understandably their own, .NET. If you already use .NET, you've hit the cloud computing jackpot with Azure. If not, you can learn it, or wait for the additional languages/platforms promised in the coming months and years.
- Microsoft wants to make portability extremely simple...within its own product line. Like the others, there are ways to get your data via APIs, but there is no simple mechanism to port between Azure and other cloud platforms.
- At this point, we can only guess at the reliability of the Microsoft cloud. Will it match the relatively solid record of the current Live properties, or will it run like a Microsoft operating system...
- Mark Benioff was adamant at their Dreamforce conference this week that SF is going to kill the idea of on-premises software. It is an ambitious goal; one that smart people like Geva Perry think is going to happen anyway. However, I'm not so sure. The long and the short off it, however, is you can forget any "on-premises" version of Force.com or Sites in the foreseeable future.
- Force.com operates with a custom data model, a custom user interface framework, and a custom domain-specific programming language. While new to most developers, it appears to be extremely easy to learn, and cuts out a lot of the "down and dirty" stuff when it comes to programming against the SF applications and data model.
- Again, while you can go and get you data programatically at will, there are no simple mechanisms for doing so, nor is there anywhere to move APEX code. Portability is not really an option here.
- As in the Google case, SF hides so much of the underlying infrastructure that you just have to trust they can handle your application for you. In SF's case, however, they reportedly rely on vertical scaling, so there may be limits to how high they can scale.
