2009 September

5 Reasons Simple Cloud is a Dark Cloud

Thursday, September 24th, 2009
at 12:10pm

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?

Memo to Start-ups: You Don’t Need a Meat Market

Friday, September 18th, 2009
at 12:37pm

With all the TechCrunch50 chatter earlier this week, it's easy to see how entrepreneurs feel that if they're not putting on a great showing at an event like TC50, they're missing a golden opportunity. That notion was craftily compounded by the announcement of the sale of the first TechCrunch40 winner's (Mint.com) to Intuit for $170M. Well played PR, folks.

All the buzz was then followed by Sarah Lacy's parade-drenching "Memo to Start-ups: You're Supposed to Be Changing the World, Remember?", which gripes about this year's TC50 crop playing it safe.

I didn't attend TC50, but I have attended these start-up launch binges before. It's never clear who benefits the most from these events, but my gut tells me it's most often the event organizers, and not the start-ups themselves. Sometimes the commentary is good, but there are other ways to get that kind of honest feedback. In some cases, the launch binge meat markets don't even offer commentary or criticism -- they just give you a five minute slot.

To me, these kinds of events aren't necessary for entrepreneurial success. By the end of the event, no one remembers who's launching what, and instead of gaining momentum naturally, all an entrepreneur's efforts are bet on the hope that everything will go off without a hitch with the presentation, the people watching won't be bored or distracted, etc. Despite what start-up bloggers and event organizers want you to think, you just don't need the meat market for a successful launch.

Look at the esteemed judges of TechCrunch 50:

Also, consider the other world-changing companies that Lacy mentions, such as Google, Facebook and Twitter.

Now ask yourself: How many of these world-changing companies launched their start-up selves at a meat market?

I'm not questioning the value of "normal" TechCrunch publicity, nor am I even saying that I'll never launch a start-up at one of these events someday (as hard as it is to imagine, never say never). I'm merely suggesting that many of the real game-changers of the next wave may have decided their companies are worth more than 15 minutes of pseudo-fame at a launch binge.

We'll know them when we see them.