7 ms·

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

lemmsjid 3y ago
You can do the same with the approach I described. If you set up the modular DAG as I mentioned above, you can now set up service boundaries between the leaves of the DAG. E.g. parts of the code call other parts of the code as a service. You then version and deploy the same codebase separately. Say you have Libraries A, B, and C, where B and C depend on A and not one another. You can have B call into C via a service, just as you would in a microservice. Now B and C can be versioned and deployed independency. You can also deploy updates to Library A incrementally, tying it to the B and C deployments. If you are literally pushing different features that are in fact unrelated, you don't even need to worry about B calling into C, you can just partition your app into different modules, deploy them separately, and use a load balancer with routing rules to arbitrate between the deployments. I like having this type of environment because you can make fairly quick and easily-resersible decisions about whether or not different parts of the codebase are deployed differently: sometimes it's compute and hardware requirements, sometimes it's because you want parts to be stable and other parts more experimental and volatile. The microservice argument isn't addressing this type of deployment scenario: it's suggesting a shared-nothing or shared-little architecture across services.
charcircuit 3y ago
> a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once. git revert <bad commit>
- LelouBil 3y ago
  Well yes, but if you used a compiled language you have to make a new release based on this commit. What I mean is, if you have v2 of your software that introduces a bugfix for module A that's perfectly fine and a bugfix for module B that breaks everything, you can just roll back just module B directly with your deployment pipeline. There's no need to go back to the code base and make a new release.

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

lemmsjid 3y ago

You can do the same with the approach I described. If you set up the modular DAG as I mentioned above, you can now set up service boundaries between the leaves of the DAG. E.g. parts of the code call other parts of the code as a service. You then version and deploy the same codebase separately. Say you have Libraries A, B, and C, where B and C depend on A and not one another. You can have B call into C via a service, just as you would in a microservice. Now B and C can be versioned and deployed independency. You can also deploy updates to Library A incrementally, tying it to the B and C deployments. If you are literally pushing different features that are in fact unrelated, you don't even need to worry about B calling into C, you can just partition your app into different modules, deploy them separately, and use a load balancer with routing rules to arbitrate between the deployments. I like having this type of environment because you can make fairly quick and easily-resersible decisions about whether or not different parts of the codebase are deployed differently: sometimes it's compute and hardware requirements, sometimes it's because you want parts to be stable and other parts more experimental and volatile. The microservice argument isn't addressing this type of deployment scenario: it's suggesting a shared-nothing or shared-little architecture across services.

charcircuit 3y ago

> a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once. git revert <bad commit>

LelouBil 3y ago
Well yes, but if you used a compiled language you have to make a new release based on this commit. What I mean is, if you have v2 of your software that introduces a bugfix for module A that's perfectly fine and a bugfix for module B that breaks everything, you can just roll back just module B directly with your deployment pipeline. There's no need to go back to the code base and make a new release.