×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

EC2 Vs. App Engine Vs. GoGrid Vs. AppNexus

kdawson posted more than 5 years ago | from the seeing-shapes-in-the-clouds dept.

The Internet 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)."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

109 comments

The definition of cloud computing is still vague (5, Interesting)

strider2k (945409) | more than 5 years ago | (#24310053)

Even after reading the wikipedia article on Cloud computing, I still can't give a good definition of it. I know the general concept but if a non-tech person asked me to describe it, I'll give a blank stare.

Re:The definition of cloud computing is still vagu (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24310133)

._.

Re:The definition of cloud computing is still vagu (4, Funny)

Anonymous Coward | more than 5 years ago | (#24310225)

you mean the definition of cloud computing is still cloudy?

Re:The definition of cloud computing is still vagu (1)

Tumbleweed (3706) | more than 5 years ago | (#24312977)

you mean the definition of cloud computing is still cloudy?

My Magic 8-Ball(tm) says the outlook of cloud computing is cloudy.

Re:The definition of cloud computing is still vagu (1)

TheRealMindChild (743925) | more than 5 years ago | (#24310455)

I'll take a stab at it, though, someone is bound to try and correct me.

I would categorize cloud computing as derivative of grid computing, if you will. You throw some crap at the beast, but unlike grid computing, there can be many independent cells working completely disconnected from the rest, possibly even unaware of them or even unable to communicate between one another.

Like the clouds in the sky, they don't need to be connected or aware of each other for it to rain.

Re:The definition of cloud computing is still vagu (2, Funny)

hedronist (233240) | more than 5 years ago | (#24310627)

So you're saying you fail Rowell's Extension to Einstein's Test of Comprehension? Sad, sad day.

Einstein: You do not really understand something unless you can explain it to your grandmother.
Rowell's Extension: You totally don't understand something if you can't even explain it to a bunch of geeks. Also, they'll probably laugh at you.

Re:The definition of cloud computing is still vagu (0)

Anonymous Coward | more than 5 years ago | (#24310897)

"Cloud Computing" : Definition hazy, with a 30% chance of being understood.

Re:The definition of cloud computing is still vagu (5, Insightful)

chabotc (22496) | more than 5 years ago | (#24311041)

I think the best way i've heard it explained is:

"When details of implementation are sufficiently hidden away that you no longer have to think about them, people often draw a 'cloud' around it, just like you do with the internet where (most of us) don't have to worry about all the wires and the protocols but it's just there, and it just works.."

Cloud computing is trying to draw the same cloud around.. computing (resources), you don't have to worry about connectivity, electricity, how to make db's and file systems scale across systems.. it's an abstract cloud that's just there without having to worry about it.

Re:The definition of cloud computing is still vagu (4, Informative)

Bazzargh (39195) | more than 5 years ago | (#24316009)

'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:The definition of cloud computing is still vagu (0)

Anonymous Coward | more than 5 years ago | (#24311139)

This is a new hype name for gridRPC.

Re:The definition of cloud computing is still vagu (0)

Anonymous Coward | more than 5 years ago | (#24311705)

It's something to do with selling books, right?

Re:The definition of cloud computing is still vagu (0)

Anonymous Coward | more than 5 years ago | (#24312087)

Well, the article was pretty superficial. In my opinion, the "new" part of cloud computing is the distributed storage interface that is completely transparent with regards to it's implementation. Think memcached, but without having to list the servers. So, Google BigTable and Amazon's SimpleDB are what we are really talking about here. The rest is just hosting + dynamic provisioning + a few useful SOAs or APIs tossed in.

And here is the cheat sheet the article should have included:

EC2:
1. You can use your existing LAMP stack.
2. Scales by explicitly adding servers
3. Load balancing is an explicit service
4. Clustered database store is BASE, not ACID compliant
5. Generally more flexible but leaves many problems to the developer
6. More appropriate for legacy applications

GAE:
1. You must write in python and store data in the GAE datastore
2. Scales transparently
3. Load balancing is transparent
4. Clustered database store is ACID compliant, but scope is limited to "Entity Groups"
5. Generally less flexible but with the tradeoff of saving work for the developer
6. More appropriate for new applications

Re:The definition of cloud computing is still vagu (1)

DamnStupidElf (649844) | more than 5 years ago | (#24312619)

From the way cloud computing is implemented with EC2, my basic definition of cloud computing is that it is "On Demand" computing. Unlike the Internet, which is a series of tubes, cloud computing is like a bunch of trucks that you just dump stuff on. If your servers get too busy, just dump the work on more trucks.

For instance, it allows a small web site to survive the slashdot effect by starting up a dozen servers for a few hours or days, costing much less than having a dozen servers running 365.2425 days a year.

Additional benefits are much higher availability and connectivity. Anyone can sign up for a cloud computing account and have a virtual server colocated at an Amazon or Google datacenter.

I prefer Google for Cloud Computing... (4, Funny)

PC and Sony Fanboy (1248258) | more than 5 years ago | (#24310181)

I'd choose Google App Engine. Since no one really knows what cloud computing is, and no one knows what google does, I think they make a good fit.

oh wait. I do know what google does - It makes the internet better... and it prints money (I guess...)

Re:I prefer Google for Cloud Computing... (5, Informative)

albee01 (1326563) | more than 5 years ago | (#24310747)

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:I prefer Google for Cloud Computing... (1)

pimpimpim (811140) | more than 5 years ago | (#24314255)

I've been looking into this a bit, and the amazon option seemed the best. The problem of most (I'd say 90%) "cloud" computing systems is that you have no control over the software. Packages are precompiled and all. That sounds easy, but if part of your web solution is based on a specific version of, say, python, you might not be able to use it. And what happens when you change your software at a later point, requiring a different combination of versions than you were using before? Or what if the "cloud" computing provider switches versions at some point. All in all, it doesn't seem a good solution because you need to adjust yourself to your computing solution, instead of having a solution adjusting itself to you.

The idea of putting your own image on a "cloud" computer is very appealing for anyone who wants to be in control of the software. Also it decreases the time you need to spent on getting and remainging your compatible installs.

Re:I prefer Google for Cloud Computing... (2, Interesting)

jlar (584848) | more than 5 years ago | (#24314693)

"I've been looking into this a bit, and the amazon option seemed the best."

I also looked a bit into Google and Amazons offerings for at Python project. Google was definitely the cheapest and if I could squeeze my project into the limitations they have established I would have chosen it. Unfortunately it is not possible to install C and Fortran extensions to Python (due to security reasons, you can install pure Python modules). This was a showstopper for me.

The critique of not providing access to a local file system is in my opinion misguided. One of the main strongpoints of the Google service is the Google File System (http://labs.google.com/papers/gfs.html). If you do not want to use it, you are probably not building a scalable and distributed web application anyway.

I found the Amazon offering too expensive for my project at this point. I ended up using a minor hosting provider specialized in my type of Python applications (webfaction.com) which does a great job but miss the distributed aspects of cloud computing (not that I need that feature at this point).

Data centers will be like Cobol (1, Interesting)

cryfreedomlove (929828) | more than 5 years ago | (#24310197)

In ten years, corporate data centers will be like COBOL is today. There will still be a lot of legacy data centers manned by dinosaurs. The cool kids, young and old, will be in the cloud.

Re:Data centers will be like Cobol (0)

Anonymous Coward | more than 5 years ago | (#24310295)

In ten years, corporate data centers will be like COBOL is today. There will still be a lot of legacy data centers manned by dinosaurs. The cool kids, young and old, will be in the cloud.

I for one will not trust sensitive data to what is essentially a shared environment. I'm paranoid enough about colocation and we have our own cages.

Re:Data centers will be like Cobol (0)

Anonymous Coward | more than 5 years ago | (#24310449)

you should use better encryption

Re:Data centers will be like Cobol (1)

IMightB (533307) | more than 5 years ago | (#24310519)

Umm seriously? Your comment tells me you really don't have a good understanding of the parents concerns.

Re:Data centers will be like Cobol (1)

megaditto (982598) | more than 5 years ago | (#24310707)

Re:Data centers will be like Cobol (0)

Anonymous Coward | more than 5 years ago | (#24310999)

I'm not sure what point you're making but for the benefit of the encryption AC and on the off-chance you weren't being sarcastic...

We're not talking about backup tapes, we're talking about database queries (even read only views). CPU and bandwidth are not free, encryption increases utilization of both. What's more, the VM instances have to be able to access the database, so you necessarily have keys and login details stored on 3rd party disk. In my view it's not much of an improvement over leaving an unencrypted backup tape on your car seat!

Re:Data centers will be like Cobol (0)

Anonymous Coward | more than 5 years ago | (#24310551)

I don't really completely understand what the cloud actually is, but I have a feeling the majority of it will still reside in massive datacenters (economy of scale). Or are you suggesting the cloud will be running on random PCs, such as malware infected Win 9x computers? I suppose if we start encrypting everything it might be OK...

Re:Data centers will be like Cobol (1)

bravecanadian (638315) | more than 5 years ago | (#24310631)

I think that is very unlikely.

The capability of doing this has type of thing has been around for quite some time despite the new buzz being spun on it the last few years. From timesharing on old mainframes to Citrix for windows based systems to virtual machines, the capability for hosted/on-demand solutions has been around for a long long time and has never caught on in a big way.

Certainly some people use hosted solutions but not for the most important parts of their business. Only for commodity processes that they don't really want to use to differentiate themselves.

My opinion is that as more and more of the requirements to most businesses become a commodity, the appeal of these services go down. For 2 reasons:

1) The price of hardware is cheaper than ever, the pricing for running virtual machines is cheaper than ever, bandwidth is cheaper and on and on.. and so the cost of having an in house solution similar to these clouds is also cheaper than ever. Falling prices also crimp the margins a hosting service can possibly have, thereby limiting the support/new services that can be offered.

2) As so many business requirements become a commodity, the value of how things are done *uniquely* at an organization as well as the resulting data to support decisions becomes more valuable. So organizations will be even less likely to put their crown jewels (the stuff that makes them unique) into a "cloud" that they don't control for fear of the secret recipe getting out.

Re:Data centers will be like Cobol (0)

Anonymous Coward | more than 5 years ago | (#24310937)

In ten years, corporate data centers will be like COBOL is today. There will still be a lot of legacy data centers manned by dinosaurs. The cool kids, young and old, will be in the cloud.

The Cloud? Oh, you mean those huge corporate Data centers run by the Cloud-Providers.

Wow (4, Interesting)

BasharTeg (71923) | more than 5 years ago | (#24310339)

Finally, a burst of common sense on the latest hype. Hosted servers have offered many of the benefits you get out of "cloud" computing for years, without locking you into a particular vendor or platform. With virtualization, you should be able to build your own images and farm them out to hosting companies, using your technology and platform of choice. Clustered ESX and SANs already give us the resource scalability we need for most systems, partitioning finishes the job. You can just pay a hosted server company to host your vmware image on their ESX cluster and scale up your storage as needed on their SAN. The key is that YOU build a scalable design.

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.

Re:Wow (2, Informative)

snuf23 (182335) | more than 5 years ago | (#24310935)

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 (1)

BasharTeg (71923) | more than 5 years ago | (#24311113)

I agree, for the "cloud" systems like Amazon's EC2, but then isn't this just managed/hosted servers plus clustered virtualization plus their proprietary database system (S3)? You're still moving from fairly industry standard SQL (despite so many damned vendor extensions to SQL), to Amazon's S3 storage. Similar to how part of the "value" Google is trying to add is locking you into their non-SQL database storage.

I certainly understand that SQL has shortcomings, but is vendor lock-in, especially hosting provider lock-in, the answer? Plenty of people are scaling SQL with partitioning, which you can do with basic managed/hosted servers (even virtualized ones) without giving up control. I'd rather be able to pack up my virtual machines and move to another hosted provider if I don't like their performance.

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#24311237)

I agree, for the "cloud" systems like Amazon's EC2, but then isn't this just managed/hosted servers plus clustered virtualization plus their proprietary database system (S3)? You're still moving from fairly industry standard SQL (despite so many damned vendor extensions to SQL), to Amazon's S3 storage. Similar to how part of the "value" Google is trying to add is locking you into their non-SQL database storage.

I certainly understand that SQL has shortcomings, but is vendor lock-in, especially hosting provider lock-in, the answer? Plenty of people are scaling SQL with partitioning, which you can do with basic managed/hosted servers (even virtualized ones) without giving up control. I'd rather be able to pack up my virtual machines and move to another hosted provider if I don't like their performance.

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.

Re:Wow (3, Informative)

BasharTeg (71923) | more than 5 years ago | (#24311405)

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:Wow (1)

leenks (906881) | more than 5 years ago | (#24313501)

Oracle are scrabbling to catch up - some of their latest offerings are quite interesting, but really it is just trying to gain market share lost to the likes of Netezza. Netezza is great, but limited in capacity and very expensive. There are few SQL databases that can scale *huge* - and those that can are typically shared-nothing designs and suffer from data ingest problems (or are shared all (Superdome etc) and limited by general architecture problems, eg the typical CPU heavy/IO limited problem).

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#24314129)

yep. well said. i still scratch my head
wondering why the mysql folks don't appreciate
the importance of executing complex queries
against very dynamic data. complete mystery
to me.

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#24315177)

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.

And we need to do way instain mother. Is there a verb missing in that sentence?

Re:Wow (1)

afabbro (33948) | more than 5 years ago | (#24320407)

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.

Son, SQL databases back the biggest applications/solutions in the entire world, for either interactive or batch work. Period. Saying SQL and relational databases "don't scale" may be the single most ridiculous thing I've ever read in a Slashdot comment.

Re:Wow (1)

snuf23 (182335) | more than 5 years ago | (#24311641)

You are confusing S3 with Amazon's SimpleDB service. I currently don't use SimpleDB. We use a SQL relational database cluster running on ec2 instances. We backup/recover off of S3. Going to another host is a matter of redoing the backup scripts (easy) and changing the asset server settings from pointing to S3 to wherever the data is now being stored.

Re:Wow (2, Interesting)

BasharTeg (71923) | more than 5 years ago | (#24311833)

You're right, I did have those confused.

So it sounds like you have hosted virtual servers and some hosted SAN storage. That's cool, and it's a smart way to do business.

It's only when people call it "cloud" and act like it's something crazy and new beyond a combination of virtualization and SAN storage, managed by someone else just doesn't seem like it's worth all this hype.

I have a Vmware ESX cluster. I have an EMC SAN. They're supported through contracts with my reseller. When there are problems, the high availability features of my ESX cluster and my EMC SAN protect me. When I need to add storage, like the 15TB of storage I just added, I add storage. When I need to add another ESX node to expand my CPU or memory availablility, I add another ESX node. Each time I do, my HA gets a little better too. I use pre-built virtual machines ("appliances") for certain things either from vendors or that I build myself, just like the images Amazon offers.

If you can find someone that hosts this for you, that's great. It would probably save a lot of headaches that people with real equipment on site have to deal with. There's probably quite a bit of cost savings associated. My only point is, this isn't a massive shift of computing as we know it, it's just a turn-key solution made out of existing parts. Nothing wrong with that under you hit the vendor lock-in part.

When you start replacing SQL with Amazon's SimpleDB or Google's database, just so you can have a hosted virtualization/SAN solution, you're probably locking yourself in too much. I think your use of Amazon's service makes the most sense, because you're taking advantage of the hosting without the lock-in.

Re:Wow (1)

snuf23 (182335) | more than 5 years ago | (#24312661)

Yeah in my last job which wasn't a web business we went the virtual server attached to SAN route. It's great tech and works well for HA and expansion. The key difficulty is that there is a high cost of entry. Yes you could also go with having someone host this for you but at least with the vendors I've talked to there is always a long term contract associated.

You are right that on the technical side there isn't much that's very new about "cloud" computing. The key difference in these offerings is that with Amazon there is no contract, no minimum monthly and no upfront cost. You pay for what you turn on and how you use it (virtual server time, storage used, data transfer).
For a startup where every investor dollar is important this is a huge benefit. We previously had a much more traditional managed hosting environment (hardware load balancer, web servers, oracle back end with RAC on SAN). In a sense you are attempting to predict your load and paying for capacity upfront. Even assuming we hit the full capacity (bandwidth usage, storage, cpu) of our previous setup for a month - at Amazon the cost is about one tenth.
Also as you stated:

"When I need to add another ESX node to expand my CPU or memory availablility, I add another ESX node."

Of course - but you are limited to the hardware you own or lease. In the case of a "cloud" service, I can turn up extra application servers or database slaves based on load or in a simpler scenario just based on traffic patterns over the course of the day. I can then shut these extra servers off when load trails off or during my normal off peak hours. I only pay for the time the servers were active and have no hardware procurement costs or contractual lease obligations. Conversely if Amazon messes up

There are a number of ways these services can be used but certainly in mission critical applications at this point ESX + SAN is going to be more reliable. Although nothing says a mix can't be beneficial. It really depends on specific business needs.

Re:Wow (1)

snuf23 (182335) | more than 5 years ago | (#24312685)

Oops missed an edit - I wanted to say if Amazon messes up (see the s3 outage last weekend) there isn't anything you can do about it. Which is one reason why I feel more hesitant about using their more specialized services (such as simple db).

Re:Wow (1)

AlienSexist (686923) | more than 5 years ago | (#24312281)

Amazon's ec2 is basically just Xen virtual servers provisioned on the fly.

Not just basically, but I had come across a posting within an AWS forum from an AWS employee that Xen is, in fact, what is used for the virtualization.

The force is strong in you.

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#24315415)

Amazon's ec2 is basically just Xen virtual servers provisioned on the fly.

Not just basically, but I had come across a posting within an AWS forum from an AWS employee that Xen is, in fact, what is used for the virtualization.

The force is strong in you.

The word "basically" is a synonym for "fundamentally" as is used when someone wants to explain the core of a concept without going into more complex detail. So the OP wrote the equivalent of: "Amazon's EC2 is fundamentally just Xen virtual servers provisioned on the fly" and naturally didn't delve into details about what Amazon has custom written on their own to handle provisioning, billing, etc. because the point being made is that it's Xen.

Your reply was unnecessary as my reply ought to have been.

Re:Wow (1)

leenks (906881) | more than 5 years ago | (#24311867)

For most people that are going to be using "cloud", the limitation is I/O bandwidth - something that SAN really doesn't give you at all.

Re:Wow (1)

BasharTeg (71923) | more than 5 years ago | (#24312305)

To handle an increase in I/O bandwidth:

Add disks, thus adding spindles

Use a RAID technology that supports bandwidth over storage, like RAID 10

Upgrade your SAN heads for greater throughput and more ports (be they fibre channel or iSCSI)

Upgrade your SAN switch for greater throughput if you're using fibre channel

Add more paths to your clients and use smart load balancing SAN client software

Partition your load among different LUNs on different SAN heads

There's no reason SANs can't scale up through upgraded SAN equipment, and scale out through partitioning with a SAN just like anything else. And if you're maxing out 4Gbps fibre channel with 10+ spindle LUNs in RAID 10, perhaps you just need an object cache?

Re:Wow (1)

ruphus13 (890164) | more than 5 years ago | (#24313027)

True dat. There have been hosted servers and virtual servers (ala Linode) for a while now. However, for a class of applications that need to scale almost dynamically and rapidly, and do not want to have to provision peak-load machines for anything outside of peak load, the 'cloud' offerings are ideal. Being able to programmatically scale via bottleneck alleviation through more 'hardware', the offerings make a lot of sense. The ability to have images that can be fired up (pretty soon without any lag) on demand allows a ton of flexibility where, in the past, there was little to none without greater capital expenditure. The great part is there are already pre-built virtual images that you can ice, or have others develop, so you can fire them up at will. Imagine a service whereby you can set up a farm of web servers that get fired off so you don't have to worry about getting slashdotted (well, until your bottleneck shifts to another spot) as early! It won't be long before ALL hosting providers start offering programmatic ways of provisioning servers and paying by the drink.

Re:Wow (1)

Isao (153092) | more than 5 years ago | (#24316535)

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.

I would have though the same thing about J2EE, but every site ends up using proprietary extensions in Websphere, or whatever, and then has an terrible time migrating to another platform. It's called "vendor lock-in". I don't see why it wouldn't happen again in the cloud. Heck, there are still plenty of MAJOR sites that only offer certain features in specific browsers.

Re:Wow (1)

BasharTeg (71923) | more than 5 years ago | (#24318857)

Sure, but are you going to choose your vendor lock-in for development and database/storage technology in the same decision that you make regarding a choice in hosting providers? It would be like if I had to choose one colocation facility or hosted server provider based on whether I wanted to do J2EE or .NET. I'd rather not bundle my hosting purchasing decisions with my development platform purchasing decisions. These are obviously two of the most critical technology decisions a company can make, and making the wrong decisions and not having flexibility can make or break a company, especially in the early growth phase.

So why would you accept any restrictions of this nature on your platform choice. If I had to use a Sun|Microsoft colocation facility or Sun|Microsoft hosted servers/services platform in order to use J2EE|.NET, I'm not sure I'd feel very comfortable with that sortof all-or-nothing dichotomy.

If you expand that to databases like on the Google platform, now you're having to choose their language, their database technology, their hosting/services, etc. When we make the choice of J2EE or .NET, there are thousands of providers out there that can host our virtual machines, and we can choose between MySQL, Postgres, Microsoft SQL, Oracle, etc. We can even choose a mix of those, like MySQL for your web databases, Microsoft SQL for your accounting databases. There are plenty of hybrid systems out there. That kind of flexibility doesn't need to be given up just to get scalable hosted services.

You can have a large percentage of these services without giving up the flexibility, control, and mobility that smart systems architects should value. Often times the best design is a hybrid of products from different vendors, selecting components based on their individual strengths.

Keep control of your system in your hands and learn how to make a scalable system while taking advantage of hosted servers and services that don't lock you into one platform and technology set.

OK, but let's look at the big picture (4, Interesting)

dedazo (737510) | more than 5 years ago | (#24310427)

Comparisons are OK, but let's look at reliability. EC2 is not the same as S3, but the recent [readwriteweb.com] fiasco with S3 and SQS should give people pause before considering using any other Amazon cloud services. Two of my clients were hit with this over the weekend.

I don't know what kinds of volumes (traffic and hosting) Google AE is handling at this point, but at this point I think I would trust Google more than Amazon. One of the issues with the S3 downtime for many people was the fact that Amazon itself (and all its properties) continued to run perfectly while all the sites that hosted images and other content with them failed. Does Google use its own infrastructure to host AE? I don't know, but if they do I'd trust them a hell of a lot more than AWS.

At this point I'm thinking I'm not going to recommend AWS anymore.

Re:OK, but let's look at the big picture (1)

Pollardito (781263) | more than 5 years ago | (#24310865)

Does Google use its own infrastructure to host AE? I don't know, but if they do I'd trust them a hell of a lot more than AWS.

is it their own hardware and network resources? i'm sure. if AE goes down does that mean that search goes down with it, so they'll have to fix both quickly? not a chance. i'm not sure what "use its own infrastructure" is supposed to mean in this argument, neither company is going to support their free-to-use service as well as their own makes-us-money website

Re:OK, but let's look at the big picture (1)

dedazo (737510) | more than 5 years ago | (#24311183)

free-to-use service

While AE is free, anyone using it seriously would wait until Google finishes putting together a pricing model for it so they can pay and secure a formal SLA and some sort of support. They might have already done this, I don't know.

None of the AWS are free.

EC2 is pretty sweet (3, Interesting)

donnyspi (701349) | more than 5 years ago | (#24310439)

Just get the EC2 and S3 plugins for Firefox and it's really easy to fire up instances and manage them. Sure, there's a learning curve, but once you really get it, it's awesome.

you FAIL 1t (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24310461)

charnel house. at death's door completely before came as a 1complete dead. It is a dead will not woRk. And This very moment, officers. Others ass until I hit my platform for the

Missing the point? (5, Insightful)

DragonWriter (970822) | more than 5 years ago | (#24310471)

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.

AFAICT, they aren't intended to. The deepest problems are software problems for which there is no general solution, only problem-specific solutions for each particular task; what they are intended to deal with is the hardware problem that having a scalable software solution is of limited value if you have a fixed pool of hardware and have to go through disruptive upgrades when you expand that pool of hardware (and deal with the associated capital costs.)

Cloud computing services are, largely, tools to help dynamically "right-size" hardware, changing it from a capital investment that requires predicting the future well to plan right to an operating costs that can be quickly adjusted based on changing needs. Complaining that they don't solve the fundamental problems of software scalability seems to be missing the point.

Re:Missing the point? (2, Insightful)

Teilo (91279) | more than 5 years ago | (#24310979)

Yes, this whole article, I think, misses the point. The cloud, by its very nature, forces you to develop a solution that is intrinsically scalable. It doesn't develop it for you. Who the heck imagines that it is the responsibility of a hosting provider to make your platform scalable? Give me a break!

EC2 is not your typical co-hosting service, nor should you ever treat it like one. To properly implement a platform upon it, you, the programmer / admin need to implement machine images which have the ability to come up, plug in, and start handling requests - all without further intervention. It's a lot of work to get to that point.

No cloud service should be judged by how much engineering this requires, because it's not their responsibility. You can run crap on the cloud, and that's not the cloud's fault. But - you do the hard work first, and the cloud opens up a whole new world. Imagine - the ability to automatically scale your capacity up or down, based upon load. Pay only for what you use, and not a penny more - something that traditional colocation/hosting cannot possibly give you.

I don't know about you, but if I were running a .com start-up, with the potential for huge growth, I would really the thought that I am ready for almost any amount of traffic, no matter what.

Re:Missing the point? (1)

peterwayner (266189) | more than 5 years ago | (#24311979)

No cloud service should be judged by how much engineering this requires, because it's not their responsibility.

Yes, I agree with you, but I don't think that everyone knows this yet. I interviewed several users who seemed very annoyed that they had to backup their MySQL databases themselves.

Why? Here's a quote from Google AppEngine's front page:

Google App Engine makes it easy to build scalable applications that grow from one user to millions of users without infrastructure headaches.

Amazon is a bit more guarded on their front page, but I still think an optimistic programmer could get the wrong impression:

your application can automatically scale itself up and down depending on its needs.

It's easy to forget that it's your job to make the "automatically" apply successfully. I think a number of people will continue to be disappointed to learn what you already know so well.

Re:Missing the point? (0)

Anonymous Coward | more than 5 years ago | (#24313645)

Well, AppEngine does kinda work like that. Google gives you a lot of restrictions: no query can return more than a thousand records, no transactions except within little predefined entity groups, no more than one column can be involved in an inequality filter for a given query, etc etc. Then they give you some guidelines, like make sure your entity groups are small.

It can be a real challenge figuring out how to make your application work at all, with all these constraints. I know, I'm in the middle of it. I've had to implement my own distributed transaction engine, a paging system for queries needing more than a thousand records, etc.

But once you get it working, you've pretty much solved your scalability issues. You've taken all the problems you'll have when you start distributing, like figuring out how to do eventual consistency over a lot of machines, and you've solved them up front.

That way, you do all the hard stuff while it's just you and your laptop, instead of while thousands or millions of users are screaming at you.

Re:Missing the point? (0)

Anonymous Coward | more than 5 years ago | (#24312367)

Why can't there be a cloud that behaves like a single computer with infinite CPU, infinite RAM and infinite storage? You code your app as you would if it were on a single machine, and when visitors increase from 10 to a million, the cloud auto-scales for you. This would include all required load-balancing, redundancy, silent fail-over and so forth. You would set limits on how much money you are willing to spend balanced by your target response rate and target uptime and the system takes care of the rest. There is something cludgy about building software differently based on hardware and I think this problem won't exist in a hundred years.

Re:Missing the point? (1)

DragonWriter (970822) | more than 5 years ago | (#24313573)

Why can't there be a cloud that behaves like a single computer with infinite CPU, infinite RAM and infinite storage?

There could (conceivably) be a cloud that behaved something like a single computer with an the total number of cores available in the cloud, the total RAM of cloud, and the total storage of the cloud (all minus necessary operating overhead), but that won't change the fact that, no matter how you slice it, N cores at speed Y don't run software identically to one core at speed N*Y, so you still have to design your software to scale to take advantage of multiple cores. There's lots of ways of doing this, and the setup of the system itself can help a bit (particularly if it is narrowly tuned to to particular kinds of applications, or provides already scalable software tools for some tasks -- as Google and Amazon do for data storage.)

I suppose there may be a time when you can just draw up something like a BPMN diagram, upload the serialization of it to the cloud, and instantly get a scalable system implementing the process you've designed, but I don't see it happening all that soon.

Amazon EC2 wins (5, Informative)

orionr (1078189) | more than 5 years ago | (#24310479)

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.

Re:Amazon EC2 wins (1)

msimm (580077) | more than 5 years ago | (#24311951)

I'd bet there are probably a lot of people (like me) that didn't catch the news in April when EC2 added persistent storage and static ip addresses as options. Another thing I like is the size of the user community and available information and related projects (like scalr [google.com]).

Amazon does not automatically scale (3, Informative)

slashkitty (21637) | more than 5 years ago | (#24310485)

I'm not familiar with all of them, but with amazon's service, it doesn't "spin up more servers to handle demand" by any stretch of the imagination (unlike what the name infers). You'd have to build an application that does this. Sure, it makes ordering and setting up new servers easy, but it still has to be done by your program. With google's system, there is no need to even worry about scaling up, because it just looks like one system. Unfortunately, google's system is way to limited for anything but customized, simple db apps. I can't wait for it to expand it's feature set.

Moving to ec2 (3, Interesting)

snuf23 (182335) | more than 5 years ago | (#24310495)

The cost analysis was really what did it versus our managed hosting plan (1/10th the cost per month). Auto scaling and healing of the application cluster was also a benefit. To scale with a traditional host meant getting locked into a contract for the added server(s).

One thing about ec2 is that it forces you to use best practices for disaster recovery. Instances don't commonly just "disappear" but you need to plan for it. Well tuned ec2 images can have your site up and restored from backup automatically within minutes.

ec2 / s3 is far from perfect and certainly won't meet everyone's needs. The downtime s3 has seen (like last weekend) would be devastating to some businesses. Of course even with a traditional host you may have downtime due to truck crash [datacenterknowledge.com] or other random act.

Re:Moving to ec2 (1)

slashkitty (21637) | more than 5 years ago | (#24310861)

"Auto scaling and healing of the application cluster was also a benefit" I think you're thinking of the likes of 'scalr', which is a separate service / program ($50/month from scalr.net) . Amazon would have done well to build this in from the start.

Re:Moving to ec2 (1)

snuf23 (182335) | more than 5 years ago | (#24311473)

I'm thinking on any number of tools built around ec2 to support this behavior. Some are commercial offerings (like rightscale.com or scalr.net). You can however roll your own methods to do this if you like.
Basically you can use open source monitoring tools to check for whatever states you need to look for (server down, cpu load too heavy etc.) and trigger actions based on that (bring up another server). There is nothing really magical that the pay services are doing. It's just a cost question, roll your own tools or pay for what is out there.

Re:Moving to ec2 (1)

slashkitty (21637) | more than 5 years ago | (#24317459)

Well, if you're rolling your own load balancer and elastic scaling infrastructure, why don't you do it with faster, cheaper and more reliable servers. Why would you pick ec2?

All the features they have with starting, stopping and adding servers can be done in a dedicated server environment which has a much better price / performance.

Capitalization (1, Offtopic)

ari_j (90255) | more than 5 years ago | (#24310497)

I'll get modded down by all the grammar nazi nazis, but it has to be said: Correct capitalization of the abbreviation "vs." would have made the title of this article much more readable. But that would have required editing.

As CTO of a cloud-leaning startup ... (1)

BadERA (107121) | more than 5 years ago | (#24310895)

I see a ton of value in "cloud" computing ... but in some cases, I'm not 100% certain what the difference between a cloud and a classic farm or cluster really is. I have a simple public-facing SOA call that needs to scale to hundreds of thousands of calls per second, with automatic failover and preferably automatic scaling. GAE gives me some of that; EC2 gives me almost none of that, without something like RightScale. I've talked to the AppNexus people a bit ... not as cheap to get into, higher performance than GAE ... GoGrid doesn't seem like anything special. Rackspace seems to be the same thing. We have a SaaS-aaS startup, Apprenda, here in the Albany area ... curious to learn more about them, but they don't appear to reply to email inquiries. There's a cloud computing panel next week, Thursday the 29th, in NYC, worth checking out if there are still openings. [meetup.com]

Re:As CTO of a cloud-leaning startup ... (1)

AlienSexist (686923) | more than 5 years ago | (#24312179)

I have a simple public-facing SOA call that needs to scale to hundreds of thousands of calls per second, with automatic failover and preferably automatic scaling. GAE gives me some of that; EC2 gives me almost none of that, without something like RightScale.

AFAIK you are correct that Amazon does not provide your missing requirements. They have, however, opened the door for external providers to come up with their own solutions in all areas - just like RightScale.

The main point, I think, is that AWS will specialize in the basics and leave most of the glue and any special add-ons in the realm of vendors and the community. That way they can focus on what they do best.

That is not to say, however, that Amazon is refusing to improve or innovate. In fact due to demand from EC2 users fearing the loss of their RDBMS if an instance dies and others loathing the clunky S3 backup plan, have announced the ability to have mountable filesystem partitions that you can mount in your EC2 instance that have all the goodies of S3 in a cleaner (and higher-performance) way.

Re:As CTO of a cloud-leaning startup ... (1)

Slashdot Parent (995749) | more than 5 years ago | (#24313907)

EC2 gives me almost none of that, without something like RightScale.

Ummm... maybe you should be using RightScale, then?

If you need hundreds of thousands of calls per second, you're going to need a lot of resources... I don't know what rightscale costs, but I don't think it's very much.

For your purposes, do you really need something like auto-scaling? If your load doesn't vary much, just spin up a bunch of EC2 instances and run a monitoring program. Overloaded? Spin up a few more instances.

Re:As CTO of a cloud-leaning startup ... (1)

BadERA (107121) | more than 5 years ago | (#24319533)

We don't yet have enough data to know what our load looks like, or when/why it will vary. Holiday seasons will be higher load. Probably certain hours of the day as well. Possibly around certain events. Hard to say.

Re:As CTO of a cloud-leaning startup ... (1)

Slashdot Parent (995749) | more than 5 years ago | (#24320263)

We don't yet have enough data to know what our load looks like, or when/why it will vary.

Well, this is where the rightscales of the world (I forget the names of the other automated ec2 scalers are.. scalr or something?) fit in. If you don't want to roll your own monitoring/scaling, you can rent somebody else's. :) Or rent someone else's until you have the time to roll your own.

But, anyhow, if you have such variable load, you'd most likely save money (I haven't seen your numbers, so who can say for sure?) using some type of rentable CPU. During the holiday seasons, do you really want to buy new hardware that will sit idle for the rest of the year? Or do you want to sign a 12-month contract on a dedicated server that you won't need come January?

The usual complaint against EC2 and the like is, "I can get an el-cheapo server from Dell for $1000, and I can get colo from whomever for $50/mo including 1TB of traffic. That's $1600 to get a server for a year, or I could spend $242.75/mo getting the same setup from EC2 and not even own the server!" Well, guess what, if that's your need, then Elastic Cloud Computing is not for you.

On the other hand, if you need 2 servers from January through October, but you need 3 servers in November and December, all of a sudden you are spending $3000 in servers + $1800 in colo for the whole year. Whereas you would be spending only $314.75/mo on EC2 from Jan through Oct and $386.75 in Nov/Dec = $3921.

True, you own the servers in the colo solution, but we also only added 1 server for the holiday season. What if you need 2 more or 3 more? What if you need more at different times of the day instead of the year?

I have a client who does a huge amount of processing at the end of each month, and the results need to be available within 24 hours. When I told them that I could bring up a server farm with 400 64-bit Xeon CPUs with 140GB of RAM in under 5 minutes at a cost of $16.00/hr (paid only when in use), they thought I was making fun of other consultants who "promise the world" and fail to deliver. I had to tell them I was serious.

This is what EC2 is really useful for. I understand it can be used for web hosting, but the real value is when you take full advantage of the "E" in EC2.

$16/hr. Outrageous!

Sound familiar? (5, Funny)

psmears (629712) | more than 5 years ago | (#24310911)

From the article:

...any Web site filled with an endless stream of mostly forgettable comments trolling for reactions from the rival fans

I can't think of any site to fit that description...

AppEngine not working for me (1)

crucini (98210) | more than 5 years ago | (#24311177)

I tried to set up an app on Google's AppEngine, and got an error saying that they're out of space. They'll email me when space is available.

That somewhat deflates the promise of great scalability, etc.

controlled p2p (0)

Anonymous Coward | more than 5 years ago | (#24311325)

well after reading the wiki of "cloud computing". I think p2p is better because it isn't controlled.

A little dabbling in EC2 - eventual consistency (1)

AlienSexist (686923) | more than 5 years ago | (#24312001)

Until seeing this article I had no knowledge of the existence of either GoGrid or AppNexus. After attending 3 different talks/sessions about Amazon Web Services among TSSJS & JavaOne confs, I had begun to play with AWS. I really like EC2 & S3. I'm still trying to get my mind around the concept of "eventual consistency" [allthingsdistributed.com] which the speaker of 2 of these talks told me to look into. Presumably if you use the AWS, you must architect your applications to tolerate eventual consistency. Once I well-understand the other AWS services (SimpleDB, SMQ, etc.) in the context of eventual consistency I think I'd be able to see how to make good use of Amazon in real-world production. There was also a presentation by a company that uses AWS in production. What they use, how they do things, and the tradeoffs. The specific example had to do with news media and the need to encode a video clip into various quality, resolution, and format variations for distribution in the media website and footage archive. Naturally lots of video encoding lends itself well to cloud computing for on-demand processing capability as well as storage of all the generated artifacts. Pretty cool stuff!

Forgot one bullet point... (1)

certain death (947081) | more than 5 years ago | (#24312255)

on Go Grid...they bill you repeatedly for grid you have not used, then refuse to refund your money. They have a "pay as you go" plan, you pay, you pay, you pay, but nothing goes!!

Re:Forgot one bullet point... (1)

HighTechDad (1331813) | more than 5 years ago | (#24314687)

on Go Grid...they bill you repeatedly for grid you have not used, then refuse to refund your money. They have a "pay as you go" plan, you pay, you pay, you pay, but nothing goes!!

Would love to talk to you about your billing experience. Can you drop me an email ( michael [at] gogrid [dot] com )? I want to be sure that your issue was resolved and if it wasn't, I can make sure it is and then some.

-Michael
(tech evangelist for GoGrid.com)

Re:Forgot one bullet point... (1)

prat393 (757559) | more than 5 years ago | (#24315155)

Our company used ServePath's GridPath servers, their virtualized offering which, I believe, is the backbone behind the GoGrid service (which I believe to be basically a somewhat automated billing wrapper around GridPath). The experience was horrible, with frequent downtime, and one experience where our server was down for over 30 hours; even the upstream ISV was unable to diagnose the problem, until our server instance was simply deleted and restored from an image. We're still using ServePath, but we've moved back to physical hardware.

Re:Forgot one bullet point... (1)

HighTechDad (1331813) | more than 5 years ago | (#24319679)

Actually, the Grid Series product is completely different infrastructure and technology (even a different cage environment within our 20k sq ft data center).
GoGrid is different entirely and has been in development for 2 years, long before the whole "cloud computing" buzz started. Much of the features and functionality are based on what we learned from 7 years of being a managed service provider of internet hosting.
Thanks for the comment.

"rife with potential" (0)

Anonymous Coward | more than 5 years ago | (#24312371)

Seriously? Cloud computing is rife with potential?

I make my share of grammar mistakes, but I still cringe at some of the vocabulary abuse that makes it through on this site.

GoGrid Beta (1)

Aaron B Lingwood (1288412) | more than 5 years ago | (#24312807)

Beta indeed.

I decided to sign up for the GoGrid Public Beta $50 Trial.

The first page asks for your email address, a password, and a pre-filled promo code.

The next page asks for your personal information and CC details for billing past the free credit.

All this information was filled out correctly but their 3rd party merchant biller failed to process the details and returned an error. This may have been a glitch or it is possible that the biller does not support non-US transactions

In a second attempt to sign up, I was told that my email address was already registered and was subsequently denied. So I tried signing in, which failed.

I look forward to trialling this service when these simple but show-stopping creases are ironed-out.

--
There is a subtle, but important, difference between peeing in the pool and peeing into the pool

Re:GoGrid Beta (1)

HighTechDad (1331813) | more than 5 years ago | (#24314615)

The reason it might have failed is because of anti-fraud checks (e.g., were you traveling?). Lots of online fraud checks looks at a variety of things like IP address vs. credit card address and if there is a big distance difference, it may be flagged as potential fraud.

I am the Technology Evangelist for GoGrid (just to put it out there). I would think you would feel a bit more comfortable knowing that it was rejected because of a fraud check flag than just scooping up credit cards.

LMK if I can help you get through the registration and get you going.

-Michael

Re:GoGrid Beta (1)

Aaron B Lingwood (1288412) | more than 5 years ago | (#24314913)

Thanks for your response. Would be good to give this service a go

I was registering from home and this IP resolves to the same city as is listed with my card details. My middle initial appears on my card but no corresponding field during registration. This may have caused the flag.

Also, I can not login because I am not registered and I can't signup because i am registered. Maybe this needs looking into. I have logged a support email [No Ref] but if you are able to assist me, I will gladly take you up on your offer.

For anything that is not suitable for public forums, I can be reached at firstname.lastname@gmail.com

--

Ever seen a spam post with a signature?

Re:GoGrid Beta (1)

vikarti (1309635) | more than 5 years ago | (#24315541)

I had same situation(only different trial code was used so I have 100US$ trial) In my case IP from which I originally registers even doesn't correspond to my country(there is reason for that) and i got failed transaction. In several days I tried registering again(from home with IP corresponding to country), got message that registered arleady. After that I tried to login with password from original registration - voila!, account WAS fully created. p.s.Now if GoGrid allows for 'normal' clould computing as FlexiScale/EC2 do(and not billing for down servers as GoGrid does currently) that will be even more good. Getting to know WHY they are better than FlexiScale would also be good

Re:GoGrid Beta (1)

HighTechDad (1331813) | more than 5 years ago | (#24320557)

Well, credit card transactions are a slippery slope to travel. On one side, you could allow all cards to be processed and run the risk of a spammer spawning a bunch of spam servers using a fraudulent credit card, or, on the other side you could have some sort of fraud check that may bounce some credit cards out of the acceptable threshold and then process those manually with a verbal confirmation later. We elected to do the later to ensure as much integrity as possible for GoGrid users.

In terms of GoGrid vs. EC2 comparisons, there are, obviously, some differences between the services. More info here [gogrid.com].

Also, we recently released a REST-like API for programmatically controlling your GoGrid environment. Info here [gogrid.com].

Sorry for the salesy-esque post but I want to be sure the record is straight here.

Will the cloud really scale? (1)

zuperduperman (1206922) | more than 5 years ago | (#24312885)

One thing I wonder about is whether these cloud services will suffer the same problems as other centralized infrastructure installations - eg. such as the power grid.

Presumably Amazon has some actual very high but finite number of physical servers that is supporting EC2. What happens when (just for example) Christmas comes around and there are huge spikes in activity for specific hours of the day as people do last minute christmas shopping?

When across the board a large number of their customers suddenly allocate dozens more instances, are Amazon going to be able to meet that demand? Do they really have enough servers sitting idle to magically allocate enough to meet peak demand at any one time of the year?

It will be interesting to see if any such events arise.

Choice of OSes (1)

ruphus13 (890164) | more than 5 years ago | (#24312953)

One thing that is interesting to note is that Google, Amazon (and AppNexus, I think) do NOT offer Windows machines by the slice. Now, in the off chance that you are looking for a cloud solution that requires windows tools, and don't want to go with wine or a port, GoGrid might be your provider of choice, until MS has their own offering, or others step up.

Re:Choice of OSes (0)

Anonymous Coward | more than 5 years ago | (#24313195)

One thing that is interesting to note is that Google, Amazon (and AppNexus, I think) do NOT offer Windows machines by the slice.

I think it's interesting to note that they don't let you use your own OS image. Not so interesting about Windows, this is commodity computing and the only serious web presences running on Windows belong to Microsoft.

Turing Halting Problem & App Engine "Quota" (0)

Anonymous Coward | more than 5 years ago | (#24313123)

The problem with Google app engine "quota" based free account:

[excerpted from longer article] ...

The problem is that they canâ(TM)t tell the difference between an infinite loop and a routine (in your code) that will eventually terminate (on its own.) So they give you a quota to use in a time window of a day or a month (however theyâ(TM)ve decided to define the quota window) and your app can burn as many cpu cycles at any given time, i.e. burst, up to the remaining quota for the given time window (hopefully, without depleting all your quota before the end of the time window.)

For a âoemassively scalableâ cloud computing solution it is very dumb for Google to offer a quota-based âoefreeâ account (that maxes out and leave you hanging) unless they are working on a way to examine your code for you (before you run it) for potential infinite loops and badly designed queries.

This may sound banal but the reason for enforcing a quota for the free account is because they want to give you a limited (not infinite) free cpu cycles. The problem with the quota, however, is that once you deplete it, you will have to wait for the next quota window, e.g. 12 hours, a day or a month.

The way to handle this practically is for Google to do away with the quota model (e.g. bill you for all usage) or come up with sophisticated statistical techniques to examine your code for potential infinite loops or costly queries (remember that Turing already proved that you canâ(TM)t always deduce that logically) before they run it. Without such ability, applied in reliable manner, the only thing they can do when your app inadvertently hits the quota for the given time window is to disable your application until the start of the next quota window, which totally sucks.

**********

Is this an obvious Google Duh! moment?

More: http://evolvingtrends.wordpress.com/2008/07/23/google-app-engine-threat-or-opportunity/

Run your own Cloud in your own Data Center (1)

nullchar (446050) | more than 5 years ago | (#24313267)

If you have a lot of servers already, and would like the scalability of "cloud computing" where you easily add more cores/ram/disk, check out this demo [3tera.net] by 3tera.com [3tera.com].

I'm sure it is expensive, and I've not talked to them yet, but it sure would be great to "draw out" a new Dev or QA environment when you need one. Then when the project is complete, you can recycle those resources back into the cloud. If your Production system needs more cores, simply add them.

Re:Run your own Cloud in your own Data Center (1)

Slashdot Parent (995749) | more than 5 years ago | (#24313927)

There's an open source cloud engine. Eucalyptus, or something like that.

Re:Run your own Cloud in your own Data Center (1)

nullchar (446050) | more than 5 years ago | (#24319329)

Thanks for the info [ucsb.edu]. Eucalyptus is an open source implementation of EC2, but does not support user-defined images yet. The admin tools are designed for your own data center or computer lab.

Unfortunately, the FAQ lists nothing about data storage. With Amazon's EC2, you cannot persist data inside your image, so I wonder how it works with Eucalyptus. (This comment [ucsb.edu] says they don't support an S3 implementation.) Still, this appears to be a good starting point if you want to roll your own cloud.

Google App Engine vs Amazon AWS (1)

buddypokedave (1331917) | more than 5 years ago | (#24315735)

[1] Amazon still continues to have stability problems. An 8 hour outage for S3 - a service that's supposed to provide 99.99% up time? It seems like Amazon is still working through some of the problems associated with scaling on a massive level. Google has already solved those problems. [2] If your user base is not all in the US I don't think amazon can compete in any way with google's network of data centers. [3] Amazon aws has a different pricing model and approach than App Engine. But I think google will ultimately be cheaper. If you're only using ec2 then it might be harder to call. But certainly if you add in S3 + SimpleDB, Amazon looks to be more expensive. [4] Amazon provides a platform that allows you to scale, but does not do all the scaling for you. If you just want to create an app and concentrate 100% on features App Engine wins hands down. [5] I personally prefer the App Engine environment - python rocks, the console rocks, it's easy to write code, it's easy to deploy, it's easy to role back to previous versions etc. I still find it hard to believe that amazon doesn't have better tools for their services. There's a bunch of great tools created by the community for AWS. But it seems like at every level Google tried to make it as simple as possible to deploy massively scalable apps. Amazon provides some services and hopes the community does the rest.

Alternatives outside the US (0)

Anonymous Coward | more than 5 years ago | (#24315821)

All four services reviewed operate out of US data centers. That is a serious issue for overseas users of the cloud - both in terms of network latency/bandwidth and data jurisdiction (c.f. Canada's position [www.cbc.ca] on information sent across borders).

EU users may want to consider ElasticHosts [elastichosts.com] or FlexiScale [flexiscale.com] - both of which are UK-based.

Impressions of AppEngine (1)

YourExperiment (1081089) | more than 5 years ago | (#24316117)

From reading the article (sorry about that) I get the impression the author doesn't really understand Google's AppEngine offering.

Yes, these services let you pull more CPU cycles from thin air whenever demand appears, but they can't solve the deepest problems that make it hard for applications to scale gracefully

AppEngine does exactly that (or at least tries to). In order to do so, it takes away many features that you might consider essential, and forces you to organise your code and your database in very specific ways. But if you can accept all of these limitations, and learn to work with them rather than against them, your application automatically becomes unbelievably scalable.

This is all IMHO of course, as a developer who's got into playing with AppEngine in his spare time simply because the whole thing's so damned cool. I'm no expert yet, I'm not doing this as a job, and I've no experience of any of the other services mentioned, so take my opinions with a grain of salt.

Just thinkin' (1)

rootooftheworld (1284968) | more than 5 years ago | (#24319561)

Cloud computing? lots of load on the server, better make it a beowulf cluster... Oh wait, why not get a bunch of PCs running Plan9? If you have gigabit ethernet, it'll automagicaly include a big honkin RAID array, and it'll be multicore. the separet CPUs don't have to be powerfull.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...