The relevance of Force.com has been questioned outside of the Salesforce.com user base. Force.com is Salesforce.com platform consisting of the multi-tenancy hosting, utility provisioning and subscription pricing minus the trademark customer relationship management (CRM) interface that made the Salesforce.com name.
That said, though, the company does have a very large user base - more than 41,000 companies on its service. Force.com applications are written in the proprietary Apex language, and there are APIs for Java, .NET and other languages. The platform has some great pre-built wizards, analytics and tooling, and of course, your custom applications automatically scale.
Force.com is actually a very elegant solution to cloud development, but lacks any non-Force.com deployment options - you can't deploy your application to a third-party's data center or cloud. To be fair, Salesforce.com acknowledges that portability is not part of their design and considering the underlying technical approaches in the Amazon and Salesforce.com cloud are fundamentally different, chances are you're likely going to remain stuck for awhile once you've picked your platform.
When it comes to package management, though, Force.com is very appealing since you don't have to maintain any infrastructure - you forget about VMs, operating systems and other software. You simply deploy your application and the system knows what to do with it.
So far there are no exact replacements for EC2 or S3 for Force.com. And there aren't many clever facsimiles either, with the exception of Eucalyptus, an open source project that implements the EC2 interface.
So what does this mean in real-life?
Let's say I have an AMI running on EC2 and I love the data processing function. However, for security reasons my company decides the same application function needs to live inside the corporate firewall. There is no way I can replicate the EC2 environment. Nor is there a way to ensure that I can get my persisted data - assuming I've stored it on S3 - to automatically relate to my new internal system.
Give us the tools
Cloud providers have used APIs to obfuscate the underlying technology largely to the consumers' benefit though there are some issues. Force.com's APIs eliminate the need to manage infrastructure but hide the level of detail you might need. Amazon's web services require the user to manage the AMIs that make up their applications. This of course introduces complexity and potential downtime, and introduces another form of lock-in through Amazon's proprietary AMIs.
Let's assume the companies have acted in the interests of users, by hiding complexity to save us from ourselves through acts such as randomly introducing changes that accidentally cause lost data or corrupted applications. That's OK for the consumer. But the business needs to get into the nooks and crannies of the cloud in the same way most business IT users tailor their servers and desktop images. The answer is package managers, the kind used in operating systems.
Package mangers can maintain a vast array of items that ensure you don't accidentally screw everything up. As with a local server, in the cloud you can easily make a mess of things, and you don't necessarily have backups or replication options.
Cloud systems need to be more autonomic - good lord, was IBM right? - while not forgetting that developers stick with their personal choice of tools for everything they do. And operations people need to have visibility into cloud systems while making sure they can't accidentally blow everything away. And of course, these management tools should all be pretty, interoperable and easy to use.
Someone get on it while I grab a coffee.®
Dave Rosenberg is the co-founder and former chief executive of open source enterprise service bus and integration platform MuleSource. Dave is currently working on a new stealth start-up based in San Francisco.