This is a great approach. I like to add “macroservices” into conversations around this because I think it sums up the end state better. It’s not micro. It’s an entire billing system. It just only has API’s and not a front-end. Integrate it. That’s a macroservice. Or a service that handles the subscription, billing, and entitlements as one. That’s a macroservice and that’s totally acceptable.
What kills me is when there’s a monolith that breaks when other teams commit code. If I have to stash changes and deal with merge conflicts outside my team, it needs to be broken up.
Worry about scaling when you have a need to scale.
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
This is a great approach. I like to add “macroservices” into conversations around this because I think it sums up the end state better. It’s not micro. It’s an entire billing system. It just only has API’s and not a front-end. Integrate it. That’s a macroservice. Or a service that handles the subscription, billing, and entitlements as one. That’s a macroservice and that’s totally acceptable.
What kills me is when there’s a monolith that breaks when other teams commit code. If I have to stash changes and deal with merge conflicts outside my team, it needs to be broken up.
Worry about scaling when you have a need to scale.
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.
You might find the concept of Self-contained Systems, or SCS, interesting:
https://scs-architecture.org/
Disclaimer: I helped with the concept a tiny bit.
It sounds like you invested some effort to come up with a brand new buzzword to refer to microservices.
Sounds like microservices to me
I might start calling this a Megalith, since it kinda fits if you squint at the definition.