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

1–10 of 272 posts

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

#2

Post by pjmlp »

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.

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

#3

Post by OvervCW »

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.

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

#5

Post by keyle »

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...

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

#6

Post by fabian2k »

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?

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

#8

Post by zaphirplane »

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.

Hey! Bet I can guess who

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

#9

Post by OvervCW »

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?

Serverless only makes sense if the lifetime doesn't matter to your application, so if you find that you need to think about your lifetime then serverless is simply not the right technology for your use case.
Post reply on HN