Google App Engine is LAMP 2.0

April 9th, 2008  |  6 Comments

“Ultimately, we are trying to provide an simpler alternative to the traditional LAMP stack.”Kevin Gibbs, App Engine Tech Lead

Google’s announcement of their new App Engine was a bombshell. A big, big story that probably inspired more analysis and commentary than any story since Facebook opened up their Applications to all developers.

So, how did most bloggers frame this story? They described it as a Battle of the Titans. Goliath vs. Goliath. Google vs. Amazon. Look through the coverage on TechMeme and just try to find an article that doesn’t compare and contrast Google App Engine to Amazon’s Web Services (EC2, S3, etc.).

But, comparing Google App Engine to Amazon’s offerings misses the point. Google didn’t set out to build a killer of Amazon Web Services.

Google set out to build LAMP 2.0.

Google App Engine and Amazon Web Services are Nothing Alike

Amazon pioneered offering Web services in the Cloud, and they have an extensive array of individual Web services on their menu. One service for servers on demand (EC2). One for storage (S3). Another is a database-like service for querying structured data (SimpleDB). And, those are just the most prominent ones; they’ve got plenty more.

By offering so many tools, Amazon provides a great deal of flexibility and power to complete a wide variety of computing tasks. Photo storage, backup solutions, next-generation search engines, video publishing, Facebook Apps, data analysis and big-time number crunching…they’ve all been built with Amazon’s Web services. Now, to use all that power, you need a great deal of sysadmin smarts. But, if you’ve got the system administration know how, then you’re not limited to building only Web applications. You really can build just about anything.

In fact, when Amazon’s on-demand server farm was first introduced, it was best suited for offline tasks, and it wasn’t all that great for building complete Web applications. You couldn’t get a static IP. Amazon didn’t offer a database service. And, if you ran MySQL on an EC2 instance, you had to be very careful about your backup strategy, because if your EC2 instance went down unexpectedly, then your database files disappeared as well. To their credit, Amazon has been constantly iterating and improving their Web services, so with the recent introduction of Elastic IPs and SimpleDB, building a Web app with their services has gotten dramatically easier.

In contrast, Google is not offering developers a la carte access to individual pieces of their infrastructure. We don’t get the ability to run MapReduce tasks on their infrastructure. They’re not offering API access to BigTable.

Instead, Google’s App Engine is designed for one thing, and one thing only: building and deploying Web apps. It may lack flexibility, but it’s a comprehensive system for building Web apps the way Google prescribes. (Given it’s “There’s only one way to do it” motto, Python is a fitting choice as the first and only language supported by App Engine.) How comprehensive is it? Here’s a quick list of things App Engine handles for you that you would have to do for yourself with Amazon’s Web Services: load balancing, deployment, versioning, and backups.

What’s So Great About LAMP?

Like the Google App Engine, the LAMP stack (Linux, Apache, MySQL, PHP) is also a complete system for building and deploying Web apps. It’s widely used because it offers a great number of advantages for developers:

  • Easy to code. Novices can build something and get it up and running very quickly with PHP and MySQL.
  • Easy to deploy. Since PHP is a standard apache module, it’s easy to deploy a PHP app. Once you’ve got MySQL running, simply upload your .php files.
  • Develop locally. It’s easy to set up LAMP on your laptop, build your app locally, then deploy on the Web.
  • Cheap and ubiquitous hosting. Even the cheapest Web hosts options allow you to run PHP and MySQL.

Sounds great, right? It is…at least until Web app starts attracting significant traffic, or your Web app gets slashdotted, or suffers from the Digg Effect. Then, unfortunately, your cheap, little, ubiquitous shared Web server just falls down and dies. Just when you need it most, your Web app disappears. That’s the biggest disadvantage to using the LAMP stack.

That’s not to say that the LAMP stack can’t be scaled. Facebook and Wikipedia are just two examples that prove that it can be. But, to do so requires considerable expertise and some serious cash. You’re going to need to beef up your Web Operations team to deploy an array of load balancers, memcached servers, and Web servers. You’re going to have to manage replicated and sharded MySQL databases. You’ll need to start worrying about geopraphical redundancy. And, once you have all these systems in place, then you’ll need someone to tweak and tune your Web machine to best handle the constantly changing traffic patterns for your Web app.

LAMP 2.0: The LAMP That Scales Cheaply and Effortlessly

But, what if scaling could be handled automatically? What if you could still build Web apps quickly, easily, and cheaply, and have it also scale automatically? What if deployment was still easy? What if you could still develop your Web app on your laptop?

Even better, what if you get all that, and then running your Web app was free?

No doubt these are ambitious goals. But, what if Google can actually follow through on all these promises?

Well, then I’d say Google will have just created LAMP 2.0.

UPDATE: Found a couple more interesting discussions about how App Engine is a significantly different offering than Amazon’s Web Services.

Nate Westheimer thinks that App Engine has more in common with Facebook’s Platform. I disagree with that idea, but in our discussion in the comments of his post, he pushed back against my “LAMP 2.0” idea, rightly pointing out that Google’s services were proprietary and closed-source, and so not very LAMP-like at all.

With my LAMP analogy, I was really trying to stress the completeness of Google’s solution, and it’s emphasis on making building and deploying Web Apps easy for developers, but perhaps the “open vs. closed” debate distracts from my point.

For that reason, I think that Rich Skrenta has come up with an even better analogy: Google App Engine is “Web Hypercard”.


  1. D Sanders says:

    April 9th, 2008 at 12:34 pm (#)

    Thanks. Best analysis I’ve read so far on this topic.

  2. Tom Offermann says:

    April 9th, 2008 at 9:49 pm (#)

    Thanks for the feedback. Glad you found it worthwhile.

  3. M L says:

    April 11th, 2008 at 1:05 am (#)

    Hi Tom, great post. Couldn’t agree with Nate as well. Hope you can drop by at and see what we have built for Ruby on Rails developers. Just like Google’s App Engine, things like load balancing, deployment, versioning, and backups are all taken out of the developer’s to do list on the Morph Application Platform.

  4. T R says:

    April 11th, 2008 at 10:09 am (#)

    Bombshell indeed!
    I am a sometimes Python programmer (who loves it) who homeschools a high school freshman (who is just learning Python also). I was planning to try Django (incorporated in GAE) for web app learning projects. So for us, GAE will be a perfect way to actually ‘go live’ — once they expand beyond the initial 10000. In the meanwhile, we will play with the at-home SDK — which in definitely simpler than LAMP for me.

  5. Talha says:

    April 12th, 2008 at 5:24 pm (#)

    gr8 post, thanx, i am not web developer, but like to know who owns the content, i read in gae term, google hv rights to look into login and personal detail, what about my user if my user load data into my site, ‘ll they hv access. thanks

  6. Tom Offermann says:

    April 12th, 2008 at 7:50 pm (#)

    @Talha: If you use Google’s Users API, then obviously Google is going to know who your users are. But, that’s completely optional. If you’d rather not force your users to use Google Accounts for logging in to your Web app, you can use your own user authorization system.

    As for users uploading data, I don’t think Google states anywhere that they have any claim of ownership to your users’ content. They maintain the right to take down “prohibited content” (see Google App Engine Program Policies), but that’s pretty typical of any Web host.