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

441–450 of 671 posts

Re: Modules, not microservices

#441

Post by bradwood »

zeroonetwothree wrote: post #314
zbobet2012 wrote: post #281

Earlier quoted context omitted.

> there is no need to have the microservices built along Conways Law This is a misunderstanding of Conway's Law. Your code _will_ reflect the structure of your organization. If you use microservices so will their architecture. If you use modules, so will the modules. If you want a specific architecture, have your organization reflect the modules/microservices defined in that architecture.

Exactly. Conway's Law is descriptive not prescriptive !

Quite. And many people still seem to confuse this. The way to exploit Conway's law is not to do anything _technical_ but rather to do something _organisational_. The "Reverse Conway Manoeuvre" is the term, IIRC, for this. Rather than trying to "build something along the lines of Conway's law" (which doesn't really make sense) -- one should determine a desired architecture and then set up the _organisation_ and teams to mirror that.

Re: Modules, not microservices

#442

Post by fruit2020 »

PathOfEclipse wrote: post #70
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

As someone who has personally dealt with files as large as 60K lines, I disagree completely. I believe instead that structure and organization should be added as a business and codebase scales. The problem I think most orgs make is that, as they grow more successful, they don't take the time reorganize the system to support the growth, so, as the business scales 100x in employee account, employee efficiency is hamper…

Well said. You will see very fast if a dev is experienced or not by looking at code organization and naming. Although I deal with experienced ones that just like to live in clutter. You can be both smart and stupid at the same time.

Re: Modules, not microservices

#443

Post by beefield »

mbork_pl wrote: post #160
beefield wrote: post #17

Earlier quoted context omitted.

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

But this is precisely my question: in what way does splitting the code into many small files help with that? Personally I find jumping between many files (especially when they are located in various directories on various levels in the fs) pretty annoying... Of course, that probably depends on the nature of the project. Having all backend code of a web app in one file and all the frontend code in another would be ver…

Obviously you can split your code into many files in a way that obfuscates the workings of the program pretty much comoletely. And I think you can write a single 10kloc file that is so well organized that it is easy to read. I just never have seen one...

I believe that files offer one useful level of compartmentalizing code that makes other people easier to understand what is going on by just looking at the file structure before opening a single file. The other guy can't grep anything before they have opened at least one file and found some interesting function/variable.

Re: Modules, not microservices

#444

Post by hbrn »

com2kid wrote: post #414
hbrn wrote: post #370

Earlier quoted context omitted.

> Java doesn't let you say age is an int ranging from 0 to 130 This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not reall…

> This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age. Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!) > You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures yo…

> Ada solved this in the 80s, it isn't some unresolved field of comp sci

Every solution comes at a cost. Where is Ada now?

> Unit Tests are no different, except with worse syntax than built in language support.

And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes.

> At least with support in the type system you can turn off range checks for production builds

Sounds like dynamic typing with extra steps.

Re: Modules, not microservices

#446

Post by JamesBarney »

locutous wrote: post #422
JamesBarney wrote: post #373

Earlier quoted context omitted.

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

> 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. Famous last words, if done right... Or you just multiply your organizational issue with a technical one.

Sure poorly implemented solutions rarely solve problems well.

But implementing microservices is not an unsolvable problem. It's a problem that 1000s of organizations have solved.

Re: Modules, not microservices

#447

Post by linza »

brhsagain wrote: post #395
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 don't understand the argument around microservices purporting to fix scalability. Say your system has modules A, B and C in one app, and that A requires more resources while B and C are relatively unused. Won't B and C just run less and thereby use appropriately fewer resources from within the same system as A? Are microservices just an aesthetic separation (it feels nice to know you're "only" scaling up A)?

It doesn't necessarily fix it but has less resource waste or is easier to manage than the bin packing needed otherwise.

Re: Modules, not microservices

#448

Post by hbrn »

Guid_NewGuid wrote: post #257
ollien wrote: post #246

Earlier quoted context omitted.

The assertion that TDD is a solution to dynamic typing falls apart when you consider that the TDD dogma was born out of Java programmers. I won't argue that Java has the most expressive type system, but it _is_ statically typed.

My understanding is that it's kind of a 3-pronged thing, It originates (or is "rediscovered") by Kent Beck working in, at-the-time, Smalltalk. It has huge adoption in the RonR community. And lastly the usual Java suspects who never met a bad pattern they couldn't massively overadopt, e.g. the so-called "Uncle" Bob who never met a pattern he couldn't jam into code to overcomplicate it.

> It has huge adoption in the RonR community

Is that even true? DHH (RoR creator) hates TDD.

Re: Modules, not microservices

#449

Post by 10000truths »

locutous wrote: post #404
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…

> 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 200 threads, 12TB of RAM, with a pipe upwards of 200GB/s. This isn't even as big as you can go, this is a reasonable off the shelf item. If your service doesn't need more than this, maybe don't break it up. :) I believe that this level of service can no longer accurately be…

This cannot be emphasized enough. The top of the line configuration you can get today is a dual EPYC 9654. That nets you 384 logical cores, up to 12 TB of RAM, and enough PCIe lanes to install ~40 NVMe drives, which yields 320 TB of storage if we assume 8 TB per drive. All for a price that is comparable to a FAANG engineer's salary.

Re: Modules, not microservices

#450

Post by kjcondon »

It's not really about what's better, it's about whats been standardized upon.

I'm sure I could gain many of the advantages of microservices through an OSGi monolith, however, an OSGi monolith is not the hot thing of the day, I'm likely to be poorly supported if I go down this route.

Ideally I also want some of my developers to be able to write their server on the node ecosystem - if they so choose, and don't want updating the language my modules run on (in this case the JVM) to be the biggest pain of the century.

Besides, once my MAU is in the hundreds of thousands, I probably want to scale the different parts of my system independently anyway - so different concerns come in to play.

Post reply on HN