4 ms·
I think what you have there is a monolithic HR application and a smaller monolithic pet insurance application that exchange information via enterprise integrati
by empthought 10y ago
I think what you have there is a monolithic HR application and a smaller monolithic pet insurance application that exchange information via enterprise integration, not a microservice architecture.
- abraae 10y agoI 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...
- stuartaxelowen 10y ago"Microservices are just tiny monoliths" - gasp
- empthought 10y agoThey're not, though. sed is a microservice. Emacs is a monolith. Sed is not a tiny emacs.
- parenthephobia 10y agoNobody said it was: sed is a tiny perl.
- arglwarg 10y agosed is maximum viable perl. Well maybe awk, but that is pushing it.