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

51–60 of 469 posts

Re: The Death of Microservice Madness in 2018

#51

Post by fnbr »

TekMol wrote: post #24
fnbr wrote: post #10

Earlier quoted context omitted.

That's what I did for a recent side project. It worked really well, although coordinating the different services was a bit of a pain. We ended up using a cronjob to run everything repeatedly, which was inefficient but worked. If we had the time we would have used a proper RPC framework or some sort of queue.

What do you mean by 'run everything repeatedly'?

For instance, say I had 2 services, a scraper and then a ML algorithm that classified the scraped data. You only need to run the ML classifier when there's new data. I didn't have anything set up to tell the classifier "hey! There's new data to classify!" Instead, I just ran it every 5 minutes, which was sufficient latency for the project.

Re: The Death of Microservice Madness in 2018

#52

Post by dominotw »

dvt wrote: post #29
sk5t wrote: post #21

Earlier quoted context omitted.

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

A microservice, imo, should just be a simple black box that takes in some input and returns some output (sometimes asynchronously). No side-effects necessary. No fiddling with database flags or global state, and definitely no hitting other microservices. See @CryoLogic's post for a good example. This means that you simply can't build some things using microservices -- like logging in a user -- and you'd be right.

> A microservice, imo, should just be a simple black box that takes in some input and returns some output

I am not quite sure what you mean. A microservice with REST api that has POST method is not a microservice?

Re: The Death of Microservice Madness in 2018

#53

Post by jimktrains2 »

cjalmeida wrote: post #42
TekMol wrote: post #22

Earlier quoted context omitted.

How does an additional layer make changes to the DB easier? If a column is dropped what will your layer do when a request for data from that column comes in? What if the request joins it with other columns from other tables?

In proper microservices architecture only a single application access the DB. Other apps get the data via an API call. Thus you can drop the column (maybe it's derived data) and still keep the API interface. In the end, it's mostly about enforcing contracts and making devops simpler.

I mean, that's not true at all. No two apps should be working off the same database. Different services can have their own datastores.

Re: The Death of Microservice Madness in 2018

#54

Post by shitloadofbooks »

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 generation had no idea what they were doing and they'll do it way better. They usually nail the first 80%, then hit a new edge case not well handled by their architecture/model (but was by the old system) and/or start adding swathes of new features during the rewrite.

In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again.

Re: The Death of Microservice Madness in 2018

#55

Post by gfiorav »

Nice article but I'd point out two things:

1. 'Death' is a bit too extreme. I think everybody is excited at first and tries to find an excuse to use microservices. We're assisting to a decline in that initial push, that's all.

2. I think the point about transactions is fair, as well as the expertise and team concerns, but the rest are mostly "it's too hard and complex". It'll get better with time. I think that being a bit uncomfortable as a dev is not too bad, that's what we're here for (assuming there's a real need of course).

Re: The Death of Microservice Madness in 2018

#57

Post by outworlder »

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…

I do have a case of monoliths-in-disguise-itis.

I just wish someone with "street cred" (or with a famous, recognizable name I could use for appeal to authority) could create a simple post saying "Hey, if you have a shared data store that all services depend on and are accessing directly, you are not doing microservices". "And you also don't have microservices if you have to update everything in one go as part of a "release"".

That way I could circulate it throughout the company and maybe get the point across. I've tried to argue unsuccessfully. After all, "we are doing K8s, so we have micro-services, each is a pod, duh!" No, you have a monolith, which happens to be running as multiple containers...

Re: The Death of Microservice Madness in 2018

#58

Post by meddlepal »

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 various interests from bothering the developers. Those almost always point to a failure of management in my mind rather than a technical failure.

Re: The Death of Microservice Madness in 2018

#59

Post by joshschreuder »

dvt wrote: post #29
sk5t wrote: post #21

Earlier quoted context omitted.

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

A microservice, imo, should just be a simple black box that takes in some input and returns some output (sometimes asynchronously). No side-effects necessary. No fiddling with database flags or global state, and definitely no hitting other microservices. See @CryoLogic's post for a good example. This means that you simply can't build some things using microservices -- like logging in a user -- and you'd be right.

Aren't you talking about pure functions, more applicable to serverless than the commonly accepted use of microservices?

Re: The Death of Microservice Madness in 2018

#60

Post by friendly_chap »

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…

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?

Post reply on HN