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

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

551–560 of 671 posts

Re: Modules, not microservices

#551

Post by codethief »

kubota wrote: post #515
thayne wrote: post #476

Earlier quoted context omitted.

> I don't really think microservices are fundamentally more scalable It depends on what you are scaling. I think microservices are fundamentally more scalable for deployment, since changes can be rolled out only to the services that changed, rather than everywhere. Unless your language and runtime support hot-loading individual modules at runtime.

I disagree, in my opinion micro-services hinder scalability of deployment, and development - at least the way I see most businesses use them. Typically they break out their code into disparate repositories, so now instead of one deployment you have to run 70 different ci/cds pipelines to get 70 microservices deployed, and repo A has no idea that repo B made breaking changes to their API. Or lib B pulled in lib D that…

Man, I wish my colleagues would read your comment (and at least question their believes for one brief moment)…

> I disagree, in my opinion micro-services hinder scalability of deployment

…and of anything related to testing:

- Want to fire up the application in your pipeline to run E2E tests? Congratulations, you must now spin up the entire landscape of microservices in k8s. First, however, you need to figure out which versions of all those microservices you want to test against in the first place, since every service is living in a separate repository and thus getting versioned separately.

- Want to provide test data to your application before running your tests? Well, you're looking at 100 stateful services – good luck with getting the state right everywhere.

Re: Modules, not microservices

#552

Post by JAlexoid »

jdc0589 wrote: post #507
highspeedbus wrote: post #331

Earlier quoted context omitted.

>they force alignment on one language or at least runtime A sane thing to do. >they force alignment of dependencies and their versions A sane thing to do. Better yet to do it in a global fashion, along with integration tests. >they can require lots of RAM if you have many modules with many classes You can't make the same set of features build in a distributed manner comsume _less_ RAM than the monolith counterpart. G…

> A sane thing to do. This is incredibly subjective, and contingent on the size and type of engineering org you work in. For a small or firmly mid-sized shop? yea I can 100% see that being a sane thing to do. Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though As soon as you have highly specialized teams/orgs to solve specific problems, this is…

> Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though

And yet, that is exactly what gets done

Re: Modules, not microservices

#553

Post by deterministic »

The worst software I have ever seen in my 30+ years career is a 20 years old micro-services system. Basically the worst spaghetti code you can imagine, distributed over 150+ micro-services.

I have worked on a monolith that solved the exact same problem. And it was straightforward to maintain and upgrade.

I feel sorry for future developers who will have to take over and maintain micro-services systems created today. Teams that can’t create maintainable, well designed monoliths, will create an even bigger cluster f** using micro-services.

Re: Modules, not microservices

#554

Post by danielheath »

noogle wrote: post #543
jayd16 wrote: post #431

Earlier quoted context omitted.

Another way to look at this is microservices reduce the blast radius of problems.

How so? If functionality A is critical to functionality B, how will wrapping it in an HTTP call (microservices) reduce the damage from breaking functionality A? I can see an advantage regarding resource hogging, but the flip side is the extra point of failure of network calls in microservices. Not saying which is better, but deployment is orthogonal to logical dependence and correctness.

Most features in a modern app are not critical functionality, though.

For instance, in a shopping site, why should a crash in the recommendations engine result in a non-functional webpage (rather than a working purchase page with no recommendations)?

Personally I think microservices start to make sense when you have several hundred developers (an environment I'm currently keen to never enter again - $work has 5 devs and might one day have 6).

Re: Modules, not microservices

#555

Post by jupp0r »

eklitzke wrote: post #356
barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

I just want to point out that for the second problem (scalability of CPU/memory/io), microservices almost always make things worse. Making an RPC necessarily implies serialization and deserialization of data, and nearly always also means sending data over a socket. Plus the fact that most services have some constant overhead of the footprint to run the RPC code and other things (healthchecking, stats collection, etc.…

I think all your points are correct but none of them address scalability. What do you do if your one efficient machine is too small for your problem? To be fair, not a lot of problems reach that point in practice, definitely not every problem a microservice is written for.

It might still be completely viable to rewrite something so that it's only 10% as efficient but you can scale it horizontally easily.

Re: Modules, not microservices

#556

Post by brasic »

yellow_lead wrote: post #185
davej wrote: post #103

Earlier quoted context omitted.

Twitter has a similar issue according to Musk https://twitter.com/elonmusk/status/1592176202873085952

The tweet is obviously wrong. > I was told ~1200 RPCs independently by several engineers at Twitter, which matches # of microservices. The ex-employee is wrong. > Same app in US takes ~2 secs to refresh (too long), but ~20 secs in India, due to bad batching/verbose comms. RPCs are on the server side. Why would they app take longer to refresh in India than in the US? Some more explanation: https://twitter.com/mjg59/st…

Yep, this is trivial to falsify, Musk jumped to an incorrect conclusion based on some anecdotes that he did not follow: https://twitter.com/Popeska/status/1592179502838435847

Re: Modules, not microservices

#557

Post by lightbendover »

KptMarchewa wrote: post #242
lightbendover wrote: post #226

Earlier quoted context omitted.

> A better rule is for one service to own writes for a table This breaks down when the database is essentially a generic graph. The worst solution I've seen to this is to have another service responsible for generic write operations and any service that wants to write data goes through that service -- you're essentially re-introducing the problem you're purporting to solve at a new layer with an added hop and most li…

Added network call is often better than disjointed view on database schema.

That's a difficult claim to make without knowing the workload.

Re: Modules, not microservices

#558

Post by dools »

In my experience of building stuff in a way that I guess you would describe as micro services, but purely by happenstance (ie. I didn’t set out to “do micro services”) at the heart of micro services are queues.

Queues are awesome, just use queues almost all the time and then either build micro services or don’t.

Re: Modules, not microservices

#559

Post by davej »

yellow_lead wrote: post #185
davej wrote: post #103

Earlier quoted context omitted.

Twitter has a similar issue according to Musk https://twitter.com/elonmusk/status/1592176202873085952

The tweet is obviously wrong. > I was told ~1200 RPCs independently by several engineers at Twitter, which matches # of microservices. The ex-employee is wrong. > Same app in US takes ~2 secs to refresh (too long), but ~20 secs in India, due to bad batching/verbose comms. RPCs are on the server side. Why would they app take longer to refresh in India than in the US? Some more explanation: https://twitter.com/mjg59/st…

Musk may just be wrong but isn’t it also possible that the RPCs need to communicate with an edge node in India. Perhaps government regulation requires them to store/serve some user data from India if serving Indian customers? Or something like that?

Re: Modules, not microservices

#560

Post by peteradio »

regularfry wrote: post #221
Pamar wrote: post #129

Earlier quoted context omitted.

I have exactly the opposite problem though: the kind of problems I have worked on so far would not be "solved" by leveraging "large number of developers that can independently work on an equally large number of small, modular programs with a very well defined, concise interface". And this is not because "my stuff is complicated and your stuff is a toy", either. It's more like "ERP or Banking Systems" were deployed de…

Microservices as a named architectural pattern are over a decade old at this point. Anyone jumping on them because they're the new hotness is more than a little behind the times. > I have exactly the opposite problem though: the kind of problems I have worked on so far would not be "solved" by leveraging "large number of developers that can independently work on an equally large number of small, modular programs with…

> Anyone jumping on them because they're the new hotness is more than a little behind the times.

cough Aging directors in Health and Finance cough

Post reply on HN