6 ms·

I think some people are missing the point when comparing this to a traditional VM setup. Yes it is way more expensive, but it lets you deploy something that wor

I think some people are missing the point when comparing this to a traditional VM setup. Yes it is way more expensive, but it lets you deploy something that works in 10 minutes vs messing with VMs and auto-scaling groups and all that jazz. If you are a GCP or AWS or bare metal expert that can set this thing up in their sleep, that's great but the majority of people can really benefit from a PaaS like GCR. Because Cloud Run uses vanilla Docker containers, once you have validated the idea you can move to GKE or VMs or a server under your desk or whatever. And if it never takes off, that's fine too because you didn't spend a ton of time investing in making it work. Ahmet if you are reading this (hi) it would be REALLY cool to see something like using GKE for the base load and dynamically bursting to GCR to fill in the gaps. Not sure if this possible with GCLB today, but would be super cool. (Disclaimer: I used to work on this team at Google.)

rad_gruchalski 6y ago
> And if it never takes off, that's fine too because you didn't spend a ton of time investing in making it work. But if it “takes off” while you are caught with your pants down and you have no clue, you are stuffed with a friggin $60k bill and potentially have to remortgage your house.
- minimaxir 6y ago
  That's why businesses use expected cost to make business decisions. The odds of it taking off are very, very low. And in the rare case it does, the infra is relatively portable (Docker container) and can be moved to a more-suitable VMs in less than the full month.
  - ALittleLight 6y ago
    But if it doesn't really take off - why do you need it? The main benefit of easy scaling strikes me as the scaling, but if you don't want to scale too much for cost reasons...
  - bushbaba 6y ago
    In that case why not use digital ocean or similar cheap VM offering. Cheaper, scales in near term. And provides a path forward to a more enterprise stack if necessary. I think people underestimate the serving capabilities of a few VMs coupled with caching/cdn.
  - jillesvangurp 6y ago
    Exactly, you can repurpose much of your build pipeline and simply boot the same docker image using a vm or scaling group of vms with a single command. The cost of switching to something else if you actually need to is minimal. I improvised it a few weeks ago when I realized that doing background jobs wasn't something I should be doing on cloud run (it gets throttled). I added an endpoint that processed a data import in the background and that just wouldn't work in cloudrun. So, I wrote a script that runs the same container on a vm and then shuts it down. Took me about 10 minutes to write and it zipped through the import in a few minutes. For a proper setup, you'd want to use terraform or similar to provision the vms but that's not particularly challenging. Basically you point your provisioned infrastructure at your docker container and it will run it. Very few businesses will ever see a quarter million concurrent users doing anything on their services. If you have that challenge, you can afford a few full time devops people to get you whatever infrastructure you need to handle this. We've been running on cloud run since August. Standout features for me: - it created a working CI/CD pipeline for me from my github repository with minimal effort and sane defaults. I got the service up and running within 20 minutes of me deciding to give it a try. I was so impressed with this that I decided on the spot to continue using it. That 20 minutes of devops time is technically the largest expense we've had so far on this setup as we mostly stay below the freemium threshold and it's otherwise a zero maintenance thing for us. Merge to master ... code deploys & runs. We've done this hundreds of times in the last months. - comes with proper logging, monitoring, etc. tooling with absolutely no additional effort. I don't consider running blind an option so this stuff is usually not optional for me. - we have no cloud run specifics in our github repository beyond the cloud build yml file. There is no vendor lock in. If you need a cheap way to run your docker container; this is it. Infrastructure is a blackbox that you get as a service. That's how infrastructure should be these days. - once we got in to the test program; web sockets have been great as well. We just launched that feature a few days ago. - low cost, low hassle, yet ticks all the boxes on the operational front. This is important to me as we don't have 24x7 people on staff and I hate having to deal with outages on a weekend or at night (as the CTO, I'm basically the person that gets to deal with this). - I've been involved with devops on other projects. It can be a serious time sink. It certainly has sucked up months of my time. Many projects end up having several full time people dealing with that at typically premium consulting rates. Days of tinkering with terraform, chasing stackoverflow posts, reading piles and piles of documentation, etc. It just never ends. That stuff costs magnitudes more than you are likely to spend on hosting in your first year. Even the most expensive fancy AWS setup is a rounding error compared to that. Cloud run on the other hand is dead easy to setup and dirt cheap for small setups. It's great way to defer devops cost; potentially indefinitely.
- asdfsfkwqe 6y ago
  If you can constantly have 250k concurrent users. I don't think money would be an issue at that time.
- deleted 6y ago
  [deleted]
- thesandlord 6y ago
  1) you can cap the max instances in GCR. You can put a limit of like 2 instances and ramp it up gradually. 2) it's 60k for a full month running at 100% capacity. Chances are you will notice this. This blog post is showing the upper limits of GCR, not the typical use case.
