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

261–270 of 469 posts

Re: The Death of Microservice Madness in 2018

#261

Post by NicoJuicy »

ohyes wrote: post #97
JamesBarney wrote: post #90

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

I have a web app with a "file store" ( eg. simple dropbox over API) that i manage. I haven't touched it in a year and it uploads files, proxies them, resizes, ...

And it's just one of many.

Re: The Death of Microservice Madness in 2018

#262

Post by flukus »

charlieflowers wrote: post #242
Chiba-City wrote: post #177

Earlier quoted context omitted.

I was going to mention RMI, but couldn't recall the TLA. Does anyone else remember LANS and Windows NetDDE? That got end user machines involved in "distributed" computations.

COM+ also had distributed transactions. I was fortunate not to work with it too much.

Was this in the protocol? I thought that was around the same time as DTCC which is pretty good IMO.

Re: The Death of Microservice Madness in 2018

#264

Post by misio »

kuschku wrote: post #259
dreamcompiler wrote: post #175

Earlier quoted context omitted.

I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

That may be a bad analogy, considering painting your own apartment is something a great deal of people do, and often with good success. My parents (not in any way experts on that field) painted their entire house themselves, except for two rooms that were painted by a professional painter, and the professional painter left much worse corners than my parents. This was the paid-for result (ignore the dark corner at the…

Analogies don't always have to apply to your parents.

Re: The Death of Microservice Madness in 2018

#265

Post by lulmerchant »

manigandham wrote: post #249

There is no such thing as "microservices", it's just services, otherwise known as a service-oriented architecture (SOA). A service is a logical grouping of functionality as it makes sense in your business domain. A small service for a large company can be bigger than the entire product of a startup; there is no standard unit of measure. Computers also don't care how code is deployed and different services can be boun…

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've written plenty of well performing API endpoints in microservices, and I've also done a fair bit of business process automation with them.

Re: The Death of Microservice Madness in 2018

#266

Post by ozim »

dragonwriter wrote: post #200
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.

I think that it is accurate to say that in a system composed of microservices, a microservice should not effect the state of other microservices in the system other than by consuming them. Whether it should consume other microservices is less clear, and gets into the choreography vs. orchestration issue; choreography provides lower coupling, but may be less scalable.

Services consuming other services, sounds like recipe for spaghetti. I hope people use layering where you don't call stuff that is in the same layer.

Re: The Death of Microservice Madness in 2018

#267

Post by kuschku »

misio wrote: post #264
kuschku wrote: post #259

Earlier quoted context omitted.

That may be a bad analogy, considering painting your own apartment is something a great deal of people do, and often with good success. My parents (not in any way experts on that field) painted their entire house themselves, except for two rooms that were painted by a professional painter, and the professional painter left much worse corners than my parents. This was the paid-for result (ignore the dark corner at the…

Analogies don't always have to apply to your parents.

My argument is that painting is a much smaller skill difference between a hobbyist and a mediocre professional.

Actually good software engineering is a much larger skill difference.

Re: The Death of Microservice Madness in 2018

#268

Post by simias »

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…

The #1 thing they should teach in any engineering school (or maybe any school period) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

Re: The Death of Microservice Madness in 2018

#269

Post by walrus1066 »

z3t4 wrote: post #43
nemothekid wrote: post #33

Earlier quoted context omitted.

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…

You don't always have to know why but it's somewhat frightening that so many "engineers" don't have a clue why they are doing something (because Google does it). And I'm of course guilty of it myself jumping on the hype-train or uncritically taking advice from domain experts only to find out years later that much of it was BS. Most of the time though, you will not reach enlightenment. I guess it's in our nature to fo…

They're only following their incentives.

What's gonna look better on a devs CV: 'spent a year maintaining a CRUD monolith app' vs 'spent a year breaking monolith into microservices, with shiny language X to boot'.

We can be a very fashion and buzzword driven industry sometimes.

EDIT: this perverse incentive goes all they way to the top, through to CTO level. Sometimes I wonder if businesses understand just how much money and effort is wasted on pointless rewrites that make life harder for everyone.

Re: The Death of Microservice Madness in 2018

#270

Post by cc81 »

Mc_Big_G wrote: post #151

Next up, mixing logic and presentation like it's 1999 cough php cough react native

Have you seen the talk "Rethinking best practices" from back when React was first launched?

https://www.youtube.com/watch?v=x7cQ3mrcKaY

It addresses this and is pretty great in my opinion. Of course one does not have to agree with it but it is not the same as the mess back then and usually the separation of concerns is more about separations of technology than concerns.

As an an example:

Let us say we have a shopping basket up in the top right corner of our web page. For me there is a big difference between the logic of calculating to the total sum of the parts we have in it or collapsing/expanding it. One is "business logic" and one is "presentation logic" and they are not the same.

And I also bet that if for example HTML or CSS had native collapse/expand then people would consider that presentation as well and not to mention all the logic you usually have (loops, conditions) in a normal template language.

Post reply on HN