Make microservices look like monoliths • Hacker News Board

Re: Make microservices look like monoliths

#51

Post by thrtythreeforty » Mon, Jun 19, 2023, 3:42 AM UTC

wizofaus wrote: post #44

mabbo wrote: post #15

Earlier quoted context omitted.

I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!). I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made. If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Owne…

Out of curiosity, do the microservices at Amazon typically call each other in an orchestrated fashion (i.e. microservice A knows it needs some particular functionality and knows to call microservice B to get it), or is in more asynchronous/"choreographed", where requests are available to a general pool of services, each of which handles as they need? It's hard to see how a library like the one posted about here would…

It is definitely the first one. Microservices at AWS typically grow boundaries at team boundaries, even if it would make much more technical sense for them to be combined. Each team knows which other team provides the APIs they need.

(Under the hood, the service may in fact be distributed to a large pool of resources. But a microservice doesn't shout into a void "hey could someone please handle a LaunchInstanceInRegion class??" - it's like using a library, but over the network.)

Re: Make microservices look like monoliths

#52

Post by 88913527 » Mon, Jun 19, 2023, 3:55 AM UTC

anotherhue wrote: post #18

civilitty wrote: post #11

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.

Most (successful) paths lead to balkanization. Just one acquisition can do it, much less 2 or N more. And the pace of these changes can outpace your ability to respond to it, which makes fighting it a losing battle.

Re: Make microservices look like monoliths

#53

Post by zerbinxx » Mon, Jun 19, 2023, 4:06 AM UTC

spicybright wrote: post #36

ranting-moth wrote: post #30

Earlier quoted context omitted.

> Monoliths require alignment. So do microservices.

I think GP's point on company culture is the right answer. My only thoughts to add is monoliths can be aligned as well as microservices, if not a bit easier depending on the team. You have to align microservices to talk to each other anyways, and there's no reason you can't make those boundaries work in one codebase instead of many. That said ownership is more important in a monolith, whether that be a single team of…

The worst thing is the many-monoliths/mini-monoliths problem that you get when each team thinks it has ultra special needs and absolutely must build everything from scratch, even if it’s a near duplicate of something someone else built 2 months ago.

Re: Make microservices look like monoliths

#54

Post by zerbinxx » Mon, Jun 19, 2023, 4:20 AM UTC

anotherhue wrote: post #26

bheadmaster wrote: post #22

Earlier quoted context omitted.

One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.

That assumes the service is doing something generic enough to be trivial in any language, in which case, why not just choose one? It's like we're advocating for the outcome of the Tower of Babel tale.

I mean, ultimately most languages and frameworks are/should be at least intelligible and serviceable by your teammates. I’ve both been on teams where I cannot work on Jerry’s Fucking Insanity Factory API after he leaves even though it’s written in JS and I know JS, but this is some insane Rube Goldberg machine that only Jerry’s mind understands, I’ve also been on teams where someone will write their thing in Go or Rust and I don’t know those but I can at least maintain them, because they’re well abstracted and do nice things and their authors were not schizophrenic like Jerry

Re: Make microservices look like monoliths

#55

Post by zerbinxx » Mon, Jun 19, 2023, 4:52 AM UTC

Justsignedup wrote: post #40

Reminds me a lot of erlang and the core features of where the function runs is unimportant. This is solving microservices via dependency injection. I'm not against it, but honestly if you not gonna be thoughtful about it.. Why not just monolith it? Monoliths are only a problem at large scale, and at that scale you have the manpower to create a reliable messaging service for inter service communications.

I think the point here that is getting lost here (not on you necessarily) is that if you write your service clean/SOLID, it really doesn’t matter if/when/how you make that decision to cleave it off into its own service. Monoliths are only a problem with scale, but there is absolutely no guarantee that your engineering team will scale at the same rate as your userbase. You know the story: tech product strikes gold, gets mentioned in NYT and becomes a new hot thing and doesn’t even have time to react before they hit scaling problems. It’s not great to prematurely optimize, but if you’re not preparing for eventual success (which requires scaling) is another term for shooting yourself in the foot. Unfortunately, even if you are “scaled up” in terms of workers, monoliths can be really nasty/resistant to many hands making the work lighter because they of how tightly coupled things end up being.

Why not monolith it? Maybe one part of the app evolves to really need a time series database or it really does some crazy stuff with image editing or it has new special dependencies that take an eternity to build, and you don’t want to add 20m of build time every time you mess with the rest of the codebase, none of which needs/expects the time-series/image-editor/complicated build thing to be there deployed alongside it. That’s like OG logic of why you want microservices, and it still makes a lot of sense, just people get carried away with cargo-culting on their thousand-microservice hellscapes where each API has four routes and 4000 lines of deploy config, boilerplate, copypasta.