- 0xy 6y ago
  If it takes off and you're supporting millions of customers, a $60k infra bill is an amazing problem to have. "Oh no, we're too popular!". Who says this?
- etxm 6y ago
  We had a logging service that cost us 30k / mo. $60/k for your breadwinner seems like a deal.
  - layoric 6y ago
    I personally see the flip side, the original logging service at 30k/mo is totally wild. How much data was being logged/searched if you don't mind me asking?
    - etxm 6y ago
      About 300-600GB / hr. Data retention was based on a few different rules but could be stored for up to a month. 30k was ingress and ETL, that amount didn’t include storage. Not sure what storage costs were off-hand.
      - layoric 6y ago
        Thanks for sharing, that's a lot of logs but another good example of how linear scaling costs hurts. A lot cheaper than standard AWS CloudWatch which reckons it would be $200k+ a month.. but though 600GB an hr is not an easy problem to solve but that is a hell of a premium on both.
dilyevsky 6y ago
At this price point hiring a dedicated dev seems like a no brainer. Also using GCR name for this is a bit weird when there’s already another GCP container product with the same exact name.
- thesandlord 6y ago
  Yeah but the price starts at $0 and scales linearly with traffic. > Also using GCR name for this is a bit weird when there’s already another GCP container product with the same exact name. Very true! Naming is hard
  - blandflakes 6y ago
    And Google seems especially bad at it.
    - dodobirdlord 6y ago
      The approach of branding things as Google Cloud XYZ makes for really homogeneous acronyms. It solves the problem that AWS has with terrible names (what the hell is a “Redshift”?) by giving everything a boring name, but in exchange you get GCS being the acronym for Google Cloud Storage, Google Cloud Spanner, Google Cloud Search, Google Cloud SQL...
      - arthurcolle 6y ago
        Clearly we should start using emoji triplets for service names... easy to read/remember, and easy to type out on modern systems
        deleted 6y ago
        [deleted]
      - boxysean 6y ago
        > The name means to shift away from Oracle, red being an allusion to Oracle, whose corporate color is red and is informally referred to as "Big Red. I learned this recently and thought I'd share! From https://en.m.wikipedia.org/wiki/Amazon_Redshift https://en.m.wikipedia.org/wiki/Amazon_Redshift
ehsankia 6y ago
In general I agree, but I think this is more an issue of the example, or rather the fact that there's a cap of 250 connections per Cloud Run instance. For something as barebone as chat clients, that really seems to be under utilizing even the single vCPU on the smallest instance.
ec109685 6y ago
Clearly the right answer is to let customers go beyond 250 concurrent (maybe scale based on size of function). Get CloudRun handling the C10k problem and you’ll really have something.
- steren 6y ago
  Cloud Run PM here. WebSockets are in Preview. We've been working on increasing concurrency for GA.

rad_gruchalski 6y ago

> And if it never takes off, that's fine too because you didn't spend a ton of time investing in making it work. But if it “takes off” while you are caught with your pants down and you have no clue, you are stuffed with a friggin $60k bill and potentially have to remortgage your house.

minimaxir 6y ago
That's why businesses use expected cost to make business decisions. The odds of it taking off are very, very low. And in the rare case it does, the infra is relatively portable (Docker container) and can be moved to a more-suitable VMs in less than the full month.
- ALittleLight 6y ago
  But if it doesn't really take off - why do you need it? The main benefit of easy scaling strikes me as the scaling, but if you don't want to scale too much for cost reasons...
- bushbaba 6y ago
  In that case why not use digital ocean or similar cheap VM offering. Cheaper, scales in near term. And provides a path forward to a more enterprise stack if necessary. I think people underestimate the serving capabilities of a few VMs coupled with caching/cdn.
