4 ms·

we are struggling to maintain price parity on Google Cloud versus both Azure and AWS. AWS now has the new arm machines in production which are cheaper. AWS als

we are struggling to maintain price parity on Google Cloud versus both Azure and AWS. AWS now has the new arm machines in production which are cheaper. AWS also allows yearly prepaid managed databases - while Google still charges per second billing (with some monthly discount). My AWS TCO comes out to be much, much lower (almost 30%) than GCP if i take into account committed use/prepayment discounts.

dijit 8y ago
Interesting; maybe it's not solving the same use-cases for you then :) For us: on AWS/Azure we had to benchmark each instance when it came up and if it performed poorly it had to be reaped and redeployed constantly. The increased overhead in dealing with things "the AWS way" was enough by itself to offset the pricing difference with the steep AWS discount we were getting. Understanding administrative overhead is complicated but I'm sure you are taking into account the cost of humans. (or, you've already absorbed the cost of automating it?) :) As with all things; use what works for you. I'm just very happy with GCP over the others coming from bare metal.
- sandGorgon 8y ago
  it depends on usecases - i run a data heavy usecase. We deploy using docker swarm, so our redeployment is fairly well taken care of. in terms of benchmarking - this is not something we care about (since we dont have so much CPU utilization), so probably its easier for me. For my usecase, AWS has better administrative tools than google. I use Route 53, SES, S3 - in all those three, no other products come close (transfer acceleration...im looking at you). The one place that I agree with you is Dataproc. That's far superior to EMR in terms of spin-up/down.
Ironlink 8y ago
I dislike the concept of committing to use. It creates a disincentive to optimize jobs, because "we've already paid for three years of this".
- pantulis 8y ago
  It's up to you to see it the other way around: if you optimize jobs you can fit future workloads in the infrastructure you've already paid for. I prefer to think of reserved instances as a purely financial trick.
  - Ironlink 8y ago
    Right, but that requires your new workloads to fit well with the resources you have committed to. If you've committed to many small machines, they may not be well suited to an especially heavy workload. If you've skewed your commitment towards a large amount of memory per compute (or vice versa), you can find yourself with lots of RAM (or compute) and no natural use-case. At the bottom line, commitment impedes change.
    - pantulis 8y ago
      Your point is valid, thanks for the answer.
  - room271 8y ago
    The pay-as-you-go reductions give you more flexibility about when you make optimisations to your code though and help you handle uncertainty around this. For example, if I have a new workload that won't fit on existing hardware with AWS, I can either: a) reserve the new instances, or b) not reserve on the assumption I will be able to optimise in the 'near' future. In practice this is hard to know but AWS forces you to come to a correct decision up front, whereas Google Cloud allows you to not have to answer this up front without being punished later for making the 'wrong' choice.
- sandGorgon 8y ago
  From a startup POV, I'll give you the other perspective. I now have a significantly reduced opex that saves me a lot of money. If I grow very fast (and outgrow it)... I really dont care, because I will most likely have a financing event. If I dont grow fast enough to justify the spend, I have bigger problems. In addition, I have to commend Google and Azure here - the way they do committed use is very flexible. They price it on number of units (cores, RAM, whatever) - so if you outgrow it, you still get the discount + full cost of additional units. On AWS, if you outgrow, you have to frikking sell off your machines on their auctions and buy new ones. Only problem is that Google doesnt do this for databases (which are very expensive)

dijit 8y ago

Interesting; maybe it's not solving the same use-cases for you then :) For us: on AWS/Azure we had to benchmark each instance when it came up and if it performed poorly it had to be reaped and redeployed constantly. The increased overhead in dealing with things "the AWS way" was enough by itself to offset the pricing difference with the steep AWS discount we were getting. Understanding administrative overhead is complicated but I'm sure you are taking into account the cost of humans. (or, you've already absorbed the cost of automating it?) :) As with all things; use what works for you. I'm just very happy with GCP over the others coming from bare metal.

sandGorgon 8y ago
it depends on usecases - i run a data heavy usecase. We deploy using docker swarm, so our redeployment is fairly well taken care of. in terms of benchmarking - this is not something we care about (since we dont have so much CPU utilization), so probably its easier for me. For my usecase, AWS has better administrative tools than google. I use Route 53, SES, S3 - in all those three, no other products come close (transfer acceleration...im looking at you). The one place that I agree with you is Dataproc. That's far superior to EMR in terms of spin-up/down.

Ironlink 8y ago

I dislike the concept of committing to use. It creates a disincentive to optimize jobs, because "we've already paid for three years of this".

pantulis 8y ago
It's up to you to see it the other way around: if you optimize jobs you can fit future workloads in the infrastructure you've already paid for. I prefer to think of reserved instances as a purely financial trick.
- Ironlink 8y ago
  Right, but that requires your new workloads to fit well with the resources you have committed to. If you've committed to many small machines, they may not be well suited to an especially heavy workload. If you've skewed your commitment towards a large amount of memory per compute (or vice versa), you can find yourself with lots of RAM (or compute) and no natural use-case. At the bottom line, commitment impedes change.
  - pantulis 8y ago
    Your point is valid, thanks for the answer.
- room271 8y ago
  The pay-as-you-go reductions give you more flexibility about when you make optimisations to your code though and help you handle uncertainty around this. For example, if I have a new workload that won't fit on existing hardware with AWS, I can either: a) reserve the new instances, or b) not reserve on the assumption I will be able to optimise in the 'near' future. In practice this is hard to know but AWS forces you to come to a correct decision up front, whereas Google Cloud allows you to not have to answer this up front without being punished later for making the 'wrong' choice.
sandGorgon 8y ago
From a startup POV, I'll give you the other perspective. I now have a significantly reduced opex that saves me a lot of money. If I grow very fast (and outgrow it)... I really dont care, because I will most likely have a financing event. If I dont grow fast enough to justify the spend, I have bigger problems. In addition, I have to commend Google and Azure here - the way they do committed use is very flexible. They price it on number of units (cores, RAM, whatever) - so if you outgrow it, you still get the discount + full cost of additional units. On AWS, if you outgrow, you have to frikking sell off your machines on their auctions and buy new ones. Only problem is that Google doesnt do this for databases (which are very expensive)