share
Stack OverflowWindows Azure vs Amazon EC2 vs Google App Engine
[+119] [18] iulianchira
[2009-04-26 19:30:05]
[ google-app-engine amazon-ec2 azure ]
[ http://stackoverflow.com/questions/791447] [DELETED]

From a developer point of view which platform would you consider for a large social web application? If you could provide some details on what you consider to be the strengths of which alternative it would be great.

(2) I've been comparing the same thing recently - posted my pros/cons on my blog. Azure is out (based on cost of a small project), but EC2 and Google App Engine are both strong contenders! blog.dantup.com/2010/10/… - DanTup - Danny Tuppeny
(2) This question should be community wiki. - rfunduk
[+200] [2009-05-02 08:41:21] Richard Watson [ACCEPTED]

I've written the same app on GAE (Python and now Java) and Azure. I'll probably continue to use both, for different things. Here are a few thoughts that I'll keep updating:

Reasons to use GAE:

  • You don't pay until your app grows quite a bit. With Azure, you pay almost $100 each month, even if you don't have a single website visitor. If your db goes over 1GB, you pay an extra $90 ($9->$99) for storage.
  • GAE's payment is also very fine-grained - only for the resources you use. Azure (and AWS) is "blocky" - you pay something for each server instance you'll run (plus resources), irrespective of whether it gets any use at all.
  • GAE has the lightest admin load. Once you're setup, deploying and re-deploying is quick and they'll auto-everything. For example, you don't worry about how many servers your app is using, how to shard the data, how to load-balance.
  • Mail just works. At the time of writing, Azure doesn't offer SMTP out so you need a 3rd party server.
  • Great integration with many of the Google offerings - calendars, mail, whatever. You can delegate user management to Google if you don't want control over your user base.
  • With GAE you know any features they add to the store, you'll get. With Azure, you get the feeling Sql Azure Database will get most of the love but it'll be more expensive. Azure Storage is likely to have the most gotchas. No relational integrity, no order-by, you'll fiddle with the in-memory context more. GAE's store has far fewer restrictions and more features than Azure Tables.
  • Good choice if you're using Python or JVM-based languages already. Many languages compile to Java bytecode nowadays.
  • Updating the app is very fast. For Python, I had a shortcut key setup and it took no time at all. I now use the Eclipse Plugin for Java and it works very well. Azure is more fiddly.
  • A locally tested app will probably run on the cloud without (much or any) changes. With Azure, the config is different and I spent some time stopping-deleting-building-uploading-starting before I got it right.
  • GAE has a great UI that includes a log viewer a data editor. With Azure, you currently have to find external viewers/editors for this.
  • GAE lets you have multiple versions of your application running on the same datastore. You can deploy, test a version and then set the current 'live' version when you're ready. You can change back if something goes wrong.

  • Reasons to use Azure:

  • I've read of users getting "I think you're a robot" messages, like sometimes pop up on other Google properties. I haven't seen it, but it would alarm me.
  • Azure seems to be better designed if you have a SOA-type approach. Their architectures seem to benefit from experience in the enterprise world. GAE seems more focused on simply serving web pages.
  • You can run the app under debug, put in breakpoints, etc.
  • Azure has a "staging" environment where you can deploy to the cloud, but not make it live until you're happy it works.
  • I'm using .Net for other things, and integrating them with .Net on the backend is much easier than with GAE. (Update - using Java on GAE works fine, and the 10-second timeout is now 30 seconds).
  • Azure has two approaches to storage, offering more choice. They are SQL Azure Database (SAD) which is a relational DB, and Azure Storage, which consists of non-relational tables, blobs and queues. If you have an investment in SQL Server then SAD will be easy to move to, but is quite costly and might be less scalable.
  • Integration with many MS "Live" offerings.

    So, no obvious answers. I'm defaulting to App Engine at the moment because of costs and ease of use. I might use Azure for very MS-oriented apps. I use Amazon S3 for downloads but likely won't use EC2 because I prefer leaving everything under the application level to the experts.

  • (27) +1 for experience using both - hyperslug
    (10) Richard, maybe another plus for Azure is having a relational database. Bigtable's shards are a somewhat foreign paradigm. - hyperslug
    (3) Thanks hyperslug - changed storage point - Richard Watson
    (21) App Engine also allows you to stage multiple versions of your app. Each version gets its own URL that you can test, and when you're ready to deploy just mark that version as the default. Easy to test, deploy, and if necessary roll back to a prior version if something goes wrong. - mb
    thanks mb, updated. - Richard Watson
    Azure has pay as you go with no committments, purely on usage, its not 99$ minimum per month committment. - Akash Kava
    (1) On microsoft.com/windowsazure/pricing it says about SQL Azure: "* Web Edition: Up to 1 GB relational database = $9.99 / month * Business Edition: Up to 10 GB relational database = $99.99 / month * Data transfers = $0.10 in / $0.15 out / GB - ($0.30 in / $0.45 out / GB in Asia) " - Richard Watson
    Great comparison of GAE and Azure. Thanks - gyurisc
    @Richard - Thanks a ton for this answer - please do make a point of updating it over time. - Mark
    With GAE you can run in debug mode too (via the Eclipse Plugin) - Great job with the comparison!! - Gus
    The first reason in Azure is not necessarily a good one. What do you want happen on a DOS attack? code.google.com/appengine/docs/java/config/dos.html - Amir
    You can also use jsc to compile c# to java for use on GAE. Not production ready, but getting there: wiki.jsc-solutions.net/home/roadmap - Amir
    Amir - I think it's bad when it's a false positive, which I've experienced before on other Google properties. In any case I haven't read about it happening on GAE for a while. - Richard Watson
    1
    [+160] [2009-04-26 21:21:45] Nick Johnson

    I'm clearly biased - I work on the App Engine team doing developer relations - but this is my take:

    They're not directly comparable. There's a set of apps you could write for any of them, but you'll be writing a different thing in each case. App Engine provides a restricted runtime environment - no writing to files, no sockets, and so forth - and a non-relational DBMS. But in return, you get a runtime environment that scales indefinitely, and a reasonable degree of assurance that your app will scale as big as you want it to.

    Azure, on the other hand, provides a slightly less constrained environment, which lets you write a wider array of apps, but requires you to write more - since you're implementing more of the stack yourself - and provides a much looser assurance of scalability.

    Finally, AWS provides the ultimate do-it-yourself solution. They provide the hardware, and the storage, and not much else. You build your stack from the ground up, maintain it, upgrade it, and so forth. Your app scales if and only if you write it to scale, which is no small challenge. But, you get complete control over your hardware.

    My advice would be: If your app fits the App Engine model - and a social network app is likely to be a pretty good example of ones that does - write your app on App Engine (Java or Python, your choice). It's cheaper, and it's much easier to write an app that scales.

    If your app doesn't fit the GAE model, pick Azure or AWS, depending on if you're writing for the MS stack, and on how much control you want over the execution environment. If most of your app fits on GAE, but small parts don't, you might consider a hybrid - for example, live serving on GAE, but storage on S3, or bulk processing on EC2.


    (4) Great perspective, thanks! - Tony K.
    (1) Totally agree with you - Mash
    How do i favourite this response? Great information all round. Thanks. - JavaRocky
    What about issues like this one: When App Engine went wrong? - Cristian Ciupitu
    @Cristian I'm not sure what you want to hear - any service has occasional downtime. That includes both App Engine and EC2. - Nick Johnson
    @Nick Johnson: you're right, any service has occasional downtime and I'm not expecting an 100% uptime. On the other hand, that issue doesn't look like a downtime issue. To me it looks like a limitation of the Google App Engine, i.e. your code has to run in a pretty limited amount of time. I'm not familiar with GAE, so please correct me if I'm misunderstanding something. - Cristian Ciupitu
    (1) @Cristian Ah. The exception itself is thrown because of too much time spent executing, yes, but the cause of the slowdown was some temporary performance issues. - Nick Johnson
    I agree on the "they are not comparable". Comparing these services are like comparing apples and oranges. Both are fruit, that's about it. - Till
    2
    [+20] [2009-04-29 22:14:07] Alex Martelli

    Like Arachnid, I may be biased, being a googler. However, I'm also an Amazon stockholder, so that bias may partly offset the first;-). No Azure experience (though I also hold MSFT stock, so I hope they, too, do well -- yet another bias;-).

    My very simple take on it is that App Engine easily offers you the ability to work (within its limitations) just by coding -- no system administration tasks are needed. AWS is much more flexible, but you will need substantial system administration work (and not really trivial at all) to take advantage of that flexibility. So in the end I'd second Arachnid's suggestion: if App Engine can meet your needs, absolutely go for it; if you need more flexibility, AWS seems the way to go (unless Azure's unknown-to-me capabilities should be a better match -- but I think AWS is going to be more flexible no matter what Azure can do, for example with AWS you can even pick which OS to use, if you need that).


    3
    [+19] [2010-04-27 10:42:11] lucvdv

    For me, lock-in is the deciding factor.

    If you choose for Google, your application will work only on Google. If you find yourself being less than satisfied after some time, you're stuck.

    If you choose for MS, your application will work only on Azure. Same thing.

    At Amazon, you get (a) virtual server(s) that work exactly like the machines you're used to. Not satisfied? Pick up your app, install on real hardware, done.


    (2) GAE can run fairly standard java servlet applications, and can use standards-based persistence. - Stephen Denne
    (3) GAE is completely open (though you'll need to stick with using a JDO storage API.) - Mark
    You can get locked in to the Amazon extended services just the same, like SQS, EBS, and a lot of other acronyms. - tadman
    (1) Does Google still limit the amount of data you can get out at a time? Their lockin is based on data more than code. - Mark Ransom
    The JDO/JPA implementation on GAE does not really 100% follow the Java standards. You can't really just implement a complicated app on GAE that uses the DataStore and then suddenly move it to mysql. There are just too many specific differences about how you would implement something on top of the DS compared with a rdbms. - Jon Stevens
    @Mark We have never limited the 'amount of data you can get out at a time'. You can use the built-in bulkloader service, or write your own code to upload and download data in any manner you wish. - Nick Johnson
    @Nick, sorry if I made an incorrect statement. I remember reading about this being a problem at the launch of the service and haven't really kept current with it. If I recall it was related to a limit on what you could get back from a single query. - Mark Ransom
    (4) You can use AppScale to run your apps on EC2, or anywhere else you want: appscale.cs.ucsb.edu - Amir
    @Mark Ah. Yes, queries were limited to 1000 results. That was never an issue for bulkloading, however, as it was always possible to 'page through' resultsets by providing bounds on the primary key, which is what the bulkloader did. Now, we provide built-in cursor support, which makes this even easier. - Nick Johnson
    (3) Ran across this today, someone was able to transition off of Google in a week. They also admit that it could have taken months if they hadn't used good practices from the beginning. carlosble.com/?p=719 - Mark Ransom
    4
    [+11] [2009-04-26 19:34:59] Mash
    • If you're .NET Developer - go to Azure.
    • If you're on Python or Java - go to Google.
    • If you're on Ruby - go to Amazon

    My personal choice right now would be Google with Java (even if I'm .NET most of the time). Think about costs - their schema is difficult to compare.

    Check out this article - http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure


    (6) Not all .NET developers should go to Azure. Amazon EC2 is a perfectly acceptable option for them. But +1 for referencing the excellent article. - Andrew Arnott
    Yes, Amazon is somewhat freedom of virtual machine, but the community mostly Ruby oriented initially... - Mash
    (1) AWS does support .Net developers on their Windows 2003 Server AMI but I suspect a good number of .Net developers would rather be deploying to Windows Server 2008 which has yet to materialise on AWS. If you're a regular on the AWS forums you may have picked up that Amazon is some what quiet on this issue. - Richard Dorman
    (1) I'm a .NET developer by trade, but the price of using Azure for a website getting 0 hits sent my Google's way. I wrote some comparisons on my blog: blog.dantup.com/2009/12/… blog.dantup.com/2009/12/… - DanTup - Danny Tuppeny
    I agree that AWS/EC2 is a perfectly acceptable solution for .Net devs. While I too wish that I could deploy to 2K8, their additional services and pricing are tough to beat. We use SimpleDB, S3 and SQS extensively with a mix of CentOS frontends handling our content needs and backing up to WCF services, balanced using ELB, which feed our enterprise services (behind our firewall) through SQS and SimpleDB. It's a terrific dev platform - IMO. - Hal
    I'm a .NET developer who can't stomach Microsoft's prcing model. Why pay $100/month per site when simple web hosting is so much cheaper? The scaling model and pay-per-use of app engine has made it attractive enough for me to dust off my Java skills. - Mark
    (2) If you're on Ruby, consider Heroku or EngineYard instead of Amazon. - andy318
    @andy318 +1 for Heroku - slf
    5
    [+10] [2009-04-26 23:58:20] Alexy

    I've just started working with Azure, and am already impressed you can do it in F#: http://code.msdn.microsoft.com/fsharpazure! So far, it's the only cloud platform allowing one to use functional programming in a managed way (of course you can do Haskell in EC2... or Algol 68 for that matter). I'm very impressed with the quality of Visual Studio integration -- you get a local "cloud" to test, DevFabric, with a storage which is a real SQL Server, so you can play before uploading. Can GAE do that? Looking at Azure, learning VS with F# (coming from Linux and OCaml), I wish I'd have switched to MS stack long ago for it. It's super easy to create SQL storage and inspect it in VS -- comes very handy. Open Source does not have a matching toolset and it's time folks give MS a fair consideration -- they've done an awesome job here. I'm surely sticking with my Mac OSX base (dual-booting into Vista), and my hunch is, with the ability of Azure to be developed locally, I'll be getting a separate Vista box for Azure development. .NET is truly overwhelming when you come from Unix pipe world -- PowerShell, SQL and LINQ, C# and F# (which is my key reason) -- but it turns out it all adds up and is worth learning in addition to, not instead of, Linux; and in all cases, Azure will widen your horizons.


    (1) Azure does not have something that even remotely matches to functionality of Amazon Elastic Map Reduce (based on Open Source Hadoop). It does not even allow to set number of worker roles programmatically. - Rinat Abdullin
    (3) Microsoft are clearly trying to monetize their .NET developer base, and it's true that there is benefit to leveraging the Microsoft stack. I'm not convinced that this alone makes up for the expensive, blocky costing model. The whole point of cloud computing is zero maintenance pay-as-you-go elasticity, which Azure doesn't yet offer. - Mark
    You can use Clojure in GAE. the-deadline.appspot.com/login - edwin.nathaniel
    6
    [+7] [2010-11-01 15:50:01] Jon Stevens

    As much as I love GAE, one major reason why I'm going with EC2 over GAE for my current project is that I need to be able to have the front end of my application serviced from data centers located in different parts of the world. GAE runs in one data center at a time. For example, I need users in Asia to hit servers in Asia for the fastest response times possible for my application. Add on the ability to manage dns, load balancers, database of choice, flume pushing into S3 for hadoop processing of data, etc... and EC2 becomes a really compelling solution.


    7
    [+3] [2010-03-28 23:02:44] Spanky

    Some things to consider:

    Getting up to speed: how quickly can you get productive with the chosen environment what kind of docs exist and are they clear and well supported samples apparent and useful

    Cost: cost is a factor, but if you are making a commercial App that will actually have customers, these are all viable choices. If you assume that Azure, with one proc on a "small" instance runs for about $90 a month for 24x7 use... how many users can you service in that time? Add a second instance for redundancy... still not that costly if your traffic warrants it. If it doesn't, why are you in the cloud instead of at a cheap hosted provider? Larger cost factors come in your time to implement this. AWS is a roll your own solution. That's a lot to handle to get a solution that will be stable and well managed. Azure and GAE have that out of the box. In my mind AWS is the most expensive due to the work you have to put into it. Do you really need control over it at that fine a level of granularity? If so, blow the wad and buy your own boxes maybe...well AWS will still be cheaper than the hardware costs.

    Ability to do what you want: AWS all the way. Azure is second, GAE is third. No biggie if what you want is Java and Python. Biggie if you want to do relational DB or extensive multi-threaded data processing in C++ (not sure if any of these do this now?).

    What about portability? Can you take it back to your own farm later or move it to another cloud farm? They are all portable to some extent.

    Lots to think about... still learning about this myself.


    TyphoonAE and AppScale are great tools for running GAE apps elsewhere. - Noah McIlraith
    8
    [+2] [2010-12-12 00:23:16] user526498

    Here's some other considerations.

    GAE - Sits higher on the platform as a service stack then AWS and Azure, all traffic routed through their ghs.google.com DNS, dynamically loading serving your page through one of their machines, which allows them to keep prices low. scaling is fine grained with this approach, Cons is no static ip, prone to being filtered or blocked. From the no static ip limitation, you'll not be able to setup any site specific https cert.

    AWS and Azure gives you pretty much a static IP and a dedicated VM, allowing for such basic requirements like a https cert. you'll also get relational storage support. Cost is also higher to reflect this dedicated VM fact, and you'll scale per VM so in 40 dollar/month chunks. advantage is that since you get a VM to yourself, you're not constrained to the 30 second cpu processing limitation on GAE, and can run larger tasks.

    So if your considering customer bases in filtered countries, or want a static IP to do your own DNS setup, or have requirements that need relational db or more than 30 second tasks. AWS, Azure would be much more friendly to work with.


    9
    [+2] [2010-02-17 15:14:13] user217600

    If you select EC2 and you are using .Net consider using Visual Studio addin to manage EC2 - http://www.ec2studio.com


    10
    [+2] [2010-03-06 22:32:13] Peter Knego

    If you need to start instances manually to meet the demand then it's not a cloud.

    Azure and EC2 are just virtual servers with some services on the side.

    Update:

    EC2 and Azure do give you options to manage starting new instances automatically under load, but you still have to manage this. And you pay for instances that are up and idle.

    GAE handles this automatically out-of-the-box and it only charges you for the time when your code is running during requests.


    (1) I think Amazon CloudWatch solves the problem of starting additional instances based on the traffic. - Nirmal
    One of the most common demos I have seen for Azure is the scalability demo where they write some code to set thresholds to spin up or spin down web workers based on the load. its covered in the windows azuer trainining kit : microsoft.com/downloads/en/… - MikeJ
    11
    [+2] [2011-02-15 22:21:43] HappyCoder

    I don't have enough reputation to leave a comment for one of the answers above. The suitability of any of those cloud solutions depends on many factors including your needs and skill set.

    I have a social networking project that requires a nosql database. AppEngine would be a good solution if it had better support for the various frameworks. Django with nonrel adapter works on Python GAE, but I prefer Rails for many reasons. Rails3 has been out for a few months and no one in the community or on the GAE team has written a recipe yet to support it. Unless you have the skill set--knowing ruby and rails internals, jruby, and GAE internals--to write your own recipe, you're at the mercy of other people just to get on the platform.

    AWS is a lot more work but at least you can get on the platform with whatever tools and deal with many issues administratively rather than as an internals developer or supplicant to higher powers.

    My complaint about Heroku and EngineYard, for Ruby developers, is the mystery about how databases scale. How do they scale?

    In my case, I'm opting for a NoSQL solution and Mongo seems to be a good choice. MongoMachine seems to be the recommended solution for the likes of Heroku or EY but it is mad expensive. $2.50/GB storage? Storage is only $0.10 GB/mo on GAE or EBS.


    12
    [+1] [2009-05-01 09:19:51] Joo Park

    Look at the solutions each cloud offering provides and go the hybrid model. Some problems require a hammer and others a screwdriver. Get to know your tools and apply it to the right problem.


    13
    [+1] [2010-09-04 12:58:31] Doobi

    One thing not mentioned here, is what anyone considers of the "Windows Azure AppFabric Service Bus & ACS" besides the horrendous name...?

    It appears to be a really powerful stack of integration features that would make Azure appealing from the perspective of any business with an investment in on premises infrastructure.


    Yes, but then the flip-side is that Microsoft have officially said "No" to on-premises Azure hosting for businesses, which detracts from the appeal of the bus. - Mark
    (1) While true in name, that's not true in practice, Microsoft offers a very compelling private cloud stack with Hyper-V (which is free) and things like Systems Center & InTune, it's just not "Azure". If you want that there will soon be the option for "Azure Appliances" for 3rd parties, but you have to be pretty huge to justify those costs. I heard you need to support a minimum of around 1000 nodes, so it's more for Datacentre owners. - Doobi
    14
    [0] [2010-08-12 18:11:50] Jeff

    Azure has Windows/SQL as a server "Platform as a Service", and you are definately NOT stuck, just go back to Windows/SQL in your own datacenter (No linux, but yes they support Java, Python, PHP, Ruby, Tomcat, Apache, etc.). Like Amazon, they will be providing the fully accessible Virtual Machine option as well, so you can install/run whatever you want.

    Amazon has is Virtual Machine only, so you still have to intall, patch, license, secure, etc... Kind of defeats the benefits of moving to the cloud in my opinion. You've just moved something from your datacenter to another.

    Google has no relational database and you'd be STUCK. They really only cater to Python developers and some limited support for Java. They really are not a player in the cloud space from my opinion.


    (3) Jeff - having trained Microsoft partners on SQL Server 2008, I'm definately fond and familiar with the benefits of the Windows/SQL stack, but I'm hard pressed to agree that one is STUCK with Google's BigTable. There are half a dozen or so good libraries that wrap the BigTable API, exposing it as everything from a psuedo RDBMS to an indexed document silo. BigTable was engineered ground-up to scale across many servers (Google found the sweat spot was 1,500 per cluster), which is a feat that SQL simply can't do well. - Mark
    15
    [0] [2010-12-24 13:16:50] Bill Barnhill

    After experimenting Amazon EC2 for a while and hitting some delays I've started researching Google Apps while experimenting due to cost. I'd prefer Erlang as the development language but can deal with Python, so that wasn't a deciding factor. When I saw no static IP, that was. Also the whole part about it being higher up on the stack makes me a bit nervous with respect to performance.

    I wish AWS was cheaper, but until Google provides static IPs and preferably additional languages such as Scala, JRuby, and Erlang, the choice is clear for me: AWS. The first two languages should be simple too, they are both JVM based. May even have been done already through work-arounds, as I seem to remember reading something about that.


    16
    [0] [2011-01-24 08:13:44] Rajshekar

    Guys I think apart from just thinking about what platform it supports the comparison should be on Scalability, Ease of access, Versatile (in terms of implementation) , can accommodate different hosting platforms, equally economically viable for the business case, has multiple solutions for enterprise applications (viz. storage, delivery, bandwidth, licensing policy etc.), track record credibility of quality of service, Security audited, Transparency in billing as well as costings etc. If you look at all the above metrics I feel AWS scores much above. I am managing 10 production accounts on AWS since 2 yrs & at the same time the company / business unit were able to satisfy customer's huge scalability demands.... No doubt on AWS one needs to maintain the infrastructure, Updates (if any / if required), security etc. But you have all the tools available in the market / net freely. Existing IT resources can maintain all the infrastructure on AWS too.

    Azure sure has an integrated IDE with VS 2010, but actual costing of any cloud will start after successfully deploying the application (platform for deployment). Still a long way to mature to address real time deployment / scalable production scenarios....... As everyone knows MS plays many hidden agenda's on costings.. very difficult to make out the costs incurred or going to incur (while sending out estimates).

    GAE is very specific for Python / Java apps. Huge effort (both in terms of resource + cost) in getting the application rewritten (existing), tested , deployed etc.


    17
    [0] [2009-04-26 21:35:00] alkar

    I've started experimenting with Google App Engine fairly recently, and for a web social network I believe it would serve all your needs. It's easy to get the hang of it and can be used either with Python or Java. It is true it doesn't give you access over files, but for your application, GQL (the SQL-like interface to the database they provide) will probably be more than enough (and it's quite robust).

    One thing you might want to consider, is that an application on GAE can use an interface that will let users with Google Accounts, or accounts on a domain using Google Apps log in (a shortcut). You choose either of these. So if you already use a Google Apps Website, Google App Engine would be a great choice for you, as your users wouldn't have to register new accounts.

    EDIT: As Arachnid pointed out, it's not that you can't code your own login system. Sorry, if I got you worried there.

    As for the other two alternatives, I have only read about them and not tested them. But I believe GAE provides an easier framework, from my research, and as you mentioned great prices.

    In any case, you can try GAE out using the free quota on space and bandwidth and see if it fits your needs.

    Best of luck.


    Nitpick: GQL isn't the database. GQL is an SQL-like query language for the Python runtime, written on top of the datastore. You don't even have to use it - there's also the Query API. - Nick Johnson
    Also, You can sign in any users you want in a GAE app - it's just that GAE provides a shortcut for using Google accounts. - Nick Johnson
    Right, bad choose of words in both cases, thanks for pointing it out. Will edit it :) - alkar
    BigTable is Google's data storage engine, and after spending some time with it, I began wondering whether I've spent my whole career being brain-washed into thinking that SQL RDBMS's are essential to writting web apps. The BigTable storage model is simple, flexible, performant and scalable, and works surprisingly well. - Mark
    18