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

51–60 of 272 posts

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

#51

Post by ramraj07 »

yilugurlu wrote: post #35

These two have resonated with me deeply. - Eliminated complex caching workarounds and data pipeline overhead - Simplified architecture from distributed system to straightforward application We, as developers/engineers (put whatever title you want), tend to make things complex for no reason sometimes. Not all systems have to follow state-of-the-art best practices. Many times, secure, stable, durable systems outperform…

But when were serverless systems like lambda and cloud workers "best practices" for low latency apis?

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

#52

Post by ramraj07 »

chronark_ wrote: post #50
tacker2000 wrote: post #39

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

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

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

#53

Post by chronark_ »

ramraj07 wrote: post #47
nougati wrote: post #31

Earlier quoted context omitted.

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

I can assure you that was pretty close to the internal conversation lol

Not sure what the different takeaways would be though?

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

#54

Post by chronark_ »

kburman wrote: post #43
nougati wrote: post #31

Earlier quoted context omitted.

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.

Not everyone is born with experience in distributed systems

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

#55

Post by randomtoast »

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.

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.

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

#56

Post by ape4 »

seethishat wrote: post #7

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

Next article - why we switched from our own servers to serverless for reliability. A small performance hit was worth it.

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

#57

Post by gonzo41 »

Esophagus4 wrote: post #41
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.

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…

I feel like every cloud build meeting should have a moment where everyone has to defend the question "Wait! could this be a regular database with a regular app on a server with a regular cache?"

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

#58

Post by K0IN »

After building my first Serverless/Cloudflare worker app, this is why I migrated to Deno. Deno enables you to run the same codebase in deno (self-hosted/local) and in deno deploy (serverless platform from deno).

I wanted my app to be self-hostable as well, and Cloudflare worker is a hard ecosystem lock to their platform, which makes it undesirable (imo).

Here is a link to my reasoning from back then: https://github.com/K0IN/Notify/pull/77#issuecomment-16776070...

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

#59

Post by ramraj07 »

pjmlp wrote: post #11
fabian2k wrote: post #6

Earlier quoted context omitted.

At that point, why should I use serverless at all? If I have to think about the lifetime of the servers running my serverless functions?

Because it is still less management effort than taking full control of the whole infrastructure. Usually a decision factor between more serverless, or more DevOps salaries.

Serverless is not a panacea. And the alternative isn't always "multiple devops salaries" - unless the only two options you see are server serverless vs outrageously stupid complicated kubernetes cluster to host a website.

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

#60

Post by gloomyday »

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.

Post reply on HN