4 ms·

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn't exist.

rwmj 3y ago
We've been here before with object oriented programming which was supposed to introduce a world of reusable, composable objects, even connected by CORBA if you wanted to run them remotely.
papito 3y ago
This is a very nice academic theory, but in real life you get half-assed, half-implemented hairballs that suck out your will to live if you have to untangle that.
- kqr 3y ago
  What are the sequence of events that happen in real life that take us from nice theory to hairballs, that academics fail to foresee?
  - papito 3y ago
    Most companies severely underestimate the complexities of a distributed system and the work that goes into a truly resilient, scalable setup of this kind. An infrusctructfre of this sort is meant to solve very hard problems, not to make regular problems much harder.
tracker1 3y ago
There's also the distribution of work... if one set of teams manages the deployments or communications issues between the microservices, while the micro-service developers can concentrate on the domain it can be a better distribution of work. Where as if the same teams/devs are going to do both sides of this, it may make more sense for a more monolithic codebase/deployment.
Jtsummers 4y ago
Before "microservices" there are services, which are also composable. And in the realm of monoliths there are also modules. Which are the key to composability. What microservices give you is a hard boundary that you cannot cross (though you can weaken it, you cannot eliminate it) between modules. This means the internal state of a module now has to be explicitly and more deliberately exposed rather than merely bypassed by lack of access control, or someone swapping out public for private, or capitalizing a name in Go. If there's any real benefit of microservices, this is it. The hard(er) boundary between modules. But it's not novel, we've had that concept since the days of COBOL. And hardware engineers have had the concept even longer. The challenge in monoliths is that the boundary is so easily breached, and it will be over time because of expedient choices rather than deliberate, thoughtful choices.
- javanonymous 3y ago
  There are tools for enforcing boundaries. One name for this is "Modulith" where you use modules that have a clear enforced boundary. You get the same composability as micro-services without the complexity. Here's how Spring solves it: https://www.baeldung.com/spring-modulith https://www.baeldung.com/spring-modulith It's basically a library that ensures strict boundaries. Communication has to go through an interface (similar to service api) and you are not allowed to leak internal logic such as database entities to the outer layer If you later decide to convert the module into a separate service, you simply move the module to a new service and write a small API layer that uses the same interface. No other code changes are necessary. This enables you to start with a single service (modulith) and split into microservices later if you see the need for it without any major refactoring
- grumpyprole 3y ago
  > The challenge in monoliths is that the boundary is so easily breached The biggest challenge with monoliths is the limits of a single process and machine.
  - ndriscoll 3y ago
    Typically the application server is stateless and any persistent state is kept in a database, so you can just spawn another instance on another machine.

rwmj 3y ago

We've been here before with object oriented programming which was supposed to introduce a world of reusable, composable objects, even connected by CORBA if you wanted to run them remotely.

papito 3y ago

This is a very nice academic theory, but in real life you get half-assed, half-implemented hairballs that suck out your will to live if you have to untangle that.

kqr 3y ago
What are the sequence of events that happen in real life that take us from nice theory to hairballs, that academics fail to foresee?
- papito 3y ago
  Most companies severely underestimate the complexities of a distributed system and the work that goes into a truly resilient, scalable setup of this kind. An infrusctructfre of this sort is meant to solve very hard problems, not to make regular problems much harder.

tracker1 3y ago

There's also the distribution of work... if one set of teams manages the deployments or communications issues between the microservices, while the micro-service developers can concentrate on the domain it can be a better distribution of work. Where as if the same teams/devs are going to do both sides of this, it may make more sense for a more monolithic codebase/deployment.

Jtsummers 4y ago

Before "microservices" there are services, which are also composable. And in the realm of monoliths there are also modules. Which are the key to composability. What microservices give you is a hard boundary that you cannot cross (though you can weaken it, you cannot eliminate it) between modules. This means the internal state of a module now has to be explicitly and more deliberately exposed rather than merely bypassed by lack of access control, or someone swapping out public for private, or capitalizing a name in Go. If there's any real benefit of microservices, this is it. The hard(er) boundary between modules. But it's not novel, we've had that concept since the days of COBOL. And hardware engineers have had the concept even longer. The challenge in monoliths is that the boundary is so easily breached, and it will be over time because of expedient choices rather than deliberate, thoughtful choices.

javanonymous 3y ago
There are tools for enforcing boundaries. One name for this is "Modulith" where you use modules that have a clear enforced boundary. You get the same composability as micro-services without the complexity. Here's how Spring solves it: https://www.baeldung.com/spring-modulith https://www.baeldung.com/spring-modulith It's basically a library that ensures strict boundaries. Communication has to go through an interface (similar to service api) and you are not allowed to leak internal logic such as database entities to the outer layer If you later decide to convert the module into a separate service, you simply move the module to a new service and write a small API layer that uses the same interface. No other code changes are necessary. This enables you to start with a single service (modulith) and split into microservices later if you see the need for it without any major refactoring
grumpyprole 3y ago
> The challenge in monoliths is that the boundary is so easily breached The biggest challenge with monoliths is the limits of a single process and machine.
- ndriscoll 3y ago
  Typically the application server is stateless and any persistent state is kept in a database, so you can just spawn another instance on another machine.