After my post on Google App Engine and its lock-in factor I was surprised to see this on the top of Techmeme...

One of the biggest criticisms of Google's App Engine have been cries of lock-in, that the applications developed for the platform won't be portable to any other service. This weekend, Chris Anderson, the Portland-based cofounder of the Grabb.it MP3 blog service, just released AppDrop — an elegant hack proving that's not true.

My first thought: "Wow, That's incredible"

My second thought: "Wait a minute, what now?"

Here's the thing, the information part of an API is a way to get information to and from somewhere.  It is a gateway to an information repository such as a database or a membership directory.  So while this is an impressive feat by Chris Anderson it doesn't change the fact that the information repository on the other end of Google's API is proprietary and using that repository locks you in.

Having a copy of the APIs is great but you are still faced with the fact that your data is stored in a proprietary directory (bigtable), your users are using the Google log-in accounts, and so on.  So to make the transfer to another server you are still going to have to recreate all that.

Which is exactly what I and every other Google App Engine critic has been saying from the start.  No one ever claimed it was impossible to move your Google App Engine application to another server, just that it was difficult.  From my previous post (bold added for emphasis)...

In fact, the end result of all these libraries is to lock you into Google's proprietary system and force you to use their language of choice (at least until they expand beyond python).  So if you do use those features you really can't move your site to another host without a massive rewrite.

That's still true.  As is my original point which is that using a standard apache web host with mySQL and your own membership provider is still a better bet.  It allows you to move your application anywhere and it allows you to do so seamlessly. 

Again, this isn't meant as an anti-Google App Engine post as much as its meant to say "lets be realistic about this and actually look at what's going on here".  A good part of the blogosphere seems infatuated with this and that infatuation is causing them to spread a lot of mis-information.  The idea that people would see this port and say "that's it, lock-in problem solved!" just shows how blinded some of them are.

From the Amazon Web Services Blog...

If you have taken a close look at Amazon EC2, you know that the instances are ephemeral. The instances have anywhere from 160 GB to 1.7 TB of attached storage. The storage is there as long as the instance is running, but of course it disappears as soon as the instance is shut down. Applications with a need for persistent storage could store data in Amazon S3 or in Amazon SimpleDB, but they couldn't readily access either one as if it was an actual file system

As you can read in our forum post, we've been working on addressing this.

In the same way that your running EC2 instances, your Elastic IP addresses, your S3 buckets and your SQS queues can be thought of as items contained within the scope of your AWS account, our forthcoming persistent storage feature will give you the ability to create reliable, persistent storage volumes for use with EC2. Once created, these volumes will be part of your account and will have a lifetime independent of any particular EC2 instance.

