5 ms·

I think people forget that code in monoliths can be written in a way to set boundaries with namespaces and thinking through class-level API design. Most of the

I think people forget that code in monoliths can be written in a way to set boundaries with namespaces and thinking through class-level API design. Most of the time you can accomplish the same outcome of what a microfrontend might provide inside a monolith. Same is often the case for the backend.

klysm 3y ago
They can, but the walls are not strong enough to perturb those programmers who do not know any better, don’t care, or are under sufficient pressure to sweep aside good practice. Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed. It’s obvious that strong walls have immense cost, but perhaps for a large enough organization it enables faster movement overall with fewer faults. Walls are good after all. What’s fascinating to me about micro-anything vs. monolith-anything is it’s much more a function of team structure and culture than of technical merit. In some cases, the technically inferior solution can deliver more to the business when combined with the unfortunate realities of human development. I agree with the original offer that micro-anything should ultimately be considered a failure of better modularity mechanisms.
- strken 3y ago
  I thought it was more about independence. Got a bug in your service? Instead of one massive build deployed once an hour/day/week/etc. that gets rolled back if any commit was bad, you deploy your service when it changes and don't worry too much about the unrelated pieces.
  - Sankozi 3y ago
    Got a feature that touches several modules? Instead of one massive build deployed once, you deploy each service. With dependencies you need to wait after each deployment to check if everything is ok. Instead of one big build and one deployment, you get quick build, deployment, check, quick build deployment, check... So in case of microservices/microfrontends you gain minutes on build time but lose hours/days on deployment and verification.
    - klysm 3y ago
      Yes that is true, but the other side of that coin is that deploying changes to the interface between modules is now hard - that's the tradeoff space. If you have really clear interfaces with low churn then you probably have a net win, but in my experience it's really hard to get those interfaces right and that cost can end up beating your gains.
      - Sankozi 3y ago
        Not sure what you mean. Changes to the interfaces in modular monolith are much easier than in microservices. You just release new version with updated interfaces - no need for versioning if you update interface and its usages. In case of microservices you must do versioning and either have to keep and support old version of the interface or spend some time to determine when to remove it.
        klysm 3y ago
        Oops I replied to the wrong comment. I meant to reply to the parent and was trying to say the same thing
  - klysm 3y ago
    Yeah there's definitely other tradeoffs involved when decomposing a program into multiple binaries connected over the network, deployment coupling being one of them. However, I still think this is fairly related to what I was trying to convey because it's related to the _process_ of the engineering vs. the technical merit of the deployed solution. The tradeoff space you're describing is pretty much a function of how big the team is, how it's structured, the products uptime requirements, deployment frequency, etc. as opposed to the technical merit of the design in isolation. I don't think I worded it particularly well in my original comment, but I think these tradeoffs are interesting and frequently people talk past eachother about them because the 'right' decision depends on all the non-technical factors of the product.
  - 10000truths 3y ago
    Why does a monolith imply one massive build? Pretty much every compiled language has some concept of pre-compiled modules. Java has class files, C/C++ has shared/static object files, Rust has rlibs, Golang has internal object files, and so on. Caching them in a CI/CD pipeline is one of the first steps in the DevOps checklist for reducing build times.
    - strken 3y ago
      Massive in terms of the changes going into it rather than the time required. Commits will be batched together while the previous CI/CD job runs, then each deploy will have a bunch of stuff on it. A single failure will halt the deploy for every change, and someone will need to go find and revert whatever caused it. Microservices split up the management across services, which ideally means each team only has to fix its own broken builds. I want to be clear that I don't think microservices are a good idea for most companies. I just disagree with "Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed." It's not about the walls, it's about the independence of development and deployment. There are easier ways to enforce walls without such ridiculous operational and technological overhead.
      - klysm 3y ago
        Agreed that perhaps the notion of walls I used was too narrowly focused on code modularity, but I think we're pretty much saying the same thing about isolation and independence. The ability to apply local reasoning is the important part - if 'wall' is taken to mean something like this then I think we are in agreement.
- mrinterweb 3y ago
  I agree that the boundaries are not naturally enforced and need to be put in place by the developers. It is a team culture thing to enforce these types of boundaries in code review.
  - klysm 3y ago
    Agreed. Doing micro-anything is accepting that your team can’t keep good walls

klysm 3y ago

They can, but the walls are not strong enough to perturb those programmers who do not know any better, don’t care, or are under sufficient pressure to sweep aside good practice. Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed. It’s obvious that strong walls have immense cost, but perhaps for a large enough organization it enables faster movement overall with fewer faults. Walls are good after all. What’s fascinating to me about micro-anything vs. monolith-anything is it’s much more a function of team structure and culture than of technical merit. In some cases, the technically inferior solution can deliver more to the business when combined with the unfortunate realities of human development. I agree with the original offer that micro-anything should ultimately be considered a failure of better modularity mechanisms.

strken 3y ago
I thought it was more about independence. Got a bug in your service? Instead of one massive build deployed once an hour/day/week/etc. that gets rolled back if any commit was bad, you deploy your service when it changes and don't worry too much about the unrelated pieces.
- Sankozi 3y ago
  Got a feature that touches several modules? Instead of one massive build deployed once, you deploy each service. With dependencies you need to wait after each deployment to check if everything is ok. Instead of one big build and one deployment, you get quick build, deployment, check, quick build deployment, check... So in case of microservices/microfrontends you gain minutes on build time but lose hours/days on deployment and verification.
  - klysm 3y ago
    Yes that is true, but the other side of that coin is that deploying changes to the interface between modules is now hard - that's the tradeoff space. If you have really clear interfaces with low churn then you probably have a net win, but in my experience it's really hard to get those interfaces right and that cost can end up beating your gains.
    - Sankozi 3y ago
      Not sure what you mean. Changes to the interfaces in modular monolith are much easier than in microservices. You just release new version with updated interfaces - no need for versioning if you update interface and its usages. In case of microservices you must do versioning and either have to keep and support old version of the interface or spend some time to determine when to remove it.
      - klysm 3y ago
        Oops I replied to the wrong comment. I meant to reply to the parent and was trying to say the same thing
- klysm 3y ago
  Yeah there's definitely other tradeoffs involved when decomposing a program into multiple binaries connected over the network, deployment coupling being one of them. However, I still think this is fairly related to what I was trying to convey because it's related to the _process_ of the engineering vs. the technical merit of the deployed solution. The tradeoff space you're describing is pretty much a function of how big the team is, how it's structured, the products uptime requirements, deployment frequency, etc. as opposed to the technical merit of the design in isolation. I don't think I worded it particularly well in my original comment, but I think these tradeoffs are interesting and frequently people talk past eachother about them because the 'right' decision depends on all the non-technical factors of the product.
- 10000truths 3y ago
  Why does a monolith imply one massive build? Pretty much every compiled language has some concept of pre-compiled modules. Java has class files, C/C++ has shared/static object files, Rust has rlibs, Golang has internal object files, and so on. Caching them in a CI/CD pipeline is one of the first steps in the DevOps checklist for reducing build times.
  - strken 3y ago
    Massive in terms of the changes going into it rather than the time required. Commits will be batched together while the previous CI/CD job runs, then each deploy will have a bunch of stuff on it. A single failure will halt the deploy for every change, and someone will need to go find and revert whatever caused it. Microservices split up the management across services, which ideally means each team only has to fix its own broken builds. I want to be clear that I don't think microservices are a good idea for most companies. I just disagree with "Micro-anything is the philosophy based in the presumption that your engineers will not respect softer walls and modules and therefore strong ones must be constructed." It's not about the walls, it's about the independence of development and deployment. There are easier ways to enforce walls without such ridiculous operational and technological overhead.
    - klysm 3y ago
      Agreed that perhaps the notion of walls I used was too narrowly focused on code modularity, but I think we're pretty much saying the same thing about isolation and independence. The ability to apply local reasoning is the important part - if 'wall' is taken to mean something like this then I think we are in agreement.
mrinterweb 3y ago
I agree that the boundaries are not naturally enforced and need to be put in place by the developers. It is a team culture thing to enforce these types of boundaries in code review.
- klysm 3y ago
  Agreed. Doing micro-anything is accepting that your team can’t keep good walls