3 ms·

This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same obs

This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same observations and conclusions? If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!

jolux 4y ago
Microservices to me are solving two problems: an organizational problem and a technical problem. The organizational problem is more obvious: well-factored monolithic codebases go poorly with large, interdependent groups of teams. The technical problem is that while it’s true that you can write a monolith in a modular style, in my experience enforcing the single responsibility principle in a monolith demands a level of discipline that is not feasible to maintain indefinitely in an environment with personnel turnover. When architectural coupling requires making coordinated changes to multiple services, the barrier is high enough that people will tend to avoid it instead.
- eanghel 4y ago
  Wholeheartedly agree, I also feel like people are overestimating how much discipline you can collectively have in an organization. And if you create a monolith with hard-enough boundaries to enforce modularization then you might as well create multiple services (and not necessarily the one-microservice-per-entity kind of architectures, just as many as the modules)
jameshart 4y ago
I think anyone who has taken a large monolith through a significant platform version upgrade or change, like .NET 2 to .NET 4, or Python2 to Python3, or Angular to React, would need a very persuasive argument to make them believe that starting a new project with a monolithic design was a good idea.
- KyeRussell 4y ago
  I’d tell anyone that thought that that it’s a very shortsighted view. If they had started with microservices there’s a good chance the project wouldn’t be around long enough to even go through that transition.
  - jameshart 4y ago
    So don't start with microservices. But also don't start with a monolith! If you have offline batch processes, don't make the mistake of implementing them in the same codebase as your website just because you already have the DB access and build/deploy tooling set up. If you have an admin portal and a public website that listen on different ports, don't run both listeners in the same process. 'don't build microservices yet' does not have to mean 'start with a monolith'.
- dontlaugh 4y ago
  Having upgraded both kinds of projects to Python 3, the monoliths were far simpler to deal with.
- svieira 4y ago
  As someone who has done this, both for version upgrades and for substantial refractors of the codebase, I have to prefer monoliths. Atomic commits are cheaper than adding and releasing version support across a system that doesn't have it.

jolux 4y ago

Microservices to me are solving two problems: an organizational problem and a technical problem. The organizational problem is more obvious: well-factored monolithic codebases go poorly with large, interdependent groups of teams. The technical problem is that while it’s true that you can write a monolith in a modular style, in my experience enforcing the single responsibility principle in a monolith demands a level of discipline that is not feasible to maintain indefinitely in an environment with personnel turnover. When architectural coupling requires making coordinated changes to multiple services, the barrier is high enough that people will tend to avoid it instead.

eanghel 4y ago
Wholeheartedly agree, I also feel like people are overestimating how much discipline you can collectively have in an organization. And if you create a monolith with hard-enough boundaries to enforce modularization then you might as well create multiple services (and not necessarily the one-microservice-per-entity kind of architectures, just as many as the modules)

jameshart 4y ago

I think anyone who has taken a large monolith through a significant platform version upgrade or change, like .NET 2 to .NET 4, or Python2 to Python3, or Angular to React, would need a very persuasive argument to make them believe that starting a new project with a monolithic design was a good idea.

KyeRussell 4y ago
I’d tell anyone that thought that that it’s a very shortsighted view. If they had started with microservices there’s a good chance the project wouldn’t be around long enough to even go through that transition.
- jameshart 4y ago
  So don't start with microservices. But also don't start with a monolith! If you have offline batch processes, don't make the mistake of implementing them in the same codebase as your website just because you already have the DB access and build/deploy tooling set up. If you have an admin portal and a public website that listen on different ports, don't run both listeners in the same process. 'don't build microservices yet' does not have to mean 'start with a monolith'.
dontlaugh 4y ago
Having upgraded both kinds of projects to Python 3, the monoliths were far simpler to deal with.
svieira 4y ago
As someone who has done this, both for version upgrades and for substantial refractors of the codebase, I have to prefer monoliths. Atomic commits are cheaper than adding and releasing version support across a system that doesn't have it.