The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#91

Post by pricetag » Mon, Jan 22, 2018, 12:19 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…

The company I work for is currently undergoing an effort to move many of the old PHP apis to Graphql. The repo for the graphql api wrapper was quickly becoming a monolith in itself, so it has since been broken down into separate packages.

I do wonder about the sustainability of an architecture like this. This is the largest company I’ve ever worked for, so I’ve never seen how this plays out. Who will manage each package/service as time goes on and they sink into obscurity as the original team transitions out or leaves the company? I totally see some of these becoming the technical debt of the future.

Re: The Death of Microservice Madness in 2018

#92

Post by Chiba-City » Mon, Jan 22, 2018, 12:20 AM UTC

Reminds me of distributed architectures like CORBA turning into spaghetti in the 90's.

Re: The Death of Microservice Madness in 2018

#93

Post by ibejoeb » Mon, Jan 22, 2018, 12:27 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…

It's not exclusive to inheritance, though. There are lots of times that the original principal decides that he could have done it better and winds up in exactly the same place. It could be progress, too, if it trades on set of failure modes for another that is less severe or less frequent.

This is why a team needs access to good architect who's seen the paradigms shift, or even cycle. You're almost never starting from scratch, so you really need someone who's able to incorporate better or more suitable tech without throwing out the baby.

If you're microservices-based, that last part is easier, even if it falls into one of the described pitfalls, e.g., system-of-systems.

Re: The Death of Microservice Madness in 2018

#94

Post by burlesona » Mon, Jan 22, 2018, 12:36 AM UTC

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.

Yep, this has been my experience as well. When micro services work well they have a simple and well-defined API that is easy to keep backwards compatible as it evolves, and it tends to be something that evolves quite slowly compared to the primary application codebase.

For the posters who said "like a library," yeah that's exactly the idea, but consider if you have an operation that can be done by a library but that has very different scaling characteristics compared to the rest of your system. Eg. you have one highly compute intensive operation while the rest of your system is IO bound. If you can split these apart it's easier to deal with scaling.

Re: The Death of Microservice Madness in 2018

#95

Post by floogtheunfound » Mon, Jan 22, 2018, 12:40 AM UTC

tyingq wrote: post #76

meddlepal wrote: post #58

Earlier quoted context omitted.

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…

I wouldn't dismiss the effect of résumé based development either. Even if subconscious, having the latest buzzwords on your CV is a motivator.

These replies are so salty

Re: The Death of Microservice Madness in 2018

#96

Post by bri3d » Mon, Jan 22, 2018, 12:45 AM UTC

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…

Is this truly a management failure?

If a few things are true, I could see this as a win:

* I can isolate my developers from outside interests using microservices. * My developers are more effective in each dimension (quality, retention/happiness, velocity) because they are isolated from outside interests. * My software is easier to operate and more reliable because it is a microservice.

If any of these three things aren't true, then I agree. But I'm not sure that a "communication culture" can scale to a large organization and I'd like to see a truly large company (1000+ developers) successfully doing so. I've seen more success come from separation of concerns and well-deployed microservices seem to be fairly effective to this end.

Re: The Death of Microservice Madness in 2018

#97

Post by ohyes » Mon, Jan 22, 2018, 12:46 AM UTC

JamesBarney wrote: post #90

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

Re: The Death of Microservice Madness in 2018

#98

Post by trimbo » Mon, Jan 22, 2018, 12:46 AM UTC

jacques_chester wrote: post #84

saryant wrote: post #17

Earlier quoted context omitted.

I've been down that road. Eventually it turns into a nightmare because evolving your DB means making simultaneous changes to multiple applications. "We think we can drop this column, someone figure out which of our eight apps using this DB might be using it still" I much prefer putting a single service layer in front of the DB that speaks thrift or protobuf and letting all clients interface with that instead. Evolvin…

The old-timey way to do this is with SQL views and triggers. Separation between logical schemata and physical schemata.

As well as stored procs.

I heard a few years ago that some government jobs apparently actually still require stored procs for security reasons. The ACL is controlled there.

Re: The Death of Microservice Madness in 2018

#99

Post by raspie » Mon, Jan 22, 2018, 12:48 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…

To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm.

Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject to the same organizational effectiveness, etc.

Re: The Death of Microservice Madness in 2018

#100

Post by ramses » Mon, Jan 22, 2018, 12:52 AM UTC

"Real world systems often have poorly defined boundaries" ... I have seen teams getting hit by that multiple times. As usual, it is a bad idea to try to make everything fit a single model before attempting to understand the consequences.