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

The Death of Microservice Madness in 2018

dwmkerr.com

Post reply on HN
Print view View original

61–70 of 469 posts

Re: The Death of Microservice Madness in 2018

#61

Post by openasocket »

dvt wrote: post #47
friendly_chap wrote: post #45

Earlier quoted context omitted.

> A microservice should generally not have side effects. That's plainly wrong. I get the gist of what you are saying and I more or less agree with it but you expressed it poorly. Having API dependencies is not an issue. As long as the microservices don't touch each others data and only communicate with each other through their API boundaries microservices can and should build on top of each other. In fact that's one…

> That's plainly wrong. I get the gist of what you are saying and I more or less agree with it but you expressed it poorly. I'm not sure what you think side effects are, but I'm using the standard computer science definition you can look up on Wikipedia. If you have a microservice that modifies, e.g. some hidden state, it's a disaster waiting to happen. Having multiple microservices that have database side-effects wi…

So, according to your advice, we shouldn't use micro-services that write to a database, ever? That doesn't make any sense to me. Multiple services writing to the same database can be bad, but a single service storing persistent state in a database is perfectly fine. Just because we're micro- doesn't mean we have to cut out 90% of what a service is.

Re: The Death of Microservice Madness in 2018

#62

Post by dvt »

friendly_chap wrote: post #60
dvt wrote: post #47

Earlier quoted context omitted.

> That's plainly wrong. I get the gist of what you are saying and I more or less agree with it but you expressed it poorly. I'm not sure what you think side effects are, but I'm using the standard computer science definition you can look up on Wikipedia. If you have a microservice that modifies, e.g. some hidden state, it's a disaster waiting to happen. Having multiple microservices that have database side-effects wi…

I'm using the same definition. Writing data to a database is a side effect. If there is no side effect then what's the point of calling a service? So it does computation? Then who saves the result of that computation, thus doing a side effecting operation? If no one then what's the point of that service's existence?

A side effect is by definition some mutation that's out of the scope of the function -- if the purpose of the microservice is to put stuff in a database, then (by definition) it's not a side effect. Switching a flag on top of doing some work, on the other hand (e.g. flip "processed" to true in a global database) is a side effect.

Re: The Death of Microservice Madness in 2018

#63

Post by napsterbr »

CryoLogic wrote: post #8

Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression. Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.

So basically a library? :)

Re: The Death of Microservice Madness in 2018

#64

Post by brucephillips »

dvt wrote: post #62
friendly_chap wrote: post #60

Earlier quoted context omitted.

I'm using the same definition. Writing data to a database is a side effect. If there is no side effect then what's the point of calling a service? So it does computation? Then who saves the result of that computation, thus doing a side effecting operation? If no one then what's the point of that service's existence?

A side effect is by definition some mutation that's out of the scope of the function -- if the purpose of the microservice is to put stuff in a database, then (by definition) it's not a side effect. Switching a flag on top of doing some work, on the other hand (e.g. flip "processed" to true in a global database) is a side effect.

If a function writes to a DB, yes, that's a side effect. I think you're conflating "scope" and "purpose".

Re: The Death of Microservice Madness in 2018

#65

Post by [deleted] »

meddlepal wrote: post #58
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I think it has to do with control. I've written microservices and microservices tooling now for a long time... so long when I started we were just calling it something like (isolated-responsibility) SOA and we didn't have a fancy buzzword. Developers want to own their thing. Microserivces desire springs up because of a lack of communication culture and desire for siloification in a companies organization to keep vari…

[deleted]

Re: The Death of Microservice Madness in 2018

#66

Post by friendly_chap »

dvt wrote: post #62
friendly_chap wrote: post #60

Earlier quoted context omitted.

I'm using the same definition. Writing data to a database is a side effect. If there is no side effect then what's the point of calling a service? So it does computation? Then who saves the result of that computation, thus doing a side effecting operation? If no one then what's the point of that service's existence?

A side effect is by definition some mutation that's out of the scope of the function -- if the purpose of the microservice is to put stuff in a database, then (by definition) it's not a side effect. Switching a flag on top of doing some work, on the other hand (e.g. flip "processed" to true in a global database) is a side effect.

Modifying data in a database is a side effect. Since you brought up the wikipedia definition, here it is:

> In computer science, a function or expression is said to have a side effect if it modifies some state outside its scope or has an observable interaction with its calling functions or the outside world besides returning a value. For example, a particular function might modify a global variable or static variable, modify one of its arguments, raise an exception, write data to a display or file, read data, or call other side-effecting functions.

Note "write data to a display or file". I think we agree that writing to a database falls under this definition, hence using terms like "side effecting" when talking about microservices is misleading.

Re: The Death of Microservice Madness in 2018

#67

Post by merb »

nemothekid wrote: post #33
dvt wrote: post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

> Of course since they had 12 different JVM applications, the services needed a host with at least 9GiB of RAM so they used a larger instance.

well experimentally oracle solved that problem, somewhat. you could now use CDS and *.so files for some parts of your application. it probably does not eliminate every problem, but yeah it helps a bit at least. but well it would've been easier to just use apache felix or so to start all the applications on a OSGI container. this would've probably saved like 5-7 GiB of RAM.

Re: The Death of Microservice Madness in 2018

#68

Post by endorphone »

sk5t wrote: post #21
dvt wrote: post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

> A microservice should generally not have side effects I gotta ask, how is this realistic? A salient feature of most of the software I've worked on is that it has useful side effects.

It isn't realistic, and borders on absurd gatekeeping.

Re: The Death of Microservice Madness in 2018

#69

Post by philipkglass »

napsterbr wrote: post #63
CryoLogic wrote: post #8

Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression. Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.

So basically a library? :)

It's like a library that you can call regardless of language ecosystem.

I joined a company that had a large, old, and mature selection of services written in PHP. If I'd tried to rewrite that mature code in a different language I probably would have wasted a lot of time for little benefit. If I'd had to write new code in PHP just to access old code as libraries that would have been a problem too. But functionality was exposed over HTTP APIs that could be used from any language, any runtime.

Re: The Death of Microservice Madness in 2018

#70

Post by dvt »

friendly_chap wrote: post #66
dvt wrote: post #62

Earlier quoted context omitted.

A side effect is by definition some mutation that's out of the scope of the function -- if the purpose of the microservice is to put stuff in a database, then (by definition) it's not a side effect. Switching a flag on top of doing some work, on the other hand (e.g. flip "processed" to true in a global database) is a side effect.

Modifying data in a database is a side effect. Since you brought up the wikipedia definition, here it is: > In computer science, a function or expression is said to have a side effect if it modifies some state outside its scope or has an observable interaction with its calling functions or the outside world besides returning a value. For example, a particular function might modify a global variable or static variable…

Yeah, I stand corrected. I am indeed conflating scope with purpose. Should've been clearer in my OP.
Post reply on HN