10 ms·

My two cents, GCP has a few excellent gems which are better than pretty much any competing cloud offering: - Cloud Run. Best way to deploy containers hands do

by Ameo 3y ago

My two cents, GCP has a few excellent gems which are better than pretty much any competing cloud offering: - Cloud Run. Best way to deploy containers hands down. All of the benefits of a serverless/containerized workload with all the ease of a traditional VPS deployment. Extremely cheap (pay $0 for side projects with little traffic). - BigQuery. Very easy to use with immense power without having to deal with the details yourself. Billing can be either extremely cheap or rather expensive depending on what you're doing, though. - GCS Archive Storage. 1/3 the cost of glacier for storage ($0.0012/GB/Month lol), but more for retrieval. Has none of the annoyances of Glacier (you can download your files instantly, upload using normal APIs). Perfect for extremely cheap backups. - Cloud Spanner. I've not had a reason to use this yet myself, but there really aren't any comparable offerings that I know of.

JSavageOne 3y ago
Yes Google Cloud Run is my go-to for all my side projects, and AWS doesn't have anything equivalent. Never saw any reason to use AWS for that reason as Google has everything else I'd need. And if I just want a cheap VPS, would prefer to use something cheaper like Linode or Digital Ocean.
- siquick 3y ago
  In my experience of using both, AWS AppRunner is as good as Cloud Run except you can’t scale AppRunner down to 0 instances so it has an ongoing cost.
  - pid-1 3y ago
    It basically doesn't have the main thing that makes Cloud Run so valuable. Speaking more generally, it seems AWS is allergic to creating products that scale to zero nowadays.
    - slrainka 3y ago
      App Runner is an abstraction on top of FarGate designed to compete with Cloud Run, which is why it doesn’t scale down to zero. I too haven’t found anything that beats the simplicity of a GCP deployment sigh..
      - badrequest 3y ago
        If it doesn't scale down to zero, then it doesn't compete with Cloud Run.
        fomine3 3y ago
        It depends on use case. Some corps don't care about down to zero.
        aenis 3y ago
        In fact, I was waiting for years for them to add a min instances option. But otherwise, agree, been running large and small production workloads since it launched and its been great.
    - ramraj07 3y ago
      Scaling down to zero appeals to amateur side project folks - no enterprise customer probably cares about that marginal expense here..
      - starfallg 3y ago
        It really depends on which workloads. We have teams working only on FinOps to optimize our architecture to take advantage of various cloud pricing models. Enterprise spend on cloud is a massive topic right now and definitely in the spotlight. A consensus is developing that the current implementation of public cloud promotes lock-in and overall much more expensive at scale. Cloud is complex and engineers are expensive. Instead of throwing CPU cycles and disk at the problem (which is cheap compared to engineer time), we are nickel-and-dimeing everything, and changing our architectures to hack the cloud pricing models. It's pretty silly.
      - pid-1 3y ago
        According to my anedoctal experience, that's grossly wrong across many industries.
    - leptons 3y ago
      I've paid $0.00 for my many AWS Lambda functions, and will always pay $0 so long as I keep it under 1 million executions per month (and AWS keeps this free tier going). I also use SimpleDB, SES, and other services that also cost $0.00/mo. The only thing I pay for is S3, which totals about $0.30 per month, for a few gigs of data. And I'm very happy with AWS, It's been costing me less than $6 per year to build out and run a complex web app, albeit with no users. But still, AWS absolutely does scale down to zero very nicely.
      - pid-1 3y ago
        Sure. Just note all products you mentioned are rather old. When AWS announces anything serverless nowadays, things do not scale to zero.