Re: Make microservices look like monoliths

#56

Post by nologic01 » Mon, Jun 19, 2023, 5:01 AM UTC

anotherhue wrote: post #19

vineyardmike wrote: post #16

Earlier quoted context omitted.

I’m working a short term job (while they find a FTE hire) for a friends startup since their last SDE quit unexpectedly. The last employee tried every framework and architecture pattern under the sun. This company has more micro services than employees and customers combined. Each one is like ~200LOC, uses a different framework, etc. I’ve spent the last month just deleting shit and simplifying shit. You don’t need a c…

Blame a few things: 1. The developer, of course. 2. The person who let them do it. 3. The eight thousand devtool companies that pitch their solutions to developers. 4. The hiring managers for whom 'resume driven development' is effective. 5. The VCs who wrote the playbook for how all these companies (and the dev tool companies) have to grow. 6. The Fed for so much ZIRP that VCs are in power. 7. The government for unc…

11. The developer for having a human brain (well some do)

Re: Make microservices look like monoliths

#57

Post by hinkley » Mon, Jun 19, 2023, 5:11 AM UTC

ars wrote: post #21

My issue with microservices isn't the network calls, it's the extra work to keep the source code up to date. New spring library? Have fun applying the same changes to 14 different microservices. Microservices might make sense with completely different teams developing them - but multiple microservices in the same team, with the services talking to each other, really doesn't make sense.

Change to build process? That's 20 build plans you have to update.

Yeah, it's just a laugh a minute.

Re: Make microservices look like monoliths

#58

Post by theshrike79 » Mon, Jun 19, 2023, 5:12 AM UTC

vineyardmike wrote: post #16

Zetice wrote: post #6

I’d rather compose my systems with widely understood and commonly used components that make hiring and maintaining over time more of a puzzle problem than a, “learn a new framework” problem. This feels like we make our jobs harder than they have to be, sometimes…

I’m working a short term job (while they find a FTE hire) for a friends startup since their last SDE quit unexpectedly. The last employee tried every framework and architecture pattern under the sun. This company has more micro services than employees and customers combined. Each one is like ~200LOC, uses a different framework, etc. I’ve spent the last month just deleting shit and simplifying shit. You don’t need a c…

It might've also been CV Based Programming.

You just pick the crap that looks good on your CV and use that. Repeat until you get a new job.

Re: Make microservices look like monoliths

#59

Post by theshrike79 » Mon, Jun 19, 2023, 5:15 AM UTC

watermelon0 wrote: post #33

mjr00 wrote: post #29

Earlier quoted context omitted.

> New spring library? Have fun applying the same changes to 14 different microservices. On the flip side, at some point monoliths can get large enough that upgrading libraries or runtimes becomes an incredibly difficult problem. When I was at Amazon a major service was finally getting upgraded from Java 7 to Java 8. Took a cross-functional team 6 months (!) to make it happen due to the massive amounts of existing cod…

Wouldn't they similarly need comparable amount of time to update all 14 microservices? IMHO unless you have a strong engineering culture, having the same dependencies is the only way to ensure they are all properly updated (regarding security updates, and replacing deprecated dependencies/versions.)

There are always those specific cases you need to do when upgrading major versions.

The chance of a percentage of 14 microservices just plain not using that feature is bigger than the chance of that monolith not using it.

A completely contrived and fake example:

The language you're using has a complete refactor of its math library, everything must be rewritten in a new style that's incompatible with the old style.

In a microservice world there's a good chance that very few of those actually need the high-powered math library.

But your monolith has a few sections that use it so the whole shebang is delayed until that bit is rewritten to the new API.

Re: Make microservices look like monoliths

#60

Post by patrick451 » Mon, Jun 19, 2023, 5:19 AM UTC

zerbinxx wrote: post #55

Justsignedup wrote: post #40

Reminds me a lot of erlang and the core features of where the function runs is unimportant. This is solving microservices via dependency injection. I'm not against it, but honestly if you not gonna be thoughtful about it.. Why not just monolith it? Monoliths are only a problem at large scale, and at that scale you have the manpower to create a reliable messaging service for inter service communications.

I think the point here that is getting lost here (not on you necessarily) is that if you write your service clean/SOLID, it really doesn’t matter if/when/how you make that decision to cleave it off into its own service. Monoliths are only a problem with scale, but there is absolutely no guarantee that your engineering team will scale at the same rate as your userbase. You know the story: tech product strikes gold, ge…

Microservices don't solve the tight coupling problem. Rather, they make dealing with it even more painful because rather than updating assumptions across modules, you update them across different units of deployment. This leads to ossification because it is even more difficult to fix bad architecture.