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

41–50 of 106 posts

Re: Make microservices look like monoliths

#41

Post by ivix »

I find a lot of people conflate both service separation for human factors and service separation for technical factors.

Unless you have multiple independent development teams you do not need to worry about the human factors. Addressing them fully is always going to come at a technical cost in terms of things like latency and complexity.

Separation for technical reasons (generally scaling) may well be a factor but easily addressed without building 'true' microservices, for example with serverless functions.

Don't let the purists sneer at your architecture because it's not true microservices.

Re: Make microservices look like monoliths

#43

Post by wizofaus »

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.

Are there actually many real-life examples of large-scale microservices architecture operating successfully with a range of different languages in use? I did (briefly) work at such a shop, I can't say the experience was particularly rewarding, but I was expected to be on top of ALL said languages/stacks and their various idiosyncrasies etc., and much of the code was pretty poorly written. Arguably the biggest challenge was maintaining the build system!

Re: Make microservices look like monoliths

#44

Post by wizofaus »

mabbo wrote: post #15
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 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 help much with the latter.

Re: Make microservices look like monoliths

#45

Post by wizofaus »

2c2c2c wrote: post #12
mati365 wrote: post #2

It makes no sense. Why not just create modular monolith?

On a large/quickly growing team the risk is folks begin to not respect the modularity and you end up with just a regular monolith Perhaps formalized abstractions around these barriers is a good idea? At the very least better than the 60 kubernetes services at my 100eng headcount team? :-)

One major criticism I have of the way modules work in many stacks is that the dependencies between modules are hard to visualise and/or manage. Certainly in the C#/.NET world it's very easy to accidentally end up with one module depending on another that depends on the initial module via some chain of dependencies. And it's too easy to add extra dependencies to some low-level module that's supposed to be a "core" base layer module that's used across the board. That's less of a problem with microservices, esp. in a multi-repo environment, where you can enforce boundaries more easily. It's one of the few points in favour of microservices, from what I've observed so far - that you can safely make a change to a particular microservice and know a) it's definitely not going to break the CI/CD pipeline for the rest of the product b) if you have introduced a bug, there's typically very limited impact it can have.

Re: Make microservices look like monoliths

#46

Post by anotherhue »

wizofaus wrote: post #43
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.

Are there actually many real-life examples of large-scale microservices architecture operating successfully with a range of different languages in use? I did (briefly) work at such a shop, I can't say the experience was particularly rewarding, but I was expected to be on top of ALL said languages/stacks and their various idiosyncrasies etc., and much of the code was pretty poorly written. Arguably the biggest challen…

I haven't heard of any, the classic 'allowed languages' pages of tech companies come to mind.

"You build it you run it", until the OCaml guy quits and now you need to support OCaml.

Re: Make microservices look like monoliths

#47

Post by floydnoel »

bheadmaster wrote: post #39
ohgodplsno wrote: post #38

Earlier quoted context omitted.

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.

probably because you are replying to a quote of a quote, but didn't read the quoted comment? spend more time reading and less time writing would be my suggestion to help with understanding the comments here.

Re: Make microservices look like monoliths

#48

Post by dragonwriter »

floydnoel wrote: post #47
bheadmaster wrote: post #39

Earlier quoted context omitted.

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

probably because you are replying to a quote of a quote, but didn't read the quoted comment? spend more time reading and less time writing would be my suggestion to help with understanding the comments here.

> probably because you are replying to a quote of a quote

Its not a quote of a quote, its an attempt at a mocking modification of an upthread comment that isn’t a quote, but the original doesn’t fix the incoherence of the mocking reply.

Re: Make microservices look like monoliths

#49

Post by dragonwriter »

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.

I disagree that this is the case; decomposing into microservices doesn’t mean that the functionality within a service boundary is trivial and easy to rewrite.

Re: Make microservices look like monoliths

#50

Post by Zetice »

friendly_chap wrote: post #25
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’d rather compose my systems with widely understood and commonly used components OP here. Fortunately the authors of the components you use didn't get discouraged by comments like this otherwise they would've never been written ; )

Yeah well they wrote useful things.
Post reply on HN