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

gRPC for Microservices Communication

techdozo.dev

Post reply on HN
Print view View original

61–70 of 73 posts

Re: gRPC for Microservices Communication

#61

Post by rualca »

Zababa wrote: post #20
mirekrusin wrote: post #12

"In the olden days, a software application was built as a large monolith (...)" - people should stop writing this kind of shit. You can hear this nonsense from some poor quality bloggers. People who are serious about it say things like "for most startups microservices is bad idea", "monolith should be starting point in most cases", "there is a price that comes with microservices", "modularised monoliths are often pef…

I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size o…

> Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system.

I feel this line of argument is disingenuous and is based on a mix of strong personal opinions and very limited to non-existent insight onto which problems other orgs experience.

For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast radius is limited.

But regarding performance, let's not fool ourselves into believing that there's always a fatter network pipe and a beefier box to deploy to. Often there is, but often there simply isn't. Once you are forced to deploy your monolith into multiple instances, most of the criticism directed at microservices is rendered moot. Also, beefier boxes are far more expensive to operate, so let's not pretend there are no costs.

Also, there's the reliability aspect. If you want to have a reliable service then you need redundancy, which means multiple deployments. Once you have to deal with load balancers serving traffic to multiple instances of your monolith, there is no longer a significant architectural and ops difference in whether you operate a monolith or shave a service or two out of it. Thus most of the criticism directed at microservices is rendered moot.

Lastly, some orgs are ok with serving users in a very limited geographical region. That's perfectly fine. Other orgs might have users in different parts of the globe. Do you expect them to tolerate latencies in the 200-500ms range routinely, or do you find acceptable to reel in those latencies back to the 50ms territory by deploying a part of the service closer?

I get the Monolith first principle, but you're fooling yourself if you believe that only FAANG-level companies can benefit from it.

Re: gRPC for Microservices Communication

#62

Post by Zababa »

rualca wrote: post #61
Zababa wrote: post #20

Earlier quoted context omitted.

I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size o…

> Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. I feel this line of argument is disingenuous and is based on a mix of strong personal opinions and very limited to non-existent insight onto which problems other orgs experience. For starters, the main selling…

> For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast radius is limited.

That's true, but at this point we should clarify what we mean by microservices. By "microservices", I mean "you end up with more services than engineers". If you've got a team for each service, then I would just call them services. I also don't agree that back and forth with other teams is always a waste of time, especially since just after this you talk about limiting their blast radius if they screw up. That's probably necessary if your org doubles every year or already has thousands of engineers, but that's not for everyone.

> But regarding performance, let's not fool ourselves into believing that there's always a fatter network pipe and a beefier box to deploy to. Often there is, but often there simply isn't.

I don't think we are talking about the same thing here. My point was that if you don't have network effect (like Twitter or Facebook), there's no need to put all of your users into the same box. You could have the extreme opposite, one instance for each users. So you only need to be able to handle your biggest client.

> Once you are forced to deploy your monolith into multiple instances, most of the criticism directed at microservices is rendered moot.

I don't think that's true. Having multiple instance of a monolith is not the same as having multiple different services.

> Also, there's the reliability aspect. If you want to have a reliable service then you need redundancy, which means multiple deployments. Once you have to deal with load balancers serving traffic to multiple instances of your monolith, there is no longer a significant architectural and ops difference in whether you operate a monolith or shave a service or two out of it. Thus most of the criticism directed at microservices is rendered moot.

> Lastly, some orgs are ok with serving users in a very limited geographical region. That's perfectly fine. Other orgs might have users in different parts of the globe. Do you expect them to tolerate latencies in the 200-500ms range routinely, or do you find acceptable to reel in those latencies back to the 50ms territory by deploying a part of the service closer?

Again, I don't think that's true. You can have one/multiple monolith instances in each region. You may argue that it's not strictly a monolith if there is a routing and load-balancing service in front of it, and that's true, but it's also not a microservice architecture.

Re: gRPC for Microservices Communication

#65

Post by rualca »

Zababa wrote: post #62
rualca wrote: post #61

Earlier quoted context omitted.

> Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. I feel this line of argument is disingenuous and is based on a mix of strong personal opinions and very limited to non-existent insight onto which problems other orgs experience. For starters, the main selling…

> For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast r…

> That's true, but at this point we should clarify what we mean by microservices. By "microservices", I mean "you end up with more services than engineers".

That's not what "microservices" is.

If you are not familiar with the concept then you should refrain from post personal assertions on guidelines or best practices.

Re: gRPC for Microservices Communication

#66

Post by robertjp »

Zababa wrote: post #20
mirekrusin wrote: post #12

"In the olden days, a software application was built as a large monolith (...)" - people should stop writing this kind of shit. You can hear this nonsense from some poor quality bloggers. People who are serious about it say things like "for most startups microservices is bad idea", "monolith should be starting point in most cases", "there is a price that comes with microservices", "modularised monoliths are often pef…

I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size o…

Sometimes you just need the scalability. I work on a 2 programmer team making a data integration product. There's a whole lot of features, but one is that you can push a button and move like 10 years of ERP data from 1 system to another. This is done as a scalable microservice because running big migration can up our resources like 50X from baseline, and sometimes we're running 5 to 10 at once. Usually we're running 0. Between all services we utilize on average less than a gig of memory, but regularly allocate 10 or even 100s of gigs at once for short periods of time.

Re: gRPC for Microservices Communication

#67

Post by Zababa »

rualca wrote: post #65
Zababa wrote: post #62

Earlier quoted context omitted.

> For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast r…

> That's true, but at this point we should clarify what we mean by microservices. By "microservices", I mean "you end up with more services than engineers". That's not what "microservices" is. If you are not familiar with the concept then you should refrain from post personal assertions on guidelines or best practices.

> That's not what "microservices" is.

That's how it sometimes ends up. You said:

> For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops.

But that's just regular old services. The "micro" in "microservices" usually implies smaller services, and one extreme of that is having more services than engineers. That's something I saw happen, heard about and read about. Microservices can be abused by making them too small and making too many of them. Uber is an example of that.

Re: gRPC for Microservices Communication

#68

Post by Zababa »

robertjp wrote: post #66
Zababa wrote: post #20

Earlier quoted context omitted.

I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size o…

Sometimes you just need the scalability. I work on a 2 programmer team making a data integration product. There's a whole lot of features, but one is that you can push a button and move like 10 years of ERP data from 1 system to another. This is done as a scalable microservice because running big migration can up our resources like 50X from baseline, and sometimes we're running 5 to 10 at once. Usually we're running…

That's a great example that compliments nicely the remark of jayd16 here https://news.ycombinator.com/item?id=28636152

> microservices are just services with the acknowledgement that minimum size should not factor into breaking off a new service

Thanks to you both for the perspective.

Re: gRPC for Microservices Communication

#69

Post by cbsmith »

marsdepinski wrote: post #54
cbsmith wrote: post #35

Earlier quoted context omitted.

I couldn't help but read this article through the eyes of CORBA, and the bit about "the olden days" made me crack up even harder.

SOAP. I'm waiting for gRPC and OpenAPI to get me where WSDLs were 20 years ago.

SOAP was the successor to CORBA really, and then everyone decided it was too complicated and heavy weight. ;-)

Re: gRPC for Microservices Communication

#70

Post by ammanley »

gravypod wrote: post #49
ammanley wrote: post #47

Earlier quoted context omitted.

> The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. Second this. I think its also really important to consider the "trap" of going in on gRPC, but using something like grpc-gateway to also spit out JSON as a "backup". We did this for a project I was on, and the JSON API was the thing everyone else used (because up until then, everything there was a JSON API, naturally). As a re…

One thing that was doable in my last company where I used gRPC was I made interfacing with the gRPC API dead simple. Something like `connect(ServiceBlockingStub.class)` was in your code and it would instantly pull configs, build the service, wire up all of our middle wares + logging, etc. You can automate a lot of this which essentially makes the normal level of friction easier.

That's pretty cool. Was there a particular local environment needed to make this work? I recall auto generation being a part of the whole suite, but sounds like you took it up a notch.
Post reply on HN