Re:Saving Three Months of Latency with a Single OpenTelemetr...
by serverlessmom on Friday June 07, 2024 @01:28PM
(#40610810)
I think that’s flawed analysis, if you’re running FaaS then sure you can fail to see benefit from small improvements in time (AWS Lambda changed their billing resolution a few years back but before then the Go services didn’t save much money despite being faster) but if you’re running thousands of requests, and speeding them all up, you should be able to realize tangible compute savings whatever your platform.
[ Parent
| on HN ]
Re:Saving Three Months of Latency with a Single OpenTelemetr...
by hiatus on Friday June 07, 2024 @01:31PM
(#40610851)
Help me to understand, then. If this stuff is being done on an autoscaling cluster, I can see it, but if you are just running everything on an always-on box for instance, it is less clear to me.
edit: Do you have an affiliation with the blog? I ask because you have submitted several articles from checkly in the past.
Re:Saving Three Months of Latency with a Single OpenTelemetr...
by tnolet on Friday June 07, 2024 @01:53PM
(#40611074)
Hey Checkly founder here, we changed our infra quite a bit over the last ~1 year. Still, it's mostly ephemeral compute. We started actually on AWS Lambda. We are on a mix of AWS EC2 and EKS now, all autoscaled per region (we run 20+ of them).
It seems tiny, but in aggregate this will have an impact on our COGS. You are correct that if we had a fixed fleet of instances, the impact would have been not super interesting.
But still, for a couple of hours spent, this saves us quite some $1Ks per year.
Re:Saving Three Months of Latency with a Single OpenTelemetr...
by serverlessmom on Friday June 07, 2024 @01:56PM
(#40611108)
Yes I work at Checkly, though I didn’t answer authoritatively since this one wasn’t written by me!