3 Comments

Summary:

Developers at the Surge conference in Baltimore have a love-hate relationship with America’s largest online retailer and cloud provider. But repeated tales of Amazon’s failures were immediately followed by assurances that the service was cheaper and better than buying your own hardware.

Andy Parsons CTO of Bookish

Andy Parsons CTO of Bookish

Developers at the Surge conference in Baltimore have a love-hate relationship with America’s largest online retailer and cloud provider. But repeated tales of Amazon Web Services’ failures were immediately followed by assurances that the service was cheaper and better than buying your own hardware.

As for other cloud providers, Andy Parsons, CTO for startup Bookish, summed it up after being asked if he had even looked at other cloud service providers: “Yes, but the devil you know is better than the devil you don’t.”

This might be considered a figure of speech, except that Parsons spent a good portion of his presentation cautioning the audience about how ephemeral Amazon EC2’s local storage was, explaining the poor latency of storing stuff to Elastic Block Storage (Amazon’s persistent storage) and lamenting the fact that Amazon’s networking was pretty constrained. And he wasn’t the only one.

Mark Imbriaco, director of cloud operations at Heroku, had a similar approach. He too has looked beyond EC2, he said in his presentation, but ultimately Heroku is still hosted on Amazon’s cloud (even after being purchased last year by Salesforce.com). However, he pointed out on multiple occasions that Amazon’s monitoring systems were generally “10-15 minutes behind” Heroku’s and explained how difficult it was to diagnose hardware issues when one doesn’t own the hardware. The consensus among speakers seemed to be that when things go wrong, just restart the instance, because troubleshooting isn’t going to happen.

Imbriaco also touched on the challenges Heroku had during the multi-day Amazon outage earlier this year. He recognized the limits of Heroku’s options when Amazon went down, but he and his team are still thinking of ways to extract more data about what customers might be hosted in specific Amazon data centers, so he can deliver more exact information to customers that are affected.

In general, the presentations and speakers were essentially telling their peers what to watch out for and how to build among Amazon’s constraints.

In a way, this could benefit Amazon, because these people are building applications that are tailored for EC2’s weaknesses as opposed to those of Rackspace or GoGrid or another provider. At the same time, it points to a potential problem should Amazon stand still or focus entirely on the enterprise market. Developers are keenly aware that Amazon is constantly adapting its infrastructure to their needs and so are happy to stick with it and see how it can improve their lives. But if Amazon stops, who knows if sticking with the devil they know will be enough.

You’re subscribed! If you like, you can update your settings

  1. well, ultimately is an analysis of benefits vs drawbacks. everyone build around weakness even in the corporate physical world. Amazon can improve a lot but they are really miles away from all other vendors. rackspace, etc etc are a laughable cloud. They can even get simple security right (VLANs or security groups).

  2. “But repeated tales of Amazon Web Services’ failures were immediately followed by assurances that the service was cheaper and better than buying your own hardware.” Repeated failures are neither cheaper nor better.

  3. If the late Chicago Cubs announcer, Harry Caray, were here he’d be saying something like “Oh sherrie, hold on here” (i.e., danger is lurking, the opposing team has the bases loaded with nobody out). Seriously people, Jeff Bezos is going to do what’s in the best interest of Amazon (putting Amazon.com and Kindles like the new Fire) first and foremost, not his AWS customers (even though his AWS customers will end up being forever Guinea pigs).

Comments have been disabled for this post