Some quantitative data - we monitor Alexa and Fortune 500 marketshare for cloud services. This article is mostly accurate - Google has not taken much marketshare according to our stats. Currently, EC2 is 13% for Alexa 1k/10k and 11% Fortune 500. Rackspace is 5.5% Alexa 1k/10k and 19.4% Fortune 500. Google is under 1% for both, while Azure is between 1-2%. Our stats are available here:
19.4% of Fortune 500 using Rackspace's cloud product sounds very high. How do you differentiate normal Rackspace customers from those using their cloud offering? I would assume they're all in the same data centers.
Cloud Harmony has done some more testing since then which covers some more configurations and you will see Google does quite well - especially if you normalize by price (not in the charts, but prices are public)
I wrote that post - new GCE capabilities like pd-ssd and local SSD are very competitive for price and performance. You can review current benchmark metrics here: https://cloudharmony.com/benchmarks
The question was asked to CIO's to "name their preferred public cloud provider". It's not clear to me what preferred means here. I'd bet a large number of them still have a large amount of on-premise. Does preferred mean the vendor with the highest compute workload, or the one they would pick if they were to move to the cloud?
I have to think that it would be the latter, because moving that much compute workload off of Google's Cloud between 2014 and 2015 would be a big effort.
While the article was informative, it'd be a lot more interesting if it went into the reason people prefer AWS. Does anyone care to comment why they or their company decided to use AWS over competing products?
I think Google's history of shutting down products would keep me from picking Google Cloud for a major project. If Google Cloud continues to lag behind the market, you have to think they will shut it down like Google Reader, Google Wave and a number of other products. Even if Amazon isn't perfect, I feel like AWS will be around for a long time.
Seeing as I can't reply to the comment in question... the price hike article you mention is in 2011. The price hike was a change of system, and everything went up because most people were using Python 2.5 which had no threading support. Python 2.7 had proper threading support, and unsurprisingly when that was enabled, everyone's cost dropped by three-quarters. Google dropped support for 2.5 two years ago.
If were really worried about costs, you'd convert your App Engine app to Go.
Yes that was 2011 but it scared the hell out of me. Since then all my company's project are hosted on Heroku and other Amazon technologies (Simpledb, Dynamo etc.). If I had to have a vendor lock in in exchange of faster development process, I'd prefer to get locked in with Amazon other than Google after that GAE pricing incident.
It wasn't easy to mitigate: re-writes were needed because of the private apis. We ended up doing a lot of optimization to prevent a pet project from costing us too much money, which before the price increase stayed well under the charging threshold. The pricing incident was the only thing on my mind about Google's cloud because we left Google since then. I'm sure things are different now, but then I got too many other things to do before taking a serious look at ditching aws for google.
Amazon might be known for good support on the customer business, but I've not heard the same regarding AWS -- quite the opposite. If Google support were worse, it would have to just ignore you.
It think it varies based on your account. We were one of the companies that presented during the keynote at this year's re:Invent. We've also got an enterprise account. I'm not sure if either of these are a determining factor, but we get excellent support. Phone support is good and emails are answered in about an hour. They've also connected us with their engineers when support isn't able to resolve things.
On the whole, I think the only thing they could improve would be to reduce the siloing between different offerings. When dealing with an issue that spans, say, EC2 and Route 53, I would expect their support to talk to each other and present a unified response to the customer rather than require us to deal with two separate support reps. But this type of siloing goes beyond support and applies equally to the AWS product.
Yes the fact that you were inside the loop enough to be part of the presentation side of re:Invent means your experience is abnormal. You've got the right contacts and profile for them to brag about you.
Having said that, we pay for their 500$/mo support offering and the responses are pretty good. We're also split between AZ's etc as recommended.
As <pm> points out nearby, the GAE pricing issue was in 2011. It's now 2015.
I use GAE for http://recent.io/ (which I left CBS last year to found), and have found that prices have been gradually falling for the last few years. I can't speak to what happened in 2011, but I think it's fair to say that GAE was a much less mature product then.
My own sense is that Google would like to diversify away from being 90%+ reliant on advertising, and is highly unlikely to discontinue a paid service that serves that goal, that is profitable, that is under active development, that allows it to compete with Amazon, and that is used for its own products internally. You might as well speculate they'd discontinue search or email.
I use AWS for some smaller components of http://recent.io/, and have found both to be equally reliable. Google also has assigned me a rep who I can call or email when there's a billing issue, sign up for beta trials of new features I'd like to test, address technical problems, etc., and I've never heard from a human at Amazon.
While a fair assessment, Google is a cloud provider to its internal teams anyways. While there is some overhead to providing it to customers, it's probably less than the overhead of Google Reader or Google Wave because much of the work is already necessary.
I'm not convinced CIOs are thinking about Reader or Wave. Before entering a big deal, it would make sense for people to read the deprecation policy. Unfortunately, the Cloud Platform deprecation policies are unclear.
As a CIO, I would be most concerned with the ecosystem and availability of talent. Google have done a good job trying to reuse some of the same tools and ideas like reuse boto, but writing scripts for their cloud platform vs. AWS is still as different as English and Dutch.
Google has shut down much more than Reader and Wave, or drastically change the paradigm or pricing of their existing offerings in ways that can drastically increase costs. Here is a link to a comment I wrote a year and a half ago, looking at Checkout and Charts.
(Note one correction: at the time, the deprecation of OpenID had no migration path; I complained to a bunch of people at Google I/O, as did likely other developers, explaining in detail the migration problem, and sometime in 2014 Google corrected this mistake.)
I am with you on this. Google needs to demonstrate enterprise awareness about needed guarantees.
However, the bigger issue is that AWS isn't "broken". There is no compelling reason to look at alternative solutions. In particular alternative solutions that have a learning curve.
If google implemented an Amazon API compatibility library that would help a lot. But right now for me to try out google cloud - I have to recode my app.
Google have some pretty good deprecation policies in place with regard to sunsetting their Cloud offering. I recall when I last looked (for appengine a couple of years ago) it equated to a promise to keep the service running for about 3 years. Doing a quick check of terms now, it seems like this has been updated to:
"Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):"
https://cloud.google.com/terms/
Not great, but a year is a long enough time to migrate away. That being said, my recent experience (https://news.ycombinator.com/item?id=8784356) has prompted me to migrate away asap.
I personally wouldn't use the Google cloud because I've had the experience when interacting with Google APIs that API stability is not important to them. The Adwords api used to change every few months and old versions would break. This is not convenient for running a production system.
As a VP Eng who has made the call on Google vs AWS on a few occasions this has certainly affected my thinking. I see Amazon's web services being a big part of Amazon's revenue and I feel comfortable they are in it for the long haul, whereas I see that Google doesn't even call out its cloud service revenue[1] which suggests it isn't notable. And services with that sort of profile from Google end up dead because Google just doesn't seem able to commit to long term strategic visions.
This. Google have a bad history of this. And not to mention they also have have a history of introducing new versions totally incompatible from the last (re Angular) would keep me from ever choosing their stack.
> “We attribute the Google losses to AWS winning the initial branding war over Google Cloud,” he said in an email. “Specifically the initial market share lead triggers future market share gains.”
what a depressingly ignorant and dismissive explanation! How about technical merit, no? All of us preferring to run real OSes rather than some awkward proprietary sandbox, it's all just our falling for "branding" huh?
I haven't used it myself, but I thought Compute Engine ran normal VMs? Could you give some more detail?
Edit: The article says "Google Cloud," which includes App Engine, Compute Engine, and Container Engine... so I guess without more clarification, it's hard to know what exactly is being compared.
Well, i think the second sentence is the important bit. You probably know as well as I that products, especially in large companies, are not always chosen on technical merit alone. Hell, the director of IT at the company I currently work for just went with AWS, primarily because he sees them as the big player in the market. He's not overly technical, more of a buzzword regurgitator, but it's ultimately his call.
> All of us preferring to run real OSes rather than some awkward proprietary sandbox, it's all just our falling for "branding" huh?
The first part of your sentence sounds like you are confusing the whole of Google Cloud -- which includes an IaaS that runs "real OS's" (Google Compute Engine) -- with one of the older components of Google Cloud, the PaaS (AppEngine) that might reasonably be described as something like a "proprietary sandbox".
So, it seems like exactly the effect that was described with regard to perception and branding.
I would guess that this confusion is pretty common, too. Maybe it was a mistake to launch GAE before Compute. It'd be like AWS starting with Lambda for a few years, messing with pricing, then somewhat quietly launching a general-purpose compute PaaS.
Also, AWS has dozens of services. Does Google have the same building blocks? (Storage, caching, CDN, databases, load balancing, etc)
Not identical -- GCE has less separate products than AWSthe ones that are under the Google Cloud Services are listed on the Google Cloud homepage: https://cloud.google.com
The dominance of Amazon continues to amaze me. I thought that Google would win since this is a technology fight. In 20/20 hindsight, it's a price war, and that's in the DNA of Amazon.
App Engine was released a long time ago, around the same time as AWS, but they aren't comparable products. It seems clear that the market chose the AWS technology since it was more compatible with existing code.
It probably helps that AWS has some big and vocal clients. NFLX has probably helped AWS drive innovation and new tooling by providing use cases that most other platforms likely don't have. It also helps that NFLX is crazy vocal on the technical side about how they use AWS to it's fullest capabilities and how they build around "limitations". Makes others feel comfortable that the stack should be able to work for anyone.
I work with CIOs of major companies often. The biggest driver here from what I see is that people are more familiar with AWS. All along the chain of decision making, people have experience with AWS, and can validate it for use.
Not so for other cloud services. It becomes inevitable when every decision maker in your chain can validate one product, and has no experience with others.
That rings true for me. AWS has a huge amount of momentum behind it because people are already familiar with the product, thanks in part to its market position, but also due to the 12 months free trial that a lot of people [ab]use in their own time.
I will say Microsoft has been doing a lot to familiarise people with Azure, they've been giving it away to students and MSDN subscriptions like candy as well as offering trials in various shapes and sizes.
I dread to think how much Microsoft spends on Azure advertising, but considering there is now an NFL ad for it, likely a heck of a lot.
I moved my company over to AWS before all the other options popped up. I did have a few back and forth conversations with someone from GCE late last year, but the end of the year is not really a great time to start a move like that. We are forced to use some other Google products and the lack of support, number of new "features" that aren't thought through, and their lack of ability to give answers to BASIC and SIMPLE question drives me crazy. Sometimes it feels like they're out to specifically screw us. We've cut our adwords budget significantly. The only nagging thing that tugs at my brain is that maybe we'd be considered a 'fast' internet site and get better search engine ranking if we were on GCE. That might make it worth it.
59 comments
[ 4.9 ms ] story [ 119 ms ] threadhttp://blog.cloudharmony.com/2014/12/compute-marketshare-ale...
https://cloudharmony.com/cloudsquare#compare-aws:ec2-and-goo...
Edit: added blog link
https://cloudharmony.com/benchmarks/compute/storage#4k_Rand_...
https://cloudharmony.com/benchmarks/compute/terasort
I have to think that it would be the latter, because moving that much compute workload off of Google's Cloud between 2014 and 2015 would be a big effort.
Also, amazon is known for good support, google is known for horrible support.
http://www.informationweek.com/cloud/platform-as-a-service/g...
If were really worried about costs, you'd convert your App Engine app to Go.
On the whole, I think the only thing they could improve would be to reduce the siloing between different offerings. When dealing with an issue that spans, say, EC2 and Route 53, I would expect their support to talk to each other and present a unified response to the customer rather than require us to deal with two separate support reps. But this type of siloing goes beyond support and applies equally to the AWS product.
Having said that, we pay for their 500$/mo support offering and the responses are pretty good. We're also split between AZ's etc as recommended.
I use GAE for http://recent.io/ (which I left CBS last year to found), and have found that prices have been gradually falling for the last few years. I can't speak to what happened in 2011, but I think it's fair to say that GAE was a much less mature product then.
My own sense is that Google would like to diversify away from being 90%+ reliant on advertising, and is highly unlikely to discontinue a paid service that serves that goal, that is profitable, that is under active development, that allows it to compete with Amazon, and that is used for its own products internally. You might as well speculate they'd discontinue search or email.
I use AWS for some smaller components of http://recent.io/, and have found both to be equally reliable. Google also has assigned me a rep who I can call or email when there's a billing issue, sign up for beta trials of new features I'd like to test, address technical problems, etc., and I've never heard from a human at Amazon.
The terms of service (https://cloud.google.com/terms/) point to the cloud platform deprecation policy (https://cloud.google.com/terms/deprecation). The Cloud Platform deprecation policy points to the product launch stage page (https://cloud.google.com/terms/launch-stages), which points back to the "deprecation policy" section of the terms of service!
As a CIO, I would be most concerned with the ecosystem and availability of talent. Google have done a good job trying to reuse some of the same tools and ideas like reuse boto, but writing scripts for their cloud platform vs. AWS is still as different as English and Dutch.
https://news.ycombinator.com/item?id=6518473
(Note one correction: at the time, the deprecation of OpenID had no migration path; I complained to a bunch of people at Google I/O, as did likely other developers, explaining in detail the migration problem, and sometime in 2014 Google corrected this mistake.)
However, the bigger issue is that AWS isn't "broken". There is no compelling reason to look at alternative solutions. In particular alternative solutions that have a learning curve.
If google implemented an Amazon API compatibility library that would help a lot. But right now for me to try out google cloud - I have to recode my app.
Not. going. to. happen.
"Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):" https://cloud.google.com/terms/
Not great, but a year is a long enough time to migrate away. That being said, my recent experience (https://news.ycombinator.com/item?id=8784356) has prompted me to migrate away asap.
[1] http://investor.google.com/earnings/2014/Q3_google_earnings....
what a depressingly ignorant and dismissive explanation! How about technical merit, no? All of us preferring to run real OSes rather than some awkward proprietary sandbox, it's all just our falling for "branding" huh?
Edit: The article says "Google Cloud," which includes App Engine, Compute Engine, and Container Engine... so I guess without more clarification, it's hard to know what exactly is being compared.
The first part of your sentence sounds like you are confusing the whole of Google Cloud -- which includes an IaaS that runs "real OS's" (Google Compute Engine) -- with one of the older components of Google Cloud, the PaaS (AppEngine) that might reasonably be described as something like a "proprietary sandbox".
So, it seems like exactly the effect that was described with regard to perception and branding.
Also, AWS has dozens of services. Does Google have the same building blocks? (Storage, caching, CDN, databases, load balancing, etc)
As does Google Cloud
> Does Google have the same building blocks?
Not identical -- GCE has less separate products than AWSthe ones that are under the Google Cloud Services are listed on the Google Cloud homepage: https://cloud.google.com
App Engine was released a long time ago, around the same time as AWS, but they aren't comparable products. It seems clear that the market chose the AWS technology since it was more compatible with existing code.
Two years later, actually.
I'm an Azure client and prefer azure personally.
Not so for other cloud services. It becomes inevitable when every decision maker in your chain can validate one product, and has no experience with others.
I will say Microsoft has been doing a lot to familiarise people with Azure, they've been giving it away to students and MSDN subscriptions like candy as well as offering trials in various shapes and sizes.
I dread to think how much Microsoft spends on Azure advertising, but considering there is now an NFL ad for it, likely a heck of a lot.
2-sample test for equality of proportions with continuity correction
data: c(13, 8) out of c(152, 152)
X-squared = 0.8184, df = 1, p-value = 0.3656
alternative hypothesis: two.sided
95 percent confidence interval: -0.03057673 0.09636621
So there's no evidence that there actually was a statistically significant change in usage of google's cloud.