- Beijinger 3y ago
  Is google so cheap? I am a small fish in the big sea but I use this for my personal projects: https://www.nearlyfreespeech.net/ https://www.nearlyfreespeech.net/
  - neurostimulant 3y ago
    GCP and AWS are cheap for small and low traffics applications. But once your usage passes a certain point, you'll quickly find out they're more expensive than other vendors. The problem is, once you reached that point, you're probably already locked yourself in by using their specific offerings not found anywhere else. Limiting yourself to plain vps/containers/k8s might help preventing lock in.
    - steveBK123 3y ago
      And yet many large enterprises with existing data centers have made forays into cloud only to discover how stunningly expensive it is once the free credits run out.
      - dartos 3y ago
        It’s a classic walled garden strategy
    - throwaway2990 3y ago
      If you limit yourself you will end up paying a ton.
  - dewey 3y ago
    As always it depends what you need. If you think you might need a database that's not MySQL and maybe a bucket to host your images and static assets then nearlyfreespeech is already not a good match any more if you prefer to have everything in one place. For small projects or Wordpress installations you can of course find a lot of very cheap or even free options as it's such a commodity by now.
latchkey 3y ago
Cloud Functions, Cloud Tasks and Cloud SQL Postgres are fantastic too. Very low cost that scales with you and essentially zero lockin.
- r3trohack3r 3y ago
  Has Cloud Functions solved their logging issues yet? Last I checked, the lifetime of the function was bound to the lifetime of the request. So you have to fully flush your logs to their log ingress service before you respond to a request, otherwise GCP will suspend the function and eat your logs. Originally, this resulted in me having - to my surprise - very few logs coming from my functions. Once I discovered what was going on, it resulted in me having to increase the latency of responding to the request while I waited for logging to flush to GCP's log ingress service.
  - latchkey 3y ago
    I built a service with a few functions (golang based) that ran just fine for over a year with no log flushing issues. I did actually have an issue where it was logging two blank lines, which was annoying. It definitely wasn't coming from my code and it got fixed at one point, then reappeared later on. I gave up trying to resolve it. That said, their logging system is fantastic. I found it really easy to deal with.
  - inlined 3y ago
    Are you using a log service directly, or stdout? Stdout has no such issue. On Run (and therefore functions 2nd gen) you get a SIGINT before the container is shut down. Open Telemetry is pretty easy to configure to flush on SIGINT in the background.
    - heyoni 3y ago
      My guess would be that their app isn’t running with PID 1. This can happen when services are launched from an entrypoint script in docker without using exec. If the request is fulfilled and the system sends a sigint to the container, docker will relay that to whatever is running on pid 1. If that’s their app, it’ll flush logs and quit. If their app is using another pid, docker will kill the container by force.
deleted 3y ago
[deleted]
code_runner 3y ago
bigquery is a joy to use! I really don't hate the editor in the browser either.
gnarlouse 3y ago
Honestly Cloud Run is so well designed, it really puts AWS Lambda & Fargate to shame.
datadrivenangel 3y ago
BigQuery is very pleasant. It just works serverlessly. Apparently some of the key people behind BQ are now working on MotherDuck, which is a cloud data warehouse version of DuckDB.
- vgt 3y ago
  MotherDuck head of Produck and co-founder checking in. Happy to answer any questions :)
- ramraj07 3y ago
  I’ll have to try this just for the name!
