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

91–100 of 139 posts

Re: Some thoughts on microservices

#91

Post by zo1 »

helge9210 wrote: post #61
trixie_ wrote: post #36

Earlier quoted context omitted.

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

If execution of your binary is stopped some time between the call and return (with following restart), dealing with it is no simpler than dealing with network partitioning.

It most certainly is easier to deal with the in-process version. I'm specifically referring to database transactions, which are much harder to have available in a distributed context. That failed network call complicates your life so much.

Re: Some thoughts on microservices

#92

Post by geodel »

acjohnson55 wrote: post #24

Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…

Indeed. I did simple calculation for myself. We kind of split a service in 5 microservices. Now if I look at e.g 5% integration related issues between 2 services, which would obviously not exist in monolith, we are actually looking > 20% chances of error in an end-to-end transaction.

To me this is pretty high chance of error on day to day basis. And in our case some errors are convoluted, so possibly getting missed and causing slow data corruption.

Re: Some thoughts on microservices

#93

Post by bluGill »

daxfohl wrote: post #89
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 could maybe see that for some specialized case, but for the general case it seems like the more independent, distributed things you're juggling, the more likely you are to end up with security holes in the first place. The time you have to spend on security would have to be spread too broad and thin.

The cost varies. Some of the code I work with is safety critical - people can die if it isn't working. If someone breaks into our system and gets private data that "only" costs us a lot of money, but if they break into our system and take over the safety critical parts people die.

Re: Some thoughts on microservices

#94

Post by bluGill »

Nextgrid wrote: post #40
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.

There have been examples of people breaking out of VMs. My ultimate wish is to run everything on separate CPUs.

Re: Some thoughts on microservices

#95

Post by cjfd »

jayd16 wrote: post #67
cjfd wrote: post #11

Earlier quoted context omitted.

Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.

So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?

Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue.

On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.

Re: Some thoughts on microservices

#96

Post by pooper »

taeric wrote: post #87
amelius wrote: post #46

Earlier quoted context omitted.

Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.

I'd be more worried with, "do you just have shared infrastructure for all data?" Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.

> Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.

Are you talking about Bank of America? My impression from the interview was that it is not a free for all but rather all teams are equal but some teams are more "equal" than others (compliance). I still don't get why they need write/execute access. I would be OK with other teams having read access to my database.

There was a discussion the other day about using views as an external interface to a "service" so basically we maintain rest, gRPC, or whatever but if other teams just need read only access to our data, we can expose a view to them

https://news.ycombinator.com/item?id=29357874 https://web.archive.org/web/20211201192151/https://news.ycom...

Re: Some thoughts on microservices

#97

Post by spmurrayzzz »

jeffbee wrote: post #76
Sohcahtoa82 wrote: post #69

My thoughts on microservices... They're fine. But what's NOT fine are nano services. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.

Shoot, that's practically a monolith compared to the nightmare from which I resigned earlier this year. No way would they have allowed the entire password reset to reside in a single service. It would have been in the password-db-reader service, the password-db-mutator service, and the password-checker-service, among others. Absolutely terrifying and unmanageable.

This is the flavor of reductio ad absurdum example I always give when people hype up the "micro" part of microservices. Only meant to be illustrative— I had no idea that any org was actually doing that sort of nonsense, yikes.

Re: Some thoughts on microservices

#98

Post by mLuby »

throwaway984393 wrote: post #50
recursivedoubts wrote: post #25

Microservices means just that: tiny, single purpose services that deploy and scale on their own. I often see appeals to Conway's Law when discussing microservices, but teams don't organize themselves this way. Instead, teams work on a macro services: the email delivery team, or the monitoring team, or whatever. In most cases these macroservices would be best implemented and deployed as a monolith, and then presented…

^ This. Microservices are introduced because it seems like they'll be able to decouple and scale well, and then they make mistakes that make everything even harder than if it'd stayed a monolith. Usually they don't plan for how they'll coordinate their work, and that leaves gaps in the design, and puts more risk on the business. Team A: ↑ Email product: __|_____________ ↑ Service C On top of that, they don't even mak…

Total tangent: very nice ASCII diagram, especially for a throwaway account. It's so unusually nice that it'd probably help identify the author if they ever made ASCII diagrams on their non-throwaway account (and who could resist?).

Re: Some thoughts on microservices

#99

Post by spmurrayzzz »

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…

Scale independently, and as a result can fail independently in an unfathomably opaque cascade of failure modes.

I'm a big SOA fan, but my experience with any non-trivial lambda architectures has soured me on the FaaS concept writ large.

Re: Some thoughts on microservices

#100

Post by satyrnein »

taeric wrote: post #87
amelius wrote: post #46

Earlier quoted context omitted.

Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.

I'd be more worried with, "do you just have shared infrastructure for all data?" Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.

Assuming people will need reports that cut across team/microservice boundaries, all that data has to end up in one common place, possibly a data warehouse. At which point, other teams can still add and remove columns and break your reports.

Is there another way to do things?

Post reply on HN