11–20 of 40 posts
We wrote about how we migrated off Cloud Run to K8s (might be your next step): https://newscatcherapi.com/blog/google-kubernetes-engine-as-...
You mentioned that Cloud Run allowed you to reserve a number of always-running instances, but that feature is available for Cloud Functions as well [0]. [0] https://cloud.google.com/functions/docs/configuring/min-inst...
Hi! Author here. Functions still only run a single request at a time, while Cloud Run can run as many as the container can handle. We want to build for multiple smaller requests, so when we get ~10k requests incoming in a short timespan it's a lot more useful to have Cloud Run. I may be mistaken, but I believe cold start is roughly the same for both.
Earlier quoted context omitted.
Hi! Author here. Functions still only run a single request at a time, while Cloud Run can run as many as the container can handle. We want to build for multiple smaller requests, so when we get ~10k requests incoming in a short timespan it's a lot more useful to have Cloud Run. I may be mistaken, but I believe cold start is roughly the same for both.
[deleted]
We wrote about how we migrated off Cloud Run to K8s (might be your next step): https://newscatcherapi.com/blog/google-kubernetes-engine-as-...
I haven't read the entire article, but I assume you need someone to admin the cluster? How does the savings in billing compare to work needed for maintenance?
You can learn the basics of Kubernetes and save around 20-25% compare to use the same Docker Containers but with Cloud Run.
There is a minor cost for one Kubernetes cluster to be run on GCP, but it is negligible if you consider to have some heavy jobs.
It would be better to measure response times in percentiles. Not saying you will get a different result in your particular case, but it's a more accurate representation of what is actually happening.
We wrote about how we migrated off Cloud Run to K8s (might be your next step): https://newscatcherapi.com/blog/google-kubernetes-engine-as-...
I haven't read the entire article, but I assume you need someone to admin the cluster? How does the savings in billing compare to work needed for maintenance?
[0]: https://cloud.google.com/blog/products/containers-kubernetes...
I would love to see a full comparison of an API like the one mentioned in the article and full-fledged REST API (built with cacheability in mind) having something like Varnish or Squid in front.
We use Firebase for basically everything at our company ─ we run an API-first "digital keychain" ─ and we love it! however our API (based on Cloud Functions) response times were... not so great to say the least, with some of our endpoints taking more than a couple of seconds to respond, which was kind of a big issue for our clients. We tried several techniques but by far what got us to reduce response times the most…
I’m in the process of figuring out what to use for my next startup. Have you had any issues with Firebase? If you were to start again, would you still mainly use Firebase on the client or would you have the clients hit Cloud Run endpoints?
We hit some snags when we started requiring a performant API, which is why we don't use Firebase for that any more, although we still use Firestore and a lot of other stuff for the platform.
As every other technology it's choosing what pains you want, and the current Firesbase pains are quite easy to live with.
I'm pretty sure somewhere north of 80% of load testing tasks play out exactly like this - certainly at least 4 or 5 of these efforts that I've been a part of started with an attempt to get the latest version of JMeter to work ("we should use the mature solution and not reinvent the wheel, right?"), hit major difficulties, and ended up with me cobbling together an ugly but working 100 LoC script that did the job with far fewer headaches than the feature-rich but not really functional Cadillac solutions out there. Apache Bench can do quite a bit in a pinch, and doesn't choke up as quickly as a lot of other ways that you might generate traffic.
Re: Cloud Functions vs. Cloud Run, both are fantastic services and I do tend to prefer Cloud Run lately. For minimizing cold start latency another trick you can use if that's too big a move is to do your function routing within a single global endpoint (obviously this only works for internal-only APIs) - rather than having 100+ endpoints that you hit, you always hit the same endpoint and just include the desired call as a parameter, and route to the correct logic in a few extra lines of code. With all your functionality now passing through the same cloud function call, you're much less likely to incur the cold start penalty on your less frequently called functions, though it comes at the cost of some complexity in code. If you're going through Firebase it also speeds up your deployments quite a bit because you only have 1 function to deploy. Not a silver bullet (and it's also not a good solution if you want a proper REST API, since you're basically forced to jam everything through a POST endpoint), but can be an effective intermediate workaround if going all the way to Cloud Run is too daunting.