Various pundits such as Garret Rogers at ZDNet and Richard MacMannus are viewing Google versus Amazon Cloud Computing as Apples to Oranges.  The reason is that Google’s App Engine bundles all the services together and forces you to use Python while Amazon’s services are unbundled and can be accessed piecemeal.

At 100,000 feet, it’s an accurate analysis.  Certainly the pundits need some way to pigeonhole the two offerings into distinct flavors.  But as is often the case with technology, there is more to it than that. 

For one thing, it isn’t all that desirable to use Amazon piecemeal due to latency issues and bandwidth charges.  Do I really want to run my database in a completely different datacenter than my business logic?  The answer is no, I do not.  I already have a big speed bump between the client and data center, having a third speed bump would be painful.  Also, Amazon doesn’t charge for bandwidth between nodes within its cloud, but costs to get data in and out of the Amazon cloud are higher than for most datacenters.  Hence the smart money views Amazon as an all-in-one anyway. 

Historically, companies have gotten their feet wet with Amazon a little at a time, perhaps using S3 to replace backups.  But that isn’t the money play for Cloud Dominance.  It’s just an entry-level experiment.  Over time more and more gets sucked into the Cloud.  Google simply short circuited that thinking.

We can turn it around and look at it another way.  Suppose you want to use Google File System strictly as a substitute for Amazon S3, and you plan to ignore as much of the rest of Google’s App Engine as you can.  You can certainly do that.  You simply need to write a wrapper in Python that exposes the API of your choice to let you talk to the Google GFS.   I wonder how long before someone clever mimics the Amazon S3 API’s in this way?

There’s also a lot of chit chat among the pundits about what a poor choice Python is.  I hear things like it is an unpopular language, yada, yada.  That’s more silly business for several reasons.  First, Python is quite a popular language as O’Reilly’s book sales would indicate.  Ruby and some others are more popular (by book sales), but it would be hard to view Python as “unpopular”.  Second, Python is but the very first language they’re tackling.  There will be more and I understand there are groups inside Google already working on others.  Be patient, the rest will follow.  Meanwhile, as I pointed out already, you can view Python simply as the way create API’s to get started playing with Google App Engine if you like.

Personally, I think Google could acquire Heroku and Zend and immediately pick up Ruby on Rails and PHP.  If I were at those two companies I would be eagerly trying to have the conversation.  I would also be calling up Amazon.  Heroku is Ruby on Amazon already, and would instantly give Amazon parity again with Google App Engine only with Ruby instead of Python.  That would make a wonderful return shot from Amazon.

And for all those pundits that worry about trusting their apps to big companies (hello MacMannus again!) like Google, fear not.  MacMannus fears developers will be locked into a single source the way people used to fear Microsoft.  But it isn’t so.  Google doesn’t own Python and will be supporting other languages they also don’t own.  They’re also supporting frameworks for these languages that they don’t own.  They are Open Sourcing their SDK.  By placing their platform at the language level more than the API level, they actually make it easier to port into or out of their world.

And, despite the conspiracy theory that Google is doing this to make it easier to acquire companies that built on their fabric, Cloud Computing is not going to be a one horse race.  We now have two horses.  I would expect another couple to show up before it’s all over, maybe more.  It will be an arms race and in that situation, the startups can win because the competition will create price pressure and tons of new features they benefit from.

It’s a good day on the Cloud Computing Apple and Orange farm!

Mike Arrington:

What this all means: Google App Engine is designed for developers who want to run their entire application stack, soup to nuts, on Google resources. Amazon, by contrast, offers more of an a la carte offering with which developers can pick and choose what resources they want to use.

You want all of these components in the same cloud, else the connect charges can be painful.  This is true of Amazon also–connect between their services is free, data moving in and out is not.  Folks tell me Amazon’s charges for bandwidth are pretty high.  Aside from the costs, the latency and performance issues of trying to put part of your infrastructure in one cloud and the rest in another is prohibitive.  The scenario only works if the second cloud is used for second-class citizen purposes.  It is popular, for example, to use S3 as a backup service.  You can of course still do this with Google, you simply write a Python script to front-end that service.  I score this advantage Google.

Mathew Ingram:

Mathew focuses on whether Google is a competitor or just a knock-off, meaning have they innovated or just copied Amazon?  He writes:

Aaron Brazell of Technosailor — former technology guru for b5media — says the Google announcement is “much to do about nothing.” Among other things, Aaron says that Python, the only programming language that Google’s service currently supports, is not trivial to learn or to implement (several commenters on the TechCrunch post also seemed to think that restricting it to Python was a big negative as well). Aaron’s other beef with Google’s initiative is that it seems like an “Amazon S3 me-too” kind of product. “There is no innovation here,” he says.

Okay guys, this is a tech announcement, so you have to be a tech to get what’s going on.  First, Python is way more approachable than Amazon’s stuff which is just raw virtual machines and storage with API’s.   Google really is innovating by moving a whole level up in the stack in what they offer.  Suppose you wanted to run Python on Amazon to get something similar.  There’d be a whole bunch of work you’d have to do before you could even get started.  Trust me, this is no simple knock-off of Amazon. 

The business about people complaining about Python should also be ignored.  If you’re not a Python guy, of course you’re complaining!  But it doesn’t take Google very many languages before there are few complainers left.  Add Ruby on Rails and PHP, for example, and most of the Web 2.0 world is now in your camp.  Add Java and what’s really left?  Microsoft will be more isolated than ever on their .NET platform.

Stacey Higginbotham at GigaOm:

Stacey writes:

Google, with its new Application Engine product, has taken aim squarely at the web services market — and companies from Amazon.com to Bungee Labs should be running scared.

Right on Stacey!  Interesting you mention Bungee Labs.  I have been classing them in a world I call “MS Access in the Cloud.”  Coghead and a whole bunch of others are in that same spot.  Their primary advantage will lie in their ability to make it much easier to create apps in their proprietary languages than in Python or the other more public languages Google will likely wind up supporting.  I think it will be hard.  Back in the era of these kind of languages when we had things like dBase and Paradox, what really killed the market wasn’t Access, it was things like Visual Basic.  Tools like Python, Ruby on Rails, and PHP have gotten pretty darned easy. 

Stacey goes on to wonder what this does to Google’s margins:

He’s right, but it will come at a cost to Google in terms of its margins. Providing that kind of infrastructure isn’t free. It also will have a ways to go before it can compete with the 330,000 developers Amazon says are using its Web Services as of January.

Yep, this is exactly why the service isn’t free forever.  It’s free if you’re small and not using many resources.  It costs if you build something a lot of people actually want to use.  Google knows more about delivering apps cheaply from the cloud than any other company on the planet, Amazon included.  They’re at a level where they build their own switches (no need for Cisco and Juniper), their own compute nodes (no thanks HP and Dell), and their own TCP/IP stack software.  Shave a few cycles on the TCP/IP stack and it goes directly to their bottom line.  We’ll need to watch pricing carefully, but this is no more threatening to their margins than the free storage for gmail, for example, and it is hugely strategic.  As I’ve written elsewhere, there is a window to get in the cloud computing game and Google just jumped through it.  It’ll be fun to see who else can follow!

Also see my own first blush report on the Google App Engine.

Note:  This is a quick “just the facts, ma’am” post to get the info out.   I’ll follow with deeper analysis later.

I am watching the Google announcement courtesy of Scoble’s Qik Channel.  First, I want to thank Robert Scoble and mention that this real time connection for the uninvited is awesome.  It has huge ramifications for the way businesses communicate.  But the Scoble and others have been trying to tell us that for a while.  This is just the first one I plugged into where something I really cared about was happening.  Second, the medium was Qik, as filmed with Scoble’s cellphone.  I hate to think of the security and privacy ramifications, but puttin that aside, it actually worked unbelievably well.  The biggest issue is that it crashed a lot because Scoble is so popular and this is such a big announcement.

On to the scoop!

What Google is announcing they call Google App Engine.  It consists of the following “stack”:

1.  Scalable Server Infrastructure

2.  Language Runtimes:  Python will be the first language they support, others will follow.  In terms of frameworks, it is largely Django focused, but will also support EZT, Cheetah, ClearSilver, Quixote, Django and CherryPy.

3.  SDK:  So you can code your app locally

4.  Web admin console:  This is how you manage your operations, although most of it is automated.

5.  Data Store:  As widely expected, this is BigTable, not SQL.

In terms of the problems Google means to solve for their “customers” it consists of the following:

1.  They’re all about running web applications.  This is not a platform for scientific grid computing or massively scalable search engines (chuckle).  Hand them an URL to your (Python) code and they’ll suck it in and serve it up.

2.  They want to own the whole lifecycle.  That means request logs, app logs, running the DB, pushing new versions out, the whole workflow linking your development to operations and delivery.

3.  They’re providing access to the same infrastructure and building blocks Google uses for all its apps:

–  Google accounts:  This is big.  I have said before Amazon needs to deliver an identity system, and preferably based on OpenID.  Google has it.

–  GFS:  Google file system, their Amazon S3 equivalent.

–  BigTable

–  Other Services such as E-mail

4.  Costs.  It isn’t free, as Dave Winer and others suggested, but it starts out free.  You get 500 MB of free storage, 200M cycles/day of CPU time, and 10 GB bandwidth up and down per day for free.  This let’s startups develop on the platform and pay when they start to get traction.

How do I sign up?

The first 10,000 on a first come first serve basis can join the beta test.  Be on the lookout, possibly here. 

A few brief observations:

–  This is a great collection of functionality, and it is a step beyond what Amazon has offered.  They’ve moved higher up the stack by providing first class language support, albeit for Python only initially, rather than just raw virtual machines.

–  Many likely lament that it is limited to Python.  That’s to be expected from Google, but it is temporary.  Other languages will be supported.  Not sure what this may mean for a small outfit like Heroku, which does something similar for Ruby on Rails, but I have a hard time seeing Google not doing Ruby.

–  The Cloud Computing timetable just ratcheted the bar up a notch.  The arms race has begun.  I’ll stick to my 2 year timetable before entry of new players will be impossible.  Google has just raised the bar on what you have to get done in the 2 years.  Others may raise the bar futher.  Refer to my post on how these layers will unfold to understand how best to dance among the elephants without getting trampled.  Seems I foretold the desirability of moving up the stack to languages next!

–  The ball is in Amazon’s court.  They have a lot of momentum, but they will finally have to offer something beyond what they already built for their existing business if they want to keep up with Google. 

– Salesforce.com:  You may have bested Hasso Platner in your recent debate, but Google App Engine does exactly what Force.com does.  Both are front-end web app platforms, neither are batch processing transaction-intensive platforms.  Mr Benioff, your pricing model was already untenable, but Google just blew the bottom out of your boat.  It’s going to get a lot worse before it gets better!

And finally, well done Google!  And congratulations Python!  App Engine is good for both!