Google unlocks its data centers
April 08, 2008
The clouds open and . . . the face of Google appears. As long anticipated, Google is now allowing outside developers to write applications that will run on its vast network of data centers. The company's App Engine, now in a closed beta, provides a new cloud-based development platform that will compete with, and perhaps complement, the platforms run by Amazon Web Services, Salesforce.com, and others.
As it happens, I'm about to give a talk about the new cloud platforms, so I don't have time to write more at the moment. But you'll find more details from Richard MacManus and Brady Forrest (or you can go to TechMeme and enjoy the full force of the firehose).
To be honest, it's just a nice shared hosting solution. Other than the integrated Google Account authentication, it looks pretty much like MediaTemple's Grid system, or Engine Works's RoR platform.
Posted by: Thomas at April 8, 2008 12:06 PM
After sitting through the 6 videos posted over at Google App Engine (GAE) and browsing through the documentation for implementing a webapp, I have to say that this is hardly your typical glorified shared hosting environment.
Amazon Web Services (AWS) has unbundled the data center. GAE, arguably, is bundling the whole suite of application server, middleware, and data storage, built on top of fault-tolerant hardware. More like Akamai on steroids!
GAE is truly about turning a Big Switch on. With AWS, you still need to provision for server instances to cope with traffic.
Alright, as a webapp developer in my other slash career, I must confess that I am not totally unbiased in my optimism with the development. But hey, even a Turtle would not bet against the trend, especially after seeing so many breakouts.
The idea that I can just concentrate on developing a webapp and turning it loose on a free, scalable platform brings a smile to my face anytime! Now I just hope they start supporting PHP real soon.
Posted by: Allen Tan at April 8, 2008 01:01 PM
The "cyc" project had two defects, from a certain perspective. First, it was hard to get people to throw data at it. Second, it wasn't instituted in such a way as to really gain commercial advantage for its owners by application of Eliza-like AI. In short, it wasn't selfish enough to succeed and it was too frank about its goals to get hoi poloi involved.
Google has solved both problems!
Posted by: Tom Lord at April 8, 2008 04:10 PM
What is interesting here is how comfortable people seem with the intense level of lock-in on this platform. Even the Python code you write will be completely reliant on Google libraries.
On the other hand, if you are building a web business, this may be the best developer experience you'll find. It will be interesting to see how this evolves.
Posted by: James Urquhart at April 8, 2008 05:31 PM
Yup, I was wowed when I saw the announcement yesterday. But the devil will be in the details. They seem to have a long "waiting list" for new accounts, so I can't say what it looks like from the inside. One thing though, from the name I assumed it would be integrated with google apps, allowing me to write plugins and extensions to google sites, incorporate docs and forms, write scripts to manage users, etc. Looks like google is true to its internal cloud tradition: release first, and if it catches, integrate later. (I'm still waiting for groups to be integrated with the rest).
I want to write a web app that resides in some sort of interactive site, and mashes up data sources and visualization tools from across the web, isn't it funny that I have to implement google apps from scratch in google apps engine?
Posted by: yish at April 8, 2008 06:32 PM
Allen, I'll go and watch those videos. But I would see this as Google entering the hosting business, rather than a major innovation. Having said that, GMail was just a prettier interface in the well established webmail market, and that did nicely for Google.
What these people think of it is more important for its success than anything I think though...
Posted by: Thomas at April 9, 2008 11:53 AM
I agree with Thomas et. al. -- it's little more than just another Web-hosting platform. Do we really need another one, with so many affordable options out there today?
The difference between "free" (as in Google) and "cheap" (as in [insert Web hosting company here]) is more significant than you might imagine. One gives up a lot of ownership with "free." Cheap may not be free, but at least it's yours.
If you ask me, "getting into the Web hosting business" looks a tad lame for a company like Google. And as a software developer myself, I'm stumped as to the real benefits of using a shared, proprietary platform like that, aside from just the curiosity looking under the hood. To me, it seems tough to beat the freedom and flexibility of the status quo on this one.
Posted by: Christian Nunciato at April 9, 2008 01:35 PM
The innovation is in the provision of an open SDK and the current arguments about which languages are supported and how it compares to a HaaS (I know too much aaS, but you started this one Nick) environment, miss the point.
It has the potential to be much more than just another hosting environment or framework or platform as a service.
Posted by: Simon Wardley at April 11, 2008 06:32 PM
In addition to the (very important) open source SDK that Simon mentions, there is one other key innovation that separates a PaaS environment, like Google App Engine, from a traditional hosting solution: hiding of the deployment and operational complexity from the developer. As I have noted, this alone will open up scalable web application development to a class of developers that would have struggled to do so otherwise. Forte Software once did this for distributed application development, and I still run into developers that used that platform who tell me how much they miss it.
Do not underestimate the game changing nature of pushing more and more of the architectural complexity to the cloud. Soon someone's 13 year old kid will write a small app that does some little thing well, and he'll handle 1M page views a month without blinking...for free. Try that with a Java app in a traditional hosting solution, or even the new cloud solutions (e.g. Mosso)
1m views / (30 days * 8 hours per day * 60 mins * 60 sec) = 1 page view per second
For a normal php-nuke style site. Not hard, not hard at all :-) If it's not a normal web app, then who knows.
Posted by: Thomas at April 13, 2008 10:16 AM
Seriously. Do you honestly think ANY hosting provider (RackSpace included) is really hiding deployment to every layer of the stack--from middleware to OS to hardwar--the way that Google and its related ilk (e.g. Bungee) are? Which other hosting provider do you know of that is providing their own open source SDK?
This type of a solution is game changing for a limited (though lucrative) class of applications. Google is the most game changing because it has the most leverage to apply to the market. It doesn't eliminate the need for traditional hosting, SaaS or a variety of other IT needs, but it changes the way to build one particular type of application...probably for good.
Posted by: James Urquhart at April 14, 2008 01:24 AM
Which class of application is it game changing for? Why would you want an SDK? What purpose does an SDK serve here?
Google aren't hiding the scaling properties of their system. You still have to code around the performance characteristics of BigTable, etc. Some things that would be easy (ex. SUM(x)) on a normal SQL database would require far more work on BigTable. For many sites, the big constrain is image/media hosting, we've yet to see how Google will handle this.
It is interesting and clever, but App Engine is a continuation/refinement of what's already out there. For most webmasters who just want to put up Yet Another Forum Site, CPanel can offer click-to-deploy with most hosts already. Google's success in this will depend on how it stacks up against existing comparable solutions (e.g. LAMP) in solving the issues that people actually have.
P.S. Bungee does look like a nice way for regular users to snap together something small and helpful.
Posted by: Thomas at April 17, 2008 07:06 PM
Why would you want to hide deployment and operational complexity from a developer? Doesn't this just foster ignorance? Isn't it better to understand how to build software that performs well than to rely on someone else to second-guess and correct for one's technical weakness?
If the argument in favor of systems like this one is that they shelter developers from needing to know more about how to build scalable software systems, then I'd say it's inherently bad.
Posted by: Christian Nunciato at April 18, 2008 12:45 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)
"Riveting" -San Francisco Chronicle
"Rewarding" -Financial Times
"Ominously prescient" -Kirkus Reviews
"Riveting stuff" -New York Post