In Defence of the Monolith, Part 2

Re:In Defence of the Monolith, Part 2 by abraae on Sunday March 26, 2017 @08:48PM (#13964307)

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?

[ Parent | on HN ]

Re:In Defence of the Monolith, Part 2 by empthought on Sunday March 26, 2017 @09:07PM (#13964372)

What'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/messag...

[ Parent | on HN ]