Hacker News Reader

Comment by empthought | Hacker News Reader

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.

View on HN

"Microservices are just tiny monoliths" - gasp

They're not, though. sed is a microservice. Emacs is a monolith. Sed is not a tiny emacs.

Nobody said it was: sed is a tiny perl.

sed is maximum viable perl. Well maybe awk, but that is pushing it.

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?

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...

Reply on news.ycombinator.com