Macroservices are the way to go. Currently I work on a system that is a macroservice basically. We have more than one team working on the service which is great, since that means on-call rotations, upgrades, etc are much more reasonable. Having 50 people on a service really takes work off compared to 6, and there is a lot less reinventing the wheel. As long as the CICD pipeline is solid there really isn't any issues with a lot of teams working on the same code base.
As you say having a "Billing" service is much better than what you would typically see in a microservices architecture that you'll have a Billing-Stripe, Billing-Visa, Billing-Invoices, and so on, creating a web of dependencies.
Exactly. So long as merge conflicts stay within the team (i.e. your macroservice is logically divided within the code, models and services aren't just thrown into a models and services package or folder. I really detest merge conflicts when I can't track the work or have to reach out to another team to discern intent.
Having microservices for billing where you have Billing-stripe, Billing-visa, would make me want to scream. Why not a generic abstract or interface and those are simply implementations within the billing service? Macroservices FTW.
The important advantage is that you can scale parts of the "macroservice" independently when they're microservices. You can isolate stateful stuff into one microservice and then it is much easier to scale the other microservices horizontally.
Comments
Macroservices are the way to go. Currently I work on a system that is a macroservice basically. We have more than one team working on the service which is great, since that means on-call rotations, upgrades, etc are much more reasonable. Having 50 people on a service really takes work off compared to 6, and there is a lot less reinventing the wheel. As long as the CICD pipeline is solid there really isn't any issues with a lot of teams working on the same code base.
As you say having a "Billing" service is much better than what you would typically see in a microservices architecture that you'll have a Billing-Stripe, Billing-Visa, Billing-Invoices, and so on, creating a web of dependencies.
Exactly. So long as merge conflicts stay within the team (i.e. your macroservice is logically divided within the code, models and services aren't just thrown into a models and services package or folder. I really detest merge conflicts when I can't track the work or have to reach out to another team to discern intent.
Having microservices for billing where you have Billing-stripe, Billing-visa, would make me want to scream. Why not a generic abstract or interface and those are simply implementations within the billing service? Macroservices FTW.
The important advantage is that you can scale parts of the "macroservice" independently when they're microservices. You can isolate stateful stuff into one microservice and then it is much easier to scale the other microservices horizontally.