Live data from Hacker News

Leaving serverless led to performance improvement and a simplified architecture

unkey.com

81–90 of 272 posts

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

#81
post #11

Earlier quoted context omitted.

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.

> Serverless inherently makes the whole architecture more complex with more moving parts

Why's that? Serverless is just the generic name for CGI-like technologies, and CGI is exactly how classical web application were typically deployed historically, until Rails became such a large beast that it was too slow to continue using CGI, and thus running your application as a server to work around that problem in Rails pushed it to become the norm across the industry — at least until serverless became cool again.

Making your application the server is what is more complex with more moving parts. CGI was so much simpler, albeit with the performance tradeoff.

Perhaps certain implementations make things needlessly complex, but it is not clear why you think serverless must fundamentally be that way.

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

#82
post #62

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!

Thanks

It’s totally fair criticism that the title and wording is a bit clickbaity

But that’s ok

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

#83

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

Really great writeup. The charts tell the story beautifully, and the latency gains are surely a win for your company and customers. I always wonder about the tradeoffs. Is there a measurable latency difference for your non-colocated customers? What does maintenance look like for your Go servers? I assume that your Cloudflare costs dropped?

It’s faster for non-colocated customers too weirdly

I think cause connections can be reused more often. Cloud flare workers are really prone to doing a lot of TLS handshakes cause they spin up new ones constantly

Right now were just hang aws far hate for the go servers, so there really isn’t much maintenance at all. We’ll be moving that into eks soon though cause we are starting to add more stuff and need k8s anyways

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

#84

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.

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.

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

#85
"Self-Hosting : Being tied to Cloudflare's runtime meant our customers couldn't self-host Unkey. While the Workers runtime is technically open source, getting it running locally (even in dev mode) is incredibly difficult.

With standard Go servers, self-hosting becomes trivial:"

A key point that I always make. Serverless is good if you want a simple periodic task to run intermittently without worrying about a full time server. The moment things get more complex than that (which in real world it almost always is), you need a proper server.

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

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

But but it's webscale!

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

#87

As someone who worked with serverless for multiple years (mostly amazon lambda but others too) i can absolutely apporove the authors points. While it "takes away" some work from you, it adds this work on other points to solve the "artificial induced problems". Another example i hit was a hard upload limit. Ported an application to a serverless variant, had an import API for huge customer exports. Shouldnt be a proble…

The way to work around this issue is to provide a presigned S3 url

Have the users upload to s3 directly and then they can either POST you what they uploaded or you can find some other means of correlating the input (eg: files in s3 are prefixed with the request id or something)

I agree this is annoying and maybe I’ve been in AWS ecosystem for too long.

However having an API that accepts an unbounded amount of data is a good recipe for DoS attacks, I suppose the 100MB is outdated as internet has gotten faster but eventually we do need some limit

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

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

In that scenario, how do you keep cold startup as fast as possible?

The nice thing about JS workers is that they can start really fast from cold. If you have low or irregular load, but latency is important, Cloudflare Workers or equivalent is a great solution (as the article says towards the end).

If you really need a full-featured container with AOT compiled code, won't that almost certainly have a longer cold startup time? In that scenario, surely you're better off with a dedicated server to minimise latency (assuming you care about latency). But then you lose the ability to scale down to zero, which is the key advantage of serverless.

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

#89

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

TFA states that they’re running on AWS Fargate.

That said, as an example, an m8g.8xlarge gives you 32 vCPU / 128 GiB RAM for about $1000/month in us-east-1 for current on-demand pricing, and that drops to just under $700 if you can do a 1-year RI. I’m guessing this application isn’t super memory-heavy, so you could save even more by switching to the c-family: same vCPU, half the RAM.

Stick two of those behind a load balancer, and you have more compute than a lot of places actually need.

Or, if you have anything resembling PMF, spend $10K or so on a few used servers and put them into some good colo providers. They’ll do hardware replacement for you (for a fee).

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

#90

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.

A lot of people don’t know about compilers, bash scripts and libraries.
Post reply on HN