Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving serverless led to performance improvement and a simplified architecture

unkey.com

Post reply on HN
Print view View original

61–70 of 272 posts

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

#61

Post by ramraj07 »

chronark_ wrote: post #53
ramraj07 wrote: post #47

Earlier quoted context omitted.

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 p…

I can assure you that was pretty close to the internal conversation lol Not sure what the different takeaways would be though?

What did your internal discussion conclude for the question "Why did we not take a step back earlier and think, why are we doing it this way?"

Im genuinely curious because this is not singling out your team or org, this is a very common occurrence among modern engineering teams, and I've often found myself on the losing end of such arguments. So I am all ears to hear at least one such team telling what goes on in their mind when they make terrible architecture decisions and if they learned anything philosophical that would prevent a repeat.

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

#62

Post by wiether »

chronark_ wrote: post #29

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

Not 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!

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

#63

Post by chronark_ »

ramraj07 wrote: post #52
chronark_ wrote: post #50

Earlier quoted context omitted.

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

Where did their marketing or documentation say this service is perfect for low latency APIs?

I doubt they literally said “perfect for low latency APIs” but their messaging is definitely trying to convince you that they’re fast globally, just look at the workers.ckoudflare.com page

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

#64

Post by sgarland »

chronark_ wrote: post #54
kburman wrote: post #43

Earlier quoted context omitted.

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.

Not everyone is born with experience in distributed systems

Sure, but there are some fundamentals about latency that any programmer should know [0] (absolute values outdated, but still useful as relative comparisons), like “network calls are multiple orders of magnitude slower than IPC.”

I’m assuming you’re an employee of the company based on your comments, so please don’t take this poorly - I applaud any and all public efforts to bring back sanity to modern architecture, especially with objective metrics.

0: https://gist.github.com/hellerbarde/2843375

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

#65

Post by bamboozled »

gloomyday wrote: post #60

I think developers are drowning in tools to make things "easy", when in truth many problems are already easy with the most basic stuff in our tool belt (a compiler, some bash scripts, and some libraries). You can always build up from there. This tooling fetish hurts both companies and developers.

Excerpt AWS lambda is stupidly cheap!

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

#66

Post by kburman »

chronark_ wrote: post #54
kburman wrote: post #43

Earlier quoted context omitted.

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.

Not everyone is born with experience in distributed systems

That's fair, but then the framing matters. The article criticizes serverless architecture rather than acknowledging an evaluation failure.

"Serverless was fighting us" vs "We didn't understand serverless tradeoffs" - one is a learning experience, the other is misdirected criticism.

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

#67

Post by osigurdson »

torginus wrote: post #38
kburman wrote: 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.

My personal experience is that if you want guaranteed anything (quick scaling, latency, CPU, disk or network throughput), your best bet is to manually provision EC2 instances (or use some API that does). Once you give up control hoping to gain performance for free, you usually end up with an unfixable bottleneck.

There isn't much for them to mess with in EKS either. It is very close to the metal and easy to reason about.

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

#68

Post by sgarland »

randomtoast wrote: post #55
torginus wrote: post #38

Earlier quoted context omitted.

My personal experience is that if you want guaranteed anything (quick scaling, latency, CPU, disk or network throughput), your best bet is to manually provision EC2 instances (or use some API that does). Once you give up control hoping to gain performance for free, you usually end up with an unfixable bottleneck.

If you're looking for a middle ground between VMs and serverless, ECS Fargate is a good option. Because a container is always running, you won't experience any cold start times.

Yes, though unless you’re provisioning your own EC2s for them to run on, you have no guarantee about the server generation, and IME AWS tends to provision older stuff for Fargate.

This may or may not matter to you depending on your application’s needs, but there is a significant performance difference between, say, an m4 family (Haswell / Broadwell) and an m7i family (Sapphire Rapids) - literally a decade of hardware improvements. Memory performance in particular can be a huge hit for latency-sensitive applications.

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

#69

Post by whynotmaybe »

czhu12 wrote: post #33
kburman wrote: 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?

On serverless, whenever you call your code, it has to be executed but first the infrastructure has to find a place to run it and sometimes if there's no running instance available, it must fire up a new instance to run your code.

That's hot start VS cold start.

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

#70

Post by dlisboa »

Danjoe4 wrote: post #48
Esophagus4 wrote: post #41

Earlier quoted context omitted.

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.

I'm partial to this, the only thing I've found that is harder to achieve is the "edge" part of cloud services. Having a server at each continent is enough for most needs but having users route to the closest one is not as clear to me.

I know about Anycast but not how to make it operational for dynamic web products (not like CDN static assets). Any tips on this?

Post reply on HN