5 ms·

We did a performance analysis of Google Cloud vs AWS. The results are in line with what is published in the post. The biggest thing that we can not quantify is

We did a performance analysis of Google Cloud vs AWS. The results are in line with what is published in the post. The biggest thing that we can not quantify is "ease of use". Google Cloud is a pleasure to work with. AWS feel so clunky compared to Google Cloud. Don't take my word for it. Create a VM, login into it on AWS and Google Cloud, you will change your opinion about what a good cloud is.

autotune 11y ago
If you're using the GUI to manage your resources rather than going the Infrastructure As Code route, you're probably doing it wrong. You should be using a tool like Terraform, which lets you use multiple cloud providers (https://www.terraform.io/docs/providers/ https://www.terraform.io/docs/providers/), and can actually tell you if there are any immediate errors before attempting to launch a resource, so is friendly with Jenkins or any other CI tool you prefer to use as a result as well.
- obulpathi 11y ago
  We don't use GUI to manage our resources. We use CloudFormation for AWS and Deployment Manager for Google. Let me tell you a couple of things about those services. In AWS some resources are zonal, some regional and some are global. It's a mess to work with. For example, same AMI image has different ids in different regions. You need to create maps and stuff to make your code work across regions. Come to Google Cloud, no more zonal/regional/global fuss. An image is a global resource. It's available by the same id in all regions. Your infrastructure template looks much cleaner. Combine the power of Jinja, you can create far powerful templates and evaluate them on the fly. AWS has "three" queuing systems, "two" storage solutions with different API's and different quirks. Google just has one and its nails the use cases for queuing and storage. AWS micro-instance go poof, without any notice. Their NATS are known for being unreliable. Load balancers can't scale. Every service that I looked into, Google is way better than AWS.
  - matwood 11y ago
    AWS definitely feels like a product that has grown organically and needs some house cleaning. GC was able to look at AWS, take those lessons, and improve from the start.
    - StreamBright 11y ago
      Being late for the party has its perks. The also need more work on convincing people moving over and they do a good job with Spotify and other companies who talk openly about moving to GCP.
  - defen 11y ago
    For me, GCP comes with unquantifiable existence risk. As in, how do I know that it won't get shut down in 5 years when some VP sees that it's not bringing in as much money as it should? I trust Amazon more in this regard, and their offering is not "so bad" that I feel a need to switch.
    - AdamN 11y ago
      Existence risk here is HUGE. If GCP doesn't move the needle, Google will shut it down. AWS is a much more living organism and I can't see Amazon shutting it down before their drones take over ...
      - mikecb 11y ago
        To shut down GCP, they would be shutting down the same services and infrastructure that power their own services. The dogfooding memo from years back is being taken to heart, and you're seeing more and more exposure of internal services and infrastructure. The scary thing would be if it ends up reducing the rate of innovation because they worry about changing APIs or services too much; obsolete accumulates quickly when you're serving large numbers of people because most business want to write once run till it's dead. But this is true of any service that exposes anything but an extreme abstraction.
- dcgoss 11y ago
  Terraform has worked incredibly well for us so far. Definitely deserves a look by anyone.
StreamBright 11y ago
I have created more than a single VM on AWS, if I add together all of the companies that I used to work for it is close to 8000 instances (5000+3000). I am not sure what I am doing wrong not running into clunky stuff but I guess it is automation that makes the difference. With projects like Ansible, Terraform or even aws cli creating and managing these large clusters is a breeze. I understand that you are using the UI and having trouble with UX but it does not mean that every user experiences that or they have the same sentiments or conclusions.

autotune 11y ago

If you're using the GUI to manage your resources rather than going the Infrastructure As Code route, you're probably doing it wrong. You should be using a tool like Terraform, which lets you use multiple cloud providers (https://www.terraform.io/docs/providers/ https://www.terraform.io/docs/providers/), and can actually tell you if there are any immediate errors before attempting to launch a resource, so is friendly with Jenkins or any other CI tool you prefer to use as a result as well.

obulpathi 11y ago
We don't use GUI to manage our resources. We use CloudFormation for AWS and Deployment Manager for Google. Let me tell you a couple of things about those services. In AWS some resources are zonal, some regional and some are global. It's a mess to work with. For example, same AMI image has different ids in different regions. You need to create maps and stuff to make your code work across regions. Come to Google Cloud, no more zonal/regional/global fuss. An image is a global resource. It's available by the same id in all regions. Your infrastructure template looks much cleaner. Combine the power of Jinja, you can create far powerful templates and evaluate them on the fly. AWS has "three" queuing systems, "two" storage solutions with different API's and different quirks. Google just has one and its nails the use cases for queuing and storage. AWS micro-instance go poof, without any notice. Their NATS are known for being unreliable. Load balancers can't scale. Every service that I looked into, Google is way better than AWS.
- matwood 11y ago
  AWS definitely feels like a product that has grown organically and needs some house cleaning. GC was able to look at AWS, take those lessons, and improve from the start.
  - StreamBright 11y ago
    Being late for the party has its perks. The also need more work on convincing people moving over and they do a good job with Spotify and other companies who talk openly about moving to GCP.
- defen 11y ago
  For me, GCP comes with unquantifiable existence risk. As in, how do I know that it won't get shut down in 5 years when some VP sees that it's not bringing in as much money as it should? I trust Amazon more in this regard, and their offering is not "so bad" that I feel a need to switch.
  - AdamN 11y ago
    Existence risk here is HUGE. If GCP doesn't move the needle, Google will shut it down. AWS is a much more living organism and I can't see Amazon shutting it down before their drones take over ...
    - mikecb 11y ago
      To shut down GCP, they would be shutting down the same services and infrastructure that power their own services. The dogfooding memo from years back is being taken to heart, and you're seeing more and more exposure of internal services and infrastructure. The scary thing would be if it ends up reducing the rate of innovation because they worry about changing APIs or services too much; obsolete accumulates quickly when you're serving large numbers of people because most business want to write once run till it's dead. But this is true of any service that exposes anything but an extreme abstraction.
dcgoss 11y ago
Terraform has worked incredibly well for us so far. Definitely deserves a look by anyone.

StreamBright 11y ago

I have created more than a single VM on AWS, if I add together all of the companies that I used to work for it is close to 8000 instances (5000+3000). I am not sure what I am doing wrong not running into clunky stuff but I guess it is automation that makes the difference. With projects like Ansible, Terraform or even aws cli creating and managing these large clusters is a breeze. I understand that you are using the UI and having trouble with UX but it does not mean that every user experiences that or they have the same sentiments or conclusions.