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

61–70 of 106 posts

Re: Make microservices look like monoliths

#61

Post by bheadmaster »

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.

I wrote the quoted comment.

You'd probably notice that if you were to spend more time reading and less time writing.

Re: Make microservices look like monoliths

#62

Post by jamesfinlayson »

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've worked at a place where it was a case of choose what you want - there's lots of C#, Python and Javascript, some Go but there's still Scala and CoffeeScript lurking around, as well as some other more esoteric stuff that seemed like a good idea at the time.

Re: Make microservices look like monoliths

#63

Post by bheadmaster »

dragonwriter wrote: post #49
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.

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.

Of course, there's a whole continuum of complexity between microservices and monoliths in real life. Much of that continuum is labeled as "microservices".

I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.

Re: Make microservices look like monoliths

#64

Post by scott_w »

anotherhue wrote: post #46
wizofaus wrote: post #43

Earlier quoted context omitted.

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.

I do recall speaking to people at a betting company many moons ago who tried to recruit me with the claim they were so open with microservices that they had a key system written in Erlang that only one engineer in the company understood.

I politely explained my position on why that seemed suboptimal.

Re: Make microservices look like monoliths

#65

Post by scott_w »

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.

He’s mocking you

Re: Make microservices look like monoliths

#67

Post by Quekid5 »

wizofaus wrote: post #45
2c2c2c wrote: post #12

Earlier quoted context omitted.

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

Exactly. On the JVM (at least, dunno if C#/.NET has a similar mechanism) you can technically get away with using OSGi which can load things into separate classloaders along with all implementation-dependencies such that you can truly separate the API of a dependency from its implementation.

Alas, support for OSGi in the general ecosystem is abysmal, and the next best thing seems to be microservices.

Honestly, I find it pretty shocking that so many mainstream languages don't support this sort of "local isolation" better. The diamond dependency problem well-known at this point.

(To be clear, in our shop we generally only do this for very problematic dependencies that have a tendency to break backward bincompat on a whim. Those are almost always the most painful ones, especially if they are in turn dependended on by many of your project's other dependencies.)

Re: Make microservices look like monoliths

#69

Post by zerbinxx »

patrick451 wrote: post #60
zerbinxx wrote: post #55

Earlier quoted context omitted.

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.

I never claimed they did, I said if your code is SOLID then it doesn’t really matter if it’s a microservice or not, it will likely be useful up to the point where scaling/organizational/too many cooks/long deploy/spof problems start to crop up.
Post reply on HN