3 ms·
I don't usually find arguing over names to be productive. Your "smaller monolithic" application is my microservice. What's in a name? But as a customer, if I h
by abraae 10y ago
I don't usually find arguing over names to be productive. Your "smaller monolithic" application is my microservice. What's in a name?
But as a customer, if I have a HR app from vendor A, and then I want to add a pet insurance app from vendor B, the last thing I want to do is to roll out some creaky enterprise integration process/framework/product. If those products work together via APIs why should I take any of the burden of integration?
- empthought 10y agoWhat's in a name? Microservices are fine-grained and operate on a single bounded context, where applications typically have coarser-grained interfaces and involve multiple contexts. I suppose if your pet insurance system were only to provide a constrained list of values of pet insurance products, and provide an interface to associate them with a user ID from the HR monolith, then it's a microservice. (Of course, you've pushed off the integration with the _actual_ pet insurance app somewhere else, but that might be OK.) "APIs" are an enterprise integration technique [1]. There's nothing inherently creaky or frameworkey about them. [1] http://www.enterpriseintegrationpatterns.com/patterns/messaging/ComposedMessagingWS.html http://www.enterpriseintegrationpatterns.com/patterns/messag...