The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#101

Post by crimsonalucard » Mon, Jan 22, 2018, 12:53 AM UTC

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? :)

Well you don't want to call a processor intensive task with a library. A separate service for these types of tasks is a better architecture.

Although I'm not sure whether or not a task queue architecture with separate server workers executing code passed over from a central monolithic app server is still considered a "microservice" architecture.

Re: The Death of Microservice Madness in 2018

#102

Post by virmundi » Mon, Jan 22, 2018, 12:55 AM UTC

brown9-2 wrote: post #73

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’m confused. If a microservice doesn’t call the api of any other microservices, then when is sending the requests to any of them? A large purpose of service oriented architecture is encapsulation. If no other microservices can make requests to your microservice, then you really haven’t encapsulated much.

I tend to think that the job of invoking the services lies within a gateway. For example, you can have a microservice for recipes, but a web gateway that know all of the various integrations necessary to generate a page. So the web gateway is essentially a monolith.

If and when you need to support mobile devices independently of your web UI, you can have a mobile gateway. Same idea. This gateway is optimized to know how to handle mobile traffic realities like smaller download sizes, etc.

Re: The Death of Microservice Madness in 2018

#103

Post by virmundi » Mon, Jan 22, 2018, 12:57 AM UTC

outworlder wrote: post #57

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 "r…

Martin Fowler on shared DB's: https://martinfowler.com/bliki/IntegrationDatabase.html

So yes, you now have an authority that says doing that is bad.

Re: The Death of Microservice Madness in 2018

#104

Post by humanrebar » Mon, Jan 22, 2018, 1:00 AM UTC

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…

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

I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already.

The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithic service and microservice people are trying to do exactly that. It's just what sort of scale they're thinking about and what part of the software development lifecycle they think will be especially difficult going forward.

Re: The Death of Microservice Madness in 2018

#105

Post by virmundi » Mon, Jan 22, 2018, 1:03 AM UTC

linkmotif wrote: post #50

Will someone enlighten me as to why a microservice should have no dependent services? Seems reasonable to me.

Service dependencies indicate that you're domain is not properly broken down, or that the services are communicating incorrectly. They can share information, but probably better to do so via events and data copy.

For example, you have a centralized security service. It handles the things related to accounts, profiles and group membership. You have a recipe service. It handles things like finding recipes, adding them to "books", etc. The recipes need to be guarded. They are shown only to members of certain groups.

You could have the recipe service call the security service each time to get the caller's groups. Then compare those groups to the allowed groups. If that user service goes down, you're borked.

If you use events instead, you'd keep a copy of the profile and its groups in the recipes. Every time that changes, it gets an event with the details. Now they've decoupled by sharing data async. It is not a perfect system. It can be possible that the recipes service doesn't update. Now a user that should get the data can't.

The trade off with events is that you can upgrade and redeploy services more easily. If you find a bug in the user profile service, bring it down, update and restart. No other service goes down with it.

Re: The Death of Microservice Madness in 2018

#106

Post by tunesmith » Mon, Jan 22, 2018, 1:03 AM UTC

brown9-2 wrote: post #73

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’m confused. If a microservice doesn’t call the api of any other microservices, then when is sending the requests to any of them? A large purpose of service oriented architecture is encapsulation. If no other microservices can make requests to your microservice, then you really haven’t encapsulated much.

I'm thinking this concept improperly conflates synchronous requests with eventually-consistent asynchrony.

No, you definitely don't want microservices making synchronous requests to other microservices and depending on them that way.

But it still may be necessary for your services to depend on each other, and that's where you can allow that communication through asynchronous eventually consistent communication. Actor communications, queue submission/consumption, caching, etc.

Re: The Death of Microservice Madness in 2018

#107

Post by DanielBMarkham » Mon, Jan 22, 2018, 1:06 AM UTC

There's a ton of stuff here -- enough for a book or two. I loved the article although I might take issue with several of the smaller points. It's way too much to go into on an HN thread.

There's just so many topics that all come together here: stateless programming, pure FP, NetOps, DevOps, and so on. It feels like one of those cross-discipline discussions where it's either really simple -- or really complex. In fact the core skill here is managing complexity across multiple domains up and down the entire stack. It all depends on the fine details and which choices you make.

I just finished a really good book which may seem unrelated to the current topic but actually is spot on. It's "Domain Modeling Made Functional" It uses F#, but the principles involved apply no matter which language you're using.

https://pragprog.com/book/swdddf/domain-modeling-made-functi...

Re: The Death of Microservice Madness in 2018

#108

Post by st3fan » Mon, Jan 22, 2018, 1:08 AM UTC

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.

Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.

Re: The Death of Microservice Madness in 2018

#109

Post by daxfohl » Mon, Jan 22, 2018, 1:08 AM UTC

Why is scaling independently a pro? I've heard that argument before and never understood it.

If I have one api that is low throughput and one that is high, say requires 2 and 20 nodes respectively, then you need 22 nodes whether they are two independent microservices or a monolith. I'd think the monolith would actually be easier to manage as you don't have to worry about how to divvy up the resources. All 22 nodes run the same code. Sure you could do the same with a k8s cluster autoscaling (I assume), but still, I don't see how this makes anything strictly easier than a monolith scaling. If anything it seems like one more thing to worry about.

But I've heard the argument multiple times, so wonder if I'm missing something.

Re: The Death of Microservice Madness in 2018

#110

Post by always_good » Mon, Jan 22, 2018, 1:09 AM UTC

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.

Well, I've also worked for places where I'm on call for some service maintained by one person that's built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self.

These days I kinda wince at "I run 8 services myself."