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.
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.
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.
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 thought that was a "microlith".
It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying in either direction by a whole order of magnitude.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
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 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.
inigyou•55m ago
holografix•46m ago