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

371–380 of 671 posts

Re: Modules, not microservices

#371

Post by hinkley »

> At the heart of microservices, we often find...

> ... the Fallacies of Distributed Computing.

I feel like I’m taking crazy pills, but at least I’m not the only one. I think the only reason this fallacy has survived so long this cycle is because we currently have a generation of network cards that is so fast that processes can’t keep up with them. Which is an architectural problem, possibly at the application layer, the kernel layer, or the motherboard design. Or maybe all three. When that gets fixed there will be a million consultants to show the way to migrate off of microservices because of the 8 Fallacies.

Re: Modules, not microservices

#372

Post by dmitriid »

jraph wrote: post #84
dmitriid wrote: post #64

Earlier quoted context omitted.

Just use a proper IDE. It doesn't care about how your code is structured and can easily show you what you look for in context . (And other tools like symbol search https://www.jetbrains.com/help/idea/searching-everywhere.htm... )

and it also does not magically guess what is in modules you haven't fetched yet. (I use LSP when I can)

Of course it can't know about non-existent sources. But when the sources are there, it's light years ahead of a simple text search that is grep/ripgrep.

Re: Modules, not microservices

#373

Post by JamesBarney »

BackBlast wrote: post #134
leidenfrost wrote: post #123

I think most criticisms around microservices are about good practices and skills beating microservices in theory. And the virtue of microservices is that they create hard boundaries no matter your skill and seniority level. Any unsupervised junior will probably dissolve the module boundaries. But they can't simply dissolve the hard boundary of having a service in another location.

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors from coupling your modules, perhaps it's worth it. But there are more efficient ways to build and run an engineering organization. The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices…

Any way you slice it, it's hard to manage/align/coordinate a 100 devs.

If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move.

The biggest issue is if you aren't large enough to have challenging organizational issues it's much easier to just solve the very solvable organizational issues than implement and use microservices.

Re: Modules, not microservices

#374

Post by spion »

dahfizz wrote: post #366
eklitzke wrote: post #356

Earlier quoted context omitted.

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.…

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

You can run multiple instances of most stateless monoliths

Re: Modules, not microservices

#375

Post by anthonypasq »

em500 wrote: post #116
beefield wrote: post #17

Earlier quoted context omitted.

Because one day someone else may need to read and understand your code?

But is it generally easier to read and understand, say 10 files of 1000 lines or 100 files of 100 lines or 1000 files of 10 lines, compared to one 10,000 lines file? (I don't know the answer, and don't have any strong opinion on this.)

navigating between files is trivial in most real IDE's. i can just click through a method and then go back in 1 click

Re: Modules, not microservices

#376

Post by hinkley »

fennecfoxy wrote: post #357

Idk I feel like one of the benefits to uservices is isolation; not in design or architecture as many comments say, but isolation from one service affecting another. If I run a monolith and one least-used module leaks memory real hard, the entire process crashes even though the most-used/more important modules were fine. Of course it's possible to run modularised code such that they're sandboxed/resources are controll…

If you really require that sort of isolation, then microservices are a bugridden, ad hoc implementation of half of Erlang.

Re: Modules, not microservices

#377

Post by catlifeonmars »

dahfizz wrote: post #366
eklitzke wrote: post #356

Earlier quoted context omitted.

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.…

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

Running a single server often can’t meet availability expectations that users have. This is orthogonal to scalability. You almost always need multiple copies.

Re: Modules, not microservices

#378

Post by Guid_NewGuid »

randomdata wrote: post #272
Guid_NewGuid wrote: post #219

Time to throw the cat amongst the proverbial pigeons and start the year 2023 off with discord and disharmony. Microservices are a solution to a problem. TDD is a solution to a problem, the same problem. Both are solutions that themselves create more, and worse, problems. Thanks to the hype driven nature of software development the blast radius of these 'solutions' and their associated problems expands far beyond the…

Microservices has little to do with tech. It is a way of organizing teams of people , funnelling all communication between teams through well defined specifications instead of ad-hoc meetings. It is not clear where static typing, or lack thereof, comes into play here. TDD is a method of documenting your application in a way that happens to be self-verifying. You could use a Word document instead, but lose the ability…

# Microservices

I think at the root this idea that Microservices provide this technical solution to a social issue, coordinating teams at scale, hides the driving motivation.

Why can't the teams work on the same codebase and the same database? (again note my edited in disclaimer in the GP post that maybe at certain rare scales it's necessary). What is a well defined specification and why is it only a REST/proto/whatever network API? Why not a defined interface or project/library? Why aren't teams at this scale working in languages that support defining these things in code without adding a complicating, latency and error-inducing, network call?

Statically typed languages are just superior at encoding this "well defined specification". It's a large part of their reason for being. Sure you can still bypass it and do reflection or other naughtiness, but we shouldn't pretend a network call is the only solution.

# TDD

Testing is certainly a way to provide a self-verifying application. TDD is a toxic, hype-driven, mess that has led many good developers astray. Static languages have their own devils here, mocking being chief among them (not to mention the Java clown brigade and their own enthusiastic adoption of -- originally Smalltalk conceived -- TDD).

I added TDD both to annoy people but also to illustrate the general point. These are both concepts derived from the obvious drawbacks of dynamically typed languages that are then treated as generalist answers to complexity in software.

If you'll allow me some pseudo-intellectual waffle, the complexity of a software system C_dynamic + C_software = C_total, that is, complexity of dynamically typed languages and their lack of rigour, plus complexity of software and the domain as a whole gives you total complexity. These approaches primarily target the dynamic complexity. Therefore introducing them and all attendant drawbacks in places where total complexity doesn't include the dynamic complexity because tools and approaches to remove this source of complexity are used actually worsens the entire field.

Re: Modules, not microservices

#379

Post by bcrosby95 »

spion wrote: post #374
dahfizz wrote: post #366

Earlier quoted context omitted.

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

You can run multiple instances of most stateless monoliths

It's also way easier to design for. The web is an embarrassingly parallel problem once you remove the state. That's a big reason why you offload state to databases - they've done the hardest bits for you.

Re: Modules, not microservices

#380

Post by MuffinFlavored »

__jem wrote: post #354
MuffinFlavored wrote: post #336

Earlier quoted context omitted.

so for example in the context of Java, you have one main App/main() entry, probably bounding to a port (let's say 80 serving HTTP requests) acting as a router it brokerages them to subclasses/handlers for CRUD/RPC/plumbing to database/other services then in a separate process App/main() you have a cron job or a queue of some sort you bundle these together as a monolith into one main()?

In the case of Java, imagine we have a big Maven project that has a bunch of different well factored modules that form the "libraries" of our application. At first, in our Maven project we also have a single module which is the deployable for "the monolith" -- it consumes all the other "lib" modules and gets packaged into a fat jar. We deploy a few instances of the monolith fronted by a load balancer. There's not muc…

so you end up with a monolith that might have a config flag or something to determine its purpose when it comes online, and then it can go down a few different code paths. pretty cool. is this something that is done on the fly and then later you don't let that code pattern stay alive (aka, is it not a smell/bandaid)?

my concern would be if you accidentally create bugs by basically creating new mini-monolith flavors as the modules were never expected (in the beginning of their creation) to run in a "partial" context

Post reply on HN