Tag: aws

The Snail in the Cloud

Little PO BoxesI’ve used this photo before, because I find the Post Office boxes rather lovely, in a vintage sort of way. Little did I suspect at the time that the photo might become relevant to cloud computing.

But (as I read at GigaOM), Amazon Web Services is now going postal, since snail mail is sometimes faster than the internet. “Werner Vogels, Amazon’s CTO, explains… that it would take up to 13 days to sling a terabyte of data across a 10 Mbps network… So Amazon is offering customers the chance to store their data on an external device, ship it via post, and Amazon will load it.”

Comparing Platform as a Service Offerings From Amazon and Google

A few days ago, many of us posted about Google App Engine. Most of us made some sort of comparison between GAE and AWS (Amazon Web Services.) I remarked that I didn’t understand why GAE seemed to arouse much more concern about lockin than did AWS.

Dion Hinchcliffe compares the two “Plafform as a Service” offerings, concluding that:

The decision for many startups will be an easy one; the benefits of using these platforms for their new products are compelling across the board despite minor concerns about platform lock-in even though the models used by both companies are actually surprisingly lock-in free.

So maybe the perception that GAE poses significantly greater lockin risk than does AWS is a perception about the difference between Google and Amazon, rather than a reflection of technical differences between the two platform as a service offerings. It’s a feeling that one should be wary about being locked in by the “don’t be evil” company.

Google App Engine

Yes, this is another post about Google App Engine, which you either don’t care about, or have already read about. Actually, it’s more about how such things are reported on the web, using two prominent blogs/publications as examples.

My favorite account of AppEngine so far is the account of building and launching an app provided by Henry at TechCrunch. I sometimes weary of reading account of web services obviously written by people who haven’t actually used the service. To provide the one-sentence summary: Henry was impressed with the speed with which he and Mark McGranaghan could get the app going.

Turning now to ReadWriteWeb and to Marshall Kirkpatrick, I was struck by the concern about lock-in.

It’s very, very important that there be no barriers to leaving App Engine and that the service retains customers based on price and superior service. Anything else, any lock-in, will drive a stake through the heart of innovation.

The concern is striking, not in itself, but in contrast with the comparative lack of such concern about Amazon’s competing offerings when they were launched. In fact, I don’t know anyone who expressed concern about getting locked in to Amazon Web Services besides me.

That’s one of the most interesting aspects of Google App Engine: the competition with Amazon Web Services. It promises to drive the cost and time of building and deploying web applications yet further down.

A Surf Around the Cloud

Web application developers seem to be moving toward keeping their applications in the clouds. By what is a cloud? Alex Iskold at Read/Write Web:

The idea behind cloud computing is simple – scale your application by deploying it on a large grid of commodity hardware boxes. Each box has exactly the same system installed and behaves like all other boxes. The load balancer forwards a request to any one box and it is processed in a stateless manner; meaning the request is followed by an immediate response and no state is held by the system.

Alex contrasts cloud computing with the LAMP stack on which web applications “traditionally” run. He concludes that we are at the start of “a fundamental shift in our ability to compute.”

Fred Wilson agrees, but with an interesting qualification.

I think Alex is directionally correct. We are going to see more and more companies build and host their web apps on someone else’s infrastructure. It’s not going to happen overnight because I’ve never met a more control oriented group than software engineers.

Rackspace just announced its own cloud-like service, to add to its more traditional hosting services. Erick at TechCrunch remarks that Mosso bills itself as a Web app hosting service, and contrasts Mosso with Amazon Web Services.

Mosso isn’t as purely cloudy as AWS. As such, it may be a good first step toward a walk in the clouds for those control oriented software engineers.

SimpleDB, Standards, and Lockin

A few days ago, Amazon announced SimpleDB. It’s “a web service for running queries on structured data in real time.” It’s also the newest member of the Amazon Web Services (AWS) family.

In other words, Amazon has added to AWS a database management system, and hence an additional reason to run your web application in Amazon’s cloud. Nitin Borwankar, writing at GigaOm, thinks that it will turn out to be a compelling reason.

SimpleDB is hugely disruptive. It will take some time to evolve the new thinking patterns and new design disciplines that this technology forces us to consider. To do so, consider this breakdown of the similarities and differences between SimpleDB and conventional relational databases.

A difference that I haven’t seen addressed relates to standards. If I’m using MySQL or Oracle I access my database using SQL, an established standard. If I decide to shift or mix database vendors, I can keep on using SQL.

If I’m using SimpleDB, and for whatever reason decide that Amazon’s cloud is no longer the best place for my application, what do I do? In particular, how much of an application rewrite do I have to do?

Unless I got a reassuring and convincing answer to that question, I think I’d prefer to use MySQL. I single out MySQL because it’s free, in both senses of the word: free of charge, and free software, so that I can get at the source code. But even if I used Oracle, I’d still feel in less danger of lockin than I would with SimpleDB.