21–30 of 40 posts
hehe, im just going the other way for a startup of mine. Were i started with ECS (aws cloud run basically) and now going to lambda. Bot for our usecase the cold start isnt such a big deal.
If cold starts wasn't a problem we probably would have stayed with functions, and all of our non-api stuff is still on functions.
> Ideally, we would have used JMeter or something similar, but we could not get it to run locally. So we wrote a small script to walk through most of our endpoints, with concurrent requests, ramp-up time, the works. 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 vers…
Earlier quoted context omitted.
If cold starts wasn't a problem we probably would have stayed with functions, and all of our non-api stuff is still on functions.
I wonder if the cold start will ever be fully fixed. Because most other services would seem to be made redundant then.
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?
That's an insightful article. Thanks for sharing. I still prefer the whole (logical) approach of having VM/Container/Unikernel per execution. FaaS isolates misbehaved calls/payloads from other calls. It also makes rolling out new versions easier, as it will handle ANY new call to your function. AWS has reduced Lambda's cold start a lot in the last years, but Cloud functions still have a long cold start-up time and no…
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.
It is a full-fledged REST API, but we don't do a lot of caching (other than through Cloudlfare) as most of our endpoints either have volatile data or do various operations.
Earlier quoted context omitted.
I wonder if the cold start will ever be fully fixed. Because most other services would seem to be made redundant then.
It's getting better and better, and with a predictive ML model, it can become invisible for most use cases. Unfortunately, cloud Run has an even longer startup time if you need to span more "instances" in response to spikes in traffic, so Cloud Run doesn't fix the cold start yet.
The promise of Cloud Functions is to give them code and they run it. They should be optimizing how it's run and you shouldn't have to do anything different to optimize performance.
I feel like this is a failure on Google's part.
Does anyone disagree?