So hmmmmm....

Before going any further I'd like to remind you that this is not a pre-written post.  I learned about this an hour ago and these are my initial thoughts.  Things might look completely different in the morning.

Though...I doubt it.  The quick snippit is that Microsoft Mesh, for right now, is just a sync-able desktop.  Sign Up for a Mesh account, add several computers, store all your stuff in local "Mesh Folders" and everything syncs up nicely.  That's about it for now. 

But the real promise of this is the SDK.  As Scoble put it...

We haven’t even gotten into the developer SDK. They spent about an hour showing me how to build new kinds of syncable apps on top of the Mesh in a variety of tools.

Now you’re just getting a taste of how Microsoft is going to use the Mesh to stay relevant. It is bringing its developers onto the Internet in an interesting new way.

So this is Microsoft's strategy for the future, sync based apps built around Feedsync feeds.  My initial thoughts...

Lock-In: A big part of me feels like this is Microsoft trying to devise another way to lock everyone in.  Like they are trying to replace Windows with the cloud rather than just provide a great service.

A Whole Lot of Effort for Developers: For a Developer the question is this: You can build one Online App.  Or you can build One Adobe Air App.  Or you can go with Microsoft and build an App for each and every platform out there all based around Microsoft's Sync technology.  So my question is, why would I go with Microsoft?

A Whole Lot of Files for Users: So lets say I buy into Microsoft's grand vision, sync everything up, and carry a copy of everything on each one of my devices.  Doesn't that mean I have 20 copies of files to worry about now?  If I forget to delete my old computer from my Mesh account do my files still float around on that PC?  Continuing to update while now in the hands of others?  This system seems awfully insecure.  Its true that users should be careful about leaving files on old computers but one lesson I've learned as a developer is never to trust the user to act in the ideal way.

Not Much Gain For Anyone (But Microsoft): I think my main problem with this is that it seems like an initiative that is "strategy based" and not "user based".  Its designed to pull the focus back to the desktop.  But with connections getting faster and web based technology getting more interactive why would I revert back to a desktop model?  In a constantly connected world do I really want my files residing on every computer I touch? 

Obviously I'm going to keep a very close eye on this but right now it seems profoundly uncompelling.  Almost like Microsoft made a checklist of their desires (lock people to a platform, put the focus back on desktop computing, etc...) and built a product around that without much thought given to the user. 

I'm a Microsoft Developer, my platform of choice is ASP.NET, my language of choice is C#, and I find this completely uninteresting.  If that's the case how on Earth does Microsoft plan to convince those hostile towards them to come over? 

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.

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).

I wasn't going to tackle the Google App Engine Beta at all because I thought others would come forward with the same argument I wanted to make.  But as far as I've seen that hasn't happened.  Instead a steady stream of posts praising the service as the next big thing have come out which, to me, is ridiculous.   

For those completely unfamiliar here is a summary of Google App Engine from  Niall Kennedy's post on the topic...

Google App Engine lets any Python developer execute CGI-driven Web applications, store its results, and serve static content from a fault-tolerant geo-distributed computing grid built exclusively for modern Web applications. I met with the App Engine's team leads on Monday morning for an in-depth overview of the product, its features, and its limitations. Google has been working on the Google App Engine since at least March 2006 and has only just begun revealing some of its features. In this post I will summarize Google App Engine from a developer's point of view, outline its major features, and examine pitfalls for developers and startups interested in deploying web applications on Google's servers.

After reading Mr. Kennedy's post I couldn't hold my tongue anymore.  This service has gotten entirely too much credit and I'm now to the point where I'm willing to spend the time to make a post on it. 

Google App Engine: The World's Worst Webhost

Google App Engine is essentially just a free web host.  You can throw around terms like "geo-distributed computing grid" all you want but the reality is most applications have a server or servers in one location and do just fine. 

Given that, I made a quick chart comparing Google App Engine to a popular shared hosting company (for the record, I've never done business with this company).  I compared Google's free service to the other company's $5.95 per month service...

As you can see, Google falls behind in every single category.  So the question becomes this: is there really anyone who can't afford $6 a month?

But what about Scaling?

One of the arguments for the Google App Engine has been that its backed by Google's ability to scale.  When I hear people say this I have to wonder if they've even thought through what the words mean.

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.

Beyond that, Google is allocating resources "per cycle" which means that Google's ability to scale doesn't come into play unless you are using enough resources to max out another web hosting company (which is unlikely).  

On top of all that Google hasn't even released details on how much they will charge for overages making it impossible to judge the service against other available options.

The Great Google Stack

To quote from Mr. Kennedy's post...

Google App Engine is a proprietary virtualized computing suite covering the major common components of a modern web application: dynamic runtime, persistent storage, static file serving, user management, external web requests, e-mail communication, service monitoring, and log analysis. The Google App Engine product offers a single hosted production web server stack hosted on Google's custom-designed computers and datacenters distributed around the world.

Here's what he doesn't mention: almost every modern framework manages these tasks.  .Net, Ruby on Rails, even PHP all have ways to handle the above tasks with  just a few lines of code.  Google isn't doing anything monumental by offering these items. 

The one exception to the above rule is authentication.  Google does offer the ability to authenticate your program's users through their Google account which is a nice feature.  But again, entirely proprietary.  To use it you essentially have to be willing to give your customers to Google.

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. 

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.

But Wait, There's more limitations

Going back to Mr. Kennedy's post  he lays out a few more limitations that I didn't know about...

1.  
   1. Static files are limited to 1 MB. App Engine does not support partial content requests (Accept-Ranges).
   2. Cron jobs and other long-life processes are not permitted.
   3. Applications are not uniquely identifiable by IP address, leading to a lack of identification for external communications. Applications may suffer from bad neighbor penalties from API providers upset at another app on the service.
   4. No SSL support. You can rely on Google services (and branding) for login and possibly future payments.
   5. No image processing. Python Imaging Library relies on C, and is therefore not a possible App Engine module.
   6. Google user accounts. Site visitors are very aware of your choice in web hosts each time they attempt to logon to your application. I feel like this flow makes your application seem less professional, but may be a reasonable trade-off. Google will store your user data and potentially mine its data for better ad targeting.

All but #6 are things you CAN DO on every web host I can think of. 

Conclusion

The Google App engine may some day be worth mentioning but as of right now its nothing short of comical.  Essentially Geocities 2.0. 

The idea that this is a competitor to Amazon's services or that Startups are going to start flocking to this platform is absurd.  You'd think the people singing the praises of Google's solution had never heard of a web hosting company before. 

Amazon was revolutionary because it provided a superior product for a cheaper price than most web sites were paying at the time.  Google on the other hand has provided a product inferior to every web host I can find and won't even tell us how much they'll charge to bring their service up to equal those other products. 

I can't imagine any serious developer signing up for this under the current circumstances.