4 ms·

I think the point here that is getting lost here (not on you necessarily) is that if you write your service clean/SOLID, it really doesn’t matter if/when/how yo

I think the point here that is getting lost here (not on you necessarily) is that if you write your service clean/SOLID, it really doesn’t matter if/when/how you make that decision to cleave it off into its own service. Monoliths are only a problem with scale, but there is absolutely no guarantee that your engineering team will scale at the same rate as your userbase. You know the story: tech product strikes gold, gets mentioned in NYT and becomes a new hot thing and doesn’t even have time to react before they hit scaling problems. It’s not great to prematurely optimize, but if you’re not preparing for eventual success (which requires scaling) is another term for shooting yourself in the foot. Unfortunately, even if you are “scaled up” in terms of workers, monoliths can be really nasty/resistant to many hands making the work lighter because they of how tightly coupled things end up being. Why not monolith it? Maybe one part of the app evolves to really need a time series database or it really does some crazy stuff with image editing or it has new special dependencies that take an eternity to build, and you don’t want to add 20m of build time every time you mess with the rest of the codebase, none of which needs/expects the time-series/image-editor/complicated build thing to be there deployed alongside it. That’s like OG logic of why you want microservices, and it still makes a lot of sense, just people get carried away with cargo-culting on their thousand-microservice hellscapes where each API has four routes and 4000 lines of deploy config, boilerplate, copypasta.

patrick451 3y ago
Microservices don't solve the tight coupling problem. Rather, they make dealing with it even more painful because rather than updating assumptions across modules, you update them across different units of deployment. This leads to ossification because it is even more difficult to fix bad architecture.
- zerbinxx 3y ago
  I never claimed they did, I said if your code is SOLID then it doesn’t really matter if it’s a microservice or not, it will likely be useful up to the point where scaling/organizational/too many cooks/long deploy/spof problems start to crop up.
  - regularfry 3y ago
    Not sure this holds water. Which SOLID principle, or combination, solves the problem of building a system where a request traverses a boundary that is not problematic when executed locally, but introduces too much latency when you put a new network call behind an interface? From what I can see, SOLID lets you split the monolith, as long as you happen to have interface segregation on the right seams. It says nothing about the operational properties of the service once split, which is by far the bigger problem, and depends on the non-functional properties of the code using the interfaces. Unless you already know you are headed for a microservice split, you're unlikely to have designed with that in mind.

patrick451 3y ago

Microservices don't solve the tight coupling problem. Rather, they make dealing with it even more painful because rather than updating assumptions across modules, you update them across different units of deployment. This leads to ossification because it is even more difficult to fix bad architecture.

zerbinxx 3y ago
I never claimed they did, I said if your code is SOLID then it doesn’t really matter if it’s a microservice or not, it will likely be useful up to the point where scaling/organizational/too many cooks/long deploy/spof problems start to crop up.
- regularfry 3y ago
  Not sure this holds water. Which SOLID principle, or combination, solves the problem of building a system where a request traverses a boundary that is not problematic when executed locally, but introduces too much latency when you put a new network call behind an interface? From what I can see, SOLID lets you split the monolith, as long as you happen to have interface segregation on the right seams. It says nothing about the operational properties of the service once split, which is by far the bigger problem, and depends on the non-functional properties of the code using the interfaces. Unless you already know you are headed for a microservice split, you're unlikely to have designed with that in mind.