[kemitche]

I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact.

Monoliths are simpler to understand, easier to run, and harder to break - up until you have so many people working on them that it becomes difficult for a team to get their work done. At that point, start splitting off "fiefdoms" that let each team move more quickly again.

[ManuelKiessling]

This 100%. Still depends on the specific context (e.g. what type of software are you going to build and run), but for a typical case, like web-based transactional self-service business platforms, this is where I arrived after more than 25 years in the industry.

[taylodl]

I'm also an advocate of Conway's Law:

https://en.wikipedia.org/wiki/Conway%27s_law

Operationally speaking, it yields solutions aligned with your organization and thus are easier to support.

Plus, I see microservices as a premature optimization. Let it be shown the additional complexity is warranted and provides value.

[claytongulick]

Yep. Conway's law [1]:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

[1] https://en.wikipedia.org/wiki/Conway%27s_law

[Rhapso]

You can run it backwards! Get a high level software design, then make the org-chart.

[forrestthewoods]

Yup. You ship your org structure.

[mxscho]

This is also my experience. It's always that projects grow large in terms of people working on them and that is when you want to create independence between teams by reducing the amount of cooperation needed on a very defined boundary/interface between them.

Usually you start small and grow bigger, so there is only rare exceptions where it makes sense to merge microservices back into a monolith, except maybe for cases where going for a microservice architecture was a bad decision taken without actually having the above mentioned problem.

[ActionHank]

Kind of side steps the fundamental scaling issue though.

In a banking app there will be more requests for the account balance than there are logins, but logins will likely take longer.

Your argument is more around who is allowed to touch which and who is responsible when it breaks, but not around one of the core reasons to choose microservices.

[trjordan]

If you don't want to scale the whole thing (why?), you can also deploy the monolith twice and route different API calls to different clusters. Slice and scale as much as you're willing, paying the price of deployment complexity and bin-packing the usage.

[nprateem]

You scale the whole thing. There's no issue at all.

[bcrosby95]

Can you be more specific? Because if you mean scale... meh.

For the most part, scaling a system is fungible across features. In particular, in a monolithic system, if I had to add another server due to logins, I just add another server. A side benefit is if logins are down but account balance checks are up, that extra server can pull that duty too. I don't need to say "these computing resources are only for this feature."

Isolating failures is way more important.

[outworlder]

Microservices are indeed the best approach if you want to ship your org chart. That's all there is to it. Most of the technical justifications do not make sense, outside of very niche org requirements which aren't really all that common.

Take, for example, the idea that you can scale individual services independently. Sounds amazing on paper. However, you can also deploy multiple copies of your monolith and scale them, at a much lower cost even, and at a far lower complexity. In a cloud provider, bake an image, setup an ASG or equivalent, load balancer in front. Some rules for scaling up and down. You are basically done.

'Monolith' sounds really big and bad, but consider what's happening when people start using microservices. In this day and age, this probably means containers. Now you need a container orchestrator (like K8s) as you are likely spreading a myriad of services across multiple machines (and if you aren't, wth are you building microservices for). You'll then need specialized skills, a whole bunch of CNCF projects to go with it. Once you are not able to just make API calls everywhere 1 to 1, you'll start adding things like messaging queues and dedicated infrastructure for them.

If you are trying to do this properly, you'll probably want to have dedicated data stores for different services, so now you have a bunch of databases. You may also need coordination and consensus among some of your services. Logging and monitoring becomes much more complicated(and more costly with all those API invocations flying around) and you better have good tracing capabilities to even understand what's going on. Your resource requirements will skyrocket as every single copy of a service will likely want to reserve gigabytes of memory for itself. It's a heck of a lot of machinery to replicate what, in a monolith, would be a function call. Maybe a stack.

While doing all of that you need more headcount. If you had communication issues across teams, you have more teams and more people now, and they will be exacerbated. They will just not be about function calls and APIs anymore.

There's also the claim that you can deploy microservices independently of one another. Technically true, but what's that really buying you? You still need to make sure all those services play nice with one another, even if the API has not changed. Your test environments will have to reflect the correct versions of everything and that can become a chore by itself (easier to track a single build number). Those test environments tend to grow really large. You'll need CI/CD pipelines for all that stuff too.

Even security scanning and patching becomes more complicated. You probably did have issues coordinating between teams and that pushed you to go with microservices. Those issues are still there, now you need to convince everyone to patch their stuff(there's probably a lot of duplication between codebases now).

I think it makes sense to split the monolith into large 'services' (or domains) as it grows. Just not 'microservices'.

A funny quote I read a while ago on Twitter: "Microservices are a zero interest rate phenomenon". Bit of tongue in cheek but I think there's some truth to it.

[jrs235]

I agree with you.

It seems people think "Big Ball of Mud" when they hear Monolith but they're not equivalent. Jut like I tend to hear "Spaghetti Code" when I hear Microservices. But again they're not equivalents. Both architectures are equally capable of being messy.

[ghomem]

Agreed, in general.

But don't forget about the definition of micro :-) This is an optimization problem rather than a conceptual one.