This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.
Yes, and then they start complaining that the shared domain objects are not kept up to date by team $notMine, and so they inevitably go to a shared library where they fall back into the same issues.
Is that a result of poor DDD, not modelling more appropriate objects? Eg a Customer Address, Delivery Address, Invoice Address Vs just a single shared Address
Or is there still too much conflict for the truly shareable objects?
They can serve multiple purpose and that's not the problem, because there's precedent in the literature -- software architecture the hard parts https://www.oreilly.com/library/view/software-architecture-t... -- for teams to organize architecture review cycles and decide if some microservers are better merged into a monolith. This however requires tons of refactor when microservices aren't design with this part of its lifecycle in mind, and we all know how this kind of investment is risky and hard to communicate to non-technical management.
Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time.
It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction.
I don't agree that there are organizational causes even though that's oft repeated as one of the main reasons. I have never seen a one-to-one relationship of microservices and teams irl. Most teams own many services and some services get touched by many teams. In big companies, there are also microservices with zero owners.
One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.
That's the sane way of using services, but micro-services used in the wild are often used without any organizational consideration at all: as a consultant I witnessed countless of small companies and start-ups who had multiple times more services than developers! (The biggest culprit was the latest one: 61 micro services for 3 devs and a PM, and it wasn't even an outlier) .
What could be a sensible architecture for large orgs has become more of a cult-like behavior that drags everyone down.
In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)
There are two things monoliths can't easily offer:
* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.
* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used
Concerns that shape my own decision to run Marginalia Search as a service based architecture rather than one blob include:
* NUMA optimization - on multi-CPU architectures, I/O and/or memory bottlenecked software takes a pretty significant performance hit if you let is run on both CPUs, and this has knock on effects that also degrade the performance of other software running on the same machine.
* Network namespaces - if you're e.g. running an internet crawler, and want to assign one host machine multiple public IP addresses, this is much easier if you use something like ipvlan.
* Stateful long running process lifecycles (e.g. crawling) that coexist with the need for live redeployments of other parts of the system.
> But in my experience, it's pretty rare for a team to use many programming languages at once
Teams sure, but your whole org? Nothing wrong with all teams using same tools and language, nothing wrong with them choosing their poison. Of course your monolith can have multiple build systems.
But I think this is beside the main point of the article anyway, and it’s the part about how microservices help create boundaries that mirror organizational boundaries.
Data isolation,
separate auth/permissions/roles,
Compliance,
crash isolation,
Resource/capacity management
There’s probably more off the top of my head. Not that I necessarily advocate for the micro in services. Just the sliding scale of macro-micro services.
> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.
I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone?
How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time)
What are the race conditions? User removes billing info at the same moment as making a payment - what happens? Is the payment marked as successful but not actually billed?
> Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
> What are the race conditions?
Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its transactionality, and running in READ-COMMITTED (which everyone does) also breaks transactionality. Either of these conditions is enough. My team walked away understanding this.
But we left the idea there to die, because you cannot change these things politically. No monolith owner is going to even pretend to demonstrate thread safety.
The lines of defence are:
* He will assume it's thread safe
* He will argue against change "for code consistency"
* He will argue that it makes the code simpler and easier to understand
* He will introduce a change which he assumes will fix it, but clearly only makes the race condition harder to diagnose
* He will argue that it doesn't matter because race conditions are rare anyway.
It's all academic anyway - in a monolith you won't get past the first line of defence anyway.
type ThingDoer interface {
DoTheThingIDontCareHow() (result, error)
}
func NewAmazingThingIMade(theThingINeedButIDontCareHowItDoesIt ThingDoer) {
// You receive the superduper thing and dont care about it in any other way
}
func (a *Amazing) DoSomeThing() (result, error) {
return a.DoTheThingIDontCareHow()
}
Nothing about "monoliths" prevents or hampers this development style. Once someone decides to do the Thing in another fashion, they are free to do so and you wouldn't have to change a thing.
All problems you experience are organizational, not technical. It's psychology we should be studying, not computer science.
Edit: In fact you introduced a network boundary which can fundamentally only complicate matters, not make them simpler.
I think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice.
Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to static checks, and much higher performance that microservices’ network interfaces.
monoliths can be anything under the boundaries. That's why people get this so wrong. There is no rule that says you must have internal public interfaces (misnomer? how can it be public, but internal, at the same time?). Microservices were entirely designed to split work across teams.
> I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.
It seems usual to leave code in the codebase (possibly commented out) if you think it may be used again in the near future. It's easier than digging through source control. If you know you won't need it any more, then you delete it
You do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Tracing and o11y are a poor sibling to static analysis.
> This is complete lack of experience on the authors part
Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system
The range of what a program can do is much larger than what a program does do in your two week Datadog aggregation window
It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.
Observability and operability are just not the same thing as being able to reason about the software. You need both
You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness
Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell
There will be code paths that have never been triggered that you still need to reason about as part of analysing a system, eg in threat modelling
> I get why you think I might not have worked on large systems
I didn't, necessarily. But it looked like an excessively strong claim, combined with a challenge to the author's competence. I wanted to call that out.
Static analysis doesn't go away. Metrics just covers the gap of "is this used by external callers", and nothing more than that. You need that to identify dead routes in a monolith anyway.
If you like static analysis, you should be able to spin up new code in a language more amenable to it than the incumbent code. Not doable in a monolith.
* My last monolith job had 4 hour release windows.
* You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical.
Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't have to waste any time worrying or arguing, since him keeping the system as a monolith made this change impossible.
Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
A "real" microservice (according to some definitions) might be only really necessary for organizational reasons.
But the services in a distributed monolith are also often called microservices (at least in my company).
And for them I believe there is another good reason that I do not hear about in these discussions: robustness.
In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints.
By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.
I feel like the discussion between "monolith" and "microservices" is a false dichotomy.
For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.
You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.
This is what people always say but it's not really the only case, and it's not even a particularly good case. You could achieve the same organizational thing through modules, for example.
The real—and the one thing you can't replicate—is data isolation.
Of course there are other benefits, but it's data isolation is the differentiator of micro-services and other types of architecture.
It's not just the modular organisation that you've got to get right though, although that's definitely a big thing. Deployment independence matters too: if I've got a perfectly modular monolith but I have to coordinate with everyone else who lives in that monolith to get my module into production, it's leaving half the gains on the table.
The very first time I came across the term, it was used to refer to something so small that you'd comfortably rewrite it rather than fix it if it was wrong.
Design principles:
* Isolate business logic from service framework using declarative coding
* Make the logic representation machine-writable so AI is a first-class author
* Treat business logic as versioned data, not compiled services
* Ship governance with the platform, not with each service
* Invoke services in-process, not over the network
* Modular monolith — export and scale a service independently when needed
* Push integrations into declarative connectors, keep logic pure
Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?” Once the code is spread across dozens of independent services, those answers become much harder to obtain.
Compare the fuel pump of a Jumbojet and of a car. Is the smaller one a micro-pump? No, they are both pumps. Any "micro service" is just a service. Ref: Juval Löwy
World of bloated microservices. Yet in reality many create them to be simple data proxies that constantly die down. Win in eyes of hashtag investors, loss in hands of people having to maintain that crap.
I wrote a post on my blog[1] a while back about this. Actually, there are records in memoirs and such that show similar pressures existed when MSA emerged.
Microservices are service/s that are significantly smaller than the service you're comparing them to. That's an obvious and perhaps unhelpful definition, let's contrast it with ...
"Microservices" is[0] a tech industry fashion trend. It can be a real solution to a problem, too, but it's like how throwing out all your shit is the solution to depression now because a nice lady in a book said that you probably don't want all that stuff anyway. The solution is applied/suggested because it's trendy, not because it is necessarily the best fitting solution.
Like many buzzwords, 'microservice' is difficult to define. "You know it when you see it" is a euphemism for something devoid of meaning[1]: a null concept. This is a feature and not a bug. And where the term does have meaning, it's always relative -- so everyone can have microservices, and argue about who does.
[0] I do mean 'is', as opposed to 'are'
[1] it can also be the case that the speaker just doesn't know what they're talking about, and perhaps that they know it has meaning to others, social constructs, &c. To avoid spending the next three years working on this comment, I'm assuming that's not the case above.
[x] Conspiracy-theory rabbit-hole: buzzwords are like conspiracy theories in that they rely on vagueness or being undefinable. I guess my point is that concrete ideas aren't really suited to being buzzwords. Only the vague/relative/broad ones get selected (as in natural selection, not by the shady cabal of buzzword pickers), just like how only the best impossible contradictory stories tend to become popular conspiracy theories.
... actually, mostly I just thought "conspiracy-theory rabbit-hole" was a funny heading for a tangent about conspiracy theories.
I have a team that doesn't communicate well and is generally dysfunctional in all ways imaginable.
Microservices isolate them quite literally and lets them work in peace and quiet.
The system as a whole is completely batshit crazy of course, but for some teams, this can turn an unworkable situation into "we might survive this" which is when push comes to shove all that matters.
This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.
https://en.wikipedia.org/wiki/Conway%27s_law
Yes, and then they start complaining that the shared domain objects are not kept up to date by team $notMine, and so they inevitably go to a shared library where they fall back into the same issues.
If you're needing to share code for domain objects between microservices something has gone badly wrong.
Is that a result of poor DDD, not modelling more appropriate objects? Eg a Customer Address, Delivery Address, Invoice Address Vs just a single shared Address
Or is there still too much conflict for the truly shareable objects?
They can serve multiple purpose and that's not the problem, because there's precedent in the literature -- software architecture the hard parts https://www.oreilly.com/library/view/software-architecture-t... -- for teams to organize architecture review cycles and decide if some microservers are better merged into a monolith. This however requires tons of refactor when microservices aren't design with this part of its lifecycle in mind, and we all know how this kind of investment is risky and hard to communicate to non-technical management.
Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time.
It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction.
I don't agree that there are organizational causes even though that's oft repeated as one of the main reasons. I have never seen a one-to-one relationship of microservices and teams irl. Most teams own many services and some services get touched by many teams. In big companies, there are also microservices with zero owners.
One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.
Except microservices don't do that. You still have to wrangle other people's system parts.
That's the sane way of using services, but micro-services used in the wild are often used without any organizational consideration at all: as a consultant I witnessed countless of small companies and start-ups who had multiple times more services than developers! (The biggest culprit was the latest one: 61 micro services for 3 devs and a PM, and it wasn't even an outlier) .
What could be a sensible architecture for large orgs has become more of a cult-like behavior that drags everyone down.
In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)
There are two things monoliths can't easily offer:
* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.
* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used
What else am I missing?
Concerns that shape my own decision to run Marginalia Search as a service based architecture rather than one blob include:
* NUMA optimization - on multi-CPU architectures, I/O and/or memory bottlenecked software takes a pretty significant performance hit if you let is run on both CPUs, and this has knock on effects that also degrade the performance of other software running on the same machine.
* Network namespaces - if you're e.g. running an internet crawler, and want to assign one host machine multiple public IP addresses, this is much easier if you use something like ipvlan.
* Stateful long running process lifecycles (e.g. crawling) that coexist with the need for live redeployments of other parts of the system.
> But in my experience, it's pretty rare for a team to use many programming languages at once
Teams sure, but your whole org? Nothing wrong with all teams using same tools and language, nothing wrong with them choosing their poison. Of course your monolith can have multiple build systems.
But I think this is beside the main point of the article anyway, and it’s the part about how microservices help create boundaries that mirror organizational boundaries.
Data isolation, separate auth/permissions/roles, Compliance, crash isolation, Resource/capacity management
There’s probably more off the top of my head. Not that I necessarily advocate for the micro in services. Just the sliding scale of macro-micro services.
These are more problems in larger companies.
> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.
I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone?
How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time)
What are the race conditions? User removes billing info at the same moment as making a payment - what happens? Is the payment marked as successful but not actually billed?
At least read to the end
> Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
> What are the race conditions?
Everywhere. Just fucking everywhere. I ran a workshop for my team (4-5 backenders) with a simple, pared down example with reads and writes within a 'transaction'. I then demonstrated that LINQ breaks its transactionality, and running in READ-COMMITTED (which everyone does) also breaks transactionality. Either of these conditions is enough. My team walked away understanding this.
But we left the idea there to die, because you cannot change these things politically. No monolith owner is going to even pretend to demonstrate thread safety.
The lines of defence are:
* He will assume it's thread safe
* He will argue against change "for code consistency"
* He will argue that it makes the code simpler and easier to understand
* He will introduce a change which he assumes will fix it, but clearly only makes the race condition harder to diagnose
* He will argue that it doesn't matter because race conditions are rare anyway.
It's all academic anyway - in a monolith you won't get past the first line of defence anyway.
It's called programming to an interface.
type ThingDoer interface { DoTheThingIDontCareHow() (result, error) }
func NewAmazingThingIMade(theThingINeedButIDontCareHowItDoesIt ThingDoer) { // You receive the superduper thing and dont care about it in any other way }
func (a *Amazing) DoSomeThing() (result, error) { return a.DoTheThingIDontCareHow() }
Nothing about "monoliths" prevents or hampers this development style. Once someone decides to do the Thing in another fashion, they are free to do so and you wouldn't have to change a thing.
All problems you experience are organizational, not technical. It's psychology we should be studying, not computer science.
Edit: In fact you introduced a network boundary which can fundamentally only complicate matters, not make them simpler.
I think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice.
Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to static checks, and much higher performance that microservices’ network interfaces.
monoliths can be anything under the boundaries. That's why people get this so wrong. There is no rule that says you must have internal public interfaces (misnomer? how can it be public, but internal, at the same time?). Microservices were entirely designed to split work across teams.
> I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.
Then substitute 'dead code' for 'buggy code that someone else likes'
It seems usual to leave code in the codebase (possibly commented out) if you think it may be used again in the near future. It's easier than digging through source control. If you know you won't need it any more, then you delete it
You do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.
This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.
Tracing and o11y are a poor sibling to static analysis.
> This is complete lack of experience on the authors part
Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system
The range of what a program can do is much larger than what a program does do in your two week Datadog aggregation window
It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.
Observability and operability are just not the same thing as being able to reason about the software. You need both
You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness
Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell
There will be code paths that have never been triggered that you still need to reason about as part of analysing a system, eg in threat modelling
> I get why you think I might not have worked on large systems
I didn't, necessarily. But it looked like an excessively strong claim, combined with a challenge to the author's competence. I wanted to call that out.
Missing the point.
Static analysis doesn't go away. Metrics just covers the gap of "is this used by external callers", and nothing more than that. You need that to identify dead routes in a monolith anyway.
If you like static analysis, you should be able to spin up new code in a language more amenable to it than the incumbent code. Not doable in a monolith.
Why do you think different people can't work on different parts of a single deployment unit (which is what we mean by "monolith")?
* My last monolith job had 4 hour release windows.
* You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical.
Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't have to waste any time worrying or arguing, since him keeping the system as a monolith made this change impossible.
Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
Or build core infrastructure right the first time, and not spend millions of dollars turd-polishing while your competition eats the market.
Davids talk makes some good arguments, but does not fully acknowledge low-maintenance infrastructure at scale. =3
"10 tips for failing at microservices" (David Schmitz)
https://www.youtube.com/watch?v=GWgRw5jiYy0
[dead]
A "real" microservice (according to some definitions) might be only really necessary for organizational reasons. But the services in a distributed monolith are also often called microservices (at least in my company). And for them I believe there is another good reason that I do not hear about in these discussions: robustness.
In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints. By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.
> But the services in a distributed monolith are also often called microservices (at least in my company).
I thought that was a "microlith".
I’ve been building a lot on cloudflare workers recently and I feel like microservice works pretty well there.
Sometimes you want to have some shared infra abstracted behind a single interface and a single auth model.
Having a service gives you that single isolated unit/abstraction.
In practice it’s always a scale. Some services will be bigger and some will naturally be split out.
I think also having the right server platform that makes it trivial to deploy/standup infra quickly makes this much easier.
I feel like the discussion between "monolith" and "microservices" is a false dichotomy.
For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.
You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.
We had services mostly built around deployment requirements. This package runs on the CDN edge, this other one runs centrally on a cluster.
This is what people always say but it's not really the only case, and it's not even a particularly good case. You could achieve the same organizational thing through modules, for example.
The real—and the one thing you can't replicate—is data isolation.
Of course there are other benefits, but it's data isolation is the differentiator of micro-services and other types of architecture.
It's not just the modular organisation that you've got to get right though, although that's definitely a big thing. Deployment independence matters too: if I've got a perfectly modular monolith but I have to coordinate with everyone else who lives in that monolith to get my module into production, it's leaving half the gains on the table.
The very first time I came across the term, it was used to refer to something so small that you'd comfortably rewrite it rather than fix it if it was wrong.
I decided to take a career break and build an open source project to manage services better. Feedbacks are welcome, product is too early for adoption.
https://github.com/GoPlasmatic/Orion
Design principles: * Isolate business logic from service framework using declarative coding * Make the logic representation machine-writable so AI is a first-class author * Treat business logic as versioned data, not compiled services * Ship governance with the platform, not with each service * Invoke services in-process, not over the network * Modular monolith — export and scale a service independently when needed * Push integrations into declarative connectors, keep logic pure
Microservices is a tricked coined by Martin Fowler to make up reasons for more $$$ billable developer man-hours.
Imagine you're a unicorn startup, you just hired 1000 devs in the last 2 months.
It turns out, every team thinks they got the smartest people, and they all hate the idea of collaborating with the inferior teams.
Yeah, you will need microservices to bandaid your dysfunctional org. You'll keep going, slowly.
Literally the only reason I can imagine for microservices.
Compare the fuel pump of a Jumbojet and of a car. Is the smaller one a micro-pump? No, they are both pumps. Any "micro service" is just a service. Ref: Juval Löwy
They sound great in theory, but when you've got Microservices A to Z and something isn't right, you've got 26 log files to go through just to start.
SigNoz and search for your events. You don't need to sift through 26 log files.
Splunk is way too expensive now but if you're not doing centralized logging that you can search, you're doing it wrong.
Or get the best of both worlds, use a monorepo with microservices.
World of bloated microservices. Yet in reality many create them to be simple data proxies that constantly die down. Win in eyes of hashtag investors, loss in hands of people having to maintain that crap.
Seems op is as confused as I am about what a micro service is exactly
AI written? It's not X, it's Y all over.
Tastes like slop
Conway's Law at the boxen level?
I wrote a post on my blog[1] a while back about this. Actually, there are records in memoirs and such that show similar pressures existed when MSA emerged.
[1]https://www.makonea.com/en-US/blog/how-did-microservices-arc...
Microservices are service/s that are significantly smaller than the service you're comparing them to. That's an obvious and perhaps unhelpful definition, let's contrast it with ...
"Microservices" is[0] a tech industry fashion trend. It can be a real solution to a problem, too, but it's like how throwing out all your shit is the solution to depression now because a nice lady in a book said that you probably don't want all that stuff anyway. The solution is applied/suggested because it's trendy, not because it is necessarily the best fitting solution.
Like many buzzwords, 'microservice' is difficult to define. "You know it when you see it" is a euphemism for something devoid of meaning[1]: a null concept. This is a feature and not a bug. And where the term does have meaning, it's always relative -- so everyone can have microservices, and argue about who does.
[0] I do mean 'is', as opposed to 'are'
[1] it can also be the case that the speaker just doesn't know what they're talking about, and perhaps that they know it has meaning to others, social constructs, &c. To avoid spending the next three years working on this comment, I'm assuming that's not the case above.
[x] Conspiracy-theory rabbit-hole: buzzwords are like conspiracy theories in that they rely on vagueness or being undefinable. I guess my point is that concrete ideas aren't really suited to being buzzwords. Only the vague/relative/broad ones get selected (as in natural selection, not by the shady cabal of buzzword pickers), just like how only the best impossible contradictory stories tend to become popular conspiracy theories. ... actually, mostly I just thought "conspiracy-theory rabbit-hole" was a funny heading for a tangent about conspiracy theories.
[flagged]
[flagged]
Cancer is that which increases its own number without any concern for the health of larger systems it exists within.
So you might be right.
I have a team that doesn't communicate well and is generally dysfunctional in all ways imaginable.
Microservices isolate them quite literally and lets them work in peace and quiet.
The system as a whole is completely batshit crazy of course, but for some teams, this can turn an unworkable situation into "we might survive this" which is when push comes to shove all that matters.