Live data from Hacker News

Leaving serverless led to performance improvement and a simplified architecture

unkey.com

41–50 of 272 posts

Re: Leaving serverless led to performance improvement and a simplified architecture

#41
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

I’ve found this to be true, with one caveat.

Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem.

However, in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their products’ genuine performance is a closely guarded proprietary secret, and the only way to find out… e.g. whether Lambdas are fast enough for your use case, or whether AWS RDS cross-region replication is good enough for you… is to run your own performance testing.

I’ve been burned enough times by AWS making it difficult to figure out exactly how performant their services are, and I’ve learned to test everything myself for the workloads I’ll be running.

Re: Leaving serverless led to performance improvement and a simplified architecture

#42
post #26

Linux servers running Go apps? Would be nice to see server cost and specs, backup strategy, etc.

Backup strategy? What do you mean by that?

I'm assuming "High Availability" is what is really meant here.

Re: Leaving serverless led to performance improvement and a simplified architecture

#43
post #31
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

The takeaway isn't that they didn't understand, it's that they are sharing information which you agree is valuable

What's valuable about rediscovering that stateless architectures requiring network round-trips for state access are slower than in-memory state? This isn't new information, it's a predictable consequence of their architecture choice that anyone with distributed systems experience could have told them on day zero.

Re: Leaving serverless led to performance improvement and a simplified architecture

#44
post #24

Earlier quoted context omitted.

Cloudflare has containers now too, and having used AppRunner and Cloud Run, it's much easier to work with. Once they get rid of the container caps and add more flexibility in terms of container resources, I would never go back to the big cloud containers, the price and ease of use of Cloudflare's containers just destroy them.

I doubt that the bill would be that much cheaper, nonetheless thanks for making me aware they are a thing now.

They're much cheaper, they're just DOs, and they get billed as such. They also have faster cold start times and automatic multi-region support.

Re: Leaving serverless led to performance improvement and a simplified architecture

#45

Author of that blog here, happy to answer any questions :)

Really 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?

Re: Leaving serverless led to performance improvement and a simplified architecture

#46
post #33
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

> Putting a latency-critical API on a stateless edge runtime Isn’t this the whole point of serverless edge? It’s understood to be more complex, with more vendor lockin, and more expensive. Trade off is that it’s better supported and faster by being on the edge. Why would anyone bother to learn a proprietary platform for non critical, latency agnostic service?

You're confusing network proximity with application architecture. Edge deployment helps connection latency. Stateless runtime destroys it by forcing every cache access through the network.

The whole point of edge is NOT to make latency-critical APIs with heavy state requirements faster. It's to make stateless operations faster. Using it for the former is exactly the mismatch I'm describing.

Their 30ms+ cache reads vs sub-10ms target latency proves this. Edge proximity can't save you when your architecture adds 3x your latency budget per cache hit.

Re: Leaving serverless led to performance improvement and a simplified architecture

#47
post #31
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

The takeaway isn't that they didn't understand, it's that they are sharing information which you agree is valuable

Bo Burmham said, "self awareness does not absolve anyone of anything"

But here I dont think they (or their defenders) are still aware of the real lesson here.

Theres literally zero information thats valuable here. Its like saying "we used an 18 wheeler as our family car and then we switched over to a regular camry and solved all our problems." What is the lesson to be learned in that statement?

The real interesting post mortem would be if they go, "god in retrospect what a stupid decision we took; what were we thinking? Why did we not take a step back earlier and think, why are we doing it this way?" If they wrote a blog post that way, that would likely have amazing takeaways.

Re: Leaving serverless led to performance improvement and a simplified architecture

#48
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

I’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

This is exactly why I'd rather get a fat VPS from a reputable provider. As long as the bandwidth is sufficient the only limitation is vertical scaling.

Re: Leaving serverless led to performance improvement and a simplified architecture

#49
post #23

The takeaway here isn’t that serverless doesn’t work, it’s that the authors didn’t understand what they were building on. Putting a latency-critical API on a stateless edge runtime was a rookie mistake, and the pain they describe was entirely predictable.

I’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

> the documentation is closer to marketing than truthful technical documentation

I participated in AWS training and certification given by AWS for a company to obtain a government contract and I can 100% say that the PAID TRAINING itself is also 100% marketing and developer evangelism.

Re: Leaving serverless led to performance improvement and a simplified architecture

#50

Incredible that these kinds of services were hosted like this. I guess they never came out of MVP, which could warrant using serverless, but in the end it makes 0 sense to use some slow solution like this for the service they are offering. Why didnt they go with a self hosted backend right away? Its funny how nowadays most devs are too scared to roll their own and just go with the cloud offerings that cost them tech…

We did initially but thought cloud flare was a better solution for scalability and latency.

We believed their docs/marketing without doing extensive benchmarks, which is on us.

The appeal was also to use the same typescript stack across everything, which was nice to work with

Post reply on HN