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

11–20 of 272 posts

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

#11

Post by pjmlp »

fabian2k wrote: post #6
pjmlp wrote: post #2

Their problem isn't serverless, rather Cloudflare Workers and WebAssembly. All major cloud vendors have serveless solutions based on containers, with longer managed lifetimes between requests, and naturally the ability to use properly AOT compiled languages on the containers.

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.

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

#12

Post by CuriouslyC »

pjmlp wrote: post #2

Their problem isn't serverless, rather Cloudflare Workers and WebAssembly. All major cloud vendors have serveless solutions based on containers, with longer managed lifetimes between requests, and naturally the ability to use properly AOT compiled languages on the containers.

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.

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

#13

Post by pjmlp »

keyle wrote: post #5
pjmlp wrote: post #2

Their problem isn't serverless, rather Cloudflare Workers and WebAssembly. All major cloud vendors have serveless solutions based on containers, with longer managed lifetimes between requests, and naturally the ability to use properly AOT compiled languages on the containers.

You're saying serverless can have really low latency and fast 24/7? Isn't serverless at the base the old model, of shared vms, except with a ton of people? I'm old school I guess, baremetal for days...

Yes, check Cloud Run, AWS Lambda, Azure Functions with containers.

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

#17

Post by fabian2k »

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.

I would doubt that this is categorically true. Serverless inherently makes the whole architecture more complex with more moving parts in most cases compared to classical web applications.

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

#18

Post by saidinesh5 »

muragekibicho wrote: post #4

Interesting writeup. The serverless approach helped with GTM. (I speculate) raising capital afforded them extra devs who noticed the cache latency.

> The serverless approach helped with GTM

Unlikely? They could've just as well deployed their single go binary to a vm from day 1 and it would've been smooth sailing for their use case, while they acquire customers.

The cloudflare workers they chose aren't really suited for latency critical, high throughput APIs they were designing.

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

#20

Post by CuriouslyC »

OvervCW wrote: post #3
pjmlp wrote: post #2

Their problem isn't serverless, rather Cloudflare Workers and WebAssembly. All major cloud vendors have serveless solutions based on containers, with longer managed lifetimes between requests, and naturally the ability to use properly AOT compiled languages on the containers.

Agree, it seems like they decided to use Cloudflare Workers and then fought them every step of the way instead of going back and evaluating if it actually fit the use case properly. It reminds me of the companies that start building their application using a NoSQL database and then start building their own implementation of SQL on top of it.

Ironically, I really like cloudflare but actively dislike workers and avoid them when possible. R2/KV/D1 are all fantastic and being able to shard customer data via DOs is huge, but I find myself fighting workers when I use them for non-trivial cases. Now that Cloudflare has containers I'm pushing people that way.
Post reply on HN