6 ms·

I'm only a small user of cloud providers, but find Google cloud engine much more user friendly than aws, so why is amazon still capturing the market? I don't se

I'm only a small user of cloud providers, but find Google cloud engine much more user friendly than aws, so why is amazon still capturing the market? I don't see the downsides of GCE.

impostervt 11y ago
Everytime I try and compare AWS & Google Cloud I get confused. I just find AWS pricing more straightforward.
- brianwawok 11y ago
  They are different for sure. AWS has the extra hoop of needing 1 year reservations to get fair pricing, whereas GCE gives you the good price just by using something for > 50% of a month. So from a startup POV, loving GCE pricing model.
- boulos 11y ago
  Disclaimer: I work on Compute Engine. Which services are you comparing? We (sadly) make our pricing table for Compute Engine (GCE) look a lot like EC2. Just looking at rates misses the advantage of per-minute billing for certain workloads (e.g. Batch compute or autoscaled anything) and our "sustained use discount" which gives you roughly the same discount as EC2 reserved instances but without having to do anything. As I said to someone recently, our model isn't super simple to "understand" but it's way easier: we always give you the best price. The same thing goes for GCS vs S3, general network pricing, etc. Have you tried our pricing calculator (https://cloud.google.com/products/calculator/ https://cloud.google.com/products/calculator/)?
  - nullrouted 11y ago
    Can you tell me why your disk latency and throughput is so horrible, even compared to AWS? I've seen ioping spikes in the 7-8 ms range and it has far worse throughput than AWS. Also any idea if your folks are ever going to let people set RDNS records for their IPs? It has been requested but no one at GCE seems to communicate.
    - larrymcp 11y ago
      Oh wow... I didn't know Google lacks the ability for customers to specify reverse DNS. I had assumed any full-service cloud provider would offer this feature. If Google doesn't have configurable RDNS, they're not a "one-stop shop" for all hosting needs. For example, a customer wouldn't send transactional e-mails from a server at Google because the lack of RDNS would affect deliverability.
      - boulos 11y ago
        We are most definitely not a one-stop shop yet. We don't even have IPv6 on GCE (I recommend Linode for low traffic IPv6 to IPv4 bridges). Moreover, (sadly) your example doesn't hold anyway: sending email is actually something all cloud providers try to avoid (SoftLayer in Brazil lately is the notable exception). So getting anyone to whitelist your smtp and other ports is usually an unpleasant experience.
        larrymcp 11y ago
        Oh, this actually works great at AWS, yeah! We've been sending transactional e-mails from our servers at Amazon for a couple of years. They do require you to request the e-mail ports be unblocked, but once we made the request it was approved within 24 hours. As a bonus, the same request form also has a space where you tell them what you want your reverse DNS to be. Very handy. Last year Microsoft also announced Azure support for reverse DNS entries. So I would anticipate Google getting on this "bandwagon" fairly soon too. Just my guess though!
    - boulos 11y ago
      Which "disk"? We've got Persistent Disks aka PD (logically similar to EBS / network storage) that come in both a "hard drive" variety and an "ssd" variety, as well as local SSD. I assume you're talking about one of the PD products, most likely PD-SSD and comparing to one of the EBS offerings (either the new one or a piops one)? If so, unlike traditional EBS, PD scales throughput according to disk size [1]. You get 30 IOPS/GB up to 15k or so. As far as latency goes, what instance were you testing on? Your VM's I/O competes for cycles with your vCPU (this is true of all KVM-based virtualization), so if you spike up your CPU you can easily "starve" your I/O threads or vice versa. As to your DNS question, I'll have to look into that. But where are you trying to communicate? (I mean clearly you found me, but I mean where else)
  - ufmace 11y ago
    Just curious, do you have anything to do with whatever infrastructure the Apps Script scripts run on? I normally like the Google Sheets app and find it really handy to collaborate with, but just a few days ago, I wrote an utterly trivial script for the first time in Apps Script to do some formatting changes on a small sheet automatically. This is like a 20 line script with one loop that runs through like 5 times, the kind of thing you'd expect should run in under 1ms on pretty much anything. I didn't time it when I ran it, but I'm pretty sure it took over a minute to run, certainly much more than a few seconds. What's the deal with that?
libria 11y ago
A couple guesses: * AWS has the momentum and reputation. They've been in the game a while. * Google has earned a reputation for shuttering products with little warning. CTOs really dislike an ad-hoc forced migration. That said, I've been hearing good things about GCE. If they can polish their image WRT stability, they'll be grabbing marketshare in a couple years.
- petra 11y ago
  I wonder if becoming an independent group cloud group inside of alphabet would help in that regard.
- KB1JWQ 11y ago
  > * Google has earned a reputation for shuttering products with little warning. CTOs really dislike an ad-hoc forced migration. Exactly why we smiled and said "thanks but no thanks" when their salesfolk hit us up; I can't trust that any given Google platform will still be there in three to five years.
mpdehaan2 11y ago
Does GCE still require that you name (vs simply tag) instances via their APIs in order to create new guests? That and the slightly weird authentication/setup process (rough memory of that, really) were the obvious downsides for me. Obvious upsides to GCE would be fractional hourly billing and allegedly no-need to prewarm loadbalancers. And probably there aren't mystery settings that require you to email someone to ask them to be set, and there probably aren't features that you can only access through the GUI with API support coming later -- though that is just a guess :) A downside to GCE would be if you wanted any of the various other services that AWS provides, since they provide a ton more. AWS also has really good service -- Google may also, but I haven't had direct experience.
- boundlessdreamz 11y ago
  Can you explain the name/tag requirement? Yeah, the authentication/setup process is weird. OK for individuals but very confusing for team permissions and the permissions are very basic But despite this I still prefer GCE over AWS. * GCE documentation is much better. Understanding things from AWS docs can be an exercise in frustration. * The console is easier to understand and more responsive. Command line tools have good UX. * Instances boot up faster and seems to perform better and have more predictable performance * Automatic discounts without reserving instances. (It's awesome!)
  - optionalparens 11y ago
    Maybe this is preference or something changed since I used GCE daily, but I disagree on almost all these points. * Documentation - On the surface, GCE docs always looked better to me until I realized how many mistakes there were and things out-of-date. Not to mention there was too much of the obvious documentation and not anything regarding subjects where I'd actually want detailed docs. Although Amazon's docs are trash, they have the benefit of everyone and their mother writing about how to do x, y, or z. Whether that's a benefit or not, it depends on the author. * Console - The console was sometimes more responsive depending on the action, but for some things was worse. Overall I'd give this one to GCE as well, but I think the GUI was a mess in places. Perhaps that's more based on my total usage of Google Services, which are a superset of GCE. Regarding command line tools though, I felt these were awful, slow, poorly documented, and buggy. Again, maybe an update fixed some of this. Google has a really bad history with consoles. Amazon's GUI is 90sish at times, but it's been pretty good to me and the API just works. * The answer to this one is really it depends on the machines, location, etc. GCE has some advantages here that are well documented, but performance of a running machine was never really a problem I faced on Amazon provided you select a good instance type. * Can't argue here. Amazon does like to give out its share of freebies though if you are a big enough customer or paying attention to the community.
Hermel 11y ago
I am a user of Google App Engine and found its performance unsatisfying. I can execute the same Java programs 10 times faster on my local machine than in an app engine instance with the same GHz and RAM according to Google. I.e. what takes 1 second locally (CPU-bound, no i/o), takes 10 seconds in app engine.
- RyanZAG 11y ago
  +1 Google App Engine soured me to anything cloud related from Google. It's the worst product ever launched.
- optionalparens 11y ago
  Also +1, App Engine is terrible. I worked for one of the largest App Engine deployments for startups. We were Python, Java, and Go and all were terrible. I've never felt like a company was giving me the middle finger as hard as App Engine. It's a terrible product and a shameful dev team. There's a million things wrong with GAE besides performance, but if we just focus on that, where to even start? When I first took my last job using GAE, I was able to improve the performance of one of our apps in my 2nd week on the job from requests taking anywhere from 3-14 seconds to sub 1 second. That sounds good, but actually the original authors of the app didn't really do anything too bad, it was just they tried to write a standard web CRUD app in Django. The answer to improving performance was mainly to never query their data store if you could help it. Solid advice for most apps, only the queries were completely unpredictable. Pretty much the standard Google answer for all App Engine is to do everything in memcached. OK, again, fine, but then memcached started being unpredictable. Google Answer - we'll develop private memcached to let you tweak it more. OK, fine, but it's still not as fast as when we run memcached on AWS. Even when we ran our site with 99.9% cache hit ratio, we still had erratic performance. We next switched things to do more on the client and ran an Angular SPA app. Again we saw benefits of course, but still things sometimes were slower than we wanted. Simply Google's billing API requests and their slow servers serving requests tended to be the problem, which was often something we had no control over. And that was basically the theme of other problems we had. We figured out the requests problems at the beginning FYI and told Google, and they simply said they would work on it, but actually over time things often got slower. App Engine is a terrible platform and most of the benefits can be replicated by various libraries out there for deployment, versioning, caching, etc. or through admin panels in other services like AWS. If you want to lock yourself into terrible APIs that do things like intercept your POST and re-issue it as a GET, go for it. If you want to start building your apps around billing patterns rather than proper architecture, go for it (how can I do y instead of x to avoid being billed?). I could go on, but yeah App Engine is pretty bad. It gets you going from dev to production somewhat quickly, but don't many frameworks + cloud providers do that now? The only real benefit I found which you could argue is that you alleviate some of the security challenges, but that's assuming you trust Google's environment and configuration (which you have essentially no control).
optionalparens 11y ago
I've been a big user of cloud providers, and left a startup a year ago that was a huge customer of Google (GCE, BigQuery, App Engine, Google Drive, etc.) and ran one of the larger GCE and App Engine deployments for startups. We ended up having a few fringe services in Amazon and moving a lot of new ones to Amazon. Eventually we decided to leave GCE as soon as we could migrate one of our main sites off of App Engine. I mention App Engine because it shares a lot of the same core issues as GCE in terms of pain points. Why did we want to leave? Honestly, it was a combination of things starting with the hateful and broken App Engine platform (API, admin, everything) to the usual Google nonsense of cancellations, adding useless features, bad prioritization of bugs, lack of fulfilling SLAs, etc whether it was GCE or another service. After working with 2 startups that were based heavily on Google's cloud, I can't recommend them unless something dramatic has changed. I can go into more details in private and a few publicly but it would be a huge post so I'll mention only a few things here. Suffice to say, I found GCE to be anything but friendly compared to Amazon at all levels. While Amazon has a confusing and sometimes horrible admin panel, it's been my experience as an AWS customer for a long long time that it just works most of the time. Most of the time sounds bad, but it is better than "rarely" or "never" we experienced with Google (more later). When something is broken, Amazon generally fixes it or even a primitive retry will suffice. If something was really broken, Amazon gave us free credit, while Google either lied or hardly budged on bills (even funnier since Google was one of our investors). A related and huge problem we had was that Google tended to make platforms, libraries, features, and services very 1/2 baked. Google is perhaps good at ideas and maybe even better than Amazon at building a solid core, but there is absolutely no follow-through. Too many times we encountered libraries and services that were terminated or overhauled because something was fundamentally broken. Worse, we pointed out big problems months or years in advance along with other customers and the community but saw no action. Google's dev team would continue to pretend nothing is wrong until either terminating or going back to the drawing board. I've never experienced a large company burying its head in the sand as much as Google. I love Google search, but I refuse to use any of their cloud products with the attitude that I've seen top to bottom, from sales to dev. Another very important point I think a lot of inexperience people neglect - AWS has great support when it comes to libraries and integrations. Pick x language and generally you can find at least a working version of a library for whatever service you are using, including new features. Google's cloud services in my experience are filled with broken, slow, horrible libraries, including the official ones. As an example, there was a really bad (probably still open) form encoding bug in App Engine with multi-part forms that's been broken since almost the start of App Engine (basically, anything non-Ascii got corrupted). It's never really been fixed despite multiple people giving Google tons of data, patches, and workaround. We even got on the phone with them about it several times. GCE has honestly not been as bad as App Engine in terms of fixing things, but it also lacks features and library integrations. As an example of a more specific GCE problem, anything that has issues with multi-cast had to have tons of patches. There was a special adapter for ElasticSearch when we deployed it on GCE that constantly had to be updated, and if you read about it, you'll see it's mainly a GCE thing. Pretty much every service, tech, or library we used that was more serious had similar issues - there was always a workaround or feature you had to manually implement that you didn't realize you took for granted on Amazon. The deployment story just given the tools was always far better on Amazon for example, but that may have changed. Then there's installing and developing against GCE. Most of GCE for the past few years was command line only. That's fine if your command line is well written and well-documented, but GCE is most certainly not. The command line didn't even really work on Windows and not even really with something like cygwin. You can laugh, but at my other company we did a lot of DirectX and Xbox development, and developing on other platforms didn't make that much sense. Unfortunately some people in our company decided not using AWS would be cool. Developing against GCE once you got things working was no treat and we felt we often had to write tons of new libraries to do basic things that existed somewhere in the Amazon stack. As far as the documentation, Google's services are usually out-of-date and full of mistakes. You could argue the docs are better than what Amazon has, however Amazon has the benefit of the community at this point that generally can answer your questions quickly. Moreover, Google in its own documentation often brags how good their docs are, while simple things like broken links or deprecated features are usually all over the place. How hard is it to run a broken link checker at least? The community is a huge topic, but I'll add that support was so bad at some points that the official line was to ask on StackOverflow instead (fine, but you're a huge company with a tiny install base at the time, wtf). GCE did (does) have an admin console in addition to the command line, but the early versions were very limited. The last GCE console I worked with was in-step with most Google admin consoles looks like an ASP 2.0 app. Most things in the admin console are far inferior to the command line and full of bugs. Even finding the right settings in the admin console are a complete nightmare and sometimes require you to open other Google Services that you would think have no impact on GCE, App Engine, or anything else, and yet do. They often re-arrange how all of this works, but then leave parts of the old sites still running, so you end up with crazy nesting, conflicting options and navigation, and randomness. Mostly you feel like some dev somewhere kept saying, "I don't feel like doing this, so I'll put this all here because I can." It all looks like a bad assignment done last minute in a computer lab for a comp-sci class. I know I seem a bit harsh, but I really wanted to try something new besides AWS the last few years. I joined 2 companies that did exactly that (independent of me), and that ended up terrible for both. There really was not much I couldn't do on AWS that GCE could do, while AWS could do plenty of things that GCE could not do at the time. AWS was far more reliable, stable, and well-supported for us as well, along with my own startup, and my past companies. Given I was a customer of Google's for a long, long time along with Amazon's and little changed with Google, I doubt it is much different now. Maybe someone can correct me, but usually when we get into these kinds of debates, the person with high opinions about GCE and the Google Cloud in general has not been on it long and certainly has not hosted a serious environment on it. I find Amazon as a company somewhat repulsive like Google in various ways, but AWS for all its faults is definitely more popular for a reason still. I hope Google can push Amazon to make their platform better, but from what I have seen the last few years, GCE is half-baked and only suitable if you're throwing a few small or personal servers in the cloud without significant interactions between them.

I'm only a small user of cloud providers, but find Google cloud engine much more user friendly than aws, so why is amazon still capturing the market? I don't see the downsides of GCE.

impostervt 11y ago

Everytime I try and compare AWS & Google Cloud I get confused. I just find AWS pricing more straightforward.

brianwawok 11y ago
They are different for sure. AWS has the extra hoop of needing 1 year reservations to get fair pricing, whereas GCE gives you the good price just by using something for > 50% of a month. So from a startup POV, loving GCE pricing model.
boulos 11y ago
Disclaimer: I work on Compute Engine. Which services are you comparing? We (sadly) make our pricing table for Compute Engine (GCE) look a lot like EC2. Just looking at rates misses the advantage of per-minute billing for certain workloads (e.g. Batch compute or autoscaled anything) and our "sustained use discount" which gives you roughly the same discount as EC2 reserved instances but without having to do anything. As I said to someone recently, our model isn't super simple to "understand" but it's way easier: we always give you the best price. The same thing goes for GCS vs S3, general network pricing, etc. Have you tried our pricing calculator (https://cloud.google.com/products/calculator/ https://cloud.google.com/products/calculator/)?
- nullrouted 11y ago
  Can you tell me why your disk latency and throughput is so horrible, even compared to AWS? I've seen ioping spikes in the 7-8 ms range and it has far worse throughput than AWS. Also any idea if your folks are ever going to let people set RDNS records for their IPs? It has been requested but no one at GCE seems to communicate.
  - larrymcp 11y ago
    Oh wow... I didn't know Google lacks the ability for customers to specify reverse DNS. I had assumed any full-service cloud provider would offer this feature. If Google doesn't have configurable RDNS, they're not a "one-stop shop" for all hosting needs. For example, a customer wouldn't send transactional e-mails from a server at Google because the lack of RDNS would affect deliverability.
    - boulos 11y ago
      We are most definitely not a one-stop shop yet. We don't even have IPv6 on GCE (I recommend Linode for low traffic IPv6 to IPv4 bridges). Moreover, (sadly) your example doesn't hold anyway: sending email is actually something all cloud providers try to avoid (SoftLayer in Brazil lately is the notable exception). So getting anyone to whitelist your smtp and other ports is usually an unpleasant experience.
      - larrymcp 11y ago
        Oh, this actually works great at AWS, yeah! We've been sending transactional e-mails from our servers at Amazon for a couple of years. They do require you to request the e-mail ports be unblocked, but once we made the request it was approved within 24 hours. As a bonus, the same request form also has a space where you tell them what you want your reverse DNS to be. Very handy. Last year Microsoft also announced Azure support for reverse DNS entries. So I would anticipate Google getting on this "bandwagon" fairly soon too. Just my guess though!
  - boulos 11y ago
    Which "disk"? We've got Persistent Disks aka PD (logically similar to EBS / network storage) that come in both a "hard drive" variety and an "ssd" variety, as well as local SSD. I assume you're talking about one of the PD products, most likely PD-SSD and comparing to one of the EBS offerings (either the new one or a piops one)? If so, unlike traditional EBS, PD scales throughput according to disk size [1]. You get 30 IOPS/GB up to 15k or so. As far as latency goes, what instance were you testing on? Your VM's I/O competes for cycles with your vCPU (this is true of all KVM-based virtualization), so if you spike up your CPU you can easily "starve" your I/O threads or vice versa. As to your DNS question, I'll have to look into that. But where are you trying to communicate? (I mean clearly you found me, but I mean where else)
- ufmace 11y ago
  Just curious, do you have anything to do with whatever infrastructure the Apps Script scripts run on? I normally like the Google Sheets app and find it really handy to collaborate with, but just a few days ago, I wrote an utterly trivial script for the first time in Apps Script to do some formatting changes on a small sheet automatically. This is like a 20 line script with one loop that runs through like 5 times, the kind of thing you'd expect should run in under 1ms on pretty much anything. I didn't time it when I ran it, but I'm pretty sure it took over a minute to run, certainly much more than a few seconds. What's the deal with that?

libria 11y ago

A couple guesses: * AWS has the momentum and reputation. They've been in the game a while. * Google has earned a reputation for shuttering products with little warning. CTOs really dislike an ad-hoc forced migration. That said, I've been hearing good things about GCE. If they can polish their image WRT stability, they'll be grabbing marketshare in a couple years.

petra 11y ago
I wonder if becoming an independent group cloud group inside of alphabet would help in that regard.
KB1JWQ 11y ago
> * Google has earned a reputation for shuttering products with little warning. CTOs really dislike an ad-hoc forced migration. Exactly why we smiled and said "thanks but no thanks" when their salesfolk hit us up; I can't trust that any given Google platform will still be there in three to five years.

mpdehaan2 11y ago

Does GCE still require that you name (vs simply tag) instances via their APIs in order to create new guests? That and the slightly weird authentication/setup process (rough memory of that, really) were the obvious downsides for me. Obvious upsides to GCE would be fractional hourly billing and allegedly no-need to prewarm loadbalancers. And probably there aren't mystery settings that require you to email someone to ask them to be set, and there probably aren't features that you can only access through the GUI with API support coming later -- though that is just a guess :) A downside to GCE would be if you wanted any of the various other services that AWS provides, since they provide a ton more. AWS also has really good service -- Google may also, but I haven't had direct experience.

boundlessdreamz 11y ago
Can you explain the name/tag requirement? Yeah, the authentication/setup process is weird. OK for individuals but very confusing for team permissions and the permissions are very basic But despite this I still prefer GCE over AWS. * GCE documentation is much better. Understanding things from AWS docs can be an exercise in frustration. * The console is easier to understand and more responsive. Command line tools have good UX. * Instances boot up faster and seems to perform better and have more predictable performance * Automatic discounts without reserving instances. (It's awesome!)
- optionalparens 11y ago
  Maybe this is preference or something changed since I used GCE daily, but I disagree on almost all these points. * Documentation - On the surface, GCE docs always looked better to me until I realized how many mistakes there were and things out-of-date. Not to mention there was too much of the obvious documentation and not anything regarding subjects where I'd actually want detailed docs. Although Amazon's docs are trash, they have the benefit of everyone and their mother writing about how to do x, y, or z. Whether that's a benefit or not, it depends on the author. * Console - The console was sometimes more responsive depending on the action, but for some things was worse. Overall I'd give this one to GCE as well, but I think the GUI was a mess in places. Perhaps that's more based on my total usage of Google Services, which are a superset of GCE. Regarding command line tools though, I felt these were awful, slow, poorly documented, and buggy. Again, maybe an update fixed some of this. Google has a really bad history with consoles. Amazon's GUI is 90sish at times, but it's been pretty good to me and the API just works. * The answer to this one is really it depends on the machines, location, etc. GCE has some advantages here that are well documented, but performance of a running machine was never really a problem I faced on Amazon provided you select a good instance type. * Can't argue here. Amazon does like to give out its share of freebies though if you are a big enough customer or paying attention to the community.

Hermel 11y ago

I am a user of Google App Engine and found its performance unsatisfying. I can execute the same Java programs 10 times faster on my local machine than in an app engine instance with the same GHz and RAM according to Google. I.e. what takes 1 second locally (CPU-bound, no i/o), takes 10 seconds in app engine.

RyanZAG 11y ago
+1 Google App Engine soured me to anything cloud related from Google. It's the worst product ever launched.
optionalparens 11y ago
Also +1, App Engine is terrible. I worked for one of the largest App Engine deployments for startups. We were Python, Java, and Go and all were terrible. I've never felt like a company was giving me the middle finger as hard as App Engine. It's a terrible product and a shameful dev team. There's a million things wrong with GAE besides performance, but if we just focus on that, where to even start? When I first took my last job using GAE, I was able to improve the performance of one of our apps in my 2nd week on the job from requests taking anywhere from 3-14 seconds to sub 1 second. That sounds good, but actually the original authors of the app didn't really do anything too bad, it was just they tried to write a standard web CRUD app in Django. The answer to improving performance was mainly to never query their data store if you could help it. Solid advice for most apps, only the queries were completely unpredictable. Pretty much the standard Google answer for all App Engine is to do everything in memcached. OK, again, fine, but then memcached started being unpredictable. Google Answer - we'll develop private memcached to let you tweak it more. OK, fine, but it's still not as fast as when we run memcached on AWS. Even when we ran our site with 99.9% cache hit ratio, we still had erratic performance. We next switched things to do more on the client and ran an Angular SPA app. Again we saw benefits of course, but still things sometimes were slower than we wanted. Simply Google's billing API requests and their slow servers serving requests tended to be the problem, which was often something we had no control over. And that was basically the theme of other problems we had. We figured out the requests problems at the beginning FYI and told Google, and they simply said they would work on it, but actually over time things often got slower. App Engine is a terrible platform and most of the benefits can be replicated by various libraries out there for deployment, versioning, caching, etc. or through admin panels in other services like AWS. If you want to lock yourself into terrible APIs that do things like intercept your POST and re-issue it as a GET, go for it. If you want to start building your apps around billing patterns rather than proper architecture, go for it (how can I do y instead of x to avoid being billed?). I could go on, but yeah App Engine is pretty bad. It gets you going from dev to production somewhat quickly, but don't many frameworks + cloud providers do that now? The only real benefit I found which you could argue is that you alleviate some of the security challenges, but that's assuming you trust Google's environment and configuration (which you have essentially no control).

optionalparens 11y ago

I've been a big user of cloud providers, and left a startup a year ago that was a huge customer of Google (GCE, BigQuery, App Engine, Google Drive, etc.) and ran one of the larger GCE and App Engine deployments for startups. We ended up having a few fringe services in Amazon and moving a lot of new ones to Amazon. Eventually we decided to leave GCE as soon as we could migrate one of our main sites off of App Engine. I mention App Engine because it shares a lot of the same core issues as GCE in terms of pain points. Why did we want to leave? Honestly, it was a combination of things starting with the hateful and broken App Engine platform (API, admin, everything) to the usual Google nonsense of cancellations, adding useless features, bad prioritization of bugs, lack of fulfilling SLAs, etc whether it was GCE or another service. After working with 2 startups that were based heavily on Google's cloud, I can't recommend them unless something dramatic has changed. I can go into more details in private and a few publicly but it would be a huge post so I'll mention only a few things here. Suffice to say, I found GCE to be anything but friendly compared to Amazon at all levels. While Amazon has a confusing and sometimes horrible admin panel, it's been my experience as an AWS customer for a long long time that it just works most of the time. Most of the time sounds bad, but it is better than "rarely" or "never" we experienced with Google (more later). When something is broken, Amazon generally fixes it or even a primitive retry will suffice. If something was really broken, Amazon gave us free credit, while Google either lied or hardly budged on bills (even funnier since Google was one of our investors). A related and huge problem we had was that Google tended to make platforms, libraries, features, and services very 1/2 baked. Google is perhaps good at ideas and maybe even better than Amazon at building a solid core, but there is absolutely no follow-through. Too many times we encountered libraries and services that were terminated or overhauled because something was fundamentally broken. Worse, we pointed out big problems months or years in advance along with other customers and the community but saw no action. Google's dev team would continue to pretend nothing is wrong until either terminating or going back to the drawing board. I've never experienced a large company burying its head in the sand as much as Google. I love Google search, but I refuse to use any of their cloud products with the attitude that I've seen top to bottom, from sales to dev. Another very important point I think a lot of inexperience people neglect - AWS has great support when it comes to libraries and integrations. Pick x language and generally you can find at least a working version of a library for whatever service you are using, including new features. Google's cloud services in my experience are filled with broken, slow, horrible libraries, including the official ones. As an example, there was a really bad (probably still open) form encoding bug in App Engine with multi-part forms that's been broken since almost the start of App Engine (basically, anything non-Ascii got corrupted). It's never really been fixed despite multiple people giving Google tons of data, patches, and workaround. We even got on the phone with them about it several times. GCE has honestly not been as bad as App Engine in terms of fixing things, but it also lacks features and library integrations. As an example of a more specific GCE problem, anything that has issues with multi-cast had to have tons of patches. There was a special adapter for ElasticSearch when we deployed it on GCE that constantly had to be updated, and if you read about it, you'll see it's mainly a GCE thing. Pretty much every service, tech, or library we used that was more serious had similar issues - there was always a workaround or feature you had to manually implement that you didn't realize you took for granted on Amazon. The deployment story just given the tools was always far better on Amazon for example, but that may have changed. Then there's installing and developing against GCE. Most of GCE for the past few years was command line only. That's fine if your command line is well written and well-documented, but GCE is most certainly not. The command line didn't even really work on Windows and not even really with something like cygwin. You can laugh, but at my other company we did a lot of DirectX and Xbox development, and developing on other platforms didn't make that much sense. Unfortunately some people in our company decided not using AWS would be cool. Developing against GCE once you got things working was no treat and we felt we often had to write tons of new libraries to do basic things that existed somewhere in the Amazon stack. As far as the documentation, Google's services are usually out-of-date and full of mistakes. You could argue the docs are better than what Amazon has, however Amazon has the benefit of the community at this point that generally can answer your questions quickly. Moreover, Google in its own documentation often brags how good their docs are, while simple things like broken links or deprecated features are usually all over the place. How hard is it to run a broken link checker at least? The community is a huge topic, but I'll add that support was so bad at some points that the official line was to ask on StackOverflow instead (fine, but you're a huge company with a tiny install base at the time, wtf). GCE did (does) have an admin console in addition to the command line, but the early versions were very limited. The last GCE console I worked with was in-step with most Google admin consoles looks like an ASP 2.0 app. Most things in the admin console are far inferior to the command line and full of bugs. Even finding the right settings in the admin console are a complete nightmare and sometimes require you to open other Google Services that you would think have no impact on GCE, App Engine, or anything else, and yet do. They often re-arrange how all of this works, but then leave parts of the old sites still running, so you end up with crazy nesting, conflicting options and navigation, and randomness. Mostly you feel like some dev somewhere kept saying, "I don't feel like doing this, so I'll put this all here because I can." It all looks like a bad assignment done last minute in a computer lab for a comp-sci class. I know I seem a bit harsh, but I really wanted to try something new besides AWS the last few years. I joined 2 companies that did exactly that (independent of me), and that ended up terrible for both. There really was not much I couldn't do on AWS that GCE could do, while AWS could do plenty of things that GCE could not do at the time. AWS was far more reliable, stable, and well-supported for us as well, along with my own startup, and my past companies. Given I was a customer of Google's for a long, long time along with Amazon's and little changed with Google, I doubt it is much different now. Maybe someone can correct me, but usually when we get into these kinds of debates, the person with high opinions about GCE and the Google Cloud in general has not been on it long and certainly has not hosted a serious environment on it. I find Amazon as a company somewhat repulsive like Google in various ways, but AWS for all its faults is definitely more popular for a reason still. I hope Google can push Amazon to make their platform better, but from what I have seen the last few years, GCE is half-baked and only suitable if you're throwing a few small or personal servers in the cloud without significant interactions between them.