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

231–240 of 671 posts

Re: Modules, not microservices

#231

Post by lightbendover »

jerf wrote: post #202
strictfp wrote: post #154

Earlier quoted context omitted.

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…

"This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components." Conway's Law is basically "You don't have a choice." You will cement the design of your app around your organizational design. (At least, beyond a certain org size. If you have only 4 engineers you don't really have the sort of structure in question here at all.) je42 n…

Part of the issue is that not everyone understands the trade-offs or perhaps believes the trade-offs so you get teams/leaders haphazardly ignoring expert guidance and crafting careless micro-services around team boundaries that do not line up with value.

Re: Modules, not microservices

#232

Post by snarf21 »

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

I think you are missing one point: mental load. I doubt people keep all their files in one directory or all their emails in one folder or just have one large drawer with every possible kitchen utensil in a pile. The same is true for code. Organizing your code around some logical divisions allows for thunking. I will agree that some people take it too far and focus too much on "perfect". But even some rudimentary directories to separate "areas" of code can save a lot of unnecessary mental gymnastics.

Re: Modules, not microservices

#233

Post by regularfry »

treis wrote: post #229
regularfry wrote: post #201

Earlier quoted context omitted.

You can deploy modules independently, but the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in. Modules live in the same execution context, so you need a good shared ownership model for that context itself. The point is that Parnas never conceived of doing it because he was writing about a world where the interfaces…

You need to do additional steps in both cases: With modules you need some sort of wrapper application to bring it all together. With microservices you need some sort of network layer so that the microservices can talk to each other.

And also with modules you need the business processes to coordinate deployments across teams, because they all live in the same wrapper application. That's what stops them being independent.

You don't restart the network every time you deploy a microservice.

Re: Modules, not microservices

#234

Post by lightbendover »

jonhohle wrote: post #172
strictfp wrote: post #154

Earlier quoted context omitted.

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…

One of the principal engineers at Amazon called that “Org-atecture”.

Amazon is a good example of a huge organization absolutely crippled by micro-service fiefdoms driven by sr.mgr whims and not strong technical guidance from such PEs.

Re: Modules, not microservices

#235

Post by pjmlp »

regularfry wrote: post #230
pjmlp wrote: post #212

Earlier quoted context omitted.

Same thing with microservices, unless you do a blue green deployment, have a planned shutdown, load balancer in between releases,...

The key word is "independently".

There is no independently in distributed systems.

Re: Modules, not microservices

#236

Post by techthumb »

Transaction boundaries are a critical aspect of a system.

I've often noticed that these boundaries are not considered when carving out microservices.

Subsequently, workarounds are put in place that tend to be complicated as they attempt to implement two phase commits.

Re: Modules, not microservices

#237

Post by barrkel »

ramblerman wrote: post #163
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…

You shoot yourself in the foot pretty hard regarding point 2 (scalability) if you have your microservices share a DB.

FWIW, most of Google's Ads services share a database - the catch is it's F1 on top of Spanner. Latency is highish, but throughput is good.

In the outside world, for an application that may truly need to scale, I'd go MySQL -> Vitess before I'd choose separate data stores for each service with state. But I'd also question if the need to scale that much really exists; you can go a long way even with data heavy applications with a combination of sharding and multitenancy.

Re: Modules, not microservices

#238

Post by hbrn »

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…

> What happens if you need to redesign the architecture to meet new needs?

How often does major reorganization happen? For most companies the answer is never.

The "what if" argument is what leads to all sorts of premature optimizations.

Re: Modules, not microservices

#239

Post by TimPC »

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…

Modules aren't an alternative to microservices in a reasonable way though. And for all modules solve the modularization problem at the code level, they don't really solve modularization at the service level. The main alternative to microservices is monoliths and for many applications I far prefer microservices to monoliths. I want modularization in how I scale my app, I don't want to spin up a whole bunch of servers that can serve almost any possible function in production. I'd prefer more delineated responsibilities. I don't think modularization solves this if after the modules you just throw all your modules in one big bucket and serve that up.

Re: Modules, not microservices

#240

Post by pionar »

dist1ll wrote: post #91

This article is all over the place. The author acknowledges that microservices are about organizational clarity, then writes "In theory, anyway" without elaboration, and then goes on to talk about the latency impact of network-level IPC. Why do we care about network latency, when we JUST established that microservices are about scaling large development teams? I have no problem with hackers ranting about slow, bloate…

Just saying "gRPC over HTTP" doesn't solve any of the sentence you quoted.

> common architectural backplane with well-understood integration and communication conventions, whatever you want or need it to be

Regardless of the tech used to implement, this paradigm needs to be solved to have a good system. That backplane is not an implementation, but a set of understood guiderails for inter-module communication.

Even with gRPC, both sides need to know what to call and what to provide and expect in response. That's the "conventions" part. Having consistency is more important than the underlying tech. Just simple ReST over HTTP works just as well as gRPC.

Post reply on HN