5 ms·
Author of that blog here, happy to answer any questions :)
by chronark_ 1y ago
Author of that blog here, happy to answer any questions :)
- flerchin 1y agoReally great writeup. The charts tell the story beautifully, and the latency gains are surely a win for your company and customers. I always wonder about the tradeoffs. Is there a measurable latency difference for your non-colocated customers? What does maintenance look like for your Go servers? I assume that your Cloudflare costs dropped?
- chronark_ 1y agoIt’s faster for non-colocated customers too weirdly I think cause connections can be reused more often. Cloud flare workers are really prone to doing a lot of TLS handshakes cause they spin up new ones constantly Right now were just hang aws far hate for the go servers, so there really isn’t much maintenance at all. We’ll be moving that into eks soon though cause we are starting to add more stuff and need k8s anyways
- wiether 1y agoNot a question: thanks for the writeup and for the honesty of saying that serverless is not inherently bad, just not the right fit for your usecase! Unfortunately too many comments here are quick to come to the wrong conclusion, based only on the title. Not a reason to change it though!
- chronark_ 1y agoThanks It’s totally fair criticism that the title and wording is a bit clickbaity But that’s ok
- Sammi 1y agoDo you have a clearer picture of what use-cases you would use serverless functions for in the future (if any)?
- synunlimited 1y agoHave you done new benchmarks since Cloudflare announced their latest round of performance improvements for Workers? Just curious if this workload also saw some of the same improvements (on a quick read it seems like you could have been hitting the routing problem CF mentions)