derefr 3y ago
> GCS Archive Storage Have you considered Backblaze B2? (It has free egress!) I think GCS is pretty good as a coherent offering that includes the various storage tiers + auto-classing + lifecycle notifications to pub/sub to feed Cloud Dataflow, etc. But if you're storing data purely for retention or disaster recovery, you should consider a service architected as a backup provider that happens to present an object-store abstraction, rather than an object-storage provider that happens to support your backup software — often you'll find very different that the provider themselves have made very different CapEx trade-offs, resulting in very different pricing models, that can favor your use-case heavily. (I say this as someone who uses GCP for elastic load, but has non-IaaS bare-metal for base load; and where the DB instances living on that bare metal do their pgbackrest backups + WAL streaming against a B2 bucket.) But, of course, if your data-to-be-archived is originating in GCP, it may well cost you more to send it over an external provider like Backblaze, than it costs to just keep it in GCS. That is, as they say, "where they get ya."
- nh2 3y ago
  What is the current story regarding replication between B2 and GCS Archive Storage? B2 currently costs 6 $/TB/month, GCS Archive Storage costs 5x less at 1.2 $/TB/month. Do both of these guarantee that if a single data center location catches fire, your backups will not be lost?
  - derefr 3y ago
    > B2 currently costs 6 $/TB/month, GCS Archive Storage costs 5x less at 1.2 $/TB/month. Sure, but does the GCS "archive" storage-class really fit your needs? Anything less than GCS's "nearline" storage class, has fetch costs that swamp the storage costs themselves. If you're doing FinOps/SecOps (storing customer invoice PDFs for compliance, audit logs in case of a retroactively-discovered hack, etc) — where the likelihood of fetching any given piece of archival data approaches zero — the "archive" storage class makes a lot of sense. But if you're doing DevOps — e.g. storing infra backups intended to be used for PITR in case someone fat-fingers a SQL DELETE, or in case a bad upgrade corrupts a machine's state, or even just to serve as a read-replica bootstrap base-image (think e.g. pgbackrest) — then the "archive" storage class is ill-suited, because you actually are quite likely to read back the data. (And in fact, if you regularly test your backup restore process, you're essentially 100% likely to read back the data!) For this reason, I've personally never seen anyone use "coldline" or "archive" storage classes for DevOps infra backups. Instead, SREs seem to gravitate to the "nearline" storage class for this use-case. (There's also the fact that anything beyond "nearline" requires keeping the data around for quite a long time, paying for all that time the data sits around. The processes involved in DevOps infra backups often trigger periodic full backups, that then obviate the need for retaining previous full/incremental backups. Do you really need a 12-month-old DB backup, or do you only need the 1-month-old and 2-month-old ones?) And Backblaze B2 is cheaper than GCS "nearline" storage — without any of the minimum storage lifetime requirements of GCS's colder storage classes. (GCS Nearline vs Backblaze B2 is not as much of a slam-dunk as when comparing them to GCS Standard — $10/TB-mo vs $6/TB-mo; but if your base-load is outside of GCP, adding back in the GCS egress costs to the equation still makes it seem pretty obvious that GCS won't come out the winner on a TCO basis.) > Do both of these guarantee that if a single data center location catches fire, your backups will not be lost? Hard to say, actually! Let's look specifically at the case of a fire. GCP uses the IaaS-standard term "availability zones" to describe data centers in the same region that, along with other types of isolation, are physically-distant enough that they can't catch each-other on fire. From GCS docs: > Cloud Storage redundantly stores objects that are written to it in at least two different availability zones before considering the write to be successful. Backblaze, meanwhile, seems to use the term "vaults" here, and seem to use it to mean racks/rooms of backup storage that are seemingly independent from a power/cooling/data perspective. (And possibly with their own isolated little room that has its own fire suppression? They don't mention it, but that's how I'd picture it.) They say that there are multiple vaults "per data centre." But often an entire campus of physically-isolated buildings — what in IaaS terminology would be separate AZs — would be considered one "data centre" in traditional hosting terms, if it's all owned by one company and operated by one shared ops staff. Since Backblaze don't introduce anything quite like the AZ concept in their docs, it's unclear whether their data centres are able to guarantee data durability in the event of a fire that destroys a single "vault." What is clear, is that neither Google nor Backblaze considers this type of data durability to be the most important kind. Which makes sense: there are other types of disasters that can befall a data centre, or even an entire city, that will knock out (and potentially corrupt!) all AZs in that "region." I'd mention floods as the obvious thing to picture, but nobody builds a data centre on a floodplain. Instead, how about: climate change shifting the paths of tornadoes unpredictably; compression of a tectonic plate resulting in random areas of land (potentially inside a city) having the earth heaved and thrusted up by as much as meters; and key cities — and data-centers themselves as strategic targets, actually! — being bombed during a war. Designing your archival storage to be resilient to these problems, will of course also protect your data in the event of a smaller-scale disaster like a fire, meteorite impact, or some spiteful person ramming a truck into one of the DC's buildings. Therefore, Google and Backblaze have both designed in inter-regional replication for the purposes of "geographic data redundancy." GCS has "dual-region" and "multi-region" buckets; and Backblaze has "Cloud Replication" (https://www.backblaze.com/cloud-storage/features/replication https://www.backblaze.com/cloud-storage/features/replication) where you essentially make Bucket A in region A into a streaming read-replica of Bucket B in region B. In both of these cases, enabling the feature costs money. Both providers consider the use-case for this level of durability so rare that they don't make it a guaranteed default with attempted cross-customer subsidization; but instead just offer it to the few customers who think they really need it, or who are required by law or regulation to do it.
aravindajju 3y ago
Cloud Run is the only reason to use GCP for me. I haven't seen any product/service that simple to use. It even offers mapping domain names. All my projects run on Cloud Run.
jillesvangurp 3y ago
We used cloud run for a while and it's great. It does not allow for background threads though and that caused us to upgrade the setup eventually. Upgrading from cloud run to use proper vms was very easy because vms can be booted with a docker container as one of the arguments. It will just go off and run that with a default OS. Running docker containers in gcloud is super easy. And scaling that is easy too. Basically you define an instance template that defines vm details; including the docker container url. And then you update your instance group with that template and all the instances are replaced one by one. You use the instance group as a service for your load balancer and with the right health checks configured this basically gives you zero down time deployments, auto scaling, etc. If there's an issue starting the container, it just aborts the restart and continues running the old containers. The closest thing in AWS would be ECS but it's a lot more hassle to setup. One great feature in gcloud is "copy this screen/dialog/whatever as a gcloud command". That made scripting the above super easy. We use github actions for all this. For each service, we use 1 command to update the template and 1 command to deploy it.
- QasimK 3y ago
  I’ve used Cloud Run and it does allow for background threads.
  - anisov 3y ago
    I think they introduced this feature lately: https://cloud.google.com/run/docs/configuring/cpu-allocation https://cloud.google.com/run/docs/configuring/cpu-allocation you can set --no-cpu-throttling which keeps the cpu allocated even if the request lifetime is over. Used it for Background tasks
    - jillesvangurp 3y ago
      Right; that is indeed new. We might give this another try.
Beijinger 3y ago
$0.0012/GB/Month That is interesting. How to you access this API? Can you do SFTP? This has about the same pricing: https://www.opendrive.com/pricing https://www.opendrive.com/pricing (Yes, it says unlimited, but they told me, they significantly slow it down after 10 TB)
ramoz 3y ago
Asset Inventory is slept on.
gigatexal 3y ago
As a consultant (side gig) I have to use both based on what the company that I’m assigned to is using. AWS S3 and GCP GCS are basically the same in my head. Where things fall apart are actually the cost estimator. GCP’s is far simpler. AWS’s makes me wish I had Corey Quinn on speed dial. Redshift is far too complicated and has too many knobs. Give me BigQuery all day long even with its quirks.
steren 3y ago
Cloud Run product lead here. Your comment and its replies warm my heart. On behalf of the whole Cloud Run team: Thank you!

by Ameo 3y ago

JSavageOne 3y ago

Yes Google Cloud Run is my go-to for all my side projects, and AWS doesn't have anything equivalent. Never saw any reason to use AWS for that reason as Google has everything else I'd need. And if I just want a cheap VPS, would prefer to use something cheaper like Linode or Digital Ocean.

siquick 3y ago
In my experience of using both, AWS AppRunner is as good as Cloud Run except you can’t scale AppRunner down to 0 instances so it has an ongoing cost.
- pid-1 3y ago
  It basically doesn't have the main thing that makes Cloud Run so valuable. Speaking more generally, it seems AWS is allergic to creating products that scale to zero nowadays.
  - slrainka 3y ago
    App Runner is an abstraction on top of FarGate designed to compete with Cloud Run, which is why it doesn’t scale down to zero. I too haven’t found anything that beats the simplicity of a GCP deployment sigh..
    - badrequest 3y ago
      If it doesn't scale down to zero, then it doesn't compete with Cloud Run.
      - fomine3 3y ago
        It depends on use case. Some corps don't care about down to zero.
        aenis 3y ago
        In fact, I was waiting for years for them to add a min instances option. But otherwise, agree, been running large and small production workloads since it launched and its been great.
  - ramraj07 3y ago
    Scaling down to zero appeals to amateur side project folks - no enterprise customer probably cares about that marginal expense here..
    - starfallg 3y ago
      It really depends on which workloads. We have teams working only on FinOps to optimize our architecture to take advantage of various cloud pricing models. Enterprise spend on cloud is a massive topic right now and definitely in the spotlight. A consensus is developing that the current implementation of public cloud promotes lock-in and overall much more expensive at scale. Cloud is complex and engineers are expensive. Instead of throwing CPU cycles and disk at the problem (which is cheap compared to engineer time), we are nickel-and-dimeing everything, and changing our architectures to hack the cloud pricing models. It's pretty silly.
    - pid-1 3y ago
      According to my anedoctal experience, that's grossly wrong across many industries.
  - leptons 3y ago
    I've paid $0.00 for my many AWS Lambda functions, and will always pay $0 so long as I keep it under 1 million executions per month (and AWS keeps this free tier going). I also use SimpleDB, SES, and other services that also cost $0.00/mo. The only thing I pay for is S3, which totals about $0.30 per month, for a few gigs of data. And I'm very happy with AWS, It's been costing me less than $6 per year to build out and run a complex web app, albeit with no users. But still, AWS absolutely does scale down to zero very nicely.
    - pid-1 3y ago
      Sure. Just note all products you mentioned are rather old. When AWS announces anything serverless nowadays, things do not scale to zero.
Beijinger 3y ago
Is google so cheap? I am a small fish in the big sea but I use this for my personal projects: https://www.nearlyfreespeech.net/ https://www.nearlyfreespeech.net/
- neurostimulant 3y ago
  GCP and AWS are cheap for small and low traffics applications. But once your usage passes a certain point, you'll quickly find out they're more expensive than other vendors. The problem is, once you reached that point, you're probably already locked yourself in by using their specific offerings not found anywhere else. Limiting yourself to plain vps/containers/k8s might help preventing lock in.
  - steveBK123 3y ago
    And yet many large enterprises with existing data centers have made forays into cloud only to discover how stunningly expensive it is once the free credits run out.
    - dartos 3y ago
      It’s a classic walled garden strategy
  - throwaway2990 3y ago
    If you limit yourself you will end up paying a ton.
- dewey 3y ago
  As always it depends what you need. If you think you might need a database that's not MySQL and maybe a bucket to host your images and static assets then nearlyfreespeech is already not a good match any more if you prefer to have everything in one place. For small projects or Wordpress installations you can of course find a lot of very cheap or even free options as it's such a commodity by now.

latchkey 3y ago

Cloud Functions, Cloud Tasks and Cloud SQL Postgres are fantastic too. Very low cost that scales with you and essentially zero lockin.

r3trohack3r 3y ago
Has Cloud Functions solved their logging issues yet? Last I checked, the lifetime of the function was bound to the lifetime of the request. So you have to fully flush your logs to their log ingress service before you respond to a request, otherwise GCP will suspend the function and eat your logs. Originally, this resulted in me having - to my surprise - very few logs coming from my functions. Once I discovered what was going on, it resulted in me having to increase the latency of responding to the request while I waited for logging to flush to GCP's log ingress service.
- latchkey 3y ago
  I built a service with a few functions (golang based) that ran just fine for over a year with no log flushing issues. I did actually have an issue where it was logging two blank lines, which was annoying. It definitely wasn't coming from my code and it got fixed at one point, then reappeared later on. I gave up trying to resolve it. That said, their logging system is fantastic. I found it really easy to deal with.
- inlined 3y ago
  Are you using a log service directly, or stdout? Stdout has no such issue. On Run (and therefore functions 2nd gen) you get a SIGINT before the container is shut down. Open Telemetry is pretty easy to configure to flush on SIGINT in the background.
  - heyoni 3y ago
    My guess would be that their app isn’t running with PID 1. This can happen when services are launched from an entrypoint script in docker without using exec. If the request is fulfilled and the system sends a sigint to the container, docker will relay that to whatever is running on pid 1. If that’s their app, it’ll flush logs and quit. If their app is using another pid, docker will kill the container by force.

deleted 3y ago

[deleted]

code_runner 3y ago

bigquery is a joy to use! I really don't hate the editor in the browser either.

gnarlouse 3y ago

Honestly Cloud Run is so well designed, it really puts AWS Lambda & Fargate to shame.

datadrivenangel 3y ago

BigQuery is very pleasant. It just works serverlessly. Apparently some of the key people behind BQ are now working on MotherDuck, which is a cloud data warehouse version of DuckDB.

vgt 3y ago
MotherDuck head of Produck and co-founder checking in. Happy to answer any questions :)
ramraj07 3y ago
I’ll have to try this just for the name!

derefr 3y ago

> GCS Archive Storage Have you considered Backblaze B2? (It has free egress!) I think GCS is pretty good as a coherent offering that includes the various storage tiers + auto-classing + lifecycle notifications to pub/sub to feed Cloud Dataflow, etc. But if you're storing data purely for retention or disaster recovery, you should consider a service architected as a backup provider that happens to present an object-store abstraction, rather than an object-storage provider that happens to support your backup software — often you'll find very different that the provider themselves have made very different CapEx trade-offs, resulting in very different pricing models, that can favor your use-case heavily. (I say this as someone who uses GCP for elastic load, but has non-IaaS bare-metal for base load; and where the DB instances living on that bare metal do their pgbackrest backups + WAL streaming against a B2 bucket.) But, of course, if your data-to-be-archived is originating in GCP, it may well cost you more to send it over an external provider like Backblaze, than it costs to just keep it in GCS. That is, as they say, "where they get ya."

nh2 3y ago
What is the current story regarding replication between B2 and GCS Archive Storage? B2 currently costs 6 $/TB/month, GCS Archive Storage costs 5x less at 1.2 $/TB/month. Do both of these guarantee that if a single data center location catches fire, your backups will not be lost?
- derefr 3y ago
  > B2 currently costs 6 $/TB/month, GCS Archive Storage costs 5x less at 1.2 $/TB/month. Sure, but does the GCS "archive" storage-class really fit your needs? Anything less than GCS's "nearline" storage class, has fetch costs that swamp the storage costs themselves. If you're doing FinOps/SecOps (storing customer invoice PDFs for compliance, audit logs in case of a retroactively-discovered hack, etc) — where the likelihood of fetching any given piece of archival data approaches zero — the "archive" storage class makes a lot of sense. But if you're doing DevOps — e.g. storing infra backups intended to be used for PITR in case someone fat-fingers a SQL DELETE, or in case a bad upgrade corrupts a machine's state, or even just to serve as a read-replica bootstrap base-image (think e.g. pgbackrest) — then the "archive" storage class is ill-suited, because you actually are quite likely to read back the data. (And in fact, if you regularly test your backup restore process, you're essentially 100% likely to read back the data!) For this reason, I've personally never seen anyone use "coldline" or "archive" storage classes for DevOps infra backups. Instead, SREs seem to gravitate to the "nearline" storage class for this use-case. (There's also the fact that anything beyond "nearline" requires keeping the data around for quite a long time, paying for all that time the data sits around. The processes involved in DevOps infra backups often trigger periodic full backups, that then obviate the need for retaining previous full/incremental backups. Do you really need a 12-month-old DB backup, or do you only need the 1-month-old and 2-month-old ones?) And Backblaze B2 is cheaper than GCS "nearline" storage — without any of the minimum storage lifetime requirements of GCS's colder storage classes. (GCS Nearline vs Backblaze B2 is not as much of a slam-dunk as when comparing them to GCS Standard — $10/TB-mo vs $6/TB-mo; but if your base-load is outside of GCP, adding back in the GCS egress costs to the equation still makes it seem pretty obvious that GCS won't come out the winner on a TCO basis.) > Do both of these guarantee that if a single data center location catches fire, your backups will not be lost? Hard to say, actually! Let's look specifically at the case of a fire. GCP uses the IaaS-standard term "availability zones" to describe data centers in the same region that, along with other types of isolation, are physically-distant enough that they can't catch each-other on fire. From GCS docs: > Cloud Storage redundantly stores objects that are written to it in at least two different availability zones before considering the write to be successful. Backblaze, meanwhile, seems to use the term "vaults" here, and seem to use it to mean racks/rooms of backup storage that are seemingly independent from a power/cooling/data perspective. (And possibly with their own isolated little room that has its own fire suppression? They don't mention it, but that's how I'd picture it.) They say that there are multiple vaults "per data centre." But often an entire campus of physically-isolated buildings — what in IaaS terminology would be separate AZs — would be considered one "data centre" in traditional hosting terms, if it's all owned by one company and operated by one shared ops staff. Since Backblaze don't introduce anything quite like the AZ concept in their docs, it's unclear whether their data centres are able to guarantee data durability in the event of a fire that destroys a single "vault." What is clear, is that neither Google nor Backblaze considers this type of data durability to be the most important kind. Which makes sense: there are other types of disasters that can befall a data centre, or even an entire city, that will knock out (and potentially corrupt!) all AZs in that "region." I'd mention floods as the obvious thing to picture, but nobody builds a data centre on a floodplain. Instead, how about: climate change shifting the paths of tornadoes unpredictably; compression of a tectonic plate resulting in random areas of land (potentially inside a city) having the earth heaved and thrusted up by as much as meters; and key cities — and data-centers themselves as strategic targets, actually! — being bombed during a war. Designing your archival storage to be resilient to these problems, will of course also protect your data in the event of a smaller-scale disaster like a fire, meteorite impact, or some spiteful person ramming a truck into one of the DC's buildings. Therefore, Google and Backblaze have both designed in inter-regional replication for the purposes of "geographic data redundancy." GCS has "dual-region" and "multi-region" buckets; and Backblaze has "Cloud Replication" (https://www.backblaze.com/cloud-storage/features/replication https://www.backblaze.com/cloud-storage/features/replication) where you essentially make Bucket A in region A into a streaming read-replica of Bucket B in region B. In both of these cases, enabling the feature costs money. Both providers consider the use-case for this level of durability so rare that they don't make it a guaranteed default with attempted cross-customer subsidization; but instead just offer it to the few customers who think they really need it, or who are required by law or regulation to do it.

aravindajju 3y ago

Cloud Run is the only reason to use GCP for me. I haven't seen any product/service that simple to use. It even offers mapping domain names. All my projects run on Cloud Run.

jillesvangurp 3y ago

We used cloud run for a while and it's great. It does not allow for background threads though and that caused us to upgrade the setup eventually. Upgrading from cloud run to use proper vms was very easy because vms can be booted with a docker container as one of the arguments. It will just go off and run that with a default OS. Running docker containers in gcloud is super easy. And scaling that is easy too. Basically you define an instance template that defines vm details; including the docker container url. And then you update your instance group with that template and all the instances are replaced one by one. You use the instance group as a service for your load balancer and with the right health checks configured this basically gives you zero down time deployments, auto scaling, etc. If there's an issue starting the container, it just aborts the restart and continues running the old containers. The closest thing in AWS would be ECS but it's a lot more hassle to setup. One great feature in gcloud is "copy this screen/dialog/whatever as a gcloud command". That made scripting the above super easy. We use github actions for all this. For each service, we use 1 command to update the template and 1 command to deploy it.

QasimK 3y ago
I’ve used Cloud Run and it does allow for background threads.
- anisov 3y ago
  I think they introduced this feature lately: https://cloud.google.com/run/docs/configuring/cpu-allocation https://cloud.google.com/run/docs/configuring/cpu-allocation you can set --no-cpu-throttling which keeps the cpu allocated even if the request lifetime is over. Used it for Background tasks
  - jillesvangurp 3y ago
    Right; that is indeed new. We might give this another try.

Beijinger 3y ago

$0.0012/GB/Month That is interesting. How to you access this API? Can you do SFTP? This has about the same pricing: https://www.opendrive.com/pricing https://www.opendrive.com/pricing (Yes, it says unlimited, but they told me, they significantly slow it down after 10 TB)

ramoz 3y ago

Asset Inventory is slept on.

gigatexal 3y ago

As a consultant (side gig) I have to use both based on what the company that I’m assigned to is using. AWS S3 and GCP GCS are basically the same in my head. Where things fall apart are actually the cost estimator. GCP’s is far simpler. AWS’s makes me wish I had Corey Quinn on speed dial. Redshift is far too complicated and has too many knobs. Give me BigQuery all day long even with its quirks.

steren 3y ago

Cloud Run product lead here. Your comment and its replies warm my heart. On behalf of the whole Cloud Run team: Thank you!