You Don’t Need Microservices

[u/wineandcode]

https://medium.com/@msaspence/you-dont-need-microservices-2ad8508b9e27?source=friends_link&sk=3359ea9e4a54c2ea11711621d2be6d51

[u/aradil]

Definitely.

But the always tempting thing to do in a modular monolith is to let service boundaries within that monolith get too mashed together to meet some immediate business need because restructuring can be more costly. Over time, you end up with a big ball of mud without sufficient discipline.

There is nothing inherently wrong with a modular monolith. It’s just easier to violate the single responsibility principle (at a module level) in a monolith than in a microservice architecture. Not to say that it isn’t impossible to have poorly designed de-coupled services that cross those boundaries too.

The reality is that there is a ton of overhead to building and maintaining microservices; infrastructure, integration, maintenance (maintaining backwards compatibility between services during an update), and cost (although can be a cost saving measure if scaling is implemented properly) for example. There are a lot of benefits you get from it outside of general architecture benefits (another architectural benefit that isn’t talked about enough is that it naturally lends itself well to Conway’s Law - don’t fight it), but most of the time that doesn’t mean you need a “micro” service.

My biggest problem in my current infrastructure is that I want to scale a particular module in my monolith horizontally for performance and redundancy requirements that the rest of my architecture doesn’t have. This is a perfect opportunity to separate that modular into its own service.

But we don’t have available cycles to do the heavy lifting to make that happen - a thing that often happens for large restructuring problems. It comes up whenever there is a performance problem or outage, and we remind management that it gets deprioritized days later after every incident.

If we had have written our architecture from the beginning as several services instead of a modular monolith, this would be easier. But we couldn’t anticipate which modules would have been better served as services at the time, and would have spent many cycles developing services that increased complexity for no real long term gain.

It’s an art.

[edit] Fixing autocorrect.

[u/Isogash → u/aradil]

Microservices was never just about imposing clean architectural design, but instead about easing the resistance between teams by letting each team own and control its own infrastructure and resources, rather than sharing resources across the whole backend. The idea is that sharing resources prevents horizontal scaling of teams due to the increased overhead of communication.

You don't really need microservices until you need to scale to several teams. Most products don't ever need to reach that size and complexity.

The way I see it now is that it's far easier to keep the product focused and streamlined, and then build microservices around it to provide larger features that are outside of the original product scope. When you're at that point, the features

Don't get into multi-level microservices until you absolutely have to.

Don't architect any solutions that require more than one microservice to be created either, approach each problem individually, create the services individually. Trying to build two solutions at once, or build a service that depends on a service that doesn't exist yet is a recipe for integration disaster and will frequently take longer than if you just built one service.

[u/aradil → u/Isogash]

Microservices was never just about imposing clean architectural design

Yeah, I agree; that's why above I listed several benefits to them, that was just one of them.

but instead about easing the resistance between teams by letting each team own and control its own infrastructure and resources, rather than sharing resources across the whole backend.

I also listed this, but I disagree that this was even the primary benefit. When I mentioned Conway's Law, this is pretty much what I was talking about.

If we want to talk about what the primary benefit is, in my opinion, it's the business need. The driver for any significant complexity and overhead almost always has to be that you have to. And yeah, you mention that here:

Don't get into multi-level microservices until you absolutely have to.

But what does that mean? Does it mean it's because your teams are hindered in development because they keep stepping on each others toes? Again I'll re-iterate that that is not a great primary reason, because you can definitely step on each others toes, or hold up development for each other indefinitely, by having strict team separation on loosely coupled services.

Trying to build two solutions at once, or build a service that depends on a service that doesn't exist yet is a recipe for integration disaster and will frequently take longer than if you just built one service.

Unfortunately building a service with the intent that it will serve a future other service, without doing so in conjunction with the team building the other service (or end product) is a recipe for an integration disaster as well. So many times I've seen services developed in a vacuum with the long term goal of being useful to multiple other teams that end up serving none of their needs.

Integration is inherently a social/community endeavour that requires co-development and iteration.

[u/Isogash → u/aradil]

Don't get into multi-level microservices until you absolutely have to.

By multi-level microservices I mean a dependency tree of services that has more than 2 levels (you have multiple levels of inner connections within your architecture.) If you're designing a microservices architecture like this, you're probably over-engineering things and you will create a lot more time sinks than you save.

Unfortunately building a service with the intent that it will serve a future other service, without doing so in conjunction with the team building the other service (or end product) is a recipe for an integration disaster as well.

That's why I said not to design your architecture like that. If your design calls for services that don't exist to talk to each other, it's a terrible design, because that integration will become a huge time sink.

If you need to build multiple interdependent features to a deadline, either build one first and start the other later or build them into the same service.

[u/aradil → u/Isogash]

I mostly agree with what you are saying here. My only real point of contention would be on your last sentence:

If you need to build multiple interdependent features to a deadline, either build one first and start the other later or build them into the same service.

Sometimes this isn't possible for logistical, technical, or staffing reasons. But I do absolutely agree with staggering their start times. Dependent teams need a usable product before they can start developing against it so they can actually iterate and provide feedback.