Amazon EC2 Spot Instances - And Now How Much Would You Pay?
aws.typepad.com
aws.typepad.com
I'm excited to see what innovations come out of this. Of course, this will only become really interesting when there are other providers doing the same.
Scale. It doesn't make sense to do things like this until you have thousands and thousands of nodes -- most hosting companies simply aren't anywhere near as big as Amazon.
I'd attribute their innovation more to their core values:
Ignoring competitors - probably the biggest factor. They actually sat down and thought about what people want, rather than doing what everyone else was doing. This puts them ahead of traditional hosting providers, as well as competition-oriented companies like MS.
Customer focus - having an insanely strong focus on the customer distinguishes them from equally innovative competitors like Google.
Commitment - Amazon recognized from the start that they had limited resources, and very carefully chose to enter the cloud computing market, ignoring all the other proposals. This focused them more, while also giving the public more confidence in the service. Compare Google App Engine, which isn't taken with the same seriousness.
Other than that, relative small size helps. Their customers know that Jeff won't eat them for lunch at the first opportunity. And having a few billion dollars of cash in the bank doesn't hurt either.
Sure. But they didn't do Reserved Instances and Spot Instances when they started out.
You only need a few racks in order to make renting Xen instances by the hour feasible; but in order to make a market for Spot Instances reasonable, you need to have enough "spare" capacity to support a stable market (i.e., one where a single customer won't dramatically shift the market price) -- given the variety of instance sizes, I doubt this would work without having hundreds of racks of spare capacity.
If you're talking about when EC2 first started (2006), then I think you underestimate Amazon's scale by a couple orders of magnitude. For example, it's been a long time since Amazon has had "their datacenter" rather than many large datacenters around the world. [Note: I was an Amazon employee from 2005 to 2008.]
Consider that Amazon had $10 billion in revenue in 2006, (how many pageviews does it take to end up with that many orders?) and has a lot of very complex processing under the hood (over 200 distinct services called just to render the home page; search and recommendation engines; payments; inventory control; fraud detection; etc.). Then you can start to estimate just how much infrastructure they require.
I'm not so sure about that -- Google certainly claim (and intend) to be very strongly focused on the customer. Do you think Amazon are more effective at this than Google?
(That's not to say that Amazon is always great at support, but I do feel that there's a different attitude about it, having worked at Amazon and having many friends working at Google.)
This maximizes their hardware investment and allows a whole new class of applications which need large amounts of cheap computing power but are not fussy about when the work gets done.
GENIUS. Revolutionary beyond my capacity to visualize. This is going to change the way the cloud computing space works.
The really interesting part is that physical location is one of the price parameters: picture the spinning globe, with real-time applications constantly migrating to instances where it's daytime for maximum performance, and asynchronous applications hugging the dark side where computing is cheap.
As a friend of mine said, this is to cloud computing as adsense was to online advertising: i.e. revolutionary, and an absolute cash fountain.
Amazon doesn't come close to that.
You're clearly a much better shopper than I am. Where are you seeing these rates?
j.
mail in your inbox. oh, and my bad but it should have been 'euros', not $ (force of habit, sorry).
It's technically impressive what they've done with there infrastructure from both a engineering and business/management perspective. But the idea is just time-shared computing which has been reimplemented a few times since the first companies offered compute time on their mainframes.
I'm not even talking about "high-availability", but the cessation of a key node in a dependency tree of instances messes stuff up (at least for my problem space).
What is missing here is a "5 minute warning" API call before shutdown that would let me engineer in a) the opportunity to save any long-duration calculation to disk and b) have my software make a decision to instantiate a full-price instance if my queue is too long and having no cheap-o priced instances running is going to mess things up.
Thoughts?
If having your instance die is going to cause problems, why not just bid higher in the first place? You're only going to pay the spot price, regardless of what you bid.
but thinking that out... I guess if Amazon allowed everyone to programatically do that via an API warning then I guess everyone would simply build their software to bid up 1c at the time of warning... and at scale, everyone doing that would simply inflate the spot price higher and high to the point it would approach the full cost.
I can see some people gaming the system in this way if the system allows it
They do also mention that it is 'by the hour', which I'd double check that it doesn't include fractional hours, but after the instance has been up for ~55 minutes, you have your 5 minute warning.
You do, however have a really good point with the up-sell off the 5-minute warning. I wonder if that could be too easily gamed. When that 5 minute warning comes the spot instances tell the normal-instance key node, which then requests a bunch of spot instances at 2x the current spot-instance price to be able to finish the current 'set'. (But then also request a bunch more spot instances at below the current spot price, in an attempt to drive down spot instance pricing.)
The other thing is that it is region specific; which means that you could target the EU region from the US west coast to get work done on spot-instances during the day.
Nope; Amazon can terminate spot instances at any time. Thought experiment: Assume EC2 is full (which it will be from now on) and someone requests a regular instance. To create the instance promptly, EC2 will have to shut down a spot instance.
(But then also request a bunch more spot instances at below the current spot price, in an attempt to drive down spot instance pricing.)
That's not how auctions work. The number of bids below the winning price is irrelevant.
Not with cloud storage where disk I/O costs money. You really only want to save at the end of a task rather than during it. Or you save the results off-cloud in a back store hosted elsewhere.
(all of which assumes you are working at scale, where the cumulative costs become prohibitive)
Maybe auto scaling can do this for you; if it detects that the group has no instances it will start a new (full-priced) one.
Hmm. Since this new feature can actively terminate instances, it makes a problem I have with EC2 even more of an issue: I'd like a way to query with your instance ID and find out exactly when it terminated and how much bandwidth it used (so something like a "usage/accounting" API). It would help greatly to know your exact financial situation with Amazon. A notification system (register an URL to get a POST when an instance dies or if its bandwidth use exceeds a certain threshold, etc.) would also be useful.
If a user wants to have very accurate information about these things, they currently need to set up a HA environment offsite to poll (which may not even be enough if there are network issues). That has always frustrated me when the information required ("how much have I spent?") is right there in the database after the instance is done.
This is the description: "Creates the data feed for Spot Instances, enabling you to view Spot Instance usage logs. You can create one data feed per account."
I havent tried it yet, but if anyone has can they post their impression?
That said, the documentation on the datafeed stuff is annoyingly sparse - the format is reasonably self-documenting, but I wish they'd commit to it somewhere.
What will be the consequences? Probably quite some pressure on margins and on quality, the only variables where you can vary with the product. Once there are other vendors, of course.
I'd call it the next moment in the ongoing commoditization of computing. But everybody has a different threshold of perception. ;)
1. Terminate outright when the time comes.
2. Give the instance a 5 minute warning (for a fee).
3. Keep the instance running but switch it to a non-spot pricing model per hour as a typical EC2 instance.
Much more friendly and option 3 will give them greater revenue.
Or perhaps not: if this were the option offered, no one would pay for standard EC2 instances at all, they'd just put up spot reservations and take the lower price when it's available, paying the ordinary price when it's not.
They can do that now, of course, but there's significant more complexity involved.
And how exactly would you determine that? We're talking about a spot market here -- and a large part of the supply comes from Reserved Instances which were purchased for disaster recovery purposes and aren't being used.
If a disaster strikes, the spot price will go up in a hurry.
You break even on the reservation fee if it's on half of the time.
I know I wouldn't want to be the one to have to tell my boss that we couldn't get our DR setup running because we didn't have any contract in place that ensured capacity was available.
Are they saying that they will kill your instances or kill the bids for instances??