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

Some thoughts on microservices

filipnikolovski.com

Post reply on HN
Print view View original

51–60 of 139 posts

Re: Some thoughts on microservices

#51

Post by roberthahn »

I find people’s reactions to microservices to be fascinating. I have always looked at them with the same framing as Unix userland tools - many small, focused apps that do something really well, coupled with a super generic IPC mechanism - in Unix’s case, using pipes or message queues.

But Unix isn’t all small tools. We have servers for the heavy work- like databases.

The challenge then becomes; how do you design that IPC mechanism? Maybe it exists! I don’t know the answer yet. But it’s something I think about a lot and I haven’t seen compelling evidence for “microservices are always bad, no exceptions”

Re: Some thoughts on microservices

#52

Post by UglyToad »

belter wrote: post #15
cjfd wrote: post #3

One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.

The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.

I'm going to build a lucrative personal brand / consulting business by hyping mesoservices, neither micro nor macro, just right.

Re: Some thoughts on microservices

#53

Post by foobarian »

yakshaving_jgt wrote: post #38
foobarian wrote: post #28

Earlier quoted context omitted.

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.

> There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls

I mean it's only computers and the only limit to what we can make them do is our imagination.

In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.

Re: Some thoughts on microservices

#54

Post by papito »

First of all, we called these "distributed systems". We reserved those for rare cases where scale was THE requirement, and you jumped into it fully expecting to have no life.

The world did not finally "crack" distributed systems. Most companies created multiple microservices, putting their small dev team underwater because "this is the way at the FAANG".

All of your DRY principles are out the window, and now you have to debug in production - the new word for that is OBSERVABILITY.

Not to mention that the actual reason for distributed systems is to scale multiple parts of the system independently, but you need to KNOW what has to scale individually before you do it. What I see is that the topology really reflects the company structure, of course. It's not "what has to scale separately", it's "team Y is working on X, and team Y does not want to talk to team Z, so they will create a service to make sure they don't have to talk to people".

Except that this is a giant self-own. We all still have to talk to each other, like, a LOT, because things just keep breaking all the time and no one knows why.

Dropbox, Instagram, StackOverflow - these companies are largely monoliths to this day. You thinking that your small outfit needs to be like Google is highly arrogant.

And don't get me started on the amount of money, people, CPU cycles, and CO2 emissions wasted on this solving of the problem most people don't have.

Re: Some thoughts on microservices

#55

Post by papito »

FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

The new generation of devs really develops systems as if HTTP were a zero-latency concept.

This is just like those people who consider all DB calls to be "free". Not that this went away either, it's just way more egregious now.

Re: Some thoughts on microservices

#56

Post by papito »

hbn wrote: post #37
BoumTAC wrote: post #2

I watch the other day, the Lex Fridman podcast with Kevin Systrom, founder of Instagram. He talks about the scaling issue; they were using Django at that time and scale up to 50 millions users with a small team of developers. I do not think a majority of companies have more than 50 millions users and absolutely need to go full microservices. https://www.youtube.com/watch?v=3pvpNKUPbIY

I don't think the number of users nor number of developers is really the deciding factor. Instagram, pre-Facebook acquisition, was a VERY simple application. It was literally just a chronological feed of (strictly square) photos with captions, you followed your friends, could explore hashtags, and not much more. Videos wouldn't even come for a few more years, let alone all the crazy stuff Facebook has hamfisted in th…

But they COULD have been. Insta was 12 people when it got acquired. If they tried to be "cool" and did distributed systems, the team would have ballooned to at least 10x.

Re: Some thoughts on microservices

#57

Post by cjfd »

roberthahn wrote: post #51

I find people’s reactions to microservices to be fascinating. I have always looked at them with the same framing as Unix userland tools - many small, focused apps that do something really well, coupled with a super generic IPC mechanism - in Unix’s case, using pipes or message queues. But Unix isn’t all small tools. We have servers for the heavy work- like databases. The challenge then becomes; how do you design that…

Well, pipes are very nice and useful for small processing tasks. "I want to know how often the word 'Parameter' occurs in the source files inside this repository." That is great! pipes are your friend. They are the fastest way known to mankind to solve this problem. But they are also fragile. You may not have thought about the fact that the word NoParameter also occurs in the code base and you did not want to count that. Now, when writing something big and complicated pipes simply cannot keep up. Nobody wants a browser that is actually 100 small executables that communicate over pipes. It will be horrible. The IPC mechanism that you are looking for and that can actually handle what is needed for a browser is called 'function call' and it was already quite popular when C was introduced....

The interaction mechanisms between services, e.g. REST calls, is somewhere in between pipes and function calls. They are a bit more reliable than pipes and less reliable than function calls. They can be used for more complicated task than what pipes are used for but should not be used for task that are so complicated that they need function calls.

Re: Some thoughts on microservices

#58

Post by ajuc »

FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

> Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call.

In J2EE that difference is a configurable technical detail. You have 1 service that calls another, and the protocol they use can be a normal function call, RMI, SOAP (or I think REST nowadays) depending on dynamic configuration.

Re: Some thoughts on microservices

#59

Post by foobarian »

drunkpotato wrote: post #44
foobarian wrote: post #28

Earlier quoted context omitted.

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

Yes, that is the marketing brochure pitch for microservices. In the real world, poorly designed microservices make the ball of mud problem much, much worse, and whatever pain you had in deployments in a monolith are now magnified ten-fold. I have not been fortunate enough to see well-designed microservices, so I suspect the ball of mud is the default. Can this be rectified through discipline? Probably, but I haven't…

> In the real world, poorly designed microservices make the ball of mud problem much, much worse

I can see that. I am trying to reflect on why I have such negative experience with a monolith and positive with microservices. It's possible that in the monolith setups I had, poor design was easy by default. No linting, no cross-module ownership interlocks, very slow and costly production deploys. Likewise the microservice setups tended to make poor design harder since code is isolated by default both at compile and runtime.

Can you make a monolith with all the good benefits of modularity but without the complications of network RPC etc.? Maybe, but I haven't seen it yet. (Excluding trivial single-team apps; talking about at least 3 teams and 50+ headcount orgs).

> Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing

Sure, shit happens. Again my experience may be colored, but when costly mistakes happen in monoliths, it tended to take longer to roll back because of how deploys are structured both technically and on an organizational level. I think I would still prefer smaller units in this case.

Re: Some thoughts on microservices

#60

Post by foobarian »

ratww wrote: post #48
foobarian wrote: post #28

Earlier quoted context omitted.

Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are no…

> With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file. Microservices by themselves…

I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.
Post reply on HN