5 Reasons Simple Cloud is a Dark Cloud

When it comes to technology, everyone thinks they want interoperability. Using SQL, JavaScript or map APIs? There's an abstraction layer for that (SQL, JavaScript, map APIs). Writing mobile applications? There's an abstraction layer for that too (PhoneGap, Appcelerator, among others).

Developing "cloud-native" applications? Soon there'll be an abstraction layer for that too. Yesterday Zend announced the Simple Cloud API, a set of PHP classes for "writing scalable and highly available applications that are still portable."

Sounds great, right? Not so much. As Chief Architect of a PHP-based "cloud-native" application that's handling hundreds of millions of requests per month, there's no way I'd consider using Simple Cloud. Here are five reasons why you shouldn't either:

1. Abstractions leak. It's never as easy as it seems, which becomes painfully obvious at the least opportune moment. Let's have a show of hands of how many people have launched a SQL-abstraction based web application, only to find later that the crazy-ass SQL your toolset generated was 100x slower than one you'd have cooked up on your own. Okay then. The Law of Leaky Abstractions drags us down when it's time to figure out what's broken.

2. The Lowest common denominator rules. Abstraction layers often talk about unifying access to technologies where the differences are insignificant. Which is funny, since the providers of those technologies introduce differences to be competitive. Do you really want your web applications to be built around the elements of cloud services that are all the same? Your competition will likely be focusing on leveraging cloud advantages to the max, which will inevitably mean taking advantage of features that a lowest common denominator API ignores.

3. The true leaders don't participate. Simple Cloud lists contributors including Microsoft, IBM, Rackspace, Nirvanix and Go Grid, and dubs these companies as "leading the cloud revolution." Note how the three published APIs all include support for an Amazon Web Services solution. Who's really leading here? Amazon is leading the cloud revolution, and has been all along. Everyone else is just playing catch-up.

We've seen a similar situation recently. Remember OpenSocial? Google, MySpace, Yahoo and a few others banded together when Facebook handed their asses to them a couple of years ago. Facebook has never participated, and continues to lead the pack in social platform application development.

Of course all the companies that are not leading want to band together for the sake of interoperability, since interoperability means a greater chance of survival. But as a developer, be careful of getting roped into these company-serving agendas--it will cost you more than it costs them, with little return on your investment.

4. Native adoption isn't hard. Have you looked at the Amazon Web Services APIs, and noticed how many of them actually use the term "Simple" in their full descriptions? SDB is short for SimpleDB, S3 is short for Simple Storage Service. Is an API simplifying these already-simple APIs really necessary? If you're looking for a reduced feature set and inability to leverage each service to the maximum, sure! Otherwise, bite the very tiny bullet and learn about each service that you need. They're not hard. Trust me.

5. Face it: You'll probably never move. Despite portability claims, you'll likely never move from one service to another willy nilly. Consider the last significant web application you built around the database of your choice. Even if you used an abstraction layer, do you really think you could just pick it up tomorrow and move to a competing database engine? Whenever this scenario is truly considered, it's a much more complicated problem than just swapping out the underlying RDBMS. An audit must be done of all code to make sure no one snuck in a workaround query that included vendor-specific features, a new backup system needs to be evaluated (odd that no one has cooked up an SQL backup abstraction layer!), performance testing needs to be done ... all for what? Try doing this in a real company and see how quickly your plan gets shot down. Real companies have real business problems to be solving, and rarely have spare engineering cycles to waste on switching technologies that lie behind abstraction layers. So, just because you could doesn't mean you ever will.

With all that said, don't get me wrong: I love it that there are multiple providers getting into the cloud computing game in a meaningful way. I am actively evaluating each service and looking at ways to spread my cloud dependancies around to reduce my exposure to single-company cloud fail.

However, with each set of services I evaluate, I look for exactly the kinds of differentiating details that abstraction layers strive to hide, and will build out my application to leverage each environment to the max. My company and the services my customers consume deserve the very best utilization of upstream resources possible. Don't yours?