Hacker News Reader

Comment by giovapanasiti | Hacker News Reader

This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years

View on HN

Different sections of an app can use different databases, if the bottleneck is in the database.

Different routes can be served by different servers, if the bottleneck is in CPU usage.

Different async tasks can run on different task runner services, if the problem is tasks competing with each other.

Different test suites can run for different sections of the app, if the problem is with tests taking too long to run.

Github and others even allow specific subfolders to be "owned" by different teams.

What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.

I think the point is that all of that adds complexity that is often unnecessary - a premature optimization if you will. It's like a hammer, and everything looks like a nail to a lot of people.

GP isn’t oppositional, they listed runtime constructs that all run off a single monolith. The point being you don’t need so-called microservices for flexibility in the production environment.

As the sibling poster said, you probably misunderstood my point.

I'm talking about how monoliths can also fix such problems when they happen.

Old incompatible library versions; dependency hell, security SLAs. Old company couldn't get off of Rails 3 for a multitude of reasons and splitting off microservices was a good decision. Syncing state across the services turned into its own barrel of monkeys, but was better overall.

Some might, but I imagine some have left the company when the pain is really felt and are excited to do it all again at the next company.

They're the people with guitar websites and say how "awesome" they are.

In truth, they're superficial technology terrorists.

Guitar websites?

Rock-and-roll/metal band content congratulating themselves. They're "so cool".

I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.

Ive regretted 99% of the services Ive built in AWS lambda over the years. Everytime it gets more complex than a couple hundred lines of code over a few lambas I start to think “if this were just one service, development, deployments, cicd, testing, storage would all be simpler”.

My deployments to Lambda are extremely simple. All I do is hit save in VSCode and the Lambda is updated. Change the env to prod and it deploys instantly to prod.

There's tools that make it easy, I'm still using a tool I built 10 years ago. Very little has changed except the addition of layers, which are also pretty easy and automatically handled in my dev tool.

All the Lambdas I write also run locally, and testing isn't an issue.

The only gripe I have with Lambda is when they deprecate older nodejs versions, and I am forced to update some of my Lambdas to run on current nodejs, which then leads to refactoring due to node module incompatibilities in some specific situations. But those are really nodejs problems and not so much Lambda problems, and it does get me to keep my apps updated.

YMMV.

I inherited a Lambda application at one job - when I started it was probably 200+ Lambdas and it got to 128 Lambdas. Lots of message queues, lots of Lambdas subscribed to queues where they ignored 99% of incoming messages... quite a mess. The Lambdas that are gone got repackaged into a SpringBoot application which thoroughly simplified things.

Reply on news.ycombinator.com