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

31–40 of 139 posts

Re: Some thoughts on microservices

#31

Post by helge9210 »

trixie_ wrote: post #19
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…

There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.

> When I call a function there is no chance it fails

I like to print statements like this one and put them in a frame on the wall.

Re: Some thoughts on microservices

#32

Post by samwillis »

“The longer I’m in tech, the more I’m convinced microservices were a technical solution to an organizational problem.”

@carnage4life on Twitter

https://mobile.twitter.com/carnage4life/status/1311702322024...

Now, I’ve not had the pleasure of working in an organisation using Microservices and so I’m only informed anecdotally. But I always assumed they where best used as an API boundary between teams, rather than adding more complexity to a teams work.

Re: Some thoughts on microservices

#33

Post by jjoonathan »

cjfd wrote: post #17
belter wrote: post #15

Earlier quoted context omitted.

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.

Well, a service-oriented architecture is a more general category then microservices and has been around much longer. In many cases it is much more justifiable on technical grounds. Just to give one example. You have an API that is not the most stable thing in the world and when it misbehaves you do not want it to take the whole application down with it. So you put it in a separate service that can easily be restarted…

> and has been around much longer

There's your problem. People understood the tradeoffs, so it needed a rebranding before it could go through another hype cycle.

Re: Some thoughts on microservices

#34

Post by afarrell »

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.

It is worth thinking about them before you need them because by the time you gain the skill and infra needed to support them, you’ll have scaled so large that your ability to coordinate and communicate will be overwhelmed.

Re: Some thoughts on microservices

#35

Post by [deleted] »

samwillis wrote: post #32

“The longer I’m in tech, the more I’m convinced microservices were a technical solution to an organizational problem.” @carnage4life on Twitter https://mobile.twitter.com/carnage4life/status/1311702322024... Now, I’ve not had the pleasure of working in an organisation using Microservices and so I’m only informed anecdotally. But I always assumed they where best used as an API boundary between teams, rather than addin…

[deleted]

Re: Some thoughts on microservices

#36

Post by trixie_ »

helge9210 wrote: post #31
trixie_ wrote: post #19

Earlier quoted context omitted.

There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.

> When I call a function there is no chance it fails I like to print statements like this one and put them in a frame on the wall.

Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?

Re: Some thoughts on microservices

#37

Post by hbn »

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

For the scope of that app, it would have been absurd to use microservices. And I think most people who are in favor of microservices would say the same thing. To me, what microservices help with is when you're building an entire platform, rather than a single product. Not even necessarily on the scope of Facebook or Google, but I've worked at companies where one team might work on an app for managing social media accounts, and another app helps you optimize the SEO of your website. Neither of those things really want to own the concept of a user they both share, or deal with account creation and whatnot. So that's handled by a dedicated microservice.

Now, when you get to a size where you're building a platform, you're likely going to have lots of developers and users, but I don't think whether you use microservices is a function of either of those numbers, and they're just a side effect of the thing you've built.

Re: Some thoughts on microservices

#38

Post by yakshaving_jgt »

foobarian wrote: post #28
wongarsu wrote: post #18

Earlier quoted context omitted.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

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.

Re: Some thoughts on microservices

#39

Post by bluGill »

I'm looking at micro services for a different reasons: security. I have given up on the idea that our code will ever be completely secure. However micro services means if someone breaks into one service they can't see data belonging to a different service. (that is run each service as a different user, and so OS protections means file commands cannot open such data)

This only protects against some threats related to insecure code, but layers of protection is the key to threats and it is useful for the parts it does help.

Re: Some thoughts on microservices

#40

Post by Nextgrid »

bluGill wrote: post #39

I'm looking at micro services for a different reasons: security. I have given up on the idea that our code will ever be completely secure. However micro services means if someone breaks into one service they can't see data belonging to a different service. (that is run each service as a different user, and so OS protections means file commands cannot open such data) This only protects against some threats related to…

I'd still be concerned about kernel-level exploits in this case. I'd run every service in its own VM.
Post reply on HN