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

161–170 of 272 posts

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

#161

Post by lifty »

brap wrote: post #141
jjice wrote: post #100

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…

Don’t all “serverless” platforms accept docker images? I know Cloud Run does. If I understand correctly your concern is mostly with “serverless functions” which abstracts away even more.

Cloud Run is more akin to AWS ECS (on Fargate), which also uses containers.

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

#162

Post by dalberto »

mattmanser wrote: post #140
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 develope…

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

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

#163

Post by whstl »

ecshafer wrote: post #98
usui wrote: post #95

Earlier quoted context omitted.

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

It doesn't even have to be in companies that big. The AWS salespeople took the CTO and a couple of directors of engineering for diner in a fancy restaurant. That was in a fintech that had around 200 employees. AWS also paid for the mandatory marketing... sorry, mandatory training sessions we tech managers had to do.

This is how much it takes for a CTO to demand the next week that "everything should be done with AWS cloud-native stuff if possible".

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

#164

Post by ThinkBeat »

As a soon to be graybeard think this has been fairly obvious from the start. And outside of specific workflows, you are adding unneeded complexity to a system that does not need it. In general, an anti-pattern. but it does have valid use in some cases.

On the last project I worked on that came to involve serverless, it made no sense at all other than it was "the fad".

For this system we had an excellent knowledge of what the theoretical limit of users and connections as.

This apparently needed to be done container, serverless, kafka, blah blah.

Annoyed with the whole thing I took a few nights to tear logic out from the micro servers or nano services, and wrapped the whole thing into a Frankenstein monolith.

AT least 60% of the code all had to do with dealing solely with the code needed to pass information around to different services so it was easier to maintain. Well my hacked together moonlight was not a great start for anything but a demo.

I installed Postgres on my laptop, ran the monolith on it, took 3 servers each pushing the theoretical maximum load we would have, and what do you know the performance was fine. But the architecture was the architecture decided upon.

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

#165

Post by aeldidi »

mattmanser wrote: post #140
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 develope…

It has downsides and risks involved, for sure. I think the security part is perhaps a bit overblown, though. In any environment, the developers either care about staying on top of security or they don't. In my experience, a dev team that skips proper security diligence when using Docker likely wouldn't handle it well outside of Docker either. The number of boxes out there running some old version of Debian that hasn't been patched in the last decade is probably higher than any of us would like.

Although I'm sure many people just do it because they believe (falsely) that it's a silver bullet, I definitely wouldn't call it part of a "tooling fetish". I think it's a reasonable choice much more often than the microservice architecture is.

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

#166

Post by aeldidi »

daitangio wrote: post #137
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

That's really interesting, I might actually use that for mine too. Thanks for sharing.

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

#167

Post by themafia »

reactordev wrote: post #145
akdev1l wrote: post #87

Earlier quoted context omitted.

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…

Uploads to an S3 bucket can trigger a lambda… don’t complicate things. The upload trigger can tell the system about the upload and the client can continue on their day. Uploader on the client uses presigned url. S3 triggers lambda. Lambda function takes file path and tells background workers about it either via queue, mq, rest, gRPC, or doing the lift in workflow etl functions. Easy peasy. /s

> Easy peasy. /s

It actually is though. I don't need to build a custom upload client, I don't need to manage restart behavior, I get automatic restarts if any of the background workers fail, I have a dead letter queue built in to catch unusual failures, I can tie it all together with a common API that's a first class component of the system.

Working in the cloud forces you to address the hard problems first. If you actually take the time to do this everything else becomes _absurdly_ easy.

I want to write programs. I don't want to manage failures and fix bad data in the DB directly. I personally love the cloud and this separation of concerns.

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

#168

Post by sunrunner »

bunderbunder wrote: post #154
sunrunner wrote: post #148

Earlier quoted context omitted.

> but management overrules them for some vague hand-wavy reason like, "This way is more modern." This matches my experience. It's very difficult to argue against costly and/or inappropriate technical decisions in environments where the 'Senior Tech Leadership' team are just not that technical but believe they are, and so are influenced by every current industry trend masquerading as either 'scalable', 'modern' or (wo…

What's even more dangerous is when senior tech leadership used to be technical but haven't actually got their hands dirty in 5 or 10 years, and don't realize that this means they aren't actually holding all the cards when they try to dictate these kinds of tactical, detail-oriented technical decisions. I see this a lot in startups that grew big before they had a chance to grow up.

> used to be technical

And to add, this rarely indicates anything about the depth and/or breadth of the 'used to' experience.

A lot of the strongest individual contributors I see want to stay in that track and use that experience to make positive and sensible change, while the ones that move into the management tracks don't always have such motivations. There's no gatekeeping intended here, just an observation that the ones that are intrinsically motivated by the detailed technical work naturally build that knowledge base through time spent hands-on in those areas and are best able to make more impactful systemic decisions.

People in senior tech leadership also are not often exposed to the direct results of their decisions too (if they even stay in the company for long enough to see the outcome of longer-term decisions, which itself is rare).

While it's not impossible to find the folk that do have breadth of experience and depth of knowledge but are comfortable and want to be in higher-level decision making places, it's frustratingly rare. And in a lot of cases, the really good ones that speak truth to power end up in situations where 'Their last day was yesterday, we wish them all the best in their future career endeavours.' It's hardly surprising that it's a game that the most capable technical folks just don't want to play, even if they're the ones that should be playing it.

This all could just be anecdata from a dysfunctional org, of course...

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

#169

Post by thunderfork »

leptons wrote: post #144
jjice wrote: post #100

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…

I've been doing AWS Lambda since it started up over 10 years ago. It solves a lot of problems for me. I don't ever have to worry about load balancing or scaling. I don't have to maintain a server. When it isn't being used, I am not paying for it. I've been running a pretty sophisticated project on Lambda for years, and I pay about $0.00/month for it. Most of the ~$0.45/mo I pay to AWS is in S3. Lambda code is extreme…

[dead]

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

#170

Post by Dylan16807 »

stuartjohnson12 wrote: post #155
reactordev wrote: post #145

Earlier quoted context omitted.

Uploads to an S3 bucket can trigger a lambda… don’t complicate things. The upload trigger can tell the system about the upload and the client can continue on their day. Uploader on the client uses presigned url. S3 triggers lambda. Lambda function takes file path and tells background workers about it either via queue, mq, rest, gRPC, or doing the lift in workflow etl functions. Easy peasy. /s

> Uploads to an S3 bucket can trigger a lambda… don’t complicate things. I read this and was getting ready to angrily start beating my keyboard. The best satire is hard to detect.

I don't really get the joke. S3 triggering a lambda doesn't sound meaningfully more complicated than using a lambda by itself. What am I missing?
Post reply on HN