- jillesvangurp 6y ago
  Exactly, you can repurpose much of your build pipeline and simply boot the same docker image using a vm or scaling group of vms with a single command. The cost of switching to something else if you actually need to is minimal. I improvised it a few weeks ago when I realized that doing background jobs wasn't something I should be doing on cloud run (it gets throttled). I added an endpoint that processed a data import in the background and that just wouldn't work in cloudrun. So, I wrote a script that runs the same container on a vm and then shuts it down. Took me about 10 minutes to write and it zipped through the import in a few minutes. For a proper setup, you'd want to use terraform or similar to provision the vms but that's not particularly challenging. Basically you point your provisioned infrastructure at your docker container and it will run it. Very few businesses will ever see a quarter million concurrent users doing anything on their services. If you have that challenge, you can afford a few full time devops people to get you whatever infrastructure you need to handle this. We've been running on cloud run since August. Standout features for me: - it created a working CI/CD pipeline for me from my github repository with minimal effort and sane defaults. I got the service up and running within 20 minutes of me deciding to give it a try. I was so impressed with this that I decided on the spot to continue using it. That 20 minutes of devops time is technically the largest expense we've had so far on this setup as we mostly stay below the freemium threshold and it's otherwise a zero maintenance thing for us. Merge to master ... code deploys & runs. We've done this hundreds of times in the last months. - comes with proper logging, monitoring, etc. tooling with absolutely no additional effort. I don't consider running blind an option so this stuff is usually not optional for me. - we have no cloud run specifics in our github repository beyond the cloud build yml file. There is no vendor lock in. If you need a cheap way to run your docker container; this is it. Infrastructure is a blackbox that you get as a service. That's how infrastructure should be these days. - once we got in to the test program; web sockets have been great as well. We just launched that feature a few days ago. - low cost, low hassle, yet ticks all the boxes on the operational front. This is important to me as we don't have 24x7 people on staff and I hate having to deal with outages on a weekend or at night (as the CTO, I'm basically the person that gets to deal with this). - I've been involved with devops on other projects. It can be a serious time sink. It certainly has sucked up months of my time. Many projects end up having several full time people dealing with that at typically premium consulting rates. Days of tinkering with terraform, chasing stackoverflow posts, reading piles and piles of documentation, etc. It just never ends. That stuff costs magnitudes more than you are likely to spend on hosting in your first year. Even the most expensive fancy AWS setup is a rounding error compared to that. Cloud run on the other hand is dead easy to setup and dirt cheap for small setups. It's great way to defer devops cost; potentially indefinitely.
asdfsfkwqe 6y ago
If you can constantly have 250k concurrent users. I don't think money would be an issue at that time.
deleted 6y ago
[deleted]
thesandlord 6y ago
1) you can cap the max instances in GCR. You can put a limit of like 2 instances and ramp it up gradually. 2) it's 60k for a full month running at 100% capacity. Chances are you will notice this. This blog post is showing the upper limits of GCR, not the typical use case.
0xy 6y ago
If it takes off and you're supporting millions of customers, a $60k infra bill is an amazing problem to have. "Oh no, we're too popular!". Who says this?
etxm 6y ago
We had a logging service that cost us 30k / mo. $60/k for your breadwinner seems like a deal.
- layoric 6y ago
  I personally see the flip side, the original logging service at 30k/mo is totally wild. How much data was being logged/searched if you don't mind me asking?
  - etxm 6y ago
    About 300-600GB / hr. Data retention was based on a few different rules but could be stored for up to a month. 30k was ingress and ETL, that amount didn’t include storage. Not sure what storage costs were off-hand.
    - layoric 6y ago
      Thanks for sharing, that's a lot of logs but another good example of how linear scaling costs hurts. A lot cheaper than standard AWS CloudWatch which reckons it would be $200k+ a month.. but though 600GB an hr is not an easy problem to solve but that is a hell of a premium on both.

dilyevsky 6y ago

At this price point hiring a dedicated dev seems like a no brainer. Also using GCR name for this is a bit weird when there’s already another GCP container product with the same exact name.

thesandlord 6y ago
Yeah but the price starts at $0 and scales linearly with traffic. > Also using GCR name for this is a bit weird when there’s already another GCP container product with the same exact name. Very true! Naming is hard
- blandflakes 6y ago
  And Google seems especially bad at it.
  - dodobirdlord 6y ago
    The approach of branding things as Google Cloud XYZ makes for really homogeneous acronyms. It solves the problem that AWS has with terrible names (what the hell is a “Redshift”?) by giving everything a boring name, but in exchange you get GCS being the acronym for Google Cloud Storage, Google Cloud Spanner, Google Cloud Search, Google Cloud SQL...
    - arthurcolle 6y ago
      Clearly we should start using emoji triplets for service names... easy to read/remember, and easy to type out on modern systems
      - deleted 6y ago
        [deleted]
    - boxysean 6y ago
      > The name means to shift away from Oracle, red being an allusion to Oracle, whose corporate color is red and is informally referred to as "Big Red. I learned this recently and thought I'd share! From https://en.m.wikipedia.org/wiki/Amazon_Redshift https://en.m.wikipedia.org/wiki/Amazon_Redshift

ehsankia 6y ago

In general I agree, but I think this is more an issue of the example, or rather the fact that there's a cap of 250 connections per Cloud Run instance. For something as barebone as chat clients, that really seems to be under utilizing even the single vCPU on the smallest instance.

ec109685 6y ago

Clearly the right answer is to let customers go beyond 250 concurrent (maybe scale based on size of function). Get CloudRun handling the C10k problem and you’ll really have something.

steren 6y ago
Cloud Run PM here. WebSockets are in Preview. We've been working on increasing concurrency for GA.