>> “Google is making a dent and AWS is starting to feel the pain from a pricing perspective,”
>But they didn't announce a price reduction this week!
Uh, they announced a change related to pricing, not a reduction: http://aws.amazon.com/blogs/aws/simplified-reserved-instance...
>> says one ex-Amazon employee who asked not to be identified because his current employer works with the cloud company.
>Because they work for Google. Because this is a paid Google advert.
They don't work for Google. They work for a company that works with Google. That could be one of thousands (?) that are hosted on Compute Engine.
And given Google's reputation for support (fully warranted in my experience), it's going to take a lot for corporations to shift away from AWS. It's actually astounding how much market share Azure has gotten already in spite of AWS.
In my experience the only times I've heard Google mentioned by companies as an option are small start ups.
The big difference is that with AWS, I am probably "stuck" with an instance for 1-3 years, unless I want to take my chances with the hit-or-miss reservation marketplace. This is a really bad fit for some businesses that are still vertically scaling, but don't have deep pockets. AWS can still make sense for companies on a budget because of their great portfolio of services, but EC2 is by far the most inconvenient billing-wise.
For example, we reserved an m3.large RDS instance, which at the time left us more than enough breathing room. About four months went by, and traffic grew far faster than projections. We weren't hurting, but we now wanted to bump to a m3.xlarge to feel comfortable, even after a round of optimizations and profiling. We're stuck with that 1-year reservation's sunk cost, and have no use for the old m3.large reservation if we switch to m3.xlarge.
The other fun part was buying a 3-year m1.medium reservation, only to see the new m3 series instances come out before those three years were up. These new instance types have been landing pretty frequently.
Reservations shift a lot of "risk" on to the customer and away from Amazon. GCE's pricing model is harder to estimate your bill with, but I actually like the idea of not being "stuck" if I want to be economical. Automatically give me discounts for instances that I run often, but don't lock me down.
So as long as you stuck to m3 and you know you will be using some machines, you should be fine. A bigger problem I see is that most startups don't actually know where they will be in a year (or 3).
One solution would be to reserve compute units, instead of machines. You could reserve 16 m3 "units" and could use that as 4 x m3.large or 2 x m3.xlarge. Those are equivalent in hardware anyway (minus some fragmentation).
There are a lot of caveats to this. Most importantly, you had to have purchased the reservations that you are going to combine at the same time. You can't mix and match durations. If you have one with 8 months left and another wix 6 months left, you're out of luck. So if you want this kind of thing, you've got to shell out a lot more at the same time to buy a group of reservations. That's kind of a pain to me.
> One solution would be to reserve compute units, instead of machines. You could reserve 16 m3 "units" and could use that as 4 x m3.large or 2 x m3.xlarge. Those are equivalent in hardware anyway (minus some fragmentation).
The fact that we're sitting here talking about making a huge investment that we may or may not end up using effectively is the thing I dislike about this reservation system. I'm going to have to shell out a good bit of coin upfront for all of this, and I am effectively locked in for at least a year. Unless I want to gamble on the reservation market.
This is my biggest gripe, as an AWS customer. Give me more simple billing and get out of my way. Don't lock me into this thing that resembles a contract with a cancellation fee.
To make that analogy more correct, you've got a finite amount of coffee money, and you'd be agreeing to drink the same coffee (size, flavor, quantity) for 1-3 years. If a better blend or different flavor arrived at the coffee shop, you'd be out of luck until the end of your contract. Unless you wanted to go outside of your contracted discount and pay the full rate (On Demand), while eating the sunk cost of the reservation fee. If you found your tolerance rising and wanted a bigger cup or more cups, you'd lose your discount.
It's not as simple as "give me an instance and give me a discount". It's a shifting of risk from AWS to the customer.
Sure there is. I'm not going to get into potential motivations and logistics (since I as a customer don't care), but there is no doubt that reservations are for shifting risk to the customer and away from Amazon. It doesn't matter if they're offering a discount, that's really not the point I am trying to make. I'm more concerned with the "risk" I take on each time I reserve an instance.
The big gripe I have is that a reservation is made with the assumption that everything (quality of service, the needs of your application, customer service) stays roughly the same for the duration of the reservation. If the customer service stinks, or there are some really bad outages, I've sunk the cost and end up throwing the money away if I switch (we eat the expense instead of Amazon). If I want to upgrade my instance size and have mixed duration reservations, I've got that sunk cost to swallow. If I want to scale down, ditto. I risk throwing away money if I change plans.
In a perfect world, I'd like the option to either pay an upfront reservation fee for the best rates, or run On Demand and get a graduated discount curve like Google Compute. They'd still get have an incentive to stay put, and people or companies with lower budgets could avoid the large reservation fees. At the same time, you could still pay the upfront reservation fee if you wanted the best rate and didn't mind committing for a year+.
Yeah, that was my impression too. The fact is: Google is really afraid of AWS. Google knows that it's several quarters behind on cloud infrastructure deployment, and that the lack of presence in places like Australia is a problem.
That is why they're working like crazy to rush the 'miniclusters' project out of the door to try to capture market share in those regions before Amazon and Microsoft take everything and laugh on their way to the bank.
On top of that, Google's cloud offering is also behind in the tools and support department. Most of their projects are so behind schedule it's not even funny and will most likely miss their Q4 objectives.
Amazon and Microsoft have, today, much better offerings then Google will by the end of Q2 2015.
Disclaimer: I work for TAGA (The Arrogant Google Assholes)
Dang - are Wired beating your voting ring detection or are they paid promoted content?
Except for the fact it doesn't mention App Engine at all.
And Google does have a lot of other offerings besides App Engine.
Please go on about App Engine. Perhaps you should take a better look at Googles other offerings before you criticize.
People call Amazon's entire offering "EC2" all the time. People call Google's offering "App Engine" (because it existed first, and because initially it included more stuff than it does today).
It is pretty obvious that I was talking about Google's VM product ("Google Compute Engine") because this entire discussion makes no sense otherwise. You're being intentionally obtuse just to have something to whine about.
They point to the announcement about RI pricing simplification as proof that "Google has finally arrived." No justification at all, and it isn't obvious how one relates to the other (in particular as the RI changes weren't a direct price reduction).
> “Google is making a dent and AWS is starting to feel the pain from a pricing perspective,”
But they didn't announce a price reduction this week!
> says one ex-Amazon employee who asked not to be identified because his current employer works with the cloud company.
Because they work for Google. Because this is a paid Google advert.
> But this spring, Google introduced a product called Sustained Use Discounts, and this made things much simpler.
I'd argue that the sustained use model makes it harder to calculate your ultimate bill, not easier. It has the same issues Amazon's now retired Light and Medium usage tiers had, how do you track if you're at 25%, 50%, 75%, etc utilisation? Keeping track of that is annoying and harder than you'd think in a real production environment with dynamic instances responding to load.
Amazon's new pricing model actually just scrapped something akin to sustained use billing because it was unpopular. You wouldn't know that reading the article.
> Maybe they didn’t want to draw attention to what’s obviously a reaction to Google
Maybe it was a reaction to customer feedback? I see no evidence that Google caused this change, and the fact that Amazon moved AWAY from Google's model is very telling. Light and medium utilisation RI are effectively Google's model, they just do it dynamically. Amazon hasn't added that or indicated that they will.
Do these people even understand Amazon's RI pricing structure, or Google's sustained usage, or anything at all?
> Byrne says that until Amazon changed its pricing, his company was toying with the idea of switching to Google, a move that would have saved Copper.io hundreds of thousands of dollars—until Monday, at least.
That literally makes zero sense. Heavy utilisation RIs have been available since forever, and are extremely price competitive with every other major competitor in the cloud infrastructure space (namely Google, and Azure).
If it would have saved you "hundreds of thousands" legitimately then you are mismanaging your account heavily.
> “When I saw the Amazon announcement, I said: ‘Great. We don’t have to consider moving.'”
Because, why? I don't understand what it is they think Amazon changed. Because that statement makes no sense. If you were mismanaging your account before, you'd still be mismanaging it now. Amazon moving payments will save you a little money (due to the interest on that money sitting in your accounts) but nothing like what is described here.
> When Google first got into the cloud business back in 2008, the company bet that people would want to run cloud applications on its infrastructure in highly specialized ways and not mess around with operating systems and virtual machines. That proved to be a bad bet.
That is an under-statement. Google thought that people wanted to be locked into their cloud APIs and initially at least have to completely re-write all of their software for Google's app engine. It was supremely arrogant on Google's part.
App engine now supports more standardised APIs and databases, but it remains more expensive to do than it should be. Azure's "web-sites" product is what Google App Engine should have been when it first got released, and even today I find "web-sites" more compelling as a bottled solution than Google App Engine (although VMs trump both).
> And now the company is fast catching up.
Is that a fact? Because both Google and Azure topped $1B in 2013, and from what I've been seeing Azure, not Google, has been growing to compete with Amazon in 2014. Microsoft has been leveraging many pre-existing channels (education, MSDN, et al) to give out Azure trials and it seems to be working for them.
> Byrne says that while Google doesn’t offer the wide range of products, it beats out Amazon in many respects. Google’s compute speed and network “is faster than Amazon’s,” he says. “They’re probably the only people where you can say that their infrastructure is really world-leading.”
If you weren't certain this was a paid product advert, now you should be.
Compute speed is relative to cost, and dollar per dollar that statement seems untrue. Network speed on Amazon and Google is great, Google might be better but I wouldn't migrate to them because neither Amazon or Azure have let me down in that department.