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

521–530 of 671 posts

Re: Modules, not microservices

#521

Post by satellites »

slowmovintarget wrote: post #355
dasil003 wrote: post #176

Earlier quoted context omitted.

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 teams around products. The point is to increase value delivered to the customer through the product, not to produce left-pad-as-a-service.

Agreed. I've worked at a scarce few companies who organized this way, but it seemed to work better than "frontend team, backend team, devops team." When each piece of the stack is a different team, it creates unnecessary hostility and miscommunication. Aligning engineers around products, such that your iOS dev and your backend dev are on the same team, seems to run more smoothly. YMMV.

Re: Modules, not microservices

#522

Post by SgtBastard »

catlifeonmars wrote: post #466
ElectricalUnion wrote: post #426

Earlier quoted context omitted.

You can run most applications on a single server - IBM S/390 big iron has very high reliability, redundancy and I/O bandwidth.

Yes but it’s literally a single point of failure. You probably want at least two servers in separate physical locations. Also how do you do deployments without interruption of service on a single server?

Blue/green deployments and request draining like with any other deployment topology.

Re: Modules, not microservices

#524

Post by mixermachine »

gadflyinyoureye wrote: post #517
jayd16 wrote: post #431

Earlier quoted context omitted.

Another way to look at this is microservices reduce the blast radius of problems.

Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.

Sure depends on the architecture. When the auth service is down, everything else should be down. But when the "optional feature" service is down, a core component should be unaffected by that.

Split up services where it makes sense and don't over do it. That's how I design my projects.

Re: Modules, not microservices

#525

Post by mixermachine »

kubota wrote: post #515
thayne wrote: post #476

Earlier quoted context omitted.

> I don't really think microservices are fundamentally more scalable It depends on what you are scaling. I think microservices are fundamentally more scalable for deployment, since changes can be rolled out only to the services that changed, rather than everywhere. Unless your language and runtime support hot-loading individual modules at runtime.

I disagree, in my opinion micro-services hinder scalability of deployment, and development - at least the way I see most businesses use them. Typically they break out their code into disparate repositories, so now instead of one deployment you have to run 70 different ci/cds pipelines to get 70 microservices deployed, and repo A has no idea that repo B made breaking changes to their API. Or lib B pulled in lib D that…

Breaking APIs do not happen often at least in my projects. We mostly add new Endpoints for new features (non breaking change).

We keep object definitions in a separate repo to not duplicate them and generate a maven dependence from that. Pretty simple actually. We mainly run on Java thought. Would be more complicated when there are multiple languages.

Protobuf or Json schema could come to the rescue if needed.

Re: Modules, not microservices

#526

Post by lifeisstillgood »

rented_mule wrote: post #474
8note wrote: post #401

Earlier quoted context omitted.

The systems are not only organized on the programmers managers, but their managers too, all the way up the chain.

Very good point. Tying that back into the Conway's law angle on all of this... I've been a couple levels up the chain at times in my career. When I've seen technical decisions at this level done well is when those people realize that their organizational decisions are inevitably technical decisions because of Conway's law. When the impact of Conway's law is not explicitly considered, things will often look random at…

I think microservices turn this around - the idea is that if we ignore them as technical units and treat them as organisational units we can invert conway's law - it's much easier to change how microservices talk to each other than it is to chnage how people do.

But if you chnage the dataflow in a few microservices so that the accounts team no longer deals / works directly with the sales team you have chnaged the organisation.

plus it's way easier to monitor activity etc

Re: Modules, not microservices

#527

Post by threeseed »

gadflyinyoureye wrote: post #517
jayd16 wrote: post #431

Earlier quoted context omitted.

Another way to look at this is microservices reduce the blast radius of problems.

Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.

You design your microservices so that they gracefully degrade.

So if a database service is not available you simply return stale, cached data until the service is back up.

Re: Modules, not microservices

#528

Post by JAlexoid »

10000truths wrote: post #449
locutous wrote: post #404

Earlier quoted context omitted.

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

And you're missing one little thing - if you get all of your processing on two of those, you save way more than 4 engineers salaries in development/maintenance costs.

Let alone - AWS Lets you get that machine for less than a junior engineer salary ($7.5 per hour, roughly equivalent to $32 of hourly wage = $67k)

Re: Modules, not microservices

#529

Post by JAlexoid »

vbezhenar wrote: post #501
ElectricalUnion wrote: post #426

Earlier quoted context omitted.

You can run most applications on a single server - IBM S/390 big iron has very high reliability, redundancy and I/O bandwidth.

What if I have $500/month to spend and still need high reliability and redundancy?

That's a budget for a local crafts store website hosting, not "high availability" system

Re: Modules, not microservices

#530

Post by unity1001 »

vbezhenar wrote: post #501
ElectricalUnion wrote: post #426

Earlier quoted context omitted.

You can run most applications on a single server - IBM S/390 big iron has very high reliability, redundancy and I/O bandwidth.

What if I have $500/month to spend and still need high reliability and redundancy?

Go to Digitalocean or a similar provider. Launch a managed HA db. (starts at ~$120/month). Launch an autoscaling HA K8 cluster (starts from ~$80) , deploy 1-2 stateless pods. There you go.
Post reply on HN