These volumes can be thought of as raw, unformatted disk drives which can be formatted and then used as desired (or even used as raw storage if you'd like). Volumes can range in size from 1 GB on up to 1 TB; you can create and attach several of them to each EC2 instance. They are designed for low latency, high throughput access from Amazon EC2. Needless to say, you can use these volumes to host a relational database.

Sorry for the big quote but I wanted to get the whole gist of the post in. 

The reason this is important for .Net developers is because this, in theory, means that you will be able to access SimpleDb and S3 accounts while running Mono on an EC2 instance.  This was supposedly possible before but I never found anyone who got it working.  It required some odd work arounds which, pardon the pun, didn't seem to work at all.  Because of that .Net developers have been severely limited in what they could do with EC2. 

If this resolves that you'll be able to run full fledged .Net applications in an EC2 instance which is pretty exciting. 

Admittedly, Mono still has its issues.  Most notably is the fact that it runs several versions behind the .Net Framework (it is almost caught up to 2.0 at this point).  But being that EC2 is mostly useful for processor intensive tasks and most of those tasks don't require the features introduced in later versions of the framework I think that's close to a non-issue. 

Microsoft may very well have an EC2 competitor coming in the next few weeks but until that happens this gives .Net developers something.  Beyond that, even when Microsoft gets around to producing something like this I'll feel better knowing it has some competition from Amazon. 

My last post got picked up by Reddit and YCombinator each of which have their own comments section.  I wanted to address a few of those comments below.  Please note, there were several great comments that I don't address below but I thought these few covered the overall issues. 

From ashu of Ycombinator...

People just love misinterpreting products, comparing them to completely unrelated things and just making noise. That's right. Making noise is the goal. All else is secondary.

Can't people just say "Hey look, here's a new product which IS USEFUL to somebody out there on earth and a damn nifty one at that." That somebody in Google App Engine's case is a hacker who wants to quickly try out his hobbies without worrying about all the mess that comes with managing a web host.

But no. We must compare. And we must make noise. Lots of it.

Perhaps it gives us a way to figure out which blogs / sites to NEVER visit.

I'll try to be easy on him since he'll probably never see this (if his comments are to be believed).  That said, his comments are foolish.  The point of my post was that while Google App Engine IS USEFULL there are shared hosts that do the same thing and are MORE USEFULL.  The fact that they are essentially the same and should be compared as such was part of my point. 

In response to ashu's post, randomhack of Ycombinator said...

Perhaps. But OTOH the author is pissed off about the amount of noise being generated in favor of Google App Engine as if it were completely revolutionary when, according to the author, currently its only a nicely packaged free webhost with many drawbacks. The operative word here is of course "currently".

Honestly, that's exactly right.  My original post was a response to all the positive posts out there and while I wouldn't go so far as to say I was "pissed off" I definitely think people need to view it in the context of all the positive reviews I was responding to.

Moving on, from Toffer of Ycombinator...

My favorite quote from the linked article:

"Google App Engine's ability to scale depends on how much server resources Google is willing to dedicate to the task of running these applications. Google is not going to risk slowing down their primary services for a Google App Engine application. So their ability to scale could very well be less than other companies, we just don't know."

No doubt a $6/mo. account at Dreamhost will scale better than Google.

This was a common mistake in that people who dislike shared hosting took my last article as an endorsement of shared hosting for use on applications.  It wasn't.  The truth is, anyone serious shouldn't use Google App Engine or a Shared Host.  Both are better suited for hobbyists wanting to "try something" or developers looking for a place to prototype their solution.

(or blogs for that matter, but I digress...)

My point wasn't to say Shared Hosts were sufficient it was to say Shared Hosts aren't sufficient and Google App Engine doesn't even measure up to them.  Again this goes to the point above which is that my post was a reaction to people claiming Google App Engine was ideal for startups. 

Zeco from Reddit says...

Tom says:

Those pesky privacy concerns

Another thing that doesn't seem to come up is that Google has made no guarantees as to the privacy of the content being put on their servers. They'll have access to your complete source code and the rights to do whatever they want with it. I doubt they would do anything but the fact that they could is enough to chase any smart start up away.

Google App Engine Terms of Service, §8.1 says:

Google claims no ownership or control over any Content or Application. You retain copyright and any other rights you already hold in the Content and/or Application, and you are responsible for protecting those rights, as appropriate.

Also, what web host did he find that offers 15TB / month for $6? (no, he didn't mean 15.0 GB, as he stated that Google's 300 GB were inferior)

He sounds a little desperate. What might his stakes be in this?

Two things here.  First, from the same Google document he quoted...

Google reserves the right (but shall have no obligation) to pre-screen, review, flag, filter, modify, refuse or remove any or all Content from the Service.

So Google can do whatever it wants with the content put on Google App Engine. 

On his second point, I find it odd that people automatically assume that anyone who disagrees with them has an ulterior motive.  To me, that shows limited thinking on the part of the other person.  "Since I am always right anyone who disagrees must be dishonest"

The funny thing is, had Zeco thought about it for just a second, he might have realized I went out of my way NOT to mention any web host by name.  Why would someone who works for a specific web host not mention the name of that web host in their post?  Does advocating web hosts in general really do one particular one any good at all?

From pbx of Reddit...

Translation of the "Yes" marks next to Python, Ruby, and Perl in the comparison chart: "Yes, Average Webhost will let you run these as CGI, though I have no idea what you'd do if you wanted to host a real application written in any of them. Yeah, that would probably suck. Why don't you just use PHP?"

This is probably the fairest criticism of all the ones I saw out there.  I think individual web hosts vary and I think its important to investigate the one you are going with to make sure they do a good job of supporting the environment you wish to work in.  There will always be horror stories and I've personally found shared web hosts to be a very mixed bag but when you find a good one they are usually willing to bend over backwards to make sure you are taken care of (which I suspect is more than Google will be doing for App Engine developers)

I wanted to address one issue specifically since I still think people have a weak grasp of what it means.  That issue is scaling.  There have been two scale arguments that have been presented to me in the responses to my last post so I addressed both below. 

Scaling for an Individual Application

One of the arguments presented has been that Google's solution allows applications to scale beyond the point that a shared host could match.  This is because, according to those who make the argument, Google has massive resources that they can employ if your application grows into a high traffic site.

What people are missing here is that, once you get to a certain size, it becomes cost effective to host your own site.  No matter how efficient a company like Amazon or Google is they have to charge an overhead to make money.  Once you get to the point where you can afford to hire a full time server person and maintain a server farm for yourself there's no way those companies can compete because of the overhead they have to charge. 

So people thinking that one of the benefits of the Google App Engine is that it can scale into infinity miss the point that no one will ever need that even if Google was providing it. 

Which Google isn't, and that brings me to my second point...

Scaling for Multiple Applications on Google's Server

There's been much confusion over one thing in my previous post.  That thing was...

Google App Engine's ability to scale depends on how much server resources Google is willing to dedicate to the task of running these applications.  Google is not going to risk slowing down their primary services for a Google App Engine application.  So their ability to scale could very well be less than other companies, we just don't know.

So I thought I'd elaborate on that.   One of the arguments people have made is that Google's massive data centers gives them the capability to completely eliminate performance drags.  So Google App Engine applications will perform faster because they'll never have to wait for CPU resources. 

What this line of reasoning misses is that we don't know how many of Google's computers they are willing to dedicate to the task of hosting App Engine Applications.  So while a normal shared host might put 100 website's on every computer that still might outperform Google if Google's Server-To-Application ratio is higher.  So even if Google has 300,000 computers dedicated to Google App Engine and your shared host only has 100 computers to their name they could very well be even in performance if Google has 30,000,000 App Engine applications to run. 

In fact, I'd argue that Google's popularity and the fact that the service is free makes App Engine more likely to exceed your average web hosts Server-To-Application ratio. 

In the End...

When all is said and done my point still stands.  Scalability really doesn't play a part when deciding between a web host and a service like Google or Amazon.  It all boils down to price.  Since Google has chosen not to reveal their pricing yet there's no way to compare.  That is exactly why it is too early to be singing the praises of Google's solution (which was the point of my last post).