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

311–320 of 671 posts

Re: Modules, not microservices

#311

Post by UltraViolence »

Bring back the monoliths! Divided up into modules and each of those modules being developed by another team, but essentially still the same deliverable (binary).

You only need to agree on an API between the modules and you're good to go!

Microservices suck dick and I hate the IT industry for jumping on this bandwagon (hype) without thoroughly discussing the benefits and drawbacks of the method. Debugging in itself is a pain with Microservices. Developing is a pain since you need n binaries running in your development environment.

Re: Modules, not microservices

#312

Post by pjmlp »

KptMarchewa wrote: post #247
pjmlp wrote: post #209

Earlier quoted context omitted.

Strong typed languages with support for binary modules are just as good keeping people honest. Each team gets to distribute libraries over repos (COM, JAR, DLL, whatever), no way around that unless they feel like hacking binaries.

And then each DLL creates its own thread pool... well, usually multiple.

Which is irrelevant, as many microservices do the same inside of them, and the libraries that they consume.

Re: Modules, not microservices

#313

Post by jacobr1 »

MuffinFlavored wrote: post #271
jacobr1 wrote: post #259

Earlier quoted context omitted.

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, ei…

> you have to scale up the entire thing which is huge, expensive, etc.

Yes, yet people still do it that way. This is tradeoff against the costs of microservices. I'm not saying it is worth it, but yes, sometimes you can just inefficiently throw hardware resources at scaling problems.

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

Because you are incrementally changing an existing monolith, but still getting some of the benefits of scaling distinct workloads independently. If you do this right, it does lend it self to reworking the new "service" to be become its own microservice. Or you can just keep going with the shared codebase.

Re: Modules, not microservices

#314

Post by zeroonetwothree »

zbobet2012 wrote: post #281
lifeisstillgood wrote: post #267

Earlier quoted context omitted.

I think it runs a bit deeper than that. Microservices are how the business views its self. Look, once upon a time managers designed the system that workers implemented. The factory assembly line, or the policy manual. But now the workers are CPUs and servers. The managers designing the system the workers follow are coders . I say coders are the new managers. Now this leaves two problems. The first is that there are a…

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

Re: Modules, not microservices

#315

Post by bob1029 »

We've done the round trip of splitting up a monolith into microservices and then going back the other way. Network API overhead being the biggest reason. This kind of hell is totally unnecessary until it absolutely is (i.e. hard information theory requirements demand you spread your app across more than 1 physical computer).

Monolith is better in almost every way. The only thing that still bothers us is the build/iteration time. We could resolve this by breaking our gigantic dll into smaller ones that can be built more incrementally. This is on my list for 2023.

Re: Modules, not microservices

#316

Post by zeroonetwothree »

hbrn wrote: post #238
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…

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

I've had three reorgs in the past six months. Each one changed our projects and priorities.

Yeah, didn't get a lot done...

Re: Modules, not microservices

#317

Post by zeroonetwothree »

MuffinFlavored wrote: post #271
jacobr1 wrote: post #259

Earlier quoted context omitted.

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, ei…

The way it usually works, if 1 of your 100 modules needs to be scaled, it probably means the overall monolith only needs a small amount of extra resources, since that module is only using 1% of the total. So it's not like you need to double the instances of the whole thing.

The benefit though is you get a bit of 'free' scaling. Most of the modules don't even have to consider scaling at all, as long as they are growing ~average or slower. So this saves a lot of operational burden for many teams. Conversely with microservices every team has to consider scaling, no matter how simple their service is.

(If you do have 1 module out of 100 that takes up 40% of the resources, then it may be appropriate to split it up. Monolith doesn't literally mean "exactly one service", after all, just a small number of big ones.)

Re: Modules, not microservices

#318

Post by unboxingelf »

padjo wrote: post #86
c-fe wrote: post #73

I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attem…

I don’t mean to be snarky but how is that an “unexpected consequence”? Were the pros and cons just never considered when deciding to use micro services? Additional networks calls are one of the most obvious things to go on the cons list!

Just wait until you decide you need some kind of distributed transaction support across multiple microservices… You should aim to spend a considerable amount of time in the design and discovery phases.

Re: Modules, not microservices

#319

Post by __jem »

MuffinFlavored wrote: post #271
jacobr1 wrote: post #259

Earlier quoted context omitted.

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, ei…

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

not necessarily. yes, you do pay for executable bloat and some memory overhead from loading code into memory, but the argument here is that you can still deploy a "Service B" from the same deployable that only services certain kinds of requests in order to scale parts of the application horizontally.

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

no, because again, you're still deploying the same single codebase, it's just the instance on the other end of the queue is configured just to consume and process messages.

Re: Modules, not microservices

#320

Post by ReflectedImage »

Pamar wrote: post #143
anthonypasq wrote: post #132

Earlier quoted context omitted.

ive never seen that in practice. you dont have a database for each individual lambda. thats insanity. you can have multiple microservices point to a shared datasource, its not illegal.

I agree, and yet most microservice zealots seem to have a different opinion on this. e.g.: https://www.baeldung.com/cs/microservices-db-design "2.1. Fundamentals By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements. Let’s see how it looks:" Please un…

Whilst I don't know much about cruises. Let me make up an example for you.

Let's suppose we are Acme Cruise Lines running a Cruiseliner:

Microservice - National Coastguard Ship Arrival System Feed Handler

Database - Logs incoming messages on the feed

Microservice - Asian and Australian Joint Ship Monitoring System

Database - Logs incoming messages on the feed

Microservice - Cruiser Arrival and Departure Times

Database - Cruiser Arrival and Departures Times in a Standard Format

Microservice - Customer Bookings and Payments

Database - Customer Bookings and Payments

Microservice - Fuel Management System

Database - Ship Fuel Levels & Costs of fuel at Various Ports.

It's that high level of split up.

(AWS Lambdas aren't quite the same thing as microservices.)

Post reply on HN