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.

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.

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

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?

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.

Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.

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.

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.

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

For nearly all teams of any size, with very few exceptions, Microservices™ are cancer.

"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.

   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.

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.

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?

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.

Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.