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

271–280 of 671 posts

Re: Modules, not microservices

#271

Post by MuffinFlavored »

jacobr1 wrote: post #259
MuffinFlavored wrote: post #253

Earlier quoted context omitted.

> But most people need it a lot less than they think. Normally the database is your bottleneck and if you keep your application server stateless, you can just run lots of them At my last job, there were quite a few times where being able to scale some small "microservice instance" up from 2 -> 4 instances or 4 -> 8 or 8 -> 12 was a lot easier/quicker than investigating the actual issue. It'd stop production outages/h…

A few ways, the easiest being to scale up the whole monolith with more instance. Another way is run multiple "services" using the same codebase, so you have workload segmentation, either via synchronous network calls, or async worker systems.

devil's advocate:

> A few ways, the easiest being to scale up the whole monolith with more instance

as far as I know, there's no way to granularly scale up a monolith. if the monolith has 20 or 50 or 100 modules and you need 1 or 2 of them scaled, you have to scale up the entire thing which is huge, expensive, etc.

> Another way is run multiple "services" using the same codebase, so you have workload segmentation, either via synchronous network calls, or async worker systems.

this is interesting. a monolith with some form of IPC? why not do microservices at that point? that sounds like microservices-ish?

Re: Modules, not microservices

#272

Post by randomdata »

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 for the machine to verify that the application does what the documentation claims that it should. Static typing does provide some level of documentation as well, but even if you have static typing available static typing isn't sufficient to convey the full intent that your documentation needs to convey to other developers.

Re: Modules, not microservices

#273

Post by hbrn »

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 agree, but the problem is that eventually it becomes not okay. So it requires a bit of nuance to understand when it is and when it isn't.

Unfortunately most engineers don't like nuance, they want one-size-fits-all solutions.

Re: Modules, not microservices

#274

Post by ollien »

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.

You know, I knew there was a major association between TDD and XP (wonder why!) and I had always heard of XP being Java related, but looking deeper I'm not sure that's has true as I thought

Re: Modules, not microservices

#275

Post by indymike »

arsenico wrote: post #262
hbrn wrote: post #238

Earlier quoted context omitted.

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

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

The kind of reorg we're talking about here is not the typical musical chairs, but a full realignment. This happens a lot less frequently in my experience.

Re: Modules, not microservices

#276

Post by hinkley »

mattgreenrocks wrote: post #184
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…

Implicit to this discussion is the belief that growth inevitably means more people, and that the collateral damage of more people is worth the cost of spending so much time to corral said people. So industry clings to frameworks with a single blessed path, languages that provide only one way to do things, caps expressiveness (just mention macros and people start frothing from the mouth). This isn't easily fixable, bu…

Fewer devs doing a lot more has always been my goal, and in hardware we would call this a vertical scaling versus horizontal scaling problem.

Horizontal scaling always incurs communication overheads faster, and as we know, developers have high communication overhead to begin with.

Human scaling is its own problem set and companies like to ramp projects up and then down again. Most of those people only think about how to get more people on board, not how to run the ship once attrition starts to condense responsibilities and reduce redundancy, especially for unpleasant tasks.

I’ve been trying to beat the idea of ergonomics into a smart but mule-headed developer (too old not to know better) for years now and it wasn’t until a combination of team shrink and having to work with code written by a couple of people who emulate his development style that all of a sudden he’s repeating things I said four years ago (of course with no self awareness of where those ideas came from). It remains to be seen if it affects how he writes code, or whether he starts practicing Do As I Say, Not As I Do, but I’m a short-timer now so it’s mostly an anthropological study at this point.

Re: Modules, not microservices

#277

Post by dkarl »

mpweiher wrote: post #92
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…

> Microservices [..] actually solve for a human problem in scaling up an organization. So does modularity. "The benefits expected of modular programming are: (1) managerial_development time should be shortened because separate groups would work on each module with little need for communication..." On the Criteria To Be Used in Decomposing Systems into Modules , D.L. Parnas 1972. http://sunnyday.mit.edu/16.355/parnas-…

For code modularity to serve the same purpose, I think there needs to be explicit language-level support, because on a medium-sized or larger project, when the modularity exists only in the minds of developers, it might as well not exist at all. You need virtually all of your developers to understand the design and respect the seriousness of violating it, and beyond a certain project size, that isn't possible.

Developers do a much better job with microservices. I think it's easy for them to respect the seriousness of designing and changing the API of a microservice. In contrast, they often don't respect or even realize the seriousness of making a change that affects the modular design of code.

Language-level support for defining and enforcing module interfaces might help developers invest the same level of care for module boundaries in a modular monolith as they do in a microservices architecture, but I've yet to work in a language that achieves this.

Re: Modules, not microservices

#278

Post by swsieber »

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

> It's okay to have files with 10,000 lines.

I find there are practical negative consequences to having a 10,000 line file (well, okay; we don't have those at work, we have one 30k line file). It slows both the IDE and git blame/history when doing stuff in that file (w.r.t. I'll look at the history of the code when making some decisions). These might not be a factor depending on your circumstances (e.g. a young company where git blame is less likely to be used or something not IDE driven). But they can actually hurt apart from pure code concerns.

Re: Modules, not microservices

#279

Post by jacobr1 »

pjmlp wrote: post #235
regularfry wrote: post #230

Earlier quoted context omitted.

The key word is "independently".

There is no independently in distributed systems.

But there are rules of blame.

With microservices, as long as you maintain the contract with caller services, you can deploy whenever you want. If you have some kind of issue, your team is solely responsible. If the caller services do weird things, they are responsible for fixing them.

If you are pushing changes to a module as part of a more monolithic, or wrapper service - if you do a deploy and break the whole big service, you are now responsible for the entirety of any issue, which is now more likely due to integration risk and unrelated changes from others, especially because now there need to be coordination across many teams integrating - hopefully via tests and observability. But this requires a high-degree of maturity for automated quality assurance and site reliability. If you don't have that, the operational risks are very high. So that alternative is having some ops-like function, or other integration team responsible. Or doing more top-down waterfall coordination.

Given the service maturity needed is rare, microservices distributes that operational ownership in a way where there is more accountability.

Re: Modules, not microservices

#280

Post by jcampbell1 »

dasil003 wrote: post #176
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…

How do you organize teams if not around services? As the GP points out, the whole point of SOA is to scale people. Yes, this makes rearchitecture hard, but that is always the case at scale. The problem of territoriality and resistance to change needs other solutions (tldr; clueful management and mature leadership level ICs who cut across many teams to align architecture vision and resolve disputes between local staff…

Organize around delivering value to the customer. This is the obvious split for different products, and it is natural for something like AWS where each service is a relatively small team. Sometimes the customer is internal and they need an API, and internal customer decides when they are satisfied, not the API passing tests. SOA will arise, but services need to be big rather than micro, have defined internal customers and their own team. Better to have teams with frontend, backend, designer, etc. who collectively complete features, rather than hoping a bunch of services integrate into a solution for the customer at the end. It is much easier to get the architecture right when people talk first and often about what the customer needs more than implementation details. I think once you have decided how data is going to be persisted and what the customer needs to accomplish, the architecture falls into place. The application code should be stateless so it is never a scaling issue. When the code is isolated by customer feature, the blast radius for future changes is much smaller.

Microsoft, Apple, Amazon I think do a good job at preaching the customer first model and organizing around that.

Post reply on HN