3 ms·

It always baffled me to hear:" Oh we're gonna do microservices, because our monolith is a total mess and we're very unproductive". If you can't organize a monol

by jfabre 4y ago

It always baffled me to hear:" Oh we're gonna do microservices, because our monolith is a total mess and we're very unproductive". If you can't organize a monolith, what makes you think you will be able to organize microservices which are vastly more complicated to work with. How about you learn as a company the proper skills and habits to achieve logical modularity within a single process before you try doing that with multiple processes.

jfabre 4y ago
And I would also add: The reason your monolith is a mess is because your organization has low standards on code quality and doesn't value it. It is not willing to invest in it, and probably your department didn't acquire the skills and habits to produce clean code in cheap manner. The developers who are used to good code usually leave you out of frustration. No one likes to be unproductive, especially productive people.
- eddd-ddde 4y ago
  I hate how much I can relate to this.
- atom_arranger 4y ago
  I wonder if part of why microseconds work for some companies is the hype helps justify the work to management. > We need to convert to microservices. Sounds like a cool shiny new approach enabling better scaling and organization. > We need to refactor this mess. Sounds like complaining, why is it a mess anyways? These two things may essentially be doing the same thing, organizing/breaking up the code logically, one just might sound more appealing to management.
gitfan86 4y ago
"productive" means shipping code to these people. They are trying to minimize how often someone says "we are blocked on deploying that code"
- jfabre 4y ago
  You would need to provide me with a concrete example, because I've never really had the issue you're describing. I'm willing to bet it's fixable by having better management.
  - vore 4y ago
    Assume you're having to ship a large single release bundling the code of multiple integrating teams: a bug in one of those teams' code will likely delay the release of the entire bundle: bugs are inevitable and no amount of better management will solve them. With microservices, you add coordination overhead but teams have more autonomy in shipping their own individual bundles.
    - jfabre 4y ago
      Wouldn't it be more sensible to release often and in smaller increments instead? Why can't you do that? You only release one feature on top of master, test it to make sure nothing is broken then release it. The second feature has to merge on top of the new stable git hash once it's ready to be released. And so on... Bundling a bunch of stuff all at the same time seems like asking for misery and weird integration issues in production.
    - NortySpock 4y ago
      I must be missing something: 1) if you have a blocking bug or code dependency between two microservices OR two monolith modules, that should of course block until it is fixed and resolved. Microservices do not magically solve that. 2) other code changes or features that are not blocked, can be unblocked by being released in a smaller release ( git rebase those commits to a new release branch on main, and cut, test and deploy a smaller release -- basically gitflow) 3) once the blocking modules are fixed, they should be rebased onto the latest main. The blocking "effect", even in a monolith, seems like it would be better solved by using a version control system with good rebase support. Coordination needs to happen for larger changes, and/or the changes need to be smaller.
      - 4y ago
arwhatever 4y ago
I’m probably the last person on here to discover https://grugbrain.dev/ https://grugbrain.dev/, but I like the particular quote: “grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too”

by jfabre 4y ago

jfabre 4y ago

And I would also add: The reason your monolith is a mess is because your organization has low standards on code quality and doesn't value it. It is not willing to invest in it, and probably your department didn't acquire the skills and habits to produce clean code in cheap manner. The developers who are used to good code usually leave you out of frustration. No one likes to be unproductive, especially productive people.

eddd-ddde 4y ago
I hate how much I can relate to this.
atom_arranger 4y ago
I wonder if part of why microseconds work for some companies is the hype helps justify the work to management. > We need to convert to microservices. Sounds like a cool shiny new approach enabling better scaling and organization. > We need to refactor this mess. Sounds like complaining, why is it a mess anyways? These two things may essentially be doing the same thing, organizing/breaking up the code logically, one just might sound more appealing to management.

gitfan86 4y ago

"productive" means shipping code to these people. They are trying to minimize how often someone says "we are blocked on deploying that code"

jfabre 4y ago
You would need to provide me with a concrete example, because I've never really had the issue you're describing. I'm willing to bet it's fixable by having better management.
- vore 4y ago
  Assume you're having to ship a large single release bundling the code of multiple integrating teams: a bug in one of those teams' code will likely delay the release of the entire bundle: bugs are inevitable and no amount of better management will solve them. With microservices, you add coordination overhead but teams have more autonomy in shipping their own individual bundles.
  - jfabre 4y ago
    Wouldn't it be more sensible to release often and in smaller increments instead? Why can't you do that? You only release one feature on top of master, test it to make sure nothing is broken then release it. The second feature has to merge on top of the new stable git hash once it's ready to be released. And so on... Bundling a bunch of stuff all at the same time seems like asking for misery and weird integration issues in production.
  - NortySpock 4y ago
    I must be missing something: 1) if you have a blocking bug or code dependency between two microservices OR two monolith modules, that should of course block until it is fixed and resolved. Microservices do not magically solve that. 2) other code changes or features that are not blocked, can be unblocked by being released in a smaller release ( git rebase those commits to a new release branch on main, and cut, test and deploy a smaller release -- basically gitflow) 3) once the blocking modules are fixed, they should be rebased onto the latest main. The blocking "effect", even in a monolith, seems like it would be better solved by using a version control system with good rebase support. Coordination needs to happen for larger changes, and/or the changes need to be smaller.
    - 4y ago

arwhatever 4y ago

I’m probably the last person on here to discover https://grugbrain.dev/ https://grugbrain.dev/, but I like the particular quote: “grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too”