For developers, Amazon’s cloud is a harsh mistress

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’ (s amzn) 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, (s crm) 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 (s crm) 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 (s rax) 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.