[whstl]

Is it really for "fun"?

Or is it to satisfy the ideals of some CTO/VPE disconnected from the real world that wants architecture to be done a certain way?

I still remember doing systems design interviews a few years ago when microservices were in vogue, and my routine was probing if they were ok with a simpler monolith or if they wanted to go crazy on cloud-native, serverless and microservices shizzle.

It did backfire once on a cloud infrastructure company that had "microservices" plastered in their marketing, even though the people interviewing me actually hated it. They offered me an IC position (which I told them to fuck off), because they really hated how I did the exercise with microservices.

Before that, it almost backfired when I initially offered a monolith for a (unbeknownst to me) microservice-heavy company. Luckily I managed to read the room and pivot to microservice during the 1h systems design exercise.

EDIT: Point is, people in positions of power have very clear expectations/preferences of what they want, and it's not fun burning political capital to go against those preferences.

[Treegarden]

I dont quite follow. I understand mono vs micro services, and in the last 3 weeks I had to study for system design and do the interviews to get offers. Its a tradeoff, and the system design interview is meant to see if one understands how systems can scale to hypothetical (maybe unrealistic) high loads. In this context the only reason for a microservice is independent scaling and with that also fault tolerance if an unimportant service goes down. But its really the independent scaling. One would clearly say that a monolith is good for the start because it offer simplicity or low complexity but it doesn't scale well to the hypothetical of mega scale.

[pjc50]

In practice, it seems not to be a tradeoff but an ideology. Largely because you can't measure the counter-factual of building the app the other way.

It's been a long time since I've done "normal" web development, but I've done a number of high-performance or high-reliability non-web applications, and I think people really underestimate vertical scaling. Even back in the early 2000s when it was slightly hard to get a machine with 128GB of RAM to run some chip design software, doing so was much easier than trying to design a distributed system to handle the problem.

(we had a distributed system of ccache/distcc to handle building the thing instead)

Do people have a good example of microservices they can point us to the source of? By definition it's not one of those things that makes much sense with toy-sized examples. Things like Amazon and Twitter have "micro" services that are very much not micro.

[Treegarden]

I dont disagree, but you can horizontally scale a monolith too, no? So scaling vert vs horiz is independent of microservices, its just that separating services allows you to be precise with your scaling. Ie you can scale up a compute heavy micorservice by 100x, the upload service by 10x but keep the user service at low scale. I agree that one can vert scale, why not. And I also agree that there are probably big microservices. At my last workplace, we also had people very bullish on microservices but for bad reasons and it didn't make sense, ie ideology.

[whiskey-one]

Can you elaborate on the fault tolerance advantage of micro services?

For context, my current project is a monolith web app with services being part of the monolith and called with try/catch. I can understand perhaps faster, independent, less risky recovery in the micro services case but don’t quite understand the fault tolerance gain.

[Treegarden]

Im no world leading expert but as far as I understand, coupled with events, if an unimportant service goes offline for 5 min (due to some crash, ie "fault"), its possible to have a graceful degradation, meaning the rest of the system still works, maybe with reduced ability. With events, other systems simply stop receiving events from the dead service. I agree you can achieve a lot of this also in a monolith with try catch and error handling, but I guess there is an inherent decoupling in having different services run on separate nodes.

[whstl]

The point is that it doesn't matter which is better or worse for the case, or if you know the pros/cons of each:

In those interviews (and in real work too) people still want you skewing towards certain answers. They wanna see you draw their pet architecture.

And it's the same thing in the workplace.

[Treegarden]

I fully agree on workplace politics, but for system design interviews, are you not also just supposed to ask your interviewer, ie give them your premises and if they like your conclusions? I also understand that some companies and their interviews are weird, but thats okay too, no? You just reject them and move on.

[whstl]

If there's a big enough bias, the questions become entirely about finding that bias. And on 90% of cases the systems design questions are about something they designed in-house, and they often don't have a lot of experience as well.

Also: if there's limited knowledge on the interviewer side, an incorrect answer to a question might throw off a more experienced candidate.

It's no big deal but it becomes more about reading the room and knowing the company/interviewers than being honest in what you would do. People don't want to hear that their pet solution is not the best. Of course you still need to know the tech and explain it all.

[LandR]

I worked for a company once where the CEO said I need to start using Kubernetes. Why? We didn't really have any pressing use cases / issues that were shouting out for Kubernetes at all.

His reasoning was all the big players use it, so we should be too...

It was literally a solution looking for a problem. Which is completely arse backwards.

[whstl]

I had the same situation happening with Cloud Native.

EC2 was forbidden, it had to be ECS or EKS if Lambda was not possible.

We did the math and the AWS bill had the cost of about 15 developers.