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

131–140 of 272 posts

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

#131

Post by lossolo »

nougati wrote: post #97
lossolo wrote: post #94

Earlier quoted context omitted.

You don't need experience and there is not really a lot to know about "distributed systems" in this case, that's basic CS knowledge about networks, latency and what "serverless" actually is, you can read about it. To be honest, to me it reads like people who don't understand the problem they're solving, haven't acquired the necessary knowledge to solve it (either by learning themselves or by asking/hiring people who…

Sometimes I see a post about sorting algorithms online. Some people seem to benefit from reading about these things, but often, I find there isn't much new information for me. That's OK, because I know somebody somewhere benefits from knowing this. It is your decision to make this a circlejerk of musings about how the company must be run by amateurs. Whatever crusade you're fighting in vividly criticising them is not…

[dead]

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

#132

Post by daxfohl »

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?

It can be good for connecting AWS stuff to AWS stuff. "On s3 update, sync change to dynamo" or something. But even then, now you've got a separate coding, testing, deployment, monitoring, alerting, debugging pipeline from your main codebase, so is it actually worth it?

But no, I'd not put any API services/entrypoints on a lambda, ever. Maybe you could manufacture a scenario where like the API gets hit by one huge spike at a random time once per year, and you need to handle the scale immediately, and so it's much cheaper to do lambda than make EC2 available year-round for the one random event. But even then, you'd have to ensure all the API's dependencies can also scale, in which case if one of those is a different API server, then you may as well just put this API onto that server, and if one of them is a database, then the EC2 instance probably isn't going to be a large percentage of the cost anyway.

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

#133

Post by smrtinsert »

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.

Agreed. Wondering what sort of discovery or design phase their legacy arch went thru.

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

#134

Post by daxfohl »

I don't think "serverless is bad" is necessarily the full lesson here. The bigger lesson is when a service has dependencies, moving that service closer to the client (without also moving those dependencies) will counterintuitively make the e2e experience slower, not faster.

Prefer building physically near your dependencies. If that's not fast enough, then you have to figure out how to move or sync all your dependencies closer to the client, which except in very simple cases, is almost always a huge can of worms.

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

#135

Post by aeldidi »

I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting secrets when needed. That makes it easy to run and test locally, but still provides most of the benefits I think (infrastructure-as-code setups, reproducibility, etc). Serverless goes a little too far for most applications (in my opinion), but I have to admit some apps work really well under that model. There's a nearly endless number of simple/trivial utilities which wouldn't really gain anything from having their own infrastructure and would work just fine in a shared or on-demand hosting environment, and a massively scaled stateless service would thrive under a serverless environment much more than it would on a traditional server.

That's not to say that I think serverless is somehow only for simple or trivial use cases though, only that there's an impedance mismatch between the "classic web app" model, and what these platforms provide.

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

#137

Post by daitangio »

aeldidi wrote: post #135

I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting secrets when needed. That makes it easy to run and test locally, but still provides most of the benefits I think (infrastructure-as-code setups, reproducibility, etc). Serverless goes a little too far for most applications (in my opinion), but I have to admit s…

You are ready for misterio: https://github.com/daitangio/misterio A tiny layer around stareless docker cluster. I created it for my homelab and it gone wild

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

#138

Post by TheTaytay »

evantbyrne wrote: post #84
randomtoast wrote: post #55

Earlier quoted context omitted.

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.

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

Sounds useful! I hear mixed things about Swarm. You like it?

Edit: found it. Cool! https://rove.dev/

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

#139

Post by nine_k »

One thing I could not find in the write-up is the change in the expense. Did serverless save any money, compared to always-up VMs? Did much of their load run under the free tier limits?

Serverless shines when the load is very spiky, and you can afford high long-tail latency. Then you don't pay for all that time when your server would be idling. (This is usually not the case for auth APIs, unless they auth other infrequently invoked operations.)

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

#140

Post by mattmanser »

aeldidi wrote: post #135

I think the "local maximum" we've gotten stuck at for application hosting is having a docker container as the canonical environment/deliverable, and injecting secrets when needed. That makes it easy to run and test locally, but still provides most of the benefits I think (infrastructure-as-code setups, reproducibility, etc). Serverless goes a little too far for most applications (in my opinion), but I have to admit s…

Docker is much like microservices. Appropriate for a subset of apps and yet touted as being 'the norm' when it shouldn't be.

There are drawbacks to using docker, such as security patching and operational overhead. And if you're blindly putting it into every project, how are you mitigating the risks it introduces?

Worse, the big reason it was useful, managing dependency hell, has largely been solved by making developers default to not installing dependencies globally.

We don't really need Docker anywhere near like we used to, and yet it persists as the default, unassailable.

Of course hosting companies must LOVE it, docker containers must increase their margins by 10% at least!

Someone else down thread has mentioned a tooling fetish, I feel Docker is part of that fetish.

Post reply on HN