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

191–200 of 671 posts

Re: Modules, not microservices

#191

Post by BackBlast »

guywhocodes wrote: post #151
BackBlast wrote: post #134

Earlier quoted context omitted.

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…

Are organizations ever capable of enforcing coding standards even remotely close to that of what microservices _should_ provide? Because I have not seen it. However this is muddied by the fact that I almost never see microservices, I see a lot of distributed monoliths tho.

For an org capable of adhering to standards. I've seen success in small teams. I've never seen it in a large org through, it's always a dumpster fire. Especially anything that grows really fast, culture is out the window to randomness, and it's a hodgepodge of understanding and methods that are all over the map.

Re: Modules, not microservices

#192

Post by dalbasal »

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…

"If you are institutionally incapable of..."

This is the road to bullshit. Of course no manager or CEO will admit that their team/company is that. Admitting technical non-excellence is nearly impossible. Organisation inadequacy... impossible.

So the best course of action is to pretend your organisational methods are really just software architecture... and back to square one.

Re: Modules, not microservices

#193

Post by je42 »

strictfp wrote: post #154
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…

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components. What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail. You also cannot produce any meaningful end-user value without involving several teams. Microservices is just "back…

Conways law: Tech follows communication patterns (.i.e org setup)

hence, if you want a certain architecture, you likely need to execute a "reverse conway law" org first. To get the org into the target config, the software will follow.

Re: Modules, not microservices

#194

Post by esailija »

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.

Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices.

Look up a thing called "distributed monolith".

Re: Modules, not microservices

#195

Post by Pamar »

kayodelycaon wrote: post #144
Pamar wrote: post #44

The article above, and most if not all the comments I read right before posting this, seem to be very quiet about what I thought was one of the main "distinctive elements" of Microservices. I.e. the idea that each microservice has direct access to its own, dedicated, maybe duplicated storage schema/instance (or if it needs to know, for example, the country name for ISO code "UK" it is supposed to ... invoke another m…

Country codes, and other lookup tables, could easily be handled by a repository of config files. Or, if your company uses a single programming language, a library. One strategy I've used is to designate one system as a source of truth (usually an ERP system) and periodically query its database directly to reload a cache. Every system works off their own periodically refreshed cache. Ideally, having all the apps query…

Fair enough. The catch, though is that ... I am the guy working on the ERP, in your example ¯\_(ツ)_/¯

Re: Modules, not microservices

#196

Post by beagle3 »

mcculley wrote: post #137
beagle3 wrote: post #85

Earlier quoted context omitted.

There is another downside, much more problematic in my experience - the failure modes of a distributed system (even over multiple processes in the same machine) are very different. The other process might be killed by OOM manager, user initiated kill signal, or a bug. All of a sudden, asking an object for its string identifier xyz.Name() becomes a possibly failing operation even though it succeeded a microsecond ago.

Yes, there are downsides to distributed systems. In some cases, they are still necessary. This approach allows us to make the decision to be distributed at runtime instead of at design time. For our services, there is never a single point of failure. We use Resilience4j for retries, caching inside the dynamic proxy handler (using annotations to describe what is cacheable), and annotations to describe what can be done…

I was referring to your "only downside" statement (size and mutability of messages). No, that's far from the only downside, and in my experience, not even the most important one.

> In the cases where we use these, the caller is aware (via the interface documentation) that this is a distributed system where sometimes invocations happen really fast and reliably.

This is at odds with

> I have systems where the decision to put the module in the same process or to call it via RPC is done at runtime.

Either it's in the caller's choice (based on the documentation), or it's at runtime, but it can't be both and be equally reliable.

Re: Modules, not microservices

#197

Post by riknox »

xnorswap wrote: post #168
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'…

Broadly my heuristic for this is, "Would it make sense to run these functions in the other other?". If you split up MegaFunction(){} to Func1(){} Func2(){}, etc, but it never makes sense to call Func2 except after Func1, then you haven't actually created two functions, you've just created one function in two places. Refactoring should be about logical separation not about just dicing a steak because it's prettier tha…

I think that's a reasonable heuristic, but I'd also say you have to take into account the human readability aspect of it. It sometimes does make sense IMO to split solely for that, if it allows you to "reduce" a complicated/confusing operation to a string name, leading to it being easier to understand at a glance.

Re: Modules, not microservices

#200

Post by mcculley »

beagle3 wrote: post #196
mcculley wrote: post #137

Earlier quoted context omitted.

Yes, there are downsides to distributed systems. In some cases, they are still necessary. This approach allows us to make the decision to be distributed at runtime instead of at design time. For our services, there is never a single point of failure. We use Resilience4j for retries, caching inside the dynamic proxy handler (using annotations to describe what is cacheable), and annotations to describe what can be done…

I was referring to your "only downside" statement (size and mutability of messages). No, that's far from the only downside, and in my experience, not even the most important one. > In the cases where we use these, the caller is aware (via the interface documentation) that this is a distributed system where sometimes invocations happen really fast and reliably. This is at odds with > I have systems where the decision…

I meant "only downside" in terms of how to design the API parameters and return values.

I did not say it is the caller's choice nor that it is equally reliable. It is a system composition decision. It is a system that is sometimes distributed and treated as such from a reliability point of view. Sometimes the actual implementation is more reliable and faster.

Post reply on HN