EC2 Vs. App Engine Vs. GoGrid Vs. AppNexus 109
snydeq writes "InfoWorld's Peter Wayner delves into the ill-defined realm of 'cloud computing,' providing a deeper look at four shared services: Amazon EC2, Google App Engine, GoGrid, and AppNexus. Offering wildly divergent amounts of hand-holding at various layers in the stack, the services simplify your workload but force you into a set, 'ball-and-chain-computing' routine that you may not prefer. Sure, the services allow you to pull CPU cycles from thin air whenever you need to, but they can't solve the deepest problems that make it hard for applications to scale gracefully, Wayner writes. He describes these 'clouds' as an evolving experiment, rife with potential but 'far from clear winners over traditional shared Web hosting.' The sobering look at the trend includes a QuickTime tour of each service — EC2, App Engine, GoGrid, AppNexus (those links all .MOV)."
Amazon EC2 wins (Score:5, Informative)
I run a small startup in the Boston area and have been using Amazon EC2 (plus S3, SQS, and the rest of the AWS family) for the last year. It's worked for us like a champ. A little downtime in the beginning plus some S3 outages, but with the right backup, failover, and restore procedures in place we've gotten reasonable uptime.
The big requirements for us were the following:
1. Ability to move our website (and code base) elsewhere if needed. Could be in-house, to another cloud provider, etc.
2. Minimize up-front cost and allow for massive scaling if needed
3. Cost competitive servers/computing over time
4. Cost competitive storage/disk over time
App Engine fails the first criteria, since (at least currently) you can't build a BigTable application on anything but Google App Engine. "Cloud computing" in general beat out traditional hosting on the second, third, and fourth points. I hadn't checked out GoGrid or AppNexus at the time, but other competitors (Sun, etc.) couldn't match Amazon's price-performance specs.
So, with all of those requirements, Amazon EC2 won out and I'm a happy customer.
Amazon does not automatically scale (Score:4, Informative)
Re:I prefer Google for Cloud Computing... (Score:5, Informative)
Of the four, Google seems to be the most limiting, at least on the surface. If I understand correctly, Google's offering requires the app to be written in Python and it denies some Python functionality such as file writes.
Amazon's offering, sitting at the other end of the spectrum, allows you to run a full instance of Linux complete with root level access.
The other two are not as confining as Google but more restrictive than Amazon.
On a side note, spam raining from the cloud has become a problem for at least Amazon. Some blacklists are blocking IP addresses owned by Amazon's EC2. If you want to run a mail server in the cloud, it just might rain on your parade.
Re:Wow (Score:3, Informative)
I highly doubt a majority of businesses are going to lock themselves into one hosting provider's specific development platform just to take advantage of hosted servers that push themselves into the next layer."
This depends on the service. Amazon's ec2 is basically just Xen virtual servers provisioned on the fly. s3 is a little weird but there are plenty of tools available to use it in whatever your application is running on. Code changes to support it are not all that difficult.
Re:Wow (Score:4, Informative)
SQL's scalability is next to nil for any real web application these days if all you are going to do is partitions. If you shard you get significantly more mileage but you still don't come anywhere near the reaches of Amazon and Googles simple database solutions. They didn't put all the time and effort into making those solutions because SQL scales well, they put the time and effort into it because SQL (and relational databases in general) do not scale at all past a certain threshold. Relational, partitioned SQL is for small to medium sized companies. If you're one of the big boys good luck keeping SQL up to speed with any type of real usage/growth.
I'll let Oracle and their customers running Oracle RAC that the "big boys" can't run relational SQL databases and that it is only for small to medium sized companies.
The "big boys" have been solving this problem for a lot longer than Amazon and Google have, so to appeal to their authority and the "time and effort" they put into making this product as proof that SQL doesn't scale is ridiculous. On the low end, there's sharding, and on the high end, there's scalable clustered SQL systems like Oracle RAC and IBM DB2 ICE. Making broad statements about some overall lack of scalability of SQL speaking from your MySQL and/or Postgres experience makes you look a little underinformed, when there are enterprise class solutions to SQL server scalability problems from major vendors, on top of the roll your own solutions you can do by doing partitioning / sharding.
On top of that, consider that database servers are optimizing for multi-core systems with things like parallel index scans, breaking up single indexes and joins into sub-processes, dispatched to different cores. This kind of scale up only serves to complement the scale out provided by sharding.
People who say that SQL is dead are just bored. Get over it.
PS. Go check out the TPC benchmarks for the biggest and baddest SQL servers you can buy to see how far people are scaling SQL up, and then explain why a few shards of those "big boy" SQL servers can't handle the load of any "real web application". Or go read the MySpace case study.
Re:The definition of cloud computing is still vagu (Score:5, Informative)
'the cloud' is old networking/telephony terminology. Describing interconnection of two sites, you'd diagram the systems at either end, and their local links, but once the links enter the network you don't know or care how the routing happens (generally). This part of the network was 'the cloud' (and was diagrammed as a cloud).
By inference, cloud computing would be where you know the computation is happening somewhere on the network, but you neither know or care exactly where.
See this thread back in 1995 -
http://groups.google.co.uk/group/bit.listserv.techwr-l/browse_thread/thread/d6384bd640275c43/14da0963ed1c294a?hl=en%0Eda0963ed1c294a [google.co.uk]
Or the first diagram in RFC 1587 (1994):
http://rfc.dotsrc.org/rfc/rfc1587.html [dotsrc.org]
I joined a telecoms company the year before that and the term was in use there, can't vouch for earlier.
Re:GoGrid Beta (Score:2, Informative)
Don't worry, I'm pretty thick-skinned. You have some valid questions that others probably have so I'm glad to help in what little way I can.
Currently you can't make your own images, but that is a feature request that is a common one. We do have other Linux distros, specifically, CentOS. We are working on Ubuntu among others as well.
Obviously, we are slightly smaller in terms of infrastructure compared to Amazon. However, we do have a 20,000 sq ft data center and understand hosting. Other products of our have multiple POPs around the world so things similar to "availability zones" is an obvious extension. Ok, I won't talk about the SLA with the exception of we do pro-actively issue credits. Did Amazon do that with S3 when it went down earlier?
You are right about competition. It's good for Cloud Computing in general and helps to drive standards and maintain good pricepoints. We encourage it. Hopefully we can move a bit more rapidly than the likes of Amazon or Google, but we don't have the vast resources as they do. We are 100+ and growing company (hiring as well!). I love your ideas.
In terms of failover for EC2, we whole heartedly agree in this stragegy. It makes sense. Currently, our persistent storage is tied to machine images but stay tuned on that as well.
Don't forget that $100 trial promo code I'm offering. Just enter "GGMS" in the signup page. Test it out and let me know what you think.