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

651–660 of 671 posts

Re: Modules, not microservices

#651

Post by int_19h »

dilyevsky wrote: post #288
pjmlp wrote: post #241

Earlier quoted context omitted.

So much for the theory, most services I see in the wild are stateful. As for scalability, most orgs aren't Facebook nor Google scale, regardless of how much they want it to be true. All of those issues can be tackled, when proper architecture design is done, instead of coding on the go and then will see attitude.

People keep regurgitating this “you aint going to be google” mantra but I worked there and in reality generic microservice stack is in a totally different league of complexity and sophistication of what google and co have. This argument is basically reductio ad absurdum

The argument is simply the empirical observation that the vast majority of microservices deployments don't operate anywhere near the scale that actually requires microservices and is not going to operate at that scale in the foreseeable future. When scalability is the primary argument in favor of microservices, how is that absurd?

Re: Modules, not microservices

#652

Post by int_19h »

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.

If it's .NET or Java, that's very unlikely.

Re: Modules, not microservices

#653

Post by int_19h »

rlt wrote: post #590
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…

I’d love for a language / framework that allows for an application to be composed of “modules” that can either be run in a single process, or deployed as multiple independently scalable processes, with a mostly transparent RPC system requiring minimal boilerplate. My IDE should be able to easily traverse the call graph. My development environment should be simple to setup. I’ve worked on microservices that required a…

The industry has been trying to do "transparent remoting" for decades now. DCOM and CORBA were both basically that.

It turns out that "transparent RPC" is basically a contradiction in terms. As soon as you start doing things across process boundaries, and even more so across network boundaries, it requires a very different approach for API design - something that's very cheap locally, like passing objects by reference, becomes expensive and full of footguns.

If you reduce the feature set to the point where it can be transparently mapped to either local or RPC - which is, basically, function calls processing and returning data organized into arrays & trees (but not graphs) - there's still the issue that RPC has so many more failure points that you have to handle that would never light up in local.

This is all still doable; I have my doubts about practical the end result would be, though.

Re: Modules, not microservices

#654

Post by ElectricalUnion »

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?

> it’s literally a single point of failure.

Those machines are made very redundant.

All components in a Parallel Sysplex configuration can operate in redundant mode.

Redundant power. Redundant central processor complex. Redundant multichip module (what would be a chipset on microcomputer platforms). Redundant RAM Memory. Redundant Storage. Redundant internal interconnects. Redundant network adapters.

That's why corporations that require high availability to not get sued for millions/billions use them.

Re: Modules, not microservices

#655

Post by kerblang »

lowbloodsugar wrote: post #574
kerblang wrote: post #383

Earlier quoted context omitted.

Mostly valid, but... On the RAM front, I am now approaching terabyte levels of services for what would be gigabyte levels of monolith. The reason is that I have to deal with mostly duplicate RAM - the same 200+ MB of framework crud replicated in every process. In fact a lot of microservice advocates insist "RAM is cheap!" until reality hits, especially forgetting the cost is replicated in every development/testing en…

>As for slow startup, a server reboot can be quite excruciating when all these processes are competing to grind & slog through their own copy of that 200+ MB and get situated. You are writing microservices and then running them on the same server??

There are multiple hosts, but yeah I doubt our admins would go for 1 service per host, plus they'd just be on VM's sharing the same hardware anyhow.

Re: Modules, not microservices

#656

Post by jmchuster »

mk89 wrote: post #593
jmchuster wrote: post #585

Earlier quoted context omitted.

For us, we started off with a world where each service communicates to each other only via RabbitMQ, so all fully async. So theoretically each service should be able to be down for however it likes with no impact to anyone else, then it comes back up and starts processing messages off its queue and no one is the wiser. Our data is mostly append-only, or if it's being changed, there is a theoretical final "correct" ve…

> So then back to your original question, the way that this contract can break is via schema changes. So for us, since we use postgres, we created database views that we expose for reading. And postgres view updates are constrained that they must always be backwards compatible from a schema perspective. So then now our migration path is: > - service A has some table of data that you like to share > > - write a migrat…

if service B needs some new data from the view that isn't being provided, then you first run the migration on service A to update that view and add a column. Then you are able to update service B to utilize that column.

If you don't need the new column, then you don't need to do anything on service B, because you know that existing columns on the view won't get removed and their type won't change. You only need to make changes on service B when you want to take advantage of those additions to the view.

Re: Modules, not microservices

#657

Post by catlifeonmars »

ElectricalUnion wrote: post #654
catlifeonmars wrote: post #466

Earlier quoted context omitted.

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?

> it’s literally a single point of failure. Those machines are made very redundant. All components in a Parallel Sysplex configuration can operate in redundant mode. Redundant power. Redundant central processor complex. Redundant multichip module (what would be a chipset on microcomputer platforms). Redundant RAM Memory. Redundant Storage. Redundant internal interconnects. Redundant network adapters. That's why corpo…

Redundant physical location. That means different power dependencies and different cities.

Re: Modules, not microservices

#658

Post by catlifeonmars »

JAlexoid wrote: post #529
vbezhenar wrote: post #501

Earlier quoted context omitted.

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

well, to be fair, you could host a highly available local craft store website for under 500 dollars on $cloudprovider easily. You could also trivially get regional redundancy.

Re: Modules, not microservices

#660

Post by winternett »

eklitzke wrote: post #356
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…

I just want to point out that for the second problem (scalability of CPU/memory/io), microservices almost always make things worse. Making an RPC necessarily implies serialization and deserialization of data, and nearly always also means sending data over a socket. Plus the fact that most services have some constant overhead of the footprint to run the RPC code and other things (healthchecking, stats collection, etc.…

I really miss the old days where when an app was down it was obvious... Now apps just go unresponsive because of connectivity issues between services... We used to have frameworks that could communicate errors in one log, it was a beautiful thing. As cloud infrastructure became more powerful to better host so called "monolithic" systems, it was all scrapped to move to microservices, which were made for less powerful infrastructure. Everything was refactored to the point where it's expensive to go back... Pretty crazy how much money the industry wastes on refactoring...

On top of that, the tendency to get complacent with unstructured data in a lot of systems is really creating a very complicated lock-in when systems are developed for unique services on each cloud provider... Bowls of spaghetti.

Hire Solutions Architects for dev projects, make your apps future proof... I warn you. Too much microservice customization leads to vendor lock in and expensive operational costs... This is why a lot of apps get sunsetted early.

Post reply on HN