Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defence of the Monolith, Part 2

infoq.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: In Defence of the Monolith, Part 2

#11

Post by vitalus »

beachy wrote: post #2

All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements. Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as lon…

> Yet would anyone seriously consider altering a monolithic HR application to add pet insurance management? Never.

Sure they might? I can't see a category of business features that would naturally lend themselves to being microservices rather than extended features of a monolith unless there was some real technical challenge that was otherwise more easily solved by being in a microservice.

Re: In Defence of the Monolith, Part 2

#14

Post by qaq »

beachy wrote: post #2

All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements. Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as lon…

calling something over http vs calling functions or class methods does not make much difference. So in your example how does it make it easier to add vs monolith? Monolith can have well defined modules and interfaces and microservices could be an entangled mess.

Re: In Defence of the Monolith, Part 2

#15

Post by nine_k »

qaq wrote: post #14
beachy wrote: post #2

All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements. Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as lon…

calling something over http vs calling functions or class methods does not make much difference. So in your example how does it make it easier to add vs monolith? Monolith can have well defined modules and interfaces and microservices could be an entangled mess.

No one owns the whole stack. You pick your "main" software, and customize it with third-party services. None of it runs on your premises. No party is willing to expose much more than an API.

Re: In Defence of the Monolith, Part 2

#16

Post by nine_k »

vitalus wrote: post #11
beachy wrote: post #2

All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements. Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as lon…

> Yet would anyone seriously consider altering a monolithic HR application to add pet insurance management? Never. Sure they might? I can't see a category of business features that would naturally lend themselves to being microservices rather than extended features of a monolith unless there was some real technical challenge that was otherwise more easily solved by being in a microservice.

The challenge can be non-technical. The tech can be trivial, the business know-how, key.

Re: In Defence of the Monolith, Part 2

#17

Post by qaq »

nine_k wrote: post #15
qaq wrote: post #14

Earlier quoted context omitted.

calling something over http vs calling functions or class methods does not make much difference. So in your example how does it make it easier to add vs monolith? Monolith can have well defined modules and interfaces and microservices could be an entangled mess.

No one owns the whole stack. You pick your "main" software, and customize it with third-party services. None of it runs on your premises. No party is willing to expose much more than an API.

"No one owns the whole stack" - depending on the nature of what you are integrating this can either speed things up or slow things down

"You pick your "main" software, and customize it with third-party services" - not much difference monolith vs microservices

"None of it runs on your premises" - totaly unrelated to monolith vs microservices

"No party is willing to expose much more than an API" - again consuming an API can actually be easier in monolith vs microservices

Re: In Defence of the Monolith, Part 2

#18

Post by sbov »

beachy wrote: post #2

All these architectural discussions seem to assume a kind of black box business system where the microservices vs monolith discussion is an internal one, conducted by and for techies, and limited to a rigid view of the business requirements. Perhaps the early microservices evangelizers such as Netflix have created this environment - after all, who cares whether Netflix is a monolith or a swarm of microservices as lon…

It seems like you're talking about a plugin architecture, not necessarily microservices. Microservices could be a way to implement it. Not all systems built with microservices could support a plugin like that, not all plugins need to use microservices, and even if you do you might have to write some form of adapter to integrate someone else's service with your system.

E.g. most video games support stuff like this, but they definitely don't use microservices.

Re: In Defence of the Monolith, Part 2

#19

Post by arglwarg »

parenthephobia wrote: post #13
empthought wrote: post #7

Earlier quoted context omitted.

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.
Post reply on HN