In some respects it's Google's model too. They gave away Google Apps free to small businesses for years as they pursued Microsoft's Exchange Server market. At first Google Apps was free for up to 100 users, then 50, then 10. Now they charge $5 per user per month for new plans. Legacy pricing is grandfathered so they didn't really piss anybody off in the process, but it seems pretty clear the strategy was to subsidize the product and accumulate market share.
I'd actually be worried with Google. They've demonstrated a willingness to shut down revenue sinks even if it costs them good will. If these companies find themselves in a position that they're subsidizing their cloud computing offerings with profits made elsewhere, it might make more sense just to pull the plug.
> They've demonstrated a willingness to shut down revenue sinks even if it costs them good will.
Google isn't running a charity. Shutting down losing services is a smart business decision. If you see the cloud going the way of the typewriter, then you should also be looking elsewhere to run your computing resources.
Yeah, I don't disagree at all. I think Amazon is making a longer term strategic move with AWS and is more likely to swallow a few years of not making any money than Google however. Of course a couple years ago I would have said the same about Google, but they've been on a bit of a tear recently where that doesn't seem to be as much the case anymore.
Providing cloud computing services is bulk business where the economies of scale is important Google is itself cloud computing company. When they sell resources to others, it's way to become bigger and reduce cost margins for the platform they are using for themselves.
As long as there are people who pay more for the Google cloud service than Google's own usage is worth, selling to others reduces the overall costs of computing for Google.
Service ecosystem (S3, RDS, SQS, VPCs, Cloudsearch, Elastic Transcoder, to name a few), long-term stability, reliability, support, the ability to peer directly with AWS to name a few.
Most of AWS's major outages have been related to EBS. Although outages can happen to any hosting provider, and I am sure they have fixed the previous issues. So EBS should get more stable over time and it is already quite stable.
The performance of EBS is pretty bad, and getting decent performance is expensive. Having said that, if your application runs in memory and disk usage is infrequent then it is probably fine to use EBS. EBS is also much more expensive than the instance storage, but it is also durable unlike instance storage.
On the whole, "never ever EBS" is too strong language making it incorrect. As usual, it depends.
It went down in 2012 and somehow rather than get the correct idea from that (everything breaks) people took this bizarre notion that EBS is bad and everything else has perfect reliability. In reality, tons of other AWS services run on top of EBS, including load balancers. When EBS fails again, the people thinking they are avoiding it will still have outages.
Well, you break your services out onto stateless and stateful machines. After that, you make sure that each of your stateful services is resilient to individual node failure. I prefer to believe that if you can't roll your entire infrastructure over to new nodes monthly then you're unprepared for the eventual outage of a stateful service.
Most databases have replication but you need to make sure that the characteristics of how the database handles a node failure are well understood. Worst case you use EBS, put your state on it, snapshot it regularly, and ship those snapshots to another region because when EBS fails it fails hard.
Also, logs make every machine stateful. Use something like logstash to centralize that state.
If ELB is down in a given region then DNS failover to another region. Assuming you feel comfortable rolling your entire infrastructure monthly, have good images / configuration management, and have the state replicated in the backup region.
That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.
We use RDS (they now support Postgres) and Elasticache.
The pricing seems reasonable for the performance (I've not done benchmarks if I'm being honest), and you get to treat all your EC2 instances as expendable.
Just to clarify: I don't eschew RDS because of outage issues, I use RDS because it's much easier to set up and manage compared to doing it yourself.
To be honest, I didn't know RDS was backed by EBS but it makes little real difference to me as long as the backup procedures are rock-solid and the performance is acceptable.
It's one of those "huh, never ever thought of it from that angle" sort of ideas. The very idea of putting your absolutely valuable data on ephemeral storage and just duplicating it.
But the thing people are needlessly concerned about with EBS is full datacenter failure. Which is just as much a problem for those EC2 instances. Synchronous replication to another data center is a massive performance killer.
I wouldn't take it that far! There is conflicting information on which between Standard EBS and Instance store performs better but there have been benchmarks to support that EBS does perform more consistently than instance store (example: http://serverfault.com/questions/111594/which-is-faster-for-...). Also, you can now launch EBS optimized instances which use a network stack intended to separate EBS I/O giving better throughput. iops is expensive but is great to have when you need it.
Sure, if EBS goes down in your zone, you're hosed. But unless you're completely independent as a service, chances are you do depend on something which uses EBS so you might be hosed anyways.
Instance store is great free storage to use. Since it needs to be mounted explicitly, I'm guessing that most people don't end up using it. Thats a shame too; so use that free storage but EBS isn't evil either.
With Digital Ocean, you only get almost bare VPS hosting (which is not bad per-se, I use them for a couple of personal projects), as with AWS, I get 1-click solution for pretty much anything I need, from S3 and Cloudfront, to Elasticache, hosted PostgreSQL, Route 53, OpsWorks, and numberous others.
I find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price. What's best about Amazon it their tooling. They have hands-down better tooling than their competition.
I use gandi for my personal stuff (because I'm less bothered by the French government spying on me than the US one) and it's much cheaper than Amazon. But in terms of being able to easily mass-manage a complex environment? Not even close. DO? Don't make me laugh.
> I find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price.
This is the Southwest Airlines model. Tell everyone you're great on price often enough, even if it's not always true, and plenty of people will think you're good on price.
The EC2 C3 instance type is going to be about the same price as DO for 1 year reserve and less than DO for 3 year. Spot pricing will also be lower than DO for C3s. On top of that EC2 is far superior to DO in many ways: EBS off instance storage (DO is local storage only), volume snapshots, IPv6, load balancing, private IPs, multiple IPv4 addresses, 8 data centers globally, firewalls, VPN, VPC, PCI DSS compliance, companion services like S3/CloudFront/Route 53 and much higher default quotas just to mention a few. DO is essentially a VPS with utility pricing.
They might (a little) in that this 'friction' is exactly the sort of plain bottom-line info to get people to make the step to move off of heroku and on to raw EC2 (or other more infrastructure based setups).
They already charge an immense premium over your own fleet of micro to large instances, but by the time you rack up enough dynos for it to make sense to spend the necessary weeks migrating your infrastructure there's a good chance that replicating the environment with your own in house version (30+ instances?) is non trivial enough to be scary.
Once you're over a handful of dynos, the sunk costs and uncertainty will keep you there until it becomes totally ludicrous.
Heroku hasn't changed pricing since they launched, actually. The only historical price reference I quickly found was that the EC2 was $0.085/hr for (what is now called) an m1.small[1].
Heroku launched with $0.05/hr pricing.
Amazon's new m1.small pricing is $0.044/hr, nearly a 50% price drop over four years.
Heroku still is $0.05/hr, the same price as when it launched. Heroku runs on EC2.
Uh, did I miss something here? Sounds like Heroku was actually cheaper than the raw EC2 rate when it launched, and is now just over half a cent per hour more.
I see that the prices on the M3 instances dropped a bit more than the prices on the M1 instances did, so they are encouraging us customers even more to move from the older HHD based instances to the newer, faster SSD based instances.
Yeah, but keep in mind it's only applicable if you use instance-based storage (which you declare when you spin up the instance). If you use an EBS mount it's a moot point.
The most striking thing to me is that they seem to be aggressively motivating people to longer reservations. For RDS they only dropped prices for on-demand (which is still expensive) and 3 year, heavy utilization instances.
Just to make sure I'm reading this right, the upfront reservation fees are higher, but the reserved hourly rates dropped a good bit. It's cheaper over the duration of the reservation, but you owe more of the term upfront.
Given this tidbit, might you reserve an instance now, pay the lower fee, but still take advantage of the new hourly rates on April 1? Or are you locked in at whatever rate your reservation is for?
You're locked into whatever rate your reservation is for. This is why you see rate fluctuations on the marketplace for the same instance type. It's also why a 3 year reservation may not make sense.
Bummer, though. We just reserved a multi-AZ m3.large RDS instance last week. I wish AWS would take up Google's system of graduated price reductions over steady run duration.
The other fun tidbit is on heavy reservations you pay per-hour even if you're not using the machine. That's not the case for the light or medium. So keep that in mind when planning out your reservations.
When we switched off EC2 it was financially advantageous to basically give away our heavy instances on the marketplace just to shed the liability.
After this latest round of price cuts, I'm starting to question whether I even want to reserve instances on the lower end. An m3.medium is about $52/month on demand vs $35/month (amortized over 12 months with a 1-year heavy usage reservation).
In this example, it becomes a question of whether it's worth saving $130'ish a year for the liability that a 1-year m3.medium heavy util reservation represents. At the lower end, that's not a huge amount of liability, but it may be a case where I just don't bother reserving m3.mediums anymore because it's a wash.
Maybe my math is off, but I calculated $35/mo for medium utilization m3.medium vs $32/mo for heavy utilization. In that case, I don't think a heavy utilization reservation makes sense but a medium utilization reservation still might (as you're saving ~$20/mo over on-demand).
I tried to give away a heavy instance in the past but to sell on the Reserved Instance marketplace you must have a US bank account. Worth noting if you are considering heavy instances and are based outside the US. You will be stuck with them for the life of the reservation term.
How I'm reading this, both up-front reservation fees and the hourly rates are lower for a lot of instance types.
For example:
Now: m3.xlarge $1266 $0.105 per Hour $1922 $0.086 per Hour
April 1st: m3.xlarge $886 $0.074 per Hour $1345 $0.06 per Hour
It sounds weird if Amazon is actually going to keep charging the higher rate to existing customers, as they've already paid the higher reservation fee as well.
I was just thinking that, the micro EC2 is now becoming more and more devalued as the higher ones get closer to it's price per performance. I was hoping for us to be able to spin up Beanstalk apps a little cheaper though and it is the cheapest server option and $50/app vs Heroku is a bit expensive since it requires the ELB. I wouldn't mind it all if they had a way to deploy multiple apps using the EC2 servers and ELB you setup though.
Let us hope that RDS prices also drop as a result of this. It's enough of a value for us at the current price rates to be happy with it, but there will need to be some decrease to make sure that it makes financial sense over straight self-managed EC2.
Any time something is announced for April 1, I always have to take a minute to figure out if it's a joke or not. If I wanted to make a change for my company beginning in April, I think I would announce the planned date as April 2nd just to avoid any confusion.
How many instances do you run? At $17.52 saved per year for m1.small that means you must be running over 10k instances to save enough for another full-time dev or two... if your devs are located in SF area.
We're currently spending about $20k/month on EC2 and are about to migrate a bunch of our colos over. Between what we are spending and what we're budgeting to spend with our new architecture, we're looking at a couple devs/year savings (Victoria, BC)
Hardware cost has come down significantly since the prices were last changed. They are making a lot more money now than they will be on April 1st, but it looks like they'll still be in the black.
Amazon markets the story that they operate on thin margins (which no doubt they do in retail) but in AWS the margins are probably fairly attractive. They don't break this out in their SEC filings because (a) they don't have to, and (b) doing so would undermine their marketing message.
Economically cloud can make a lot of sense for several potential customers, including:
* those who have highly variable workloads (so they can spin up lots of servers to meet demand then spin them down afterwards)
* those who favor OpEx over CapEx (Like startups)
* and for those who are bypassing internal IT for TTM reasons (e.g. "shadow IT")
Another point to consider is that while AWS is increasingly dropping prices the same is in effect happening for people procuring their own hardware. The performance over price ratio (on multiple axis) is also improving for on premises deployments (c.f. Moore's Law).
They're not making profits. Most quarters they are only slightly profitable. Current P/E is 582, which is astronomically high. E.g. for comparison Apple's P/E is 13.
But that's been Amazon's strategy for almost two decades. Their goal is to instead grow their business. Currently they are at $74 Billion / year in revenue, and still increasing. Once they stop their massive spending on growth, they will (presumably) be able to increase their profits.
I just reserved a series of heavy-utilization m3.xlarge instances for roughly $30k. Apparently, if I had waited a month, I could have saved about $13k because of these price reductions.
I can't help but feel that I got really fucked by poor timing that I couldn't control. It would hurt so much less if these price changes were more gradual and somewhat consistent (perhaps monthly).
That says a lot for their customer service. I know a lot of companies that would have had more of a "you break it, you buy it" style attitude. Good on them!
Ditto. At the AWS keynote today Andy Jassy, Senior Vice President, spoke of cost saving initiatives AWS has going with $200m already saved via automated notifications to customers to power down their inactive EC2 instances. Andy emphasized the importance of great customer service by AWS & helping customers cut costs. Use that as your leverage point in the discussions with your sales rep. Hope it works out for you!
Well, I bought a 3-year reserved heavy utilization plan just a couple of hours before these news went live. My pain is about 2 orders of magnitude less than yours, though. I wonder if you can contact someone at Amazon and ask for some kind of discount.
Anyway, what a massive drop in price and what a swift reaction from Amazon. Competition can really do wonders. I just hope we won't be seeing drops in the level of service.
Knowing amazons customer service, I would be floored if they would refund you the difference. A couple weeks/days? Maybe maybe not, depends on which rep you get honestly. But a couple hours? That would just be cruel for them not to.
Last time I priced this out for a personal project it was half the price just to build something at home... if I didn't already own the setup this would be pretty great.
150 comments
[ 585 ms ] story [ 3984 ms ] threadGoogle isn't running a charity. Shutting down losing services is a smart business decision. If you see the cloud going the way of the typewriter, then you should also be looking elsewhere to run your computing resources.
As long as there are people who pay more for the Google cloud service than Google's own usage is worth, selling to others reduces the overall costs of computing for Google.
Just never EBS. Ever.
TLDR: it's okay for backups, but in critical path it's a world of sadness. Failure modes are too painful.
The performance of EBS is pretty bad, and getting decent performance is expensive. Having said that, if your application runs in memory and disk usage is infrequent then it is probably fine to use EBS. EBS is also much more expensive than the instance storage, but it is also durable unlike instance storage.
On the whole, "never ever EBS" is too strong language making it incorrect. As usual, it depends.
Most databases have replication but you need to make sure that the characteristics of how the database handles a node failure are well understood. Worst case you use EBS, put your state on it, snapshot it regularly, and ship those snapshots to another region because when EBS fails it fails hard.
Also, logs make every machine stateful. Use something like logstash to centralize that state.
That or sidestep ELB in your region to a team of stateless load balancers that terminate SSL.
The pricing seems reasonable for the performance (I've not done benchmarks if I'm being honest), and you get to treat all your EC2 instances as expendable.
I meant rather that is there any other option for persistent data on AWS?
Also, on EC2, EBS-backed instances boot faster [2]. Of course, you can (and should) still treat EBS-backed instances as expendable.
[1] http://aws.amazon.com/rds/faqs/#hardware-scaling
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Component...
To be honest, I didn't know RDS was backed by EBS but it makes little real difference to me as long as the backup procedures are rock-solid and the performance is acceptable.
At Netflix we use Cassandra and store all data on local instance storage. We don't use EBS for databases.
It's one of those "huh, never ever thought of it from that angle" sort of ideas. The very idea of putting your absolutely valuable data on ephemeral storage and just duplicating it.
Thanks for that.
https://wiki.postgresql.org/wiki/Synchronous_replication
This way you should be able to tolerate failure of a single instance without losing data.
of course, if a comet hits the master db server, you might lose a tiny bit data (typically 0.1 seconds) if not using sync replication.
you can use sync replication for the important things that you absolutely can't lose, and async replication for everything else.
I wouldn't take it that far! There is conflicting information on which between Standard EBS and Instance store performs better but there have been benchmarks to support that EBS does perform more consistently than instance store (example: http://serverfault.com/questions/111594/which-is-faster-for-...). Also, you can now launch EBS optimized instances which use a network stack intended to separate EBS I/O giving better throughput. iops is expensive but is great to have when you need it.
Sure, if EBS goes down in your zone, you're hosed. But unless you're completely independent as a service, chances are you do depend on something which uses EBS so you might be hosed anyways.
Instance store is great free storage to use. Since it needs to be mounted explicitly, I'm guessing that most people don't end up using it. Thats a shame too; so use that free storage but EBS isn't evil either.
I prefer AWS for work stuff because firewall, security groups and networking are much easier to manage.
I have not yet tried GCE but I may move some of my dev stuff over once they roll out the private git repos.
https://source.developers.google.com/p/PROJECT/r/default
You might have to turn it on in your developer console, not sure.
At the moment, pushing to its "master" branch tries to deploy to app engine, so that might not be what you're looking for.
You can clone it (and, in the future, your connected repos and other Google-hosted repos) with 'gcloud init PROJECT', and things should work nicely.
AWS is.
I find it bizarre that Amazon put so much effort into pushing the idea theat their killer feature is price. Plenty of people outflank them on price. What's best about Amazon it their tooling. They have hands-down better tooling than their competition.
I use gandi for my personal stuff (because I'm less bothered by the French government spying on me than the US one) and it's much cheaper than Amazon. But in terms of being able to easily mass-manage a complex environment? Not even close. DO? Don't make me laugh.
This is the Southwest Airlines model. Tell everyone you're great on price often enough, even if it's not always true, and plenty of people will think you're good on price.
edit: do I get my one point back if I delete it or am I permanently shamed?
Cheers to Google.
They already charge an immense premium over your own fleet of micro to large instances, but by the time you rack up enough dynos for it to make sense to spend the necessary weeks migrating your infrastructure there's a good chance that replicating the environment with your own in house version (30+ instances?) is non trivial enough to be scary.
Once you're over a handful of dynos, the sunk costs and uncertainty will keep you there until it becomes totally ludicrous.
Heroku launched with $0.05/hr pricing.
Amazon's new m1.small pricing is $0.044/hr, nearly a 50% price drop over four years.
Heroku still is $0.05/hr, the same price as when it launched. Heroku runs on EC2.
[1] http://www.sunsetlakesoftware.com/2010/09/15/how-run-drupal-...
wonder if there would be price battle on bandwidth.
Given this tidbit, might you reserve an instance now, pay the lower fee, but still take advantage of the new hourly rates on April 1? Or are you locked in at whatever rate your reservation is for?
Bummer, though. We just reserved a multi-AZ m3.large RDS instance last week. I wish AWS would take up Google's system of graduated price reductions over steady run duration.
When we switched off EC2 it was financially advantageous to basically give away our heavy instances on the marketplace just to shed the liability.
In this example, it becomes a question of whether it's worth saving $130'ish a year for the liability that a 1-year m3.medium heavy util reservation represents. At the lower end, that's not a huge amount of liability, but it may be a case where I just don't bother reserving m3.mediums anymore because it's a wash.
For example:
Now: m3.xlarge $1266 $0.105 per Hour $1922 $0.086 per Hour
April 1st: m3.xlarge $886 $0.074 per Hour $1345 $0.06 per Hour
It sounds weird if Amazon is actually going to keep charging the higher rate to existing customers, as they've already paid the higher reservation fee as well.
And what happens when AWS is no longer a revenue source?
Shareholder (owner)'s decision: cut it.
Not a big deal if you are running a business but pretty significant ($588/year) if you are doing personal dev work.
So, pay extra for the support contract?
http://aws.amazon.com/rds/pricing/effective-april-2014/
As far as I know this minimum is set by Amazon, but I don't see that pricing listed in the announcement here.
It's pretty much Caveat emptor with them.
Economically cloud can make a lot of sense for several potential customers, including:
* those who have highly variable workloads (so they can spin up lots of servers to meet demand then spin them down afterwards)
* those who favor OpEx over CapEx (Like startups)
* and for those who are bypassing internal IT for TTM reasons (e.g. "shadow IT")
Another point to consider is that while AWS is increasingly dropping prices the same is in effect happening for people procuring their own hardware. The performance over price ratio (on multiple axis) is also improving for on premises deployments (c.f. Moore's Law).
But that's been Amazon's strategy for almost two decades. Their goal is to instead grow their business. Currently they are at $74 Billion / year in revenue, and still increasing. Once they stop their massive spending on growth, they will (presumably) be able to increase their profits.
I can't help but feel that I got really fucked by poor timing that I couldn't control. It would hurt so much less if these price changes were more gradual and somewhat consistent (perhaps monthly).
:)
Anyway, what a massive drop in price and what a swift reaction from Amazon. Competition can really do wonders. I just hope we won't be seeing drops in the level of service.