Google has just launched Google App Engine, "a developer tool that enables you to run your web applications on Google's infrastructure." This will allow startups to use Google's web servers, APIs, and other developer tools to build a web app on top of. Google clearly has the scale and smarts to provide this platform service to developers. However, it begs the question: why would a startup want to hand over that much control and dependence to a big Internet company?
Let's firstly review what this is - and what it is not. Google App Engine is similar to the Amazon Web Services stack, which rolled out at the end of 2006 and has since gone on to be utilised by many startups for their infrastructure needs. But it is not a set of standalone services like Amazon's - which includes S3 for storage, EC2 for hosting and the SimpleDB database. Google App Engine is an end-to-end service and bundles everything into one package.
In that respect Google App Engine is more like the so-called "Platform-as-a-Service" (PaaS) apps like Bungee Labs, which we profiled firstly in April 2007 and then more recently in February when it launched a new version. Other PaaS contenders include Salesforce.com's Force.com platform (nicely summarised by Dan Farber) and Morfik's Ajax platform.
Google App Engine launches as a closed Beta, with 10,000 developers granted access on a first come, first serve basis. It's free, but during the preview period applications are "limited to 500MB of storage, 200M megacycles of CPU per day, and 10GB bandwidth per day." It has a good set of initial features, which Google's Matt Cutts summarizes well:
"You can store your data in a Google Bigtable using the Google File System (GFS). There’s a bunch of App Engine APIs to simplify things like sending email and fetching urls. Your application can authenticate users that are using Google Accounts, so you can avoid the whole “ask your users to create a new account” issue if you want."
So it's a good start and you can imagine that this is just the beginning, as anyone who has read Nicholas Carr's excellent book The Big Switch will realise. Computing infrastructure is rapidly turning into a utility and Google App Engine is yet another example of this.
There are many compelling reasons for startups to use Google App Engine; and Alex Iskold summed them up in his post Reaching for the Sky Through The Compute Clouds. Alex explained why the likes of Amazon, and now Google, are providing a valuable service to startups:
"We are witnessing a fundamental shift in our ability to compute and this is just the beginning. Amazon is at the forefront of making massively parallel, web scale compute services available to the world. Free from the need to solve the scalability problems, startups are able to focus on the specific problems that their product or service is trying to solve. All of this is happening while the cost of hardware, bandwidth and services overall keep dropping."
(emphasis mine)
However, there are a few downsides to the Google approach. For one thing, it means developers must use Python as their programming language - PHP and Ruby are two other popular languages today. But looking at the bigger picture, startups which use Google App Engine are essentially tying themselves into Google's technology. They'll need to host with Google, do their processing with Google, store their data with Google, etc. And as some people have already speculated, having a web app built and deployed with Google App Engine makes it much easier for Google to eventually acquire that web app.
It does make you wonder: would you want Google to control your entire end-to-end development environment? Isn't that what developers used to be afraid of Microsoft for?
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
Take a look at my post on cloud computing:
http://deftlabs.com/2008/04/gazing-into-the-clouds/
Posted by: Ryan | April 8, 2008 5:07 AM
All due respect, Ryan, but there is nothing new or interesting in your post on cloud computing...
@Richard: you got a point - everyone should be at least a bit 'wary' when developing against this new Google platform, but so is the case with Facebook and all the other platforms.
So - in 'Dont be evil' we trust...
I liked the example with M$ though....
Posted by: Esdee | April 8, 2008 5:31 AM
@Esdee: isn't there a big difference between taking a platform risk because you want to reach that platform's audience (e.g., a Facebook app) vs. taking a platform risk for building an application unrelated to the platform itself (e.g., GAE)?
I still think the GAE platform is exciting, and competition in the PaaS market will accelerate benefits for everyone. But I also think that the risks of selecting a particular platform go beyond just their asymptotic 100% uptime. There's API change risk, cost structure change risk, terms of service change risk, etc.
Kudos to Google for their "don't be evil" motto, but good/evil are not black-and-white. Gray areas are where the majority of business and life struggles and thrives, and if you're going to have your business depend on someone's platform, I think the gray is worth a little closer analysis.
Posted by: Scott Brinker | April 8, 2008 5:58 AM
about the privacy thing, we are on the way to where everybody will be able to know anything about anybody, relax and enjoy the ride
as to the functional value of this google release, the obvious has already been said, i wonder what the unseen implications may be
Posted by: gregory | April 8, 2008 6:01 AM
I guess I see two things:
(1) They're using python, so you could conceivably port your app out to another provider.
(2) They force you to use their google-specific libraries to do things like file storage, making it harder to port out.
If you're a developer, you could abstract away the google-specific stuff, but that's extra work.
Longer term, I'd like to see if the google-specific stuff makes it out into the open source world. The sdk is under an apache 2 license, so nothing is to prevent the interfaces to the libraries being copied, if not the implementations at Google.
Posted by: Bud Gibson | April 8, 2008 6:08 AM
Its a trap!
Posted by: Jason | April 8, 2008 6:20 AM
>>It does make you wonder: would you want Google to control your entire end-to-end development environment? Isn't that what developers used to be afraid of Microsoft for?
Excellent question. How long will the Google "do no evil" mantra last? Is it already gone? Once you take billions from Wall Street, your company strives for one thing and one thing only: profit. If your startup develops an online app or other web service that's a hit, how hard will it be for the startup to then get out from under the Google platform? Google's goal in offering this free service has to be to make money. How do they make money off of the users?
Posted by: Joe | April 8, 2008 6:33 AM
Richard
Just throwing CPU cycles and storage space does not make a vendor wares a Platform. Ability to provide entire stack is critical. For all the people you should know, you have written excellent article way back in 2005. Here is your URL.
http://www.readwriteweb.com/archives/defining_web_as.php
Cheers.
Posted by: Little More | April 8, 2008 7:05 AM
There are currently big differences between a bungee and a Google platform service. Bungee, Keroku, and more to come, offer an IDE, a well as push button deployment of various flavors that will never look like a Google (and may never have to).
But it's too early to call the future: I think you are calling the play way too early. Chances the service will remain without Ruby support = 0, ditto PHP. They need a community.
Account access as mandatory for clients? That's sure to be eliminated. It's too early to tell any of these things.
All of these services are fully formed in-house for use by the Google indentured staff, so it's just the retail packaging that needs to evolve.
Too early to call the tune.
Posted by: abm
|
April 8, 2008 7:08 AM
Google's offering is just for playing around now. At least with AWS, you can use it a la carte. If you are serious, you need to use Applogic by 3tera.
Posted by: a911driver | April 8, 2008 7:32 AM
In your paragraph about downsides, it's noted "as some people have already speculated, having a web app built and deployed with Google App Engine makes it much easier for Google to eventually acquire that web app."
I'm guessing most startups wouldn't see that as a downside.
Posted by: Aaron B. Hockley | April 8, 2008 7:34 AM
@Aaron: increase likelihood of Google acquiring a GAE-based start-up, yes; decrease likelihood of Microsoft, Yahoo!, Amazon, etc. acquiring a GAE-based start-up, probably true too. Not sure that the bargaining power shifts to the start-up so much as it does to Google.
Posted by: Scott Brinker | April 8, 2008 7:40 AM
I'm going around all the blogs begging for an invite, seems they are full already.
I'd like to give it a whirl.
Google can serve eggs in the morning cooked on the drives I burned out with high-traffic ideas.
Posted by: Ferodynamics | April 8, 2008 7:48 AM
This seems so very much like dark days of the Microsoft OS monopoly. Who can forget the memories of; stifled competition, and price fixing. In this case Google does the arm twisting AND knuckle cracking by dropping the pricing of a service to free. Goolge is using the advantage of massive scale built on the backs of consumers and media to choke the life out of them and any competitor.
Do we now face a world where all apps are run on the google platform and coded to their specifications. Have we forgotten what happened to Borland, Netscape, and Novel.
Make no bones about it; Google is trying to be the next OS at any cost. If they go on this path unchallenged we will see the snuffing out of a vibrant industry that was once the home of rebels that believed in the possibilities and the freedom of choice.
It is also clear that Google is the biggest danger to Open Source software that we have ever seen.
Where is the cloud/OS for those of us that want a choice and don't think its a good idea for one company to own the very life of the internet.
We at adelph.us will be launching an alternative
"You take the blue pill and the story ends. You wake in your bed and believe whatever you want to believe."
"You take the red pill and you stay in Wonderland and I show you how deep the rabbit-hole goes. Remember -- all I am offering is the truth, nothing more."
from the Matrix written by Andy Wachowski & Larry Wachowski
Posted by: william | April 8, 2008 7:49 AM
Well, I looked it over. You will be an unpaid Google developer if you want to use Google App Engine. I guess your pay is the free Google App Engine service...whoopee! That's it! The problem here is that your application is not portable. You essentially let Google have full control over your back end. With Amazon AWS you have total control over the way your application and data are maintained. You can easily move your application to someone else if Amazon's service deteriorates. Even S3 can easily be replicated using something like MogileFS (we do this). Google forces you to use Datastore and GFS. They even want you to use their entitlements system (which is nice but not if they control everything else).
Don't get me wrong. I am very happy that they are doing this, but I would be very cautious about building a business completely on this service. Perhaps I would tie it into my Amazon AWS application, especially the email and entitlements pieces. In fact it makes more sense to me to use the Google App Engine as an interface into the pieces of Google that I would really like to use in my own app. I wonder if the ToS allow it?
Doug K.
Posted by: Doug K. | April 8, 2008 8:10 AM
Google are offering you to upload apps written in python and use their resources to jazz it up, and then publish it online immidiatly..
It's an example of a growing trend.
Microsofts Popfly.com is another example of this exact same trend.
On the surface, they seem completely different from eachother, one is a hosted service, where you can build apps using python, and the other is a hosted service where you can build apps using silverlight.. umm..
Maybe they aren't that different after all..
Both is about simplifying the process of creating an app for the web by setting up the backend as a hosted enviroment.
Webservices and/or mashups are being dealt with differently, but the idea is the same, to minimize the costs, the time and the actual work required to realise a web application and publish it.
Almost nobody seem to be willing to do this for javascript though, and nobody seem to be willing to let them out of their sandbox either.
It's like hotel california, you can check out, but you can never leave..
The problem with that, is what happens if the hosting service dies.
Take YouOS.com for example.
The service is dead as a doornail now, I know, I talked to the guys behind it and it's not happening anymore.
It's a shame, but the site is just sitting there until the server either goes down, or is harvested for some other project.
So, there's over 700 apps that went down with that ship, which equals an awful lot of hours of developing apps, testing apps, and finally deploying apps on a platform which is now defunct.
Bam, all gone, instantly.
That's a bummer, but that's what's going to happen to you if you invest in a platform that you can't leave.
If you are locked down, you will go down with the ship.
That's why it's important to go with something that you can take with you back home, and then deploy elsewhere.
Now, I dont expect either google or microsoft to die anytime soon, but they aren't exactly dedicated to all of their webprojects, are they?
They tend to abandon things that aren't immediately a success.
And if it does take off eventually, they start charging for what used to be free, and that means changes to how it's set up.
It usually means starting over from scratch for developers in any case.
Posted by: Mikael Bergkvist | April 8, 2008 8:28 AM
Seems there may now be a market for a middleware layer that abstracts a web application away from the DB/Storage/Server implemenation, and runs on GAE/AWS/etc, to allow you to Build-Once-Run-Anywhere. Meta-Web-Service-VM? :)
Posted by: dan levine | April 8, 2008 8:51 AM
Not only do you end up being locked into their APIs, you also hurt your possible company valuation with this. I wrote more about that here: http://www.geekzone.co.nz/foobar/4846
Posted by: foobar | April 8, 2008 10:27 AM
Golden handcuffs are still handcuffs.
While this may seem to be a boon to someone with a laser focus on getting deployment of their application done ASAP, using GAE is not a wise long-term decision.
As Richard and others have pointed out, the entrepreneur will find him/herself beholden to Google. It is exactly like the old days of choosing between Microsoft's "embrace and extend" proprietary web protocols vs. Java/Javascript. The effort required to port in the future will severely limit your options when perhaps you might most need options: for example, when you suddenly determine that some changed terms and conditions are no longer acceptable to you. Or when it becomes clear that "Do no evil" has exception clauses.
@3 Scott Brinker: You are spot on about the comparison between this and Facebook: there is no reasonable comparison.
Posted by: DaveA | April 8, 2008 11:57 AM
To all those fretting about lock-in, chill.
It's based on Python (open source) and lets you use other Python modules like Django (open source). There are bits that may be proprietary now but could become open source, like their own webapp lightweight Web framework. And for anything that remains proprietary, it's just an API (e.g., BigTable/GFS). I feel fairly confident that somebody will come up with thunks that bridge the Google APIs with other services (e.g., CouchDB for storage), just as there are open source replacements for Amazon's S3. In the end, you will be able to deploy you App Engine app on some other hosting service using these replacements, should the need arise.
Is that possible now? No. Will it scale like App Engine itself? Probably not. But it won't be "Google's way or the highway" for all that long.
Posted by: Mark Murphy | April 8, 2008 4:46 PM
It still is like jumping the bandwagon thing. Though more players do mean more options.
Until GAE's Paas goes agnostic, we won't get to see real head-to-head competition for devs to mix and try.
But if you're into Rails now, small Paas players like the Morph Appspace continue to hold promise.
Great post with interesting comments.
Best.
alain
Posted by: friarminor | April 8, 2008 6:14 PM
don't forget about Nirvanix... they are similar to Google's new deal, and Amazon S3, providing the API to build an app on, except their bundle is fully loaded. They market a little bit more to the enterprise end of things, but the pay-as-you-go pricing allows businesses on both ends of the spectrum to enjoy the "full service" storage.
if you're interested www.nirvanix.com
Posted by: Rick | April 9, 2008 11:40 AM
I get this horrible feeling of... ubiquitous ownership of all information by Google. They seem evil to me and as one person pointed out above "all on the backs of consumers" who are footing the bill. It just doesn't seem right. They come blundering into an industry and potentially wipe it out by giving previously legitimate business offerings away for free. What if the Chinese offered free steel on the US market because it was subsidized by our trade deficit with them? They just thought giving away free steel would help drive customers to buy more Chinese toys and other goods? A bit far fetched I know but is this really that much different?
Posted by: gumly | April 10, 2008 7:51 PM
I've talked quite a bit about the issues around SaaS lock-in and how open sourced standards could solve this.
The innovation in GAE is in the provision of an open SDK and the current arguments about which languages are supported and how it compares to other PaaS (platform as a service), miss the point.
Posted by: Simon Wardley | April 11, 2008 3:56 PM
back to the mainframe age... the architecture proposed by google, amazon doesnt mean much if not the likes of IBM, SUN and SAP join the game. google is an advertisment company making its money providing free search on a private indexed copy of the majority of public web pages. this is comparable to radio, tv and press, not to the IT business. now they want to extend their data hunger to corporate data flows. there is a long way to go letting end users develop business processes in software, without having a clue about the processes themselves, e.g. the businesses. while companies worldwide might not trust enough in a US company under the more or less obvious influence of US national policies, agencies and most of all economic risks.
Posted by: pit schultz | April 14, 2008 7:33 PM