I can deal with lambdas if every lambda has the entire application inside.

That's a little extreme.

Maybe instead you could probe at interview time whether they are happy with their microservices, how many do they have, do they feel happy that the service boundaries they finished up with are the best possible etc.

Not all microservice setups are shit shows.

Plenty of monoliths are.

> Maybe instead you could probe at interview time whether they are happy with their microservices

There is no way anyone tells you in interview that the codebase is crappy or that they are unhappy with.

You’ll always be told « well, like everywhere, we have legacy, but we learnt for it and now every new project is in [put REST + shiny front tech here] and we are happy with it. We migrate step by step ».

And then you’ll realize that the codebase they called legacy is what makes the company’s money, it’s not that bad compared to new project and is a pain to maintain because nobody works on it anymore except for urgent bug solving.

So, they’ll probably tell you that « they are happy with their microservices » (or quite happy) because they already try to fool themselves about it.

This is so accurate it hurts. No interviewer is ever going to say "dude, our codebase is terrible. The CTO wrote most of the core logic 9 years ago and everybody is afraid to touch it, so we just paper over it with increasingly complex interfaces and abstractions. There are like 25 different ways of doing everything, because every 6 months a dev comes in and thinks we should use their favorite new design pattern everywhere, but then gives up halfway through implementing it. Everything is either massively over engineered or complete spaghetti."

To be fair, I have had that conversation in a couple of interviews but then I'm usually coming in as a contractor to patch up these kind of things.

> Not all microservice setups are shit shows.

Yeah they are. One service per team, the thing that Amazon was originally doing that was the inspiration for all this, works, but you wouldn't call that "microservices" these days; the thing that people call "microservices" is always a shit show.

I've worked at one of those "one service per team" and, boy it was the suckiest most incredibly stupid thing ever.

I needed a place to store marketing and PR templates that were completely unrelated to the core of our product.

Of course the rule was "one service per team", so the CTO demanded that I store it together with our service, which is the part that performs customer authentication. Meaning, the part that is responsible for securing customer data and everything else. Whenever we had auditors checking it they're puzzled as to why there's marketing material storage inside the auth microservice.

This could have been the poster-child example of a good place do have a separate service, but no, the law was the law.

It's almost as if there's no such thing as a silver bullet.

So why was the team that did customer authentication responsible for marketing and PR templates?

Because "one thing per team" is equally as idiotic and bureaucratic as "one service per team". The company was technologically dysfunctional, not organisationally dysfunctional.

Why is it extreme? There are plenty of companies out there that don't do microservices. There's no need for me to work for one that does. Maybe I'll miss out on a job with an incredibly well architected microservice that I would love, but I'm perfectly content with missing that (rare) job.

I've found it incredibly hard or impossible to gauge the quality of a codebase during interviews. (Beyond immediate red flags like "oh, we don't write any tests or do code reviews" or whatever.) And to be honest, most codebases are bad, it's just a matter of degree. And I would almost always prefer working in a bad monolith than bad microservices.