Seen it done wrong so many times makes me wonder what it may look like if done right. What are your thoughts on "micro-services" and maybe specifically "AWS Lambdas"?

I'm not a backend developer but my previous job used it a lot and i never understood why;

They claimed costs, but the lambda communicates with a django application hosted on AWS.

They claimed it was more secure but the rest of the API was not built with security in mind

Modularity; but people complained finding the correct lambdas that they had to work on

Scalability; but the bottleneck was simply not scalable

Easier deployment; yes but it made deployment management a nightmare at that job

What i've heard during dailies, it looked flawed but backend devs loved it and yet complained a lot about it.

So i'm also interested what makes it appealing

Lambdas don't really make any sense. They're non-trivial to deploy, difficult to debug and just annoy the hell out of me, and yet they're required to do AWS things like autoscaling. I had to write some to scale up/down Jenkins worker instances at an old job.

Microservices are their own beast. The better shops I've worked at only had a few services (<12 for our core team) and you'd work on a different one every few sprints to lean the entire domain. I'm currently at a shop where they build tiny handlers and microservices for everything. Our manager tried to get one guy to built out 10 microservices. We finally convinced him to let the guy do it in one Monolith "for now" that we can "split apart later."

There's a bad "skeleton" anti-pattern I've wanted to write about; tons of empty directories and TODOs and very small modules. I did write a post about five years ago on Microservices and biological systems:

https://battlepenguin.com/tech/...

I've seen microservices many times.

I've seen microservices done right only one time in my life. It was a startup, that was supposed to compete with tiktok when there was talk about banning them. Apparently unicorn company. They hired me for one week cause they had issue that they couldnt solve and I had enough expirience with something that somehow they reached through friend of friend of friend of friend of friend to me. But I got good time to scout around their repos. Everything in nodejs split quite neatly into microservices. Over 200 of them.

Long story short, in the few situations like that one, when done right, they give you more scalability and much more complexity.

Otherwise, my hot take is...

When not done right (I would say solid 90%+ of occurences), its main purpose is so that managers / higher-ups have something to jerk off to. Buzzword.

Micro Services can be done right, but not with lambdas. And the only way microservices end up working well if they are separated by strict domains and there's not a lot of them. In any project you're unlikely to need more than 2-3 microservices. If you go beyond that there's a good chance your domains are split too small and the communication overhead will kill all the benefits.

And lambdas are by design too small to do this. They are just functions in a cloud and that's just hell. It's literal hell. Imposible to debug, track or test. Especially once you start handling communication via queues, dynamo updates and event triggers.

It sounds nice on paper, and it might work for very basic projects, but maaan, it doesn't scale at all. I mean it scales performance-wise but not maintenance wise

The problem with lambdas is that they require competent DevOps. And that's hard to find nowadays.

When done right (repos integrated with CDK and SAM), good cloud watch management and correct test events, they are basically no different from working on pretty much any other repo and running shit locally.

And yeah, snap scalability is their main use case.

No matter if you have a load balancer with autoscaling, unless you can predict spikes in traffic, by having more baseline nodes (and paying for them when idle), by the time more are spun up you already crashed that spike. Lambdas have cold boot time of around 1.5 seconds, and you pay for exactly the time they run,making them great for those situations.

So, long story short. Great for their intended use case. Terrible when abused for the buzzword like with so many other aws products.

(And it doesn't help that aws "expert-"... Salesmen lure you into overcomplicated setups for really simple use cases)