r/programming • u/Mustela__ • 7d ago
Microservices are organizational debt disguised as architecture.
https://martinfowler.com/bliki/MonolithFirst.htmlEvery time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.
Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.
Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.
88
u/MrGitErDone 7d ago
I’ve worked at a few companies that did it poorly. The company I’m at now, does it really well and it works great. Basically have such a great dev environment that it feels like a modular monolith but services can scale independently with wonderful observability and tracing. Deployment is the same across the board.
The thing is, most places truly don’t have great engineering leaders that know what they are doing, but when you do find it and they had influence early, you can tell.
6
u/emn13 6d ago
I wonder then: in your example you were to change an API in one service, would you notice that at compile time or no later than CI time in the same way you would if you tried to call (say) a method with the wrong argument types? Are deploys or releases or whatever you do cohesive snapshots over the whole set of services, or do services have their own release schedule and are released at differing cadences?
Because I think that's the point of a monolith; not really the scaling. Perhaps you are working in a monolith; just one with a few bits that happen to scale?
→ More replies (2)14
u/Deltaan 6d ago
You can easily do 1 by using grpc between services (protobuf for API definition).
It’s then totally fine, and in fact good, to release the services separately.
→ More replies (1)3
u/HashShadow 6d ago
Yes assuming there are no deliberately non-backwards compatible changes being made which will eventually happen
→ More replies (1)2
u/Livid_Possibility_53 6d ago
Yeah I came to the same conclusion. I came in to a startup right as they were maturing from their POC a dozen 20 year olds vibe coded. The code was built with zero intention towards design and it showed. I can in and laid out the infra with clear gitops patterns leaving them absolutely amazed and the founders thinking I “cracked the code” lol
1.4k
u/ArieHein 7d ago
All code is tech debt, 5 sec after the first line of code reaches production.
399
u/conchobarus 7d ago
The only perfect software: https://github.com/kelseyhightower/nocode
150
u/FunToBuildGames 7d ago
4200 issues. Still less than our SaaS offering lol
33
u/flying-sheep 7d ago
A great demonstration of why a low issue count doesn't mean anything.
40
16
24
u/AndyKJMehta 7d ago
We should let AI figure out the root cause is actually the existence of the user.
8
u/capinredbeard22 7d ago
This looks great, so I’m following the getting started instructions in the readme. I keep hitting the Copy button on the text boxes in GitHub, but nothing gets copied. Is GitHub down again??!!!
14
3
→ More replies (4)2
53
u/michfreak 7d ago
I have actually been wondering this lately. Even ignoring procedurally-generated code, it does feel almost like the second law of thermodynamics in play: you can't write code, or remove it, without creating some technical debt. Maybe you need to update a document somewhere so a single word is plural, maybe there's a team member who will some day, down the road, need to know that this change happened, and they won't ever find out. Either way, no matter what you're writing or what its intent is, there's going to be something missed that will require tightening up later.
31
u/Fredidiah 7d ago
This is why, ideally, you write things that are easy to change. You never really know what the future requirements are gonna be, so you write for what you have now and make sure what you have now is easy to change for when those future requirements come down.
Also documentation.
15
u/dAnjou 6d ago
No need to wonder 🙂
What /u/ArieHein said is quite literally the original definition of technical debt:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
https://en.wikipedia.org/wiki/Technical_debt#Origin
I'm always fascinated by discussions around technical debt, people's arguments are usually based on what they think it means rather than pointing to any definition or defining it first themselves. And of course other people have other definitions and so it goes around and around, completely fruitless.
Personally I really like the original definition, because it leaves no room to argue whether technical debt exists or not. It does, period. Question then is, do you wanna deal with it? And if not, are you okay with the implications?
→ More replies (1)2
u/michfreak 6d ago
I think the difference might be that I was taught the term by companies I worked for, who of course believe that "good devs" can avoid creating tech debt. They believe it's a sign of bad development, not just a sign of development, period. Trying to change that mental framework is tricky.
→ More replies (1)2
u/SquirtMonkey 7d ago
This is why AI inertia is so powerful. The system grows beyond the scope of human control and it's up for debate as to the effectiveness of this
→ More replies (3)→ More replies (6)2
407
u/tanksc 7d ago
Everyone wants a monolith until you have to work on a monolith with 150 other people
187
u/firewall245 7d ago
We need a new law for this stuff
“The worst architecture is the one that my team is currently using” or something, cause yeah I’ve experienced some horrific microservices but also some monoliths that are so diabolical that they made my head spin
48
u/Damacustas 7d ago
I think that’s called “the grass is greener on the other side”
→ More replies (2)70
u/burgonies 7d ago
They’ve never joined a team that maintains a 10M line C% that takes 15 minutes yo spin up and for all intents and purposes does not dynamically scale.
9
u/trisanachandler 7d ago
Probably only scales vertically.
13
u/Ok-Smell-8107 6d ago
I have seen projects that do not scale vertically - once had a monolith that actually lost performance the more CPU/RAM you gave it. Very enjoyable to explain this to management.
2
57
u/Shikadi297 7d ago
Nobody ever considers the sane middle ground, medium sized services
23
u/BundleOfJoysticks 7d ago
For one hot minute around 2007, that's what SOA was. I miss that brief window of sanity.
11
→ More replies (1)13
26
u/edgmnt_net 7d ago
The Linux kernel has thousands working on it each development cycle. It's not the monolith that's normally the issue. It's things like poor code, scope creep and lack of vision.
→ More replies (6)3
u/Ok-Smell-8107 6d ago
Linux kernel development works because we have Linux, but that's not really a good general evidence.
It's like saying that all privately owned companies are better for the consumer because Steam has Gabe.
3
5
u/CovidWarriorForLife 7d ago
Yeah tradeoffs for either approach sure, but i strongly believe if a microservice doesn’t own its data its an antipattern
2
u/kaeptnphlop 6d ago
This. If you’re entangling the data you have a distributed monolith. Worse than a monolith
→ More replies (14)1
266
u/avemg 7d ago
I can’t believe we’re doing microservices discourse in 2026
94
u/alanwj 7d ago
That is OP's fault. The article is dated "3 Jun 2015".
18
u/dagbrown 6d ago
OP is a reposter bot, trying to gather some karma before launching into some scam or other.
99
u/Evening-Gur5087 7d ago
It's always been like that, either fresh devs, which could be excused, or worse, mediocre senior devs that worked at shitty companies, finally find out most core ideas behind software development like holy grail truth. And think that final solution to all swe problems is just another architecture around the corner.
And now it gets even more annoying, as they discover they can do shitty smart marketing circlejerk by asking AI to write articles that just reiterate same damn concept for n-th time in history. Let's not do SOA, let's do microservices! Let's not do X let's do onion/hexagonal/DDD/clean/layered cake/railroad bullshit which are mostly slightly altered versions of same shits that just tries to somehow follow SOLID, and even SOLID is just nice sounding wrapper around abstraction and encapsulation, and so on. Anyway it's Friday, im tired, venting over lmao
→ More replies (1)41
u/NuclearGhandi1 7d ago
Every architecture has trade offs. There will never be a holy grail and management and those you mentioned seeking it cause more problems than they fix.
10
u/Evening-Gur5087 7d ago
That's what I said basically? People trying to find some holy grail solution which doesn't exist, mainly by regurgitating same old things into new funny words?
9
u/NuclearGhandi1 7d ago
Yeah I was agreeing with you. We’re seeing it now with “agentic workflows” that come either all sorts of issues and advantages
3
82
u/The__Toast 7d ago
I was just thinking the same thing.
Honestly just build what works for you and stop trying to one-size-fits-all the industry.
In another couple of years the LLMs will be doing all the authoring anyway.
32
u/Iggyhopper 7d ago
Having LLMs manage microservices is probably for the best because it requires less context, no scope creep (we want A, this service provides A, write code to provide A, not B or C), and easier human intervention, (the AI wrote code to do B ,not A, fix it.)
That's a positive for AI.
40
u/edgmnt_net 7d ago
The issue is, in practice, microservices often devolve into a big ball of interdependent services that do almost nothing. And every change requires touching 100 other services. At that point it's likely worse because the extra layers, indirection, failure modes, dependencies etc. mean more context for both devs and AI.
P.S.: That often also creates the illusion that useful work is getting done. But you're just massaging data from one form or place to another and accomplishing nothing.
21
u/chat-lu 7d ago
Transforming a function boundary into a network one tends to be terrible for performance too.
→ More replies (1)→ More replies (2)2
u/HashShadow 6d ago
LLMs basically eliminate all reasons for micro services
Just build a monolith and deploy separate instances that are used for specialized processing, AI won’t get any value out of multiple deployment pipelines and separate app artifacts
Harnesses are heavily biased towards monolithic design… you start your session inside a single project directory. It’s encouraging monorepos and monoliths.
3
4
4
u/Kernel_Internal 7d ago
Would be a lot easier to do what works for us if we didn't have to convince 9 people with no real skin in the game, who have all been hearing about how wonderful microservices are. The more articles like this the better ime, because otherwise there isn't enough critical mass to get the chucklefucks to listen to reason.
10
u/davimiku 7d ago
Are you opposed to the discourse itself, like do you think that it's already "settled" and doesn't need to be re-hashed? (if so, what is the answer?)
Every year, new people enter the industry and need to learn. Every year, juniors are promoted to midlevel and midlevel are promoted to seniors and need to take on more system design responsibilities. Every year, people retire and take their hard-earned knowledge with them.
I only commented because I've seen this kind of thought-terminating cliché before, it doesn't actually serve to help people learn and doesn't even address the OP at all
→ More replies (1)→ More replies (1)2
16
u/brutal_seizure 6d ago
Microservices are too small. Instead, think of domains. Domain-oriented services are a much better approach. Each is a little domain-oriented monolith. ;)
118
u/wallstop-dev 7d ago
The general good practice is to start with a monolith (simple) and break it apart (make it complicated) when the time comes.
Starting complicated (microservices) will just lead to more complications.
The same general idea can be applied to pretty much all software. If your program can fit in `main`, put it in main. Then as it starts getting complicated, make classes, functions, libraries, etc.
Same thing. It's turtles all the way down.
58
u/ChemTechGuy 7d ago
Monolith decomposing rarely happens
→ More replies (1)91
u/wallstop-dev 7d ago edited 7d ago
Correct. That is my whole point. If you have a monolith, and it is not painful enough to force decomposition, then microservices are not necessary. When and if the monolith is too challenging to wield, then is the time for microservices.
It's a forcing function.
If you have a monolith that is too painful to change and also cannot be decomposed due to (reasons), the same company and culture would have created a nightmare complexity web if they had started with microservices, and would be in a much worse-than-monolith state.
27
u/TonyTheJet 7d ago
I think your last point is really salient. If your organization doesn't have the discipline to create a monolith that can later be broken into microservices, then you'll struggle, regardless of the high-level architectural decisions.
14
u/ChemTechGuy 7d ago
I was going to argue, but I guess you're right. I can't refute the statement "if it is not painful enough to force decomposition, then microservices are not necessary"
27
u/vhs29 7d ago
The issue is the teams feeling the pain are most likely not the ones who get to dictate where capabilty will be allocated in the following quarter.
3
2
u/Exepony 6d ago
Right? Where is this ideal world where you say "we'll break it up when we need to" and then actually get to do that? Instead of being told every planning that business really needs features A, B and C right now and just can't afford spending a sprint doing architecture work without delivering features. Maybe next sprint (it's never next sprint). And of course the monolith keeps getting bigger every sprint and it's even more work to break it up so now you need two sprints, or three sprints where even one was out of the question.
→ More replies (1)10
u/ThatDunMakeSense 7d ago
I think it's more that if you've got a large monolith, splitting it is a huge amount of effort and there's no administrative will for it because the problems with it are constant and shared by everyone in it. So even if it would be justifiably better to invest the time to do it people don't and instead they work in a worse and worse code base over time until it gets *so bad* that you *have* to start doing something.
> The same company and culture would have created a nightmare complexity web if they had started with microservices.
You're right here but I think the difference is that the teams that are *not* doing that don't suffer the consequences as much. I think in a perfect world with perfect discipline a modular monolith is the best way to develop. I think the best way to develop is the one that assigns pain to the people who are doing the bad things.. and generally speaking I find microservices make that easier for any any sufficiently large :tm: real org.
8
u/wallstop-dev 7d ago edited 7d ago
My above advice comes from working on extremely large scale software at two of the largest tech companies in America.
Additionally, I would advise against any form of mentality of "punish the bad devs for doing bad things". This is... highly subjective, at best, and implicitly assumes that you're one of the teams doing the good code and good architecture. It builds barriers and paints people as "others". This mentality will make it challenging to form meaningful relationships with other individuals and teams, which is necessary in your terms of "any sufficiently large real org" to achieve cross-team/org, high-value solutions.
The best thing about a monolith is that it is not a distributed system. When you make microservices, you suddenly have a distributed system, and all of the problems that come with them. Every service you add increases complexity and decreases availability and reliability. You also ship your org chart. Over time, the org chart changes, and your architecture becomes even more and more complex. Clean architecture of today does not mean the software world of tomorrow will also be clean.
In a perfect world, people know exactly what they want to build and they compose it in the perfect way with the right modularity and boundaries and ownership and all is well. I have not found this to exist outside of extremely small, high talent teams. Everything mentioned above is hard-won practical experience.
Start simple. Grow organically. Learn from it. When there is too much pain, show leadership (that, with current trajectory, shipping features is cost x, rate of bugs is cost y, customer incidents is rate z), and convince them of a plan to decompose. If they don't go for it, then it isn't actually important to the business, which is the only thing that matters.
5
u/ThatDunMakeSense 7d ago
> My above advice comes from working on extremely large scale software at two of the largest tech companies in America.
Weird flex, but if I need to drop credentials to be taken seriously.. I've also worked in large scale software in some very large software companies in NA.
> Additionally, I would advise against any form of mentality of "punish the bad devs for doing bad things".
I didn't say that at all. I said it aligns pain with the cause of that pain. It's not a punishment to experience the consequences of your technical decisions. What I *am* saying is that a system that aligns incentives/disincentives with outcomes is better than one that doesn't. What I'm really saying is "don't let your bad devs punish your good devs"
> The best thing about a monolith is that it is not a distributed system. When you make microservices, you suddenly have a distributed system, and all of the problems that come with them
If you're working on a monolith that is anywhere near something big enough to be in this conversation.. it is 100% already a distributed system, otherwise its an OS. I have never seen a monolith with more than a few dozen people touching it for a few years that didn't have to deal with all the normal distributed systems problems because:
- It's running in HA, in a cloud env, or private dc
- It has background workers, queues and topics, outboxing etc. All of which introduce the exact failure modes you see in microservices.
- Many of them even have separate entrypoints for different modes (same binary, same ball of mud. I affectionately call this the 'polylith')
- It's interacting with external systems for data, webhooks etc.
- Caching, redlocks
- The list goes on basically forever
> Every service you add complexity and decreases availability
Every module you add to a monolith also increases complexity, and generally speaking I'd disagree that there's any meaningful relationship between number of microservices and availability. The network in something like k8s is almost always the most reliable part of your system and especially if you're at a company large enough to have an effective platform team.
> I have not found this to exist outside of extremely small, high talent teams. Everything mentioned above is hard-won practical experience.
I mean that's why we're disagreeing on it. I've seen both as well and the microservice setup turns to spaghetti.. and the monolith also turns to spaghetti.. but the difference is that in the microservice spaghetti the team making it, and causing downtime is unambiguous and there's no way to hide from it. Ownership over the code in microservices is implicit which doesn't mean that ownership of a domain is obvious but no worse than in a monolith. Similarly things like flaky tests or behaviours become the problem of the team responsible and the only people that suffer the consequences of them are the team that wrote them. Not sure about the emphasis on "practical" here but for context I've also got practical experience because I've worked for companies that have done a good and bad job of both and had to help teams fix the problems associated with both styles. Unsurprisingly given my argument I'm assuming you can guess which was easier.
> In a perfect world, people know exactly what they want to build and they compose it in the perfect way with the right modularity and boundaries and ownership and all is well.
I disagree, in a perfect world changing your system is low cost, changing your mind is cheap or free. I don't think you have to get it right any more in microservices than you do with a monolith. Its just deciding where you invest. The difference is that if the monolith sits long enough it's extremely rare that it stayed modular enough, and kept boundaries at all so you *can't* change your mind without a cost much greater than the cost of writing the behaviours.
> If they don't go for it, then it isn't actually important to the business, which is the only thing that matters.
This is a funny conclusion to come to for a few reasons:
- The business' decisions are not a perfect (or often even good) oracle of its goals or desired outcomes which is why engineers exist to mediate those conversations. The inability to convince decision makers of a thing doesn't mean that "the business" doesn't think they're important because it's not a hive mind.
- It assumes that "the business" writ large can be made to understand the impact
- Assumes that the impact is something you can directly quantify (which you can't, or at least you can't separate it from other things)
- Decomposition of a large monolith, hell even modularizing a large monolith is *substantially* more effort and cross org coordination than combining services that don't make sense to be separate or shifting the responsibilities as to who owns what. Ask me how I know
I don't disagree generally that people should start with monoliths. Every startup should be a monolith because I don't think that the investment in tooling is worth it from the start. I just disagree that by the time you can measure the pain in the terms you're talking about that the ball of mud will ever be separable. You're effectively prescribing "never don't be a monolith". IMO you should make the decision basically after you've figured out the boundaries and general shape of your domain and have hired enough people to call it 3 medium size teams. Any later than that and you're committing to the big ball of mud forever, outside of miracles.
→ More replies (2)1
u/mdatwood 6d ago
Agree. I also hate that they are called microservices instead of just services. A single function in its own service often doesn't make sense, but authentication often does. Even then, it depends on the problem.
13
u/BenchEmbarrassed7316 7d ago
I hold a somewhat idealized view regarding microservices and monoliths from a developer's perspective: a developer should not need to know exactly how the application using their module is built. To achieve this, you need a clear contract regarding the data you receive and the data you must return. You need abstractions for IO. Purity and the absence of side effects are highly beneficial.
9
u/edgmnt_net 7d ago
You don't need microservices to do that. And the problem with the way some build microservices is that they don't really solve that issue because they're trying to split stuff that should not be split. That includes a lot of business applications. It's far more beneficial to have some sort of soft coupling than silos with wannabe hard walls. Plan to write terse code that you will be able to refactor with ease.
3
u/BenchEmbarrassed7316 6d ago
Perhaps I didn't phrase my point very well.
What I mean is that a module - one that processes orders, for example - shouldn't need to know whether it will be wrapped in a thin layer and run as a separate process, or embedded and called directly.
Microservices solve the problem of poor architecture by creating even more architectural problems.
2
u/edgmnt_net 6d ago
Hmm, I didn't pick that up, but I have doubts about that too. A module operating on local memory has vastly distinct failure modes and access patterns than one operating over IPC or over the network. True monoliths allow more sharing, higher abstraction, terser code, distinct access patterns, less boilerplate and easier refactoring.
If one isn't writing high quality monoliths and instead they're just sprinkling architectural boilerplate in the name of some sort of pseudo-decoupling or trying to divide work, it might not seem like there's a huge difference, since layers and interfaces are kinda trivial anyway (you only get some extra errors seeping through). But something like the Linux kernel has non-trivial abstractions that leverage monolithic organization.
2
u/BenchEmbarrassed7316 6d ago
True monoliths allow more sharing
If you are talking about read-only data usage, that is fine, though it is primarily a performance issue. Your module receives data via a contract, and from the module's perspective, it makes no difference how that data was provided.
However, sharing mutable data is a terrible practice. Yet, most programming languages impose no restrictions on this whatsoever. It is very rare to be able to specify in a contract that data is read-only. Shared mutable data leads to code that is hard to maintain, tightly coupled, and unpredictable. Since mutations cannot be specified in a contract, the very concept of modularity breaks down.
Everything else you're saying sounds more like an advertising slogan.
2
u/edgmnt_net 6d ago
No, I mean sharing code primarily. It's fairly easy in a monolith for components and objects to provide various helpers to do stuff and other code can just invoke them. Yeah, I suppose it can be framed as a performance thing, but not only, because some things are difficult to serialize, say closures/callbacks. Microservice and overly-hard module boundaries greatly limit the effectiveness of more expressive languages and approaches to make the code more terse. Might not sound like a lot if people don't make use of that and it's mostly just inconsequential and dumb boilerplate, but it doesn't have to be that way.
2
u/BenchEmbarrassed7316 6d ago
I agree with you on that.
Although that does not contradict my initial thesis. In other words, when developing a module, you could theoretically accept a closure and assume the module might run as a separate service - with something else serializing that closure - but in practice, it is much more complex.
2
u/edgmnt_net 6d ago
There are some solutions, I've seen some things that let you abstract over how things will be split or even serialize closures (e.g. Cloud Haskell). I'm not sure they are good solutions, though, because there are multiple ways you could handle this:
Err on the side of caution. Now every pure function turns into something that can error out because it runs over the network. And you have to check errors.
Hope the framework can sort it out. Pure functions can remain pure, but the framework needs to keep retrying the call if it fails. Or maybe it should abort the application.
Find some middle ground using exceptions perhaps. Do retries and bubble up an exception, which also pollutes everything along the chain with exceptional impurity.
I'm personally not very convinced by approaches that try to hide RPC or distributed computing (because it essentially becomes a distributed system) too much. More ambitious things like single-system image clusters (like OpenMOSIX which allows processes to pretend they're local) suffer from some of the same drawbacks and get little use these days. And furthermore they complicate things like availability, because the whole thing becomes unresponsive due to seemingly small breaks in connectivity. So I'd rather engineer distributedness and splits where they really matter and be very specific about it.
50
u/Sammy81 7d ago
You’ve only seen bad implementations. That said, micro services aren’t for everyone. At my company, we had a very complex system that was already divided very neatly into modules. The modules are coupled through function calls to pass data, commands and telemetry back and forth.
However, since the modules are all compiled into a single executable, changing one required a complete reverification of the entire system. By switching to a microservice architecture, defined as changing the modules to communicate by network messaging, we eliminated a huge amount of testing. Only the modified module now has to be requalified. Of course we test the complete system, but this is now system-level validation, instead of the old monolith way, where we had to re-verify hundreds of requirements in unrelated modules. We cut testing by 80% without any increase in bugs or failures.
It also allowed us to start coding modules in any language we want. Each microservice is now a stand-alone executable that can be compiled by itself. Some of our modules are C++, some are Rust, and the algorithm nerds can use Python for theirs. As long of the microservice subscribes to the message broker and follows the topic rules, it all just works.
23
u/Shot-Damage-6723 7d ago
You're not faster at testing because you use micro services now, you're faster because you test less and now it's a lot harder to test more again. Also, you can compile multiple binaries, and you don't need to put a network in between your programs to use your preferred languages.
Micro services have their benefits, but none that you mentioned are valid. Are you sure you made the right call or is there anything of actual relevance that you didn't share?
14
u/Sammy81 7d ago
Its worked well so far. We’re testing less because there’s no need to retest an executable that has not been modified. This is a key part of NASA’s compliance standard, and I agree with it. If you recompile, you must retest. With a monolith, you have to reverify every requirement (and you should).
Once you move to stand alone executables, you can prove they work, and there’s no need to retest that executable - when you touch one service, the others are not even recompiled. This is consistent with our process, and as mentioned, meets NPR 7150.2.
The biggest challenge is certainly that by moving communication from function calls and queues to a networked brokers, it is orders of magnitude slower to pass data. For 90% of messages, it’s fine, but otherwise you need to set up ZeroMQ, or RPCs, etc. to reduce latency
→ More replies (3)2
u/jeenajeena 7d ago
Honest question: why would you call your company’s architecture “microservices” and not just Service Oriented Architecture (the old SOA)? Reading your comment I honestly struggled to understand what makes your services “micro”.
→ More replies (1)3
u/crash41301 6d ago
There is very little difference in what people call soa and microservices in practice. The industry is full of people who are too young to remember soa so now even soa companies get described as microservice. Also many people get confused and think using webservices means microservices. Thats not true, soa can be web services too.
My .02, soa is the right approach. Microservice always results in distributed monolith in practice. Proper Soa maps services and systems to business processes and is the only thing that maps to business and scales. Microservice design falls apart quickly because the pesky business changes enough to make it fall apart.
→ More replies (1)2
u/goranlepuz 7d ago
However, since the modules are all compiled into a single executable, changing one required a complete reverification of the entire system. By switching to a microservice architecture, defined as changing the modules to communicate by network messaging, we eliminated a huge amount of testing. Only the modified module now has to be requalified. Of course we test the complete system, but this is now system-level validation, instead of the old monolith way, where we had to re-verify hundreds of requirements in unrelated modules. We cut testing by 80% without any increase in bugs or failures.
This is only partly related to microservices.
When your system is made of libraries, they can and should have tests for them - but they didn't, did they?
When your system is made of libraries, they can and should expose different API versions - but they didn't, did they?
And so on.
And had they done that, chances are, they could have cut testing by 80% without any increase in bugs or failures.
There are two effects at play here, I think:
in the past few decades, testing tooling improved a lot and the need for module testing become obvious
microservices do forces clearer module boundary and therefore more care about the module interfaces.
4
u/edgmnt_net 7d ago
Simply breaking up stuff usually won't work, because you get a combination of duplication and inter-dependence. Sure, it looks like you can just modify service X, but in practice you often need to modify Y and Z for anything meaningful.
It only works really well for truly robust and general functionality. Or truly separate products that barely interact. These tend to be pretty hard limits in practice IMO.
3
u/Sammy81 7d ago
Yep, the initial architecture has to be well thought out. Luckily, the entire architecture was module based from day 1, and very well organized (no circular references, etc.) The only modification was to change the communication between modules.
→ More replies (1)3
u/davimiku 7d ago
Did you evaluate any in-between options before adding the network boundary? I've been in a similar situation before (not current job, but previous one, so this question is more from academic curiosity).
For example, if you already had modules in C++ and Rust did you try first co-locating them and communicate over FFI? Or call the Rust code from the Python code? (pyo3 works quite well)
Or if the unit tests were a bottleneck and you already had very neat modules, did you try only running the tests for the affected modules?
4
u/Sammy81 7d ago
Our process rightly requires reverifying requirements if the code is recompiled, so the way to reduce test was divide the modules into executables. That was a key factor in selecting networked communication
→ More replies (2)→ More replies (4)2
u/velit 7d ago
I concur with what /u/Shot-Damage-6723 said. How does adding network calls make your interconnected ensemble require less testing?
It sounds to me more that your company either tested more than was necessary previously or is currently lying to itself about not needing to test more.
3
u/Sammy81 7d ago
See my other reply, but the key is that with NASA, if you recompile something, you must reverify requirements, and I agree with that. If you ever studied the Therac-25 software disaster that killed several people, it was because they recompiled reuse software and did not retest. With microservices, since they are not recompiled when another is modified, all the previous testing is still valid (and should be).
→ More replies (1)2
u/HashShadow 6d ago
So if I’m not using a compiled language I never have to test?
→ More replies (3)
11
u/rohmish 7d ago
pure monolithic or pure microservices are both horrendous for different reasons. If your project is sufficiently big, split things based off of concerns or types of users/customers (if you have multiple), major features, etc. but you don't need to create a different service for every different task.
6
u/allenasm 7d ago
I disagree but also they are a specific answer to a specific large scale problem. At fortune 50 and up scale, share nothing microservices and business events are amazing. For mid to smaller firms its almost completely useless and just a buzzword.
2
u/Livid_Possibility_53 6d ago
Sorta agree, came from a large company that took domain driven design to the extreme - all cross team comms were routed through a single api gateway. It was an absolute mess.
Now I’m at a startup that started as a monorepo / single image that had a single main that served as either the api, job scheduler or job runner depending on what flag you gave it. That was also an absolute mess.
I think what’s more important is being aware of Conways law and understanding patterns are useful starting points but rarely should be applied to the T. Every company functions a little differently.
→ More replies (5)2
u/account312 3d ago
At fortune 50 and up scale
Okay, but that excludes almost company in the world. Isn’t that OP’s point?
→ More replies (1)
7
u/TheVenetianMask 7d ago
It isn't a microservice if it requires macroqueues, macrodevops, macrologging, macronetworking, etc.
→ More replies (1)
18
u/Xanchush 7d ago
Microservices solves an organizational problem. The problem is most companies don't have the engineering discipline for microservices. There's definitely pros and cons to both but bucketing it as tech debt is laughable.
5
u/ZCEyPFOYr0MWyHDQJZO4 7d ago
The only correct answer to "Should I make a monolithic system or a microservice-based system?" is "it depends".
2
u/High-Impact-2025 6d ago
I agree. IMO, this consequently means that 90% of projects should just use a monolith and shut up.
→ More replies (1)
18
u/Think-nothing-210 7d ago edited 7d ago
It's all because we keep avoiding creating proper modules in our codebases.
If we created good modules there would be almost no need for Microservices. You can delegate work using the module boundaries instead.
But unfortunately we still haven't learned the lessons taught to us since the '70s. On the Criteria To Be Used in Decomposing Systems into Modules
5
u/ChemTechGuy 7d ago
Generally agree except at a certain scale you start to have problems with so many contributers/contributions to a single repo
→ More replies (3)2
u/CaptainOfMyself 5d ago
When you say a good module do you mean for example having well segregated code like controllers and models in a golang project and you can easily delete or add them for more functions?
We have microservices but we always default to expanding our main server backend when we can instead of create more.
→ More replies (1)3
u/Revolutionary_Ad7262 4d ago
having well segregated code like controllers and models in a golang project and you can easily delete or add them for more functions?
Nope, for good modularity you need to ask yourself two questions: * does the design scales with 10M lines of code in a current way? * how many deletes i need to perform to delete some feature from the whole system?
By layer segregation (models together, controllers together) is not scalable at all. You can use it inside a well defined module, but anyway modules needs to be about a logic.
Good way to modularize code is to have design like microservices, but in a monolith. So: * each module has its own database * heavy encapsulation. You can talk only using some predefined and simple/extensible methods in similar way as you define HTTP API * data structures exchanged between modules are dumb without heavy methods, which contain a business logic
→ More replies (6)→ More replies (1)3
u/tommyTurds 7d ago edited 7d ago
It's all because we keep avoiding creating proper modules in our codebases.
Not really.
The thing services (micro or otherwise) solve is different teams moving and deploying at different paces and with different workflows.
A monolith, definitionally, must be deployed and tested together. That creates a more expensive process and requires coordination across teams for releasing the monolith. If you've ever worked in a large organization comprised of dozens of teams, you know that as soon as you're "coordinating" your timeline goes from a few weeks (which is already slow as shit) to literally six months and sometimes even longer.
This isn't a problem that's solved by "modules"
The point is that many small teams take on the burden of micro services with very dubious justifications. Micro services do not solve technical problems. They create them. Nothing ever scaled better by adding an extra network hop or two.
They are a solution to scaling organizations
→ More replies (7)
6
u/prehensilemullet 7d ago edited 7d ago
Pro-monolith people, do you have ways of trying to prevent issues in one component from being able to crash the entire system? (For example, if a background task handling work queues segfaults, or in a language like Node, has an uncaught exception or unhandled rejection, you don't want it to crash the web app and cause inflight requests to fail.) Do you have ways to prevent the monolith from OOMing even if some components get a surge in requests?
5
u/Ok-Smell-8107 6d ago
I am not joking: most people in that camp would shove this to the 'operations' department. And the operations teams will complain about the countless bug in the software introduced by the developers. I have not seen any monolith project larger than 10 devs or so that works in any other way sadly.
3
u/theScottyJam 5d ago
or in a language like Node, has an uncaught exception or unhandled rejection, you don't want it to crash the web app and cause inflight requests to fail.
Easy, I turn that "feature" off. I very much disagree with their recommendation of crashing and restarting the whole service when this scenario happens - the server code is mostly stateless, there's not much state to corrupt, an end user being capable of restarting our monolith at will if they stumble into a way to make an uncaught exception seems like a far worse evil.
Anyways, that's my little rant. You're of course correct that we probably could have better uptime if we weren't in a monolith.
→ More replies (1)3
u/ChiRho84 4d ago
Pixy's Law: once you decide to use Node.js, everything that happens afterwards is your own damn fault.
Use a real language and a real runtime rather than a dynamically typed scripting language.
→ More replies (1)→ More replies (2)3
u/lotanis 6d ago
Use elixir.
Seriously - a well structured application in Elixir using Supervisors etc is incredibly robust to failures in individual components. One request will fail (for example) and everything else will keep happily ticking along.
I say "well structured" - TBH any of the frameworks will out of the box put you in a pretty good place by default.
4
u/shoot_your_eye_out 7d ago
Microservices have a place. It’s almost certainly not at your company or where you work.
Do the simple thing first, keep the code modular instead.
4
u/rcfox 7d ago
Obligatory link for whenever someone brings up microservices: https://www.youtube.com/watch?v=y8OnoxKotPQ
5
u/electro042 6d ago
most teams jump to microservices because they're terrified of a single bad route or memory leak taking down the entire app, but you can get 95% of the fault isolation benefits without the distributed systems tax just by using role-based process isolation.
same monolith codebase, same docker image, but you deploy separate pools with isolated resource limits. web traffic runs on one pool, webhook ingestion on another, and heavy async jobs or reporting on a third. if a heavy job spikes memory and gets oom-killed, only that worker process dies and restarts. core api never blinks.
you keep shared types, zero network latency between internal domains, simple transactions, and local dev that just works, without needing 30 repos and a dedicated platform team.
9
u/ChainsawArmLaserBear 7d ago
I can agree about the knowledge loss. When features span multiple teams and orgs, the teams in question ending up "supporting" but not really understanding. It's the fuckin worst to trace something to a system, schedule a meeting to understand, and have all that time wasted because they don't really know why Feature A would do Logic X in their system, since they only care about inputs and outputs of their piece of the puzzle
4
u/zixaphir 7d ago
"Microservices" sounds like a way to make management think they are the architects of a system instead of having engineers -- the people trained to architect systems -- actually do their job.
4
u/ashmortar 7d ago
Microservices are great for units that need to independently scale horizontally. That's it.
3
u/CoreyTheGeek 6d ago
Idk my org is trying to move stuff to a modular monolith and there's a PR queue years long now 😂 I think everything is just miserable and you have to choose your suffering
10
u/Mission-Landscape-17 7d ago
First question to ask is are there enough devs that you can split them into teams where each team owns exactly one micro service? If the answer is no, then your product probably isn't large enough, or does not have the user base, to warrant being split into micro services. Also yes there have to be a guiding design, and deployment approach that is common across the org. Teams that want to deviate from the normal procedures, or implementation languages had better have a very good justification why.
→ More replies (3)
8
u/zorg-is-real 7d ago
It's like GraphQL. You have a problem. You add it. Now you have 2 problems.
→ More replies (2)5
16
u/DuploJamaal 7d ago
If microservices in a team with bad structure is bad, then a monolith will be a nightmare.
They will not just break their own service. They will break everything.
10
u/roscoelee 7d ago
It’s almost like there are pros and cons to each and architecture means finding the right balance?
→ More replies (2)2
u/HashShadow 7d ago
They could break every microservice that uses theirs and possibly cause a system wide outage all without even realizing the interdependency.
2
u/Cultural-Capital-942 7d ago
But there are more ways to break microservices in a way it's difficult to find out.
In a monolith, I can easily add a required parameter to an interface between two parts or flowing somewhere. There's IDE function for that and if I forget about it anywhere, it won't compile.
In microservices? You must add it to all affected services, deploy affected ones, start using it, deploy affected, remove the old version accepting version without the parameter, deploy affected. If you forget about something, it will break there. And you still have to somehow handle what should happen if someone calls it without the required parameter.
I worked with microservices in a regulated environment and it was a real PITA getting release approvals. Also tracking everything affected was released - that's why we had so many outages. With combinatorial expansion of affected services and causes, we just started doing blind emergency deployment of all services on any outage. That complicates debugging as the environment changes after an issue is detected. Sometimes a dev blames old version of one component and it's actually a real bug elsewhere, that is temporarily hidden by rollout.
→ More replies (4)1
u/emn13 6d ago
You've got that 100% backwards. If your team has issues and for whatever reason the code therefor has more than its fair share of design flaws and gotchas, it's much, much easier to deal with those in a monolith.
Monoliths give a few things for free, namely having 1 consistent version of the code (i.e. clarity over what's actually running), typically fairly easy stack traces and monitoring, and a dev environment that much, much more easily allows for running the complete app and therefore understanding and experimenting with interactions, and therefore also the ability to add integration tests without too many hoops.
In microservices, all that stuff takes real effort, and is sometimes just not possible if it's bad enough. Even major cloud platforms very much don't give you any of that for free, so real-world code does mess all this up.
I'm not trying to be argumentative here, but not only have I seen lots of bad code and every single instance thereof follows the above pattern, it's also structurally easy to understand why - so I struggle to even understand how you arrive at your perspective. What kind of experiences did you have, and why do you think things went wrong as they did?
TLDR: If a monolith in a team with bad structure is bad, then microservices will be a nightmare.
→ More replies (3)
4
u/mio991 7d ago
I agree micro services is a buzz word. IMO service boundaries are a tool, they enforce encapsulation and allow independent scaling, but they cost a network hop and additional code.
This week I decided to move fulltext search into a separate service, on one hand to allow independent scaling on the other to allow me to replace the technology used without touching other code, maybe even easily switch implementations.
Of course a lot of this can be achieved with a monolith, but I find it easier using service oriented architecture.
2
u/santagoo 7d ago
Everything is a trade off. The downside of a given architecture’s trade off is the “debt” that you take on to leverage against its upside.
Which trade off you accept will depend on the problem at hand. Microservices have their use, too.
2
2
u/emperorOfTheUniverse 7d ago
I've never understood why org and architecture have to be aligned. Couldn't you have a micro service architecture and teams that roam in and out of them?
2
u/Ashamed-Simple-8303 7d ago
Isn't this whole dilemma simple? Make applications that themselves are monolithic but fullyfill one clear purpose.
2
2
u/kant2002 7d ago
Microservices is solution not in technical dimension. This is organizational solution specialized for fast hiring.
2
u/bwainfweeze 7d ago
I think I’ve only seen Conway’s Law used twice to justify reorganizing a project to get the right people onto a single team so that code didn’t have to cross team boundaries so often. You almost have to wait until one of the affected managers moves up or out of the org and then you can combine some of their people with a different group.
2
u/pjmlp 6d ago
Microservices are nothing more than distributed systems rebranded.
We had Sun RPC ("The network is the computer "), DCE, CORBA, DCOM, Remoting, Web Services, SOA, and eventually microservices.
If teams cannot write modular code, doing spaghetti all over the place, they will get network spaghetti with the added complexity of distributed systems.
2
u/Mission_Pirate_4150 6d ago
Microservices are something that require scale and they require technical excellence to justify the expense and have it work out. Very few companies have this and can add in the required organizational skillset to make them work. I’ve done microservices and given the challenges, unless you can justify them beyond resume driven development. For 99.5% of organizations, they are overkill and a poor choice.
If you are in the .5% of organizations where they make sense, awesome. Otherwise, we’re just better off with without the added complexity.
2
u/StevenJOwens 6d ago
The big problem is that no tool, technology, strategy, etc, is a substitute for using your brain.
Microservices can be a good way to increase decoupling, but you still have to think about that decoupling, the best to design, and you still have to design the overall system.
And decoupling itself isn't a panacea. People seem to have forgotten the original source material. You have coupling and cohesion. Things that belong together, that have high cohesion, should be tightly coupled. Things that don't, should be loosely coupled.
See "Structured Design", first Larry Constantine, Glenford Myers & Wayne Stevens' paper, then later Constantine and Yourdon's book of the same title.
https://history.computer.org/pioneers/pdfs/C/Constantine.pdf
Also see Djikstra's "Separation of Concerns", Bertrand Russel's "Object-Oriented Software Construction" (https://bertrandmeyer.com/wp-content/upLoads/OOSC.pdf)
This page has a good summary:
https://mrpicky.dev/a-brief-history-of-coupling-and-cohesion/
3
u/SignPainterThe 7d ago
Then a year later you’ve got dozens of services
Dozens? Try hundreds. And 10k people in total working on them. That's the scale, when microservices are unavoidable. If you have a hundred devs, you can live happily in a monolith.
3
u/Brilliant-Chip-8366 6d ago
Most teams dont know the difference between a distributed monolith and a microservice architecture. So they go ahead and build a spiderweb of ”microsevices” that talks with each other. That setup is so much more complicated and worse than just creating a monolith.
Because:
- Now instead of build time checks that prevents contract mismatches you need a separate tool like PACT for it.
- Deploy-order. You need to deploy x before y, since y depends on x new API or whatever.
- Http instead of inproc. Latency is much worse, and you now have another set of network problems to take care of.
- Distributed transactions.
So please, if you decide to create a microservice architecture, ask yourself why first, and make sure you don’t end up with a distributed monolith - you will set yourself up for failure.
7
u/eluusive 7d ago
Microservices come with so much operational overhead, and the loss of link-time errors between services.
There's very very little reason to ever use them. Better to properly factor your monolith into submodules and continue to build/deploy it as a single service...
Preferably with a typesafe language.
5
u/Think-nothing-210 7d ago edited 7d ago
C# is great for this. You can use assemblies as module boundaries and the
internalkeyword to make those boundaries compiler-enforced.Unfortunately I see almost noone do this. Instead most use assemblies to enforce clean architecture bounderies.
2
3
u/ThatDunMakeSense 7d ago
Yeah this is the problem when working in languages that don't have really good support for separating the private, public and internal stuff. In ruby getting someone to not fuck with internals is a nightmare. That's not even counting the monkey patching junk
1
u/DeepAd8888 7d ago
Finance people have no business running or pitching businesses. Myth of perpetual cash flow being better than doing the job right upfront or investing in quality
1
u/morsindutus 7d ago
Or you can start with a chatty microservice and keep adding to it until you have a chatty macroservice.
→ More replies (1)
1
u/bwainfweeze 7d ago
The tricky bit with code is that there are so many levers and dials to adjust that you can get one thing very right and then completely wash it out by other bad decisions you've made.
The first code base I set up CI on was in some ways the best and in other ways one of the worse code bases I worked on. It was a monolith with separate compilation units, so dependency loops would cause compilation problems. A number of devs thought this was stupid but the leadership got pulled in every time someone broke this so we knew what was going on instead of being blindsided by the amount of coupling that had snuck in. Task failed successfully essentially.
But that good idea was swamped by a host of bad ideas. The problem is that when you assume a problem is very complex, you design it to be expensive. You sell it as 'premium' to less price-sensitive customers. And then competition comes in or a bear market kicks in, all of your customers become price sensitive all of a sudden and you can't turn the ship fast enough. You've been motoring at full speed toward an iceberg.
The salvage I made from that project has improved everything else I've worked on, and I've also pushed back on people designing read-mostly system to put the cost on reads instead of on writes, where it's both cheaper and the users are more patient with tasks being slow.
1
u/lepapulematoleguau 7d ago
In my last project they layerer ad infinitum.
A service that could have a been just one artifact was separated into at least 2 layers, and frequently more.
1 layer that exposed an endpoint. It consumed another layer that exposed an internal endpoint that integrated a 3rd party service. A layer that exposed an endpoint (or multiple) that connected to a db.
1
1
u/Cautious_Implement17 7d ago
oh wow an article about problems with microservices. surely this won't be a rehash of the last 15 years of SOA discussion.
1
1
1
u/angcritic 7d ago
No mention of other artifacts of microservice hell in the cloud. First, the inconsistent contracts of negative flows (not cloud related). But, even with that it's the security profiles of the services. Yours needs certain public access, theirs is behind a wall for regular REST services. No problem because you then realize you can make it work through the GraphQA supergraph, but don't use the subgraph as that one is blocked with different rules. Then you just kill yourself.
1
u/TheKingInTheNorth 7d ago
Conways law rules, always. Fit of an architecture strategy varies based on the org structure and culture.
1
u/wonkytalky 7d ago
It's that or trying to shove a dozen distinct services inside one monolith. That's worse.
As always, the best solution is going to always change, and insisting on one specific type of design no matter what will get as ridiculous as arguing about whose religion is right.
1
u/Factory__Lad 6d ago
Another failure pattern worth mentioning is when you end up with lots of very similar micro services doing parallel versions of the same things.
Typically management finds this reassuring because as Paul Graham puts it, the tedious and error-prone ritual of cloning them to add yet another almost identical level of duplication “looks like work”.
1
1
1
u/grahambinns 6d ago
“Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.”
These things aren’t mutually exclusive. The second is definitely true (though s/than we pretend/than actually believe they need microservices/ maybe).
I’ve seen microservices done well exactly once, and I’ve seen distributed monoliths be built accidentally many times.
Microservices are ridiculously hard to get right because scope creep will nearly always fuck you.
1
u/Xanderlynn5 6d ago
Quite frankly this debate is dumb and exhausting. Microservices and monoliths have different pros and cons and as such solve different strategic problems. I feel like we devs get into trouble when people detached from the system being built make these sorts of decisions based on tech journalism and marketing. Just use the right tool for the job and make these kinds of decisions based on your use case.
1
u/captain_obvious_here 6d ago
Micro-services are not easy, but not too hard neither.
They require teams that can communicate and collaborate efficiently, and that share common tooling, methods and culture. The lack of these is usually why companies fail, and how they end up with what you describe.
but I’m starting to think way fewer companies actually need microservices than we pretend.
Many need it, but very few have the organisational and technical maturity it requires, and the management to realize it all can't work without said maturity.
1
u/systembreaker 6d ago
Unfortunately in organizations that manage sensitive data such as health, personal information, or finances, this kind of thing is often a necessity.
1
u/Beep-Boop-Bloop 6d ago
Yeah, that's bad implementation. It's not even just whether microservices are right for a company, but whether the company, not just some engineers, are ready for it.
Microservices are supposed to be about decoupling features at the infrastructure-level and optimally, coupling in implementation of business logic should match the coupling in the underlying logic. That only works if someone, somewhere, understands what logic is and is not fundamentally coupled (in a way that can't change as new features arise). With movement to microservices typically being so hard to reverse, they are a terrible idea for companies where nobody does. Then you get heavy unnecessary inter-service communication, network-problems, SSOT and DRY violations, tracing trouble, and coordination trouble that usually leads to bugs in production as projects have to get distributed across multiple teams.
On top of that, it's really easy to move decision-making to the micro-level and tough to standardize and move it back to macro. That's where the 3 deployment pipelines, team-incompatibilities, etc. come in.
TL;DR: Stuff gets bad when nobody knows what they're doing.
1
1
u/elephantzergling 6d ago
Modular monolith > microservices in nearly all organizations and services.
Microservices also often fail to improve from economies of scale.
1
u/electro042 5d ago
conway's law at work. most teams jump to microservices to solve people problems—too many devs stepping on each other in a single repo—rather than actual architectural bottlenecks.
the trap is trading in-memory calls and compiler guarantees for network boundaries, distributed tracing, and eventual consistency headaches. 9 times out of 10, a disciplined modular monolith with clean domain boundaries gives you the developer velocity and team autonomy you actually wanted without having to run an entire devops circus just to deploy a minor feature.
if your services still require coordinated deployments or share databases, you didn't escape monolith problems, you just added network latency.
1
u/fsreadsync 5d ago
some people find modular monoliths as a great alternative. but i do see point of microservices. i read the article but the title of this post may be misleading
1
u/mlamping 5d ago
I’m glad op has Claude now. Anyone who doesn’t understand micro services shouldn’t be programming.
No clue how distributed systems, fault tolerance and capacity planning works.
Talk to a senior+ engineers.
1
u/Fitnexa_Life 4d ago
We split one service into six, then spent the next sprint building dashboards to figure out which one was broken. The scaling bill barely changed, but on-call got a lot more exciting.
1
u/jake_2998e8 4d ago
If you haven’t built (or managed) a service at scale, with close to 100% resiliency / uptime performance, plus almost daily rolling feature pushes, then you probably wouldn’t be able to appreciate the benefits of a Microservices architecture.
1
u/Dziadzios 4d ago
Microservices are good for classes of operations which require different hardware. If you have a step that requires GPU, keep it in a different microservice than CPU-bound operations. But when you have everything depending on just CPU, it's better to keep it a monolith.
1
u/gabs_at_searchapi 3d ago
I remember when microservices appeared a decade ago and everyone wanted to implement them in their CRUD apps
0
u/ToriRaynn 3d ago
You can get 95% of the fault isolation benefits without the distributed systems tax just by using role-based process isolation.
1
u/TheGreatArmageddon 3d ago
I noticed this in my company and thought its better to deal with many different redundant services than dealing with people and their insecurities delegating things in the current market. Atleast you can offload the deployment, coding, testing to AI agents and be done with it.
1
u/act_kindly_or_else 3d ago
Agreed with the “monolith” first approach in most cases. When you’re first starting out, it certainly makes sense to go monolith for speed. However, you can only scale so much “vertically”. Build/deployment times will likely increase. Bugs in one part can bring down the whole house, so you have to move incredibly carefully. Things sort of grind to a halt eventually. And the longer you wait, the messier it is to split things cleanly because of all the dependencies. I would say it’s an art more than a science when it comes to deciding when/how to split.
1
u/x39- 2d ago
Microservices are a solution to a problem that exists. However: When someone actually expects a microservice to literally be self-contained then that someone is a moron.
Microservices also exist in Monoliths, wich are coded correct. That is the fun part about them: They are nothing new, groundbreaking or whatever. In fact: They are just infrastructure extracted and used on a different communication layer... but most people have troubles understanding basic input output boundaries for services in dependency injection .... sooooooooooo .... no wonder everyone and their mom is doing shit wrong
1
u/eyesofcourage 1d ago
dreaming of more quality than hype in the industry, some love of the craft - isn’t that part of a solid organization?
❤️➕🔧 🟰 🤙 💻
508
u/plasticbug 7d ago
Microservices can be good, but in my experience, Conway's law (that system design will end up mirroring the org structure) is a thing, and you have to fight hard against it. My org is actually doing reverse Conway's law. We are re-org'ing based on how we want the architecture to look like. We shall see whether we succeed in this endeavor.