Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Internet

Amazon EC2 May Be Experiencing Growing Pains 93

1sockchuck writes "Some developers using Amazon EC2 are wondering aloud whether the popularity of the cloud computing service is beginning to affect its performance. Amazon this week denied speculation that it was experiencing capacity problems after a veteran developer reported performance issues and suggested that EC2 might be oversubscribed. Meanwhile, a cloud monitoring service published charts showing increased latency on EC2 in recent weeks. The reports follow an incident over the holidays in which a DDoS on a DNS provider slowed Amazon's retail and cloud operations."
This discussion has been archived. No new comments can be posted.

Amazon EC2 May Be Experiencing Growing Pains

Comments Filter:
  • Missed Opportunity (Score:4, Insightful)

    by cgenman ( 325138 ) on Friday January 15, 2010 @09:35AM (#30778682) Homepage

    Why not say "Yes, we're way too popular. We're adding capacity as quickly as we can, but people are just lapping up our service!"

    This seems like a missed marketing opportunity.

    • by jopsen ( 885607 )
      Because it may not be true...
      - Just, a thought :)
    • by SatanicPuppy ( 611928 ) * <Satanicpuppy@nosPAm.gmail.com> on Friday January 15, 2010 @10:09AM (#30779056) Journal

      It misses the point of the magical cloud! If the phbs learn that the magical cloud can run out of capacity, then they might have to start planning again.

      If they do that then EC2 and other similar services which sell the same capacity to 100 different people on the principle that they won't all get taxed at the same time, are going to have some explaining to do.

      • Comment removed (Score:4, Insightful)

        by account_deleted ( 4530225 ) on Friday January 15, 2010 @10:27AM (#30779228)
        Comment removed based on user account deletion
        • by segedunum ( 883035 ) on Friday January 15, 2010 @11:23AM (#30779864)

          for one, replication and startup of machines takes at best log(n) time

          Errrrrrrrrrr, yer. However, simply restarting a server image is infinitely preferable to hanging around for a few hours while you bite your nails waiting for a hoster to fix something. Been through it. Not going back.

          (if your web application requires less than at least a rack in a datacenter there is actually no sense in having it clouded)

          So you're saying if anything takes less than a rack to host then there is no point in having it hosted for you............anywhere?!

          I have no idea why people think that 'cloud' computing is any different to traditional hosting. You have all the same considerations when on EC2, Joyent or anywhere else as you do if you were getting a hosting company to specifically buy hardware and set things up for you - except many things on EC2 or such a platform are standardised and you can manage a great deal through software without hanging around for someone to schedule a time to do 'something'. Maybe that's what some people don't like? ;-)

          • Comment removed (Score:5, Insightful)

            by account_deleted ( 4530225 ) on Friday January 15, 2010 @11:40AM (#30780086)
            Comment removed based on user account deletion
            • Re: (Score:2, Informative)

              by sycorob ( 180615 )
              Caveat, I've never actually used cloud computing, just talked to people and seen presentations.

              The story I got was from a guy who does IT consulting, and does a lot of prototyping for new/potential clients. He would use the Google or Amazon clouds to spin up an application, play with it, demo it to the clients, and then spin it down. If it went live, they could either leave it in the cloud, or capitalize a "real" hosting solution. He claimed that his bill some months for the cloud was less than $1.

              And that'
              • Re: (Score:1, Informative)

                by Anonymous Coward
                Exactly. I work at a popular video hosting website, and we do just that. Our encoding mechanism scales up and down depending on the number of videos requiring encoding. The fewer videos we get, the less we pay, as less equipment is being used. If we had our own racks, we'd be shelling out thousands to begin with, and then hundreds more each month. With cloud computing, our bills can be fantastically low, but are never fantastically high.
            • Hi Allow me to disagree. I run a small IT shop and I host a couple of dozen websites for my clients and myself. I currently have a dedicated server at thePlanet which I have been very happy with.

              However, my disaster recovery plans always hit a snag when I imagine the server falling off the self or getting rooted. Sure I have all the software and license info required, and yes I have excellent off-site backups of the websites and their databases. But if I had to restore that server from scratch it woul
        • by slim ( 1652 )

          (if your web application requires less than at least a rack in a datacenter there is actually no sense in having it clouded)

          Maybe not EC2, I'll grant, because of their pricing model.

          But there's no reason why a "traditional" shared web serving service couldn't be hosted on a cloud. Indeed Google App Engine fits the bill.

      • Some part of "cloud computing" does involve over-selling of server resources. Google's App Engine is so over-sold it can take 20 seconds for a page to load. However, Amazon's service allows you to reserve dedicated hosts for a premium price.

        And, really, being over-sold isn't a problem so long as things are managed right. A project on the scale of Amazon's should be able to afford the best engineers so that such things are managed properly.

        • by maxume ( 22995 )

          How do you oversell something that is sold in units of usage? If Amazon fails to provide a unit of CPU, they can't really charge the person they didn't provide it to.

          • An over-sold server cluster becomes slow, just like an over-sold network connection. Peak demand outstrips the "expected" number of apps running at any particular moment.

            • by maxume ( 22995 )

              What does slow mean? Are instances running slower than the advertised physical equivalent, etc.

              • The problem is scalability. It's not that you're not getting what you're paying for, it's that it's not scaling as it should be, as they tell you it will.

                So something happens, and their system gets taxed and your hosted apps get choked for resources and look like crap. Sure, they're not billing you for what you're not using, but you're not getting a good product either.

        • I think that what you are seeing with AppEngine (and same effect with Heroku, which is EC2 based) is this: if your web application has not processed any requests for several seconds (or longer?), then it needs to be rolled back online.

          Try an experiment: assuming that you have a private (non-advertised) AppEngine app, time the first request with ab (Apache benchmark tool). Then time requests that are sent every second. I bet that you see the 20 second page load time vanish if you are making frequent requests

        • Google's App Engine is so over-sold it can take 20 seconds for a page to load.

          If you're app takes 20 seconds to deliver a page then it's your fault. My app consistently delivers dynamic, multi-hundred kilobyte pages in 1-2 seconds anywhere in the US. See for yourself! www.TwitGrids.com [twitgrids.com]

          If you code for App Engine like it's Rails or Django your app will be a dog.

          • The slowness in App Engine comes from when they load and unload your app. This does take a long time no matter how your code is written. If your app is already loaded because someone else has accessed within the past 60 seconds, it will respond in under two seconds, as you say.

            If AppEngine were not oversold they would not have to load/unload apps constantly.

      • by slim ( 1652 )

        It misses the point of the magical cloud! If the phbs learn that the magical cloud can run out of capacity, then they might have to start planning again.

        The whole point is that Amazon (or, insert service vendor of choice) does the planning for you. I don't have to order extra heating gas for winter - I expect the gas company to anticipate the grid's needs. If I heated my house with gas from canisters I had to order a month in advance, I'd have to do my own planning. That's would be analogous to a traditional in-house datacentre.

        It's possible that Amazon failed to provide sufficient capacity for a period. Or it's possible it did just fine - I'm not reading a

        • For me, for my critical services, double redundancy is doable. I can even do double, and then have a third cluster which can take over for any one of the other four in a pinch.

          I've got redundant data lines from different providers, I've got battery and generator backups, and I've got multiple physical locations. If I'm asked, I can say, without any doubts, that we have exercised diligence, and that we're prepared for any rational situation.

          With the "cloud" you have to trust that some third party, whose busi

          • Re: (Score:3, Insightful)

            by slim ( 1652 )

            With the "cloud" you have to trust that some third party, whose business is making money, is going to spend for the capacity to cover those contingencies. I flat do not trust them.

            This argument to be used against any and all outsourcing.

            With "motorcar servicing" you have to trust that some third party, whose business is making money, is going to perform due diligence when servicing my car.

            With "banking" you have to trust that some third party, whose business is making money, is going to keep my money in a secure manner.

            With "office cleaners" you have to trust that some third party, whose business is making money, is going to come in on a regular basis and clean the office.

            It's a non-

            • Yes, but no.

              The whole cloud concept has been defined so poorly, that you're not given any sort of benchmarks for performance or scalability.

              I'd require guarantees (as I require with my outsourced resources), and until they're going to provide them, then I'll keep doing it myself, or outsourcing it to someone who is willing to detail their services in more concrete terms.

              • by Synn ( 6288 )

                Yes, but no.

                The whole cloud concept has been defined so poorly, that you're not given any sort of benchmarks for performance or scalability.

                I think the issue with this is that it's still a fairly immature business model. At some point the market will mature and you'll have "cloud" vendors that specialize in specific contract levels of service that meet a high demanding customer. Just like today you can buy a Ford or Mercedes and expect different levels of quality and support from both.

                But the concept itself is sound. It's really about specialization and volume. A service like EC2 can specialize in that one specific area, managing the hardware a

      • It misses the point of the magical cloud! If the phbs learn that the magical cloud can run out of capacity, then they might have to start planning again.

        People have actually planned deployment? Not on the planet Earth that I'm living on they haven't.

    • They are supposed to do basic admission control if they want to be viewed as a professional service provider. Read http://en.wikipedia.org/wiki/Admission_control [wikipedia.org]

    • Because it's more than that. "Cloud Computing" is a marketing architecture, not a technical one. Incidents like this demonstrate poor planning and design, nothing more.
      • by slim ( 1652 )

        "Cloud Computing" is a marketing architecture, not a technical one.

        The fact that real programming goes into projects like Hadoop and CouchDB refutes this.

        I'll accept that "Cloud Computing" can be used to refer to both a marketing architecture and a technical architecture.

        • by Anonymous Coward on Friday January 15, 2010 @11:00AM (#30779606)

          I think the CouchDb devs would actually disagree: I've heard a few of them (janl and jchris) refer to what they do as "ground computing" rather than "cloud computing." I can't speak for them but I think their goal is a more user peer-to-peer architecture than a client-server arch (where in the server is a proprietary cloud).

          The goals of the CouchDb project sometimes seem to extend further then just a RESTful database system...

    • Re: (Score:3, Interesting)

      by happy_place ( 632005 )
      I know an IT guy that works for them, and that's exactly what he says. (He says they can't install enough servers fast enough.)
  • Staged DDoS? (Score:5, Interesting)

    by Stan Vassilev ( 939229 ) on Friday January 15, 2010 @09:53AM (#30778878)

    When the news came around for EC2's DDoS around Christmas, I remembered reading how Amazon began offering their services to third parties in the first place. Turns out Amazon has a sudden peak of traffic around shopping holidays and particularly Christmas.

    To prepare for that, they have added enough hardware to handle the peak, but that hardware went unused the rest of the year. So they started leasing it to third parties in the form of their web services.

    This immediately makes you think, ok, what happens to their ability to handle the third party apps around Christmas, when they need a lot more hardware to handle Amazon.com's traffic itself? And then this DDoS happened, which importantly overloaded not the actual app servers, but the DNS servers pointing to the app servers. So as a result the app servers experiences lower traffic for third party sites than they would have otherwise.

    It's making me think, and this is of course just speculation, this may have possibly not be a genuine attack as much as a stunt to lessen the overload of their cloud services they knew they'd experience around Christmas, while having a plausible explanation for the downtime that blames it on a malicious third party.

    Reading they do indeed have had (and still have) performance issues supports that speculation.

    • You bring up a very good point, as to how to stay looking like a real solution while trying to explain your downfalls, and a fake DDos attack would be great thing, however, if I am hearing that Amazon is subject to DDos and do not know how to circumvent them, then I have to say, this sounds just as bad to me, however, I am very pessimistic when it comes to
      security. On the whole, no one knows what they are talking about and everybody is hacked.

    • by Dalroth ( 85450 )

      What happens is eventually they add enough capacity and enough customers that the data centers themselves have no yearly peak. Amazon may peak in December, but NBC may peak in August during the Olympics. Over the course of the year, everybody's peaks average out to no peak.

  • by Anonymous Coward on Friday January 15, 2010 @09:58AM (#30778950)

    Amazon needs to move their cloud into space. Yes, space! It's the next big frontier beyond clouds, and you heard it here first.

  • Wouldn't want any of my important data stored on a system which has performance issues...

    Or having to wait significantly longer than I would storing my data locally!
    • Re: (Score:3, Interesting)

      by alen ( 225700 )

      from what i read a lot of people like to use it for testing. you can "create" a server with a loaded OS in seconds, test and and "destroy" it by lunch. I can do this on the free version of VMWare ESX but i don't know if i can copy a bare instance i set up to another instance. Otherwise we have a sort of old Proliant G5 server with the free version of ESX that we use for testing different things. in the past we used the crappiest server we had. if we needed multiple machines we were screwed. with Vmware and

      • Trinity Rescue Kit is a network boot/CD boot linux that reads and writes NTFS etc.

        We use it here to image and deimage windows systems, it takes ~10 minutes boot-to-boot to bring up a raw windows system in a known state.

        • by slim ( 1652 )

          it takes ~10 minutes boot-to-boot to bring up a raw windows system in a known state.

          So 60 times longer than bringing up a new EC2 instance from an image, and when you're not testing, you're still paying for the hardware.

          • Re: (Score:1, Flamebait)

            by nweaver ( 113078 )

            The poster specifically asked for RAW IRON testing: no vm, no nothing.

            And it works just fine on little $400 fanless Intel Atom systems, thats what we use.

            • by slim ( 1652 )

              The poster specifically asked for RAW IRON testing: no vm, no nothing.

              I've re-read it about 5 times, and I can't see where he asks for that.

              • by nweaver ( 113078 )

                Sorry, got slighty confused. Oops.

                But testing on VMs has its limits: they do introduce abberations so you should test on real systems too.

          • When did you last spin up an EC2 instance? I wait at least 5 mins, sometimes closer to 10, for an image to launch.

            Granted the EBS-backed AMIs will boot faster as the image is already boot-ready.

  • still too expensive (Score:2, Interesting)

    by alen ( 225700 )

    i priced out a high memory config and it's like $6000 per year or more for 32GB RAM of memory and 8 CPU cores. In a few months Intel will ship server CPU's with 12 logical cores per socket. RAM prices are dirt cheap and at current prices a 36GB RAM HP Proliant DL 380 G6 will run around $13,000 and 72GB of RAM another $2000. and that includes 5 year 4 hour response time support, some of the other extras like advanced ilo, and i forgot what else i added since it's so cheap.

    add in the increased bandwid

    • That's a bad analogy. A better one would be: Hosting in "the cloud" rather than in your own datacenter is like taking a taxi instead of buying a car and hiring a full-time driver.

      • Re: (Score:3, Interesting)

        by alen ( 225700 )

        the per hour plans are cheap. but the 24x7 hosting EC2 plans are a lot more expensive than physical hardware. and we're in a cycle where the hardware power is increasing at a very fast pace again. few years ago 4GB RAM was expensive on a server. today when we buy RAM for a newish server we just buy 32GB of RAM. the price difference is so small it doesn't make sense to buy less. $1200 or so for HP branded 32GB RAM. a few hundred $$$ less for 16GB or 8GB.

        CPU's power is increasing and next year with Sandy Brid

        • Re: (Score:3, Insightful)

          by slim ( 1652 )

          the per hour plans are cheap. but the 24x7 hosting EC2 plans are a lot more expensive than physical hardware.

          Which makes the GP's taxi analogy perfect. If you want to host something with reasonably static storage needs, that's getting hit consistently all year round, EC2's going to be more expensive than the alternatives.

          If you've got something like SmugMug (image hosting) where your storage needs grow forever, at an unpredictable rate, S3 might be cheaper than managing the storage yourself.

          If you get massive surges in demand, a few times a year (for example, you sell tickets for in-demand events), the ability to

        • But a small mom-n-pop shop doesn't want your 32 GB, or Sandy Bridge. They want less than 100 billion CPU cycles per day, less than 1 GB data transfer per day. But they want an always on server with redundant cooling & power supply. They don't have the expertise for this, they cannot employ a geek because good geeks come expensive. For them it is multiple orders of magnitude cheaper to go cloud.

          • 24x7 is also just one usage scenario. For intensive rendering being able to hire a small army of processors for just long enough is infinitely preferable to waiting for months for a few local machines to complete, and buying the same capacity and having it idle a lot just isn't possible for me.
            • by alen ( 225700 )

              one time i saw a stack of Nvidia brand servers delivered around here. how much data are you sending over the internet and back which is still slower than sending it to the next rack over. does EC2 support CUDA and other technologies to render via the "graphics" card which is faster than x86? i've noticed financial companies are using nvidia servers with CUDA. and these are small shops.

    • by shayne321 ( 106803 ) on Friday January 15, 2010 @10:48AM (#30779470) Homepage Journal

      Apples and tomatoes.. Unless your company already owns a fully equipped data center with excess capacity you have to factor in colocation space, power, cooling, backups, network infrastructure, and security. And if you're not colocating in a space where you can purchase bandwidth you have to factor in the cost of the physical circuit(s) (T1/T3/Metro-E, whatever).

      We haven't even begun to consider availability. What if your app can't tolerate 4 hours of downtime (for the HP monkey to come swap out your motherboard)? Now we need redundant servers, redundant connectivity, generator and ups capacity, highly-available network infrastructure, load balancers, etc. Let's not forget the highly paid staff/consultants to implement and maintain all of this.

      What happens when your app takes off and you need to scale rapidly? Now you have to procure and install servers, keeping up with the infrastructure required every step of the way.

      Also, don't forget in 5 years that $13,000 server you just bought will be a boat anchor. Time to purchase a whole new round of hardware.

      I'm not claiming cloud computing is the end all solution for everything, there are certainly drawbacks.. But you cannot compare the cost of a $13,000 server to a $6,000/year instance lease as apples to apples.

      • by alen ( 225700 )

        and EC2 is a good solution for mom and pop. i even recommend it. but what if EC2 takes off and they have to add resources? what if PHB in charge at Amazon says no way because buying all this stuff and paying the ridiculous titanium level support costs will kill the ROI/ROE and every other financial acronym and wall street will hate us? Wall Street hates it when your Return on Assets ratio is too low and buying more assets to support EC2 is not good.

        and we still have 10 year old servers doing low end things.

    • by segedunum ( 883035 ) on Friday January 15, 2010 @11:11AM (#30779732)
      You can always tell someone doesn't know what they are talking about when they price up hardware and say memory is 'dirt cheap' and then say that something like EC2 is too expensive. I see it a lot in those scrawny developers around the web who don't want to do any deployment (and want to pretend it doesn't even exist) and want something like EC2 and Engine Yard but for the cost that they were paying for shared hosting - where they complained that they were running out of resources!

      Purchasing hardware implies a lof of other costs - where you will host it, how you will connect it, how you will back it up........ Going a traditional hosting route for this is ridiculously expensive. You need to rent the hardware, you need to communicate with the hosting company about setting up, you don't know how it will be set up (at least things are standardised with EC2), how you will handle failover (buy more hardware!) and how you will back it up (buy more hardware and storage!). Can you snapshot your data easily? Can you simply fire up a copy of your server to get running again or do testing? How will you recover from a hardware failure or a disaster where you don't hear from your hosting company for several hours while everyone bites their finger nails? It's why every other hosting company is either denying that EC2 is happening, trying to trash-talk it or trying to come up with their own 'cloud' virtualised, decentralised storage platform with some kind of software management tool........and generally failing at it. They will either respond to it or they will die.

      RAM prices are dirt cheap and at current prices a 36GB RAM HP Proliant DL 380 G6 will run around $13,000 and 72GB of RAM another $2000. and that includes 5 year 4 hour response time support

      Excuse me while I get up off the floor from laughing. What kind of 'support' do you think you get for that and how useful do you think it is? That supports is for ASPs and hosters. For the rest of us, deploying something means several layers of support on top of that for the hardware. Trust me - every other hosting company has scaling, infrastructure and bandwidth issues. I've been through it. My experience with EC2 in my somewhat limited comparative forays thus far have been infinitely preferable.

      i buy an HP server i buy one machine and a few hard drives. to support me Amazon needs to buy a few servers and 5 times the raw space for DR purposes.

      Yer, probably because you don't back anything up and you haven't had to handle recovery from a disaster. Pffffffffffffffff............... We can see who the average Slahsdot reader is when this gets modded up with this level of grammar.

      • by alen ( 225700 )

        we have our own datacenter with a DR recovery site in another state via EMC SRDF and some other technologies. EC2 might be good for small companies and we rent out space in our datacenter to smaller companies but for larger ones it doesn't make sense. i work for a hosting company and i always see customers in their hardware cages. what happens if there is a problem with EC2? in typical new economy fashion do they tell you to go away and live with it? how long will it take them to add new resources if these

      • by Bengie ( 1121981 )

        Similar thing I heard. I've seen people talk up HD storage like it's dirt cheap to. It might be cheap for consumers, but not a decent hosted setup.

        My company recent bought an effective 16TB of SAN storage, costed $120k. You ask someone how much they think 16TB costs, and they'll be like "hmmm.. $200 for 2TB, so $1600 for 16TB."

        Some people also say memory is cheap also. It's cheap if you buy small amounts of it. a 2GB stick is a lot cheaper than an 8GB stick of ECC server grade memory. One of the server guys

    • It certainly costs more than owning your own hardware, but you're paying for convenience. If you have your own hardware, the actual cost is not only of the hardware itself. You can go ahead and double that cost to have redundancy (while in EC2 you don't give a crap when a server fails. Just restart the instance... if that). When it does fail you have to send someone out to the server's location to maintain it. You also have to worry about hardware upgrades and internet link upgrades. And that's if you're in
    • i priced out a high memory config and it's like $6000 per year or more for 32GB RAM of memory and 8 CPU cores. In a few months Intel will ship server CPU's with 12 logical cores per socket. RAM prices are dirt cheap and at current prices a 36GB RAM HP Proliant DL 380 G6 will run around $13,000 and 72GB of RAM another $2000.

      How much does the power drain of that 12-core HP Proliant DL with 72GB of RAM add up to every month?

      How much time will you lose when $HARDWARE fails and your server is offline? Even with 4-hour response time support, depending on what you're using the server for you could lose tons of money while it's offline - in the meantime, you can have a new EC2 instance spun up in seconds, if you even notice it die in the first place.

      You can also save a lot by reserving an EC2 instance for 1 or 3 years for a one-time

      • The real value of EC2 becomes apparent when it's not your sole host ... simply automatically scale into EC2 when the load starts rising

        Most servers would have a data store (database, filesystem etc.). If you want your own server and EC2 to aid each other in times of adversity, they will have to share the data store. How do you achieve this? Wouldn't common storage between different data centres (one is your own and another is EC2's) be very slow such that it would impact the performance of server processes running in both the data centres?

        So I would think it makes sense to either completely go to EC2, or completely host all your own server

        • So I would think it makes sense to either completely go to EC2, or completely host all your own servers. What am I missing?

          Presumably you have some way of deploying code updates to your own, non-dynamic hosts; you could use the same mechanism to bootstrap the EC2 instance.

          We did this in a distributed computing class at my university; we made an EC2 image stored on S3 (which costs pennies per month) with the right software preinstalled, and set it up to know just enough to download the latest version of the website code once it started up.

          If your website is PHP-based or something, the trivial solution is to have it run "svn chec

          • Presumably you have some way of deploying code updates to your own, non-dynamic hosts; you could use the same mechanism to bootstrap the EC2 instance.

            Bootstrapping is not a problem. But once both servers are running, any action by the user and any system event would make a change in the datastore. This must be replicated real-time across the storage of both the servers. Only proper solution for this that I can think of is: mount the same storage at both the servers. This might increase the latency of data access/commit for both the servers. Even if one of the data centres has a low-latency access to the data store, locking etc. would make sure that this

            • Which is better: somewhat higher database access latency, or unusably overloaded servers, or idle-most-of-the-time hardware?

              There's not always one right answer, but "somewhat higher database access latency" is the right answer at least some of the time. It really just depends on your use case.

              • Which is why I said it makes sense to either completely go the EC2 way, or completely roll your own. You don't get to say

                The real value of EC2 becomes apparent when it's not your sole host .... you'll magically handle the spikes without a problem ...

                (Italics yours, bold mine)

                when it works only by increased database latency.

                • All I'm saying is that sometimes increased database latency is better in some way than having idle hardware some large percentage of the time, and better than running entirely on EC2 all of the time (which can get expensive).

                  For example, let's say your page render time is in the 500ms range (perhaps it's a complex retail website). When the load goes up, is it more preferable to have some of your users get a 750ms-rendered page, or to have all of your users get a 1000ms-rendered page because you don't want

                  • You're right in that it's not always acceptable - but don't pretend it's never acceptable

                    When did I pretend that it's never acceptable? The only problem I pointed out is data store latency; and if that is not a problem, it sure makes sense. Heck, some servers may not even have a data store that needs updating. On the other hand, you pretended that it is always acceptable by, as you say, not using "sometimes".

                    Seems like we essentially agree, with different use cases in mind.

  • Uh... How else do you think they make money?

     

    • Are you insane? It's The Cloud. You don't get to question problems with their business strategy, or the consequences for their customers. What are you, some sort of Cloud Denier?
  • We use EC2 as the back-end for Netalyzr [berkeley.edu] (our free, applet-based network testing and debugging service), and right now are in the middle of a minor flashcrowd with our big updated release. No recent glitches we've noticed, with long running small instances.

  • I seen to recall a post on slashdot about Amazon Introduces Bidding For EC2 Compute Time [slashdot.org]. This announcement took place on 12/14/2009, which coincides with the increase in average ping latency as illustrated in cloudkick's chart [cloudkick.com]. Was Amazon unprepared for the increase in demand created as a result of bidding off of the unused EC2 capacity?

    I am sure that people came up with some pretty creative thing to do with low priced EC2 capacity.

  • I keep a small reserve instance running 24x7 and the cost is very low. I also have a EBS bootable large instance that I run for a few hours at a time as needed. It has been a while since I used it, but Elastic MapReduce also works well and is fairly inexpensive for what you get.

    About half of my customers also use EC2s.

    (Note: Amazon gave me a large grant to use EC2 for free for work on my last book, but my comments are my honest opinions.)

  • The cloud providers will have growing pains for years to come. However, cloud is a much better choice than the overhead of building and running your own data center.
  • Amazon's instance types (http://aws.amazon.com/ec2/instance-types/) doesn't seem to indicate the number of cycles/sec you are guaranteed to use per type.

    They sell instance types based on the physical hardware specs which is worthless in a cloud architecture.
    What they should really be doing is indicating the number of cycles/sec an instance type will be GUARANTEED and then enforce it.
    If the customer doesn't use that number of cycles/sec, then fine put the idle cycles up for bidding.

    Just my $0.02
    Ben

    • Just as a followup.
      After reading more about EC2 instance types, the amazon term is compute unit. However, they don't give any hard numbers for the Hz of the machine (just "One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.") and they don't give any GUARANTEEs that the compute unit won't be diluted over time.

Technology is dominated by those who manage what they do not understand.

Working...