I agree with you, but you are also kind of wrong only due to why software architects ROYALY mess up about MSA: chopping up APIs by entity. Architects don't tend to make the same mistakes with other applications. If its a website, then those will be logically split by.. by what the website IS. If its a batch application, then the batch had to be named something. It has a purpose. It has BOUNDARIES inherent in it's application description. APIs don't necessarily have those boundaries and thus are the primary painpoint in MSA: how to define the boundaries of an API. When you have the goal to have microservices, but don't have multiple logical API boundaries, architects all seem to make the titanic mistake of separating a perfectly cohesive API by Entity, like a UserService, AccountService, SubscriptionService, etc. These might just be database tables and the architect decides that each table needs it's own service. And even if you can define an API's boundary CAN you separate them, or is there something tightly coupling them? If that is going to be a problem to decouple them, do you really NEED to? But when the goal is to have microservices, and you don't yet have a justification for more than one API, people foolishly choose to define boundaries around silly things. A website can be a single application with well defined boundaries, but it somehow needs to call 30 different APIs all defined around a single entity each....
That was exactly what I was trying to understand, and you condensed it in less than 5 minutes. Superb!
Brilliant, just cut right to the key point!
Very informative video. Thank you
Thanks so much.. I found it helpful
Nice
Awesome
I agree with you, but you are also kind of wrong only due to why software architects ROYALY mess up about MSA: chopping up APIs by entity.
Architects don't tend to make the same mistakes with other applications. If its a website, then those will be logically split by.. by what the website IS.
If its a batch application, then the batch had to be named something. It has a purpose. It has BOUNDARIES inherent in it's application description.
APIs don't necessarily have those boundaries and thus are the primary painpoint in MSA: how to define the boundaries of an API.
When you have the goal to have microservices, but don't have multiple logical API boundaries, architects all seem to make the titanic mistake of separating a perfectly cohesive API by Entity, like a UserService, AccountService, SubscriptionService, etc.
These might just be database tables and the architect decides that each table needs it's own service.
And even if you can define an API's boundary CAN you separate them, or is there something tightly coupling them? If that is going to be a problem to decouple them, do you really NEED to?
But when the goal is to have microservices, and you don't yet have a justification for more than one API, people foolishly choose to define boundaries around silly things.
A website can be a single application with well defined boundaries, but it somehow needs to call 30 different APIs all defined around a single entity each....