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

91–100 of 272 posts

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

#91

Post by osigurdson »

Esophagus4 wrote: post #41
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’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

>> is to run your own performance testing

I think they are shooting themselves in the foot with this approach. If you have to run a monte carlo simulation on every one of their services at your own time and expense just to understand performance and costs, people will naturally shy away from such black boxes.

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

#92

Post by ivape »

whstl wrote: post #49
Esophagus4 wrote: post #41

Earlier quoted context omitted.

I’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

> the documentation is closer to marketing than truthful technical documentation I participated in AWS training and certification given by AWS for a company to obtain a government contract and I can 100% say that the PAID TRAINING itself is also 100% marketing and developer evangelism.

Infra will always be full of so much nonsense because it’s really hard to tell successful developers their code and system design is unusable. People use it because they are paid to do so usually, but it’s literally some of the worst product development I’ve ever seen.

AWS will hopefully be reduced to natural language soon enough with AI, and their product team can move on (most likely they moved on a long time ago, and the revolving door at the company meant it was going remain a shittily thought out platform in long term maintenance).

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

#93

Post by pjmlp »

iainmerrick wrote: post #88
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.

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 start…

Apparently not nice enough, given that they rewrote the application in Go.

Serverless with containers is basically managed Kubernetes, where someone else has the headache to keep the whole infrastructure running.

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

#94

Post by lossolo »

chronark_ wrote: post #54
kburman wrote: post #43

Earlier quoted context omitted.

What's valuable about rediscovering that stateless architectures requiring network round-trips for state access are slower than in-memory state? This isn't new information, it's a predictable consequence of their architecture choice that anyone with distributed systems experience could have told them on day zero.

Not everyone is born with experience in distributed systems

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 have it), and seeing such an amateurish mistake doesn't inspire confidence for the future. You should either hire people that know what they are doing or upgrade your knowledge about systems you are using before making decisions to use them.

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

#95

Post by usui »

osigurdson wrote: post #91
Esophagus4 wrote: post #41

Earlier quoted context omitted.

I’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

>> is to run your own performance testing I think they are shooting themselves in the foot with this approach. If you have to run a monte carlo simulation on every one of their services at your own time and expense just to understand performance and costs, people will naturally shy away from such black boxes.

> people will naturally shy away from such black boxes.

I don't this isn't true. In fact, it seems that in the industry, many developers don't proceed with caution and go straight into usage, only to find the problems later down the road. This is a result of intense marketing on the part of cloud providers.

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

#96

Post by ecshafer »

whstl wrote: post #49
Esophagus4 wrote: post #41

Earlier quoted context omitted.

I’ve found this to be true, with one caveat. Most cloud pain people experience is from a misunderstanding / abuse of solutions architecture and could have been avoided with a more thoughtful design. It tends to be a people problem, not a tool problem. However , in my experience cloud vendors sell the snot out of their offerings, and the documentation is closer to marketing than truthful technical documentation. Their…

> the documentation is closer to marketing than truthful technical documentation I participated in AWS training and certification given by AWS for a company to obtain a government contract and I can 100% say that the PAID TRAINING itself is also 100% marketing and developer evangelism.

100% agree with you. I took a corporate training, and at one point crammed for the developer cert. It it just marketing. There is never a question where the answer is "Just run this service on EC2 yourself". It is about maximizing your usage of AWS services.

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

#97

Post by nougati »

lossolo wrote: post #94
chronark_ wrote: post #54

Earlier quoted context omitted.

Not everyone is born with experience in distributed systems

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 valuable at all. People need to learn and share so we can all improve, stop distracting from that point.

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

#98

Post by ecshafer »

usui wrote: post #95
osigurdson wrote: post #91

Earlier quoted context omitted.

>> is to run your own performance testing I think they are shooting themselves in the foot with this approach. If you have to run a monte carlo simulation on every one of their services at your own time and expense just to understand performance and costs, people will naturally shy away from such black boxes.

> people will naturally shy away from such black boxes. I don't this isn't true. In fact, it seems that in the industry, many developers don't proceed with caution and go straight into usage, only to find the problems later down the road. This is a result of intense marketing on the part of cloud providers.

The fact is most developers in most companies have very little choice. Many medium to large companies (1k-50k employees) the CTO gets wined and dined by AWS/Azure/Oracle and they decide to move to that cloud. They bring in their solutions architects and do the training. The corporate architects for the divisions set the goals. So the rank and file developers get told that they have to make this work in AWS using RDS and they have almost zero power over this choice.

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

#99

Post by hylaride »

ivape wrote: post #92
whstl wrote: post #49

Earlier quoted context omitted.

> the documentation is closer to marketing than truthful technical documentation I participated in AWS training and certification given by AWS for a company to obtain a government contract and I can 100% say that the PAID TRAINING itself is also 100% marketing and developer evangelism.

Infra will always be full of so much nonsense because it’s really hard to tell successful developers their code and system design is unusable. People use it because they are paid to do so usually, but it’s literally some of the worst product development I’ve ever seen. AWS will hopefully be reduced to natural language soon enough with AI, and their product team can move on (most likely they moved on a long time ago,…

Some things never change. I remember ~20 years ago a bunch of expensive F5s suddenly showing up to our offices because the CTO and enterprise architects were convinced that irules could solve all their performance problems for something that wasn't even cacheable (gaming results) and would have shoved too much of our logic into the underpowered CPUs on them.

They were a much nicer, if overpriced, load balancing alternative to the Cisco Content Switch we were using, though.

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

#100

Post by jjice »

Like the article says, I think serverless has it's place, but I don't think it's for most applications. I can't see myself _ever_ using serverless services as a core part of my application for pretty much any startup, if I can avoid it. The infrastructure overhead is actually worse, IMO.

Everything is so platform specific and it's much stranger to test and develop against locally. Each platform has a different way to test, and the abstraction layers that exist (unless this has changed recently) always had pitfalls, since there are no true standards.

I'd much rather have a docker image as my deliverable "executable" so I can test, but still abstract away some stuff, like environment setup. Giving me a minimal Linux environment and filesystem feels like the most comfortable level of abstraction for me to develop well and also deploy and run in production effectively. I can also run that on demand or (most commonly) run that as a server that sits and waits for requests.

Post reply on HN