Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make microservices look like monoliths

github.com

Post reply on HN
Print view View original

31–40 of 106 posts

Re: Make microservices look like monoliths

#31

Post by letitbeirie »

mjr00 wrote: post #29
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.

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

> at some point monoliths can get large enough that upgrading libraries or runtimes becomes an incredibly difficult problem

Some languages (e.g. Go) make this easier than others by allowing two versions of the same import to coexist, but this is why we broke up our Django monolith a few jobs ago.

Re: Make microservices look like monoliths

#32

Post by sim7c00 »

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!

i think a lot invest in microservices as the services require less programming skills. ofcourse, the whole thing requires skills, but little services with simple apis are easy to make.that makes hiring a lot easier and maybe cheaper. i love monoliths, but at my company (not a software dev place) its hard to do these things. most people dont understand threads and architecture of programs, but they can make some fastapi routes and hook them up to some functions. we can create complex things despite their lack in pure software dev skills. (i wish it was different! but u have to work to ur teams strength othetwise it will end in tears!)

Re: Make microservices look like monoliths

#33

Post by watermelon0 »

mjr00 wrote: post #29
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.

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

Re: Make microservices look like monoliths

#34

Post by mjr00 »

letitbeirie wrote: post #31
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…

> at some point monoliths can get large enough that upgrading libraries or runtimes becomes an incredibly difficult problem Some languages (e.g. Go) make this easier than others by allowing two versions of the same import to coexist, but this is why we broke up our Django monolith a few jobs ago.

Yeah, the library problem has some (ugly) solutions in some languages, like Go allowing multiple versions as you mention, or doing JAR shading in Java. But I don't think there's a (mainstream) language that solves the problem of partially upgrading the underlying runtime. If you've got a Java monolith, it either all runs on Java 7 or Java 8, can't really do in-between.

Re: Make microservices look like monoliths

#35

Post by mjr00 »

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

> Wouldn't they similarly need comparable amount of time to update all 14 microservices?

In my experience doing this at AWS and elsewhere, no, the services case is much easier. Even just the ability to do releases in chunks 1/14 of the size is a huge advantage. On top of that, your services are going to have smaller dependency chains, and transitive dependencies are truly where dependency hell[0] comes into play. It boils down to complexity being multiplicative rather than additive. Depending on the size of everything, each service is probably more like 1/50th the amount of work rather than 1/14th.

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

This is working under the assumption that all your code and services should always be updated to the latest, which isn't necessarily true. I still have smaller, infrequently updated services running and happily chugging away that run on Python 3.5. Other codebases have been upgraded to Python 3.10, sure, but what's the harm in letting this one run on an end-of-life Python, especially given that it's a backend service, with no public access, that only communicates via RPCs? A vulnerability might be found in Python 3.5 that necessitates an upgrade, but it's not like moving to the latest version of everything prevents that -- i.e. "Heartbreak"[1] only affected OpenSSL 3, not people still using OpenSSL 1.1!

[0] https://en.wikipedia.org/wiki/Dependency_hell

[1] https://arstechnica.com/information-technology/2022/11/opens...

Re: Make microservices look like monoliths

#36

Post by spicybright »

ranting-moth wrote: post #30
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…

> 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 architects or architects responsible for a specific well defined part of the code base.

Having a solid process for only allowing well thought out code in is a cornerstone to keeping alignment.

Re: Make microservices look like monoliths

#37

Post by bch »

88913527 wrote: post #17
voidfunc wrote: post #5

Earlier quoted context omitted.

Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.

Is it the fault of the thought leader, or the loads of juniors asked to implement the architecture but don't really understand it? If everyone had better system design knowledge, it wouldn't be so bad. 90% of the engineers in my organization don't understand the function of an API Gateway, for example. So the thought leader does propose a reasonable solution, but then it doesn't work because the organization doesn't…

> juniors asked to implement the architecture but don't really understand it?

Can you reasonably expect a junior engineer to push back here and generally get traction? If this architectural decision has been made, it’s been made. At higher levels.

>If everyone had better system design knowledge

I don’t think this is a junior devs fault - they’re junior, after all.

> but then it doesn’t work because the organization…

Bingo.

Re: Make microservices look like monoliths

#38

Post by ohgodplsno »

bheadmaster wrote: post #22
anotherhue wrote: post #18

Earlier quoted context omitted.

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.

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.

One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten.

Micro services replace your unmaintainable bean injection XML abomination with 50 reimplementations of database access and a salary for the one guy who knows his to make your kubernetes setup work.

It's not a technology problem, it's a people problem. Micro services make it a distributed people problem.

Re: Make microservices look like monoliths

#39

Post by bheadmaster »

ohgodplsno wrote: post #38
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.

One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten. Micro services replace your unmaintainable bean injection XML abomination with 50 reimplementations of database access and a salary for the one guy who knows his to make your kubernetes setup work. It's not a technology problem, it's a people problem. Micro services make it a distributed p…

> One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten

I... I don't really understand this sentence.

Re: Make microservices look like monoliths

#40

Post by Justsignedup »

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.

Post reply on HN