5 ms·

if you have a well modularized monolith, you can get best of both worlds.

synack 3y ago
Agreed! Software modules and libraries can achieve the same independence of subsystems without implying a network topology.
jayd16 3y ago
Not really. You can't really reduce the blast radius of crashes or bad deployments. You need to have the discipline of a good CI/CD instead of siloed but decoupled workflows. Just keeping things neat doesn't go nearly as far as a separate process on separate machines. Monolith might be better but I don't think it's a situation where you can have it all.
- aidos 3y ago
  This argument always confuses me. It depends on what you’re doing but if you’re doing web services, as most here are, the crash is limited to the request being served. The blast radius is a single request, right? In every likelihood it _is_ a separate process on a separate machine.
  - threeseed 3y ago
    They are talking about deployment. With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down. With a monolith the whole system is down.
    - quickthrower2 3y ago
      There are a lot of deployments options to mitigate that risk.
    - charcircuit 3y ago
      >With a monolith the whole system is down. No, you are just at reduced capacity. The moral of the story is not to roll out to 100% right away.
      - threeseed 3y ago
        Monoliths go hand in hand with a centralised database. Bit hard to do schema evolution with a staggered rollout.
        charcircuit 3y ago
        The software should be compatible with both the old and new schema until all of your database servers have moved over to the new schema. All rollouts are going to be somewhat staggered even if you go straight to 100%.
        DougBTX 3y ago
        If schema migrations take non-zero time and you want zero-downtime deployments, then the both service versions need to be compatible with either the new schema or the old schema, regardless of service size.
        ownagefool 3y ago
        The same problem exists in microservoce land, only you now have a load of separate teams managing their own database, perhaps with different solutions.
        hervem 3y ago
        Wait, micro-service and sharing same DB? Did I miss something?
        ownagefool 3y ago
        I think you misunderstood what I said, which is you still have databases and ergo need to manage migrations and such, only that this now typically falls to the specific teams. That said, loads of folks do microservices with a shared dB.
    - gizzlon 3y ago
      > With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down. In theory, but when the getUser service is down, your app is probably broken as well.
  - jayd16 3y ago
    Even for a web service, imagine a small feature is causing the app to crash to OOM, or too many file handles or something that will take out the whole process and not just the one request. If you have long running requests (something beside small rest calls like large data transfers) then any being served by that same process are taken down.
- DougBTX 3y ago
  > You need to have the discipline of a good CI/CD Good CD is even more important if there are more services to deploy
croo 3y ago
That is a big if that can be easily broken by a new guy who don't know the rules or if the pace is fast enough that you cannot review everything. If the codebase is different you can force the separation not just ask nicely to keep the code well modularized.
- meowtimemania 3y ago
  You can enforce modularity with git acls, and multi-module workspaces within a single git repository. for example: golang - multi-module workspaces javascript - yarn workspaces With this setup, you can create modules a, b and c. And then add restrictions about which which modules are available to a given module
mmcnl 3y ago
Yes, only it takes a while to figure out the right level of abstraction for your organization. It's difficult to start right out of the box with the right type of modularization.

Agreed! Software modules and libraries can achieve the same independence of subsystems without implying a network topology.

jayd16 3y ago

Not really. You can't really reduce the blast radius of crashes or bad deployments. You need to have the discipline of a good CI/CD instead of siloed but decoupled workflows. Just keeping things neat doesn't go nearly as far as a separate process on separate machines. Monolith might be better but I don't think it's a situation where you can have it all.

aidos 3y ago
This argument always confuses me. It depends on what you’re doing but if you’re doing web services, as most here are, the crash is limited to the request being served. The blast radius is a single request, right? In every likelihood it _is_ a separate process on a separate machine.
- threeseed 3y ago
  They are talking about deployment. With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down. With a monolith the whole system is down.
  - quickthrower2 3y ago
    There are a lot of deployments options to mitigate that risk.
  - charcircuit 3y ago
    >With a monolith the whole system is down. No, you are just at reduced capacity. The moral of the story is not to roll out to 100% right away.
    - threeseed 3y ago
      Monoliths go hand in hand with a centralised database. Bit hard to do schema evolution with a staggered rollout.
      - charcircuit 3y ago
        The software should be compatible with both the old and new schema until all of your database servers have moved over to the new schema. All rollouts are going to be somewhat staggered even if you go straight to 100%.
      - DougBTX 3y ago
        If schema migrations take non-zero time and you want zero-downtime deployments, then the both service versions need to be compatible with either the new schema or the old schema, regardless of service size.
      - ownagefool 3y ago
        The same problem exists in microservoce land, only you now have a load of separate teams managing their own database, perhaps with different solutions.
        hervem 3y ago
        Wait, micro-service and sharing same DB? Did I miss something?
        ownagefool 3y ago
        I think you misunderstood what I said, which is you still have databases and ergo need to manage migrations and such, only that this now typically falls to the specific teams. That said, loads of folks do microservices with a shared dB.
  - gizzlon 3y ago
    > With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down. In theory, but when the getUser service is down, your app is probably broken as well.
- jayd16 3y ago
  Even for a web service, imagine a small feature is causing the app to crash to OOM, or too many file handles or something that will take out the whole process and not just the one request. If you have long running requests (something beside small rest calls like large data transfers) then any being served by that same process are taken down.
DougBTX 3y ago
> You need to have the discipline of a good CI/CD Good CD is even more important if there are more services to deploy

croo 3y ago

That is a big if that can be easily broken by a new guy who don't know the rules or if the pace is fast enough that you cannot review everything. If the codebase is different you can force the separation not just ask nicely to keep the code well modularized.

meowtimemania 3y ago
You can enforce modularity with git acls, and multi-module workspaces within a single git repository. for example: golang - multi-module workspaces javascript - yarn workspaces With this setup, you can create modules a, b and c. And then add restrictions about which which modules are available to a given module

mmcnl 3y ago

Yes, only it takes a while to figure out the right level of abstraction for your organization. It's difficult to start right out of the box with the right type of modularization.