Re:Modern-Day Architecture Design Patterns for Software Prof...
by tmd83 on Wednesday October 14, 2020 @01:51PM
(#24779445)
I think you can use such an architecture without almost zero or minimal code change. You don't have to split the shared endpoints using some remote API calls since they are all available inside your monolith.
Re:Modern-Day Architecture Design Patterns for Software Prof...
by amf12 on Wednesday October 14, 2020 @01:55PM
(#24779484)
Agreed. Which is why I mentioned simplicity being a benefit - if you already have a monolith that you are seeing issues with. But the parent said "You don't need microservices to do this."; this solution isn't much different from microservices.
Re:Modern-Day Architecture Design Patterns for Software Prof...
by janstice on Thursday October 15, 2020 @05:15AM
(#24786522)
The GP solution has very little in common with microservices - it’s just a load balanced architecture with specific pools for different workloads. Just like we could do in the 90s.
Microservices are only microservices if they have both narrow focus and radical independence. If they have narrow focus without the independence then you probably have a monolith with 25 executables to deploy.
Don't you now have "microservices" bundled together in a single binary - and deployed together? If each of your component exposes different APIs and each instance only handles certain endpoints, then you kind of have microservices - not literally, but it seems the idea is the same.
Simplicity being a benefit, I don't really see how the dynamic traffic routing is a huge benefit vs microservices - you can dynamically scale up/down microservices too.
I am not saying this is a bad approach, by the way, but just that it isn't much different from microservices.