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

111–120 of 272 posts

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

#111

Post by 827a »

gloomyday wrote: post #60

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.

Yeah; IMO Docker was our last universal improvement to productivity, in 2013, and very little we've invented since then can be said to have had such a wide-ranging positive impact, with such few drawbacks. Some systems are helpful for some companies, but then try to get applied to other companies where they don't make sense and things fall apart or productivity suffers. Cloudflare and others are trying to make v8 isolates a thing, and while they are awesome for some workloads, people want them to be the "next docker", and they aren't.

The model "give me docker image, we put it on internet" is staggeringly powerful. It'll probably still be the most OP way to host applications in 2040.

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

#112

Post by CuriouslyC »

OvervCW wrote: post #105
CuriouslyC wrote: post #44

Earlier quoted context omitted.

They're much cheaper, they're just DOs, and they get billed as such. They also have faster cold start times and automatic multi-region support.

What does DO mean in this context?

Durable Object

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

#113

Post by codegeek »

bamboozled wrote: post #65
gloomyday wrote: post #60

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.

Excerpt AWS lambda is stupidly cheap!

How long is a piece of string ?

"Cheap" is relevant if you are talking about work load that is one off and doesn't run continuously. A lot of people use serverless to run a 24-7 service which sort of defeats the purpose. It doesn't get that cheap anymore.

Serverless is good if you have one off tasks that are used intermittently and are not consistent.

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

#114

Post by whstl »

dlisboa wrote: post #70
Danjoe4 wrote: post #48

Earlier quoted context omitted.

This is exactly why I'd rather get a fat VPS from a reputable provider. As long as the bandwidth is sufficient the only limitation is vertical scaling.

I'm partial to this, the only thing I've found that is harder to achieve is the "edge" part of cloud services. Having a server at each continent is enough for most needs but having users route to the closest one is not as clear to me. I know about Anycast but not how to make it operational for dynamic web products (not like CDN static assets). Any tips on this?

Someone correct me if I’m wrong but:

DIY Anycast is probably beyond most people’s reach, as you need to deal with BGP directly.

One cool trick is using GeoDNS to route the same domain to a different IP depending on the location of the user, but there are some caveats of course due to caching and TTL.

EDIT: Back to Anycast, there are also some providers who allow you BGP configuration, like those: https://www.virtua.cloud/features/your-ip-space - https://us.ovhcloud.com/network/byoip - https://docs.hetzner.com/robot/colocation/pricing/ ... However you still need to get the IPs by yourself, by dealing with your Regional Registry (RIPE in my case, in Europe)

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

#115

Post by cogman10 »

Esophagus4 wrote: post #71
bamboozled wrote: post #65

Earlier quoted context omitted.

Excerpt AWS lambda is stupidly cheap!

For certain workloads :) And that is actually the advantage of serverless, in my mind. For some low-traffic workloads, you can host for next to nothing. Per invocation, it is expensive, but if you only have a few invocations of a workload that isn't very latency sensitive, you can run an entirely serverless architecture for pennies per month. Where people get burned is moving high traffic volumes to serverless... the…

Exactly. I've always found that how people want to use lambda is the exact opposite of how to use it cost effectively.

I've seen a lot of people want to use lambdas as rest endpoints and effectively replace their entire API with a cluster of lambdas.

But that's about the most expensive way to use a lambda! 1 request, one lambda.

Where these things are useful is when you say "I have this daily data pull and ETL that I need to do." Then all the sudden the cost is pretty dang competitive.

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

#116

Post by bunderbunder »

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 would not assume this was a "rookie mistake". I've been here once or twice, and a common story is that engineers don't want to do it a certain way, but management overrules them for some vague hand-wavy reason like, "This way is more modern." Another common story is that you know you're not choosing the most [scalable|robust|performant|whatever] design, but ancillary constraints like time and money push you into a "worse is better" decision.

Or maybe the original implementation team really didn't know what they were doing. But I'd rather give them the benefit of the doubt. Either way, I appreciate them sharing these observations because sharing these kinds of stories is how we collectively get better as a professional community.

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

#118

Post by stackskipton »

seethishat wrote: post #30
wltr wrote: post #26

Earlier quoted context omitted.

Backup strategy? What do you mean by that?

Servers go down. What is the plan to get them "backup" and running ;)

Most server outages are caused by hardware failures which EC2 MOSTLY abstracts from you.

Also, if it's just Golang, point Ansible or whatever deploys at new server and trigger a deploy.

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

#119

Post by stackskipton »

dlisboa wrote: post #70
Danjoe4 wrote: post #48

Earlier quoted context omitted.

This is exactly why I'd rather get a fat VPS from a reputable provider. As long as the bandwidth is sufficient the only limitation is vertical scaling.

I'm partial to this, the only thing I've found that is harder to achieve is the "edge" part of cloud services. Having a server at each continent is enough for most needs but having users route to the closest one is not as clear to me. I know about Anycast but not how to make it operational for dynamic web products (not like CDN static assets). Any tips on this?

You could start using DNS Traffic Shaping where DNS server looks at IP making the request and returns the IP of closest server.

Azure/AWS/GCP all have solutions for this and does not require you to use their services. There are probably other DNS providers that can do it as well.

Cloudflare can also do this as well but it's probably more expensive than DNS.

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

#120

Post by toast0 »

dlisboa wrote: post #70
Danjoe4 wrote: post #48

Earlier quoted context omitted.

This is exactly why I'd rather get a fat VPS from a reputable provider. As long as the bandwidth is sufficient the only limitation is vertical scaling.

I'm partial to this, the only thing I've found that is harder to achieve is the "edge" part of cloud services. Having a server at each continent is enough for most needs but having users route to the closest one is not as clear to me. I know about Anycast but not how to make it operational for dynamic web products (not like CDN static assets). Any tips on this?

To get anycast working, you need BGP, and to get it working well, I think you need a good understanding of BGP and a lot of points of presence and well connected at each. BGP's default metric of distance is number of networks traversed, which does funny things.

Say you're in city A where you use transit provider 1 and city B where you use transit provider 2. If a user is in city B and their ISP is only connected to transit provider 1, BGP says deliver your traffic to city A, because then traffic doesn't leave transit provider 1 until it hits your network. So for every transit network you use, you really want to connect to it at all your PoPs, and you probably want to connect to as many transit networks as feasible. If you're already doing multihoming at many sites, it's something to consider; if not, it's probably a whole lot of headache.

GeoDNS as others suggested is a good option. Plenty of providers out there, it's not perfect, but it's alright.

Less so for web browsers, but you can also direct users to specific servers. Sample performance for each /24 and /48 and send users to the best server based on the statistics, use IP location as a fallback source of info. Etc. Not great for simple websites, more useful for things with interaction and to reduce the time it takes for tcp slow start (and similar) to reach the available bandwidth.

Post reply on HN