[spsesk117]

I definitely agree with the line of thinking posited, what I'm less clear on is what the discrete implementation of these ideas looks like.

I worked at a company once with huge monolith system, mainly revolving around a relational database. We tried for years to break out of this, and if my understanding is correct this organization is still on this monolith today. There were a number of challenges, and we tried a number of different solutions (NoSQL models/object stores/etc), but it felt like there were base level assumptions about the availability of data in the core application that felt impossible to address without a full scale rewrite and reevaluation of all previous assumptions.

Perhaps I've answered my own question here -- it just needed to be completely redesigned from the ground up. Short of doing that however, would anyone care to provide high level insight on how they'd break down this problem, and what technology they might use to address it?

[dragontamer]

What's wrong with the monolith? If that monolith was designed 30 years ago on RAIDed hard drives, upgrading to an all-SSDs 4TB RAM system today probably would solve all of those issues.

Really: is the monolith problem so difficult that a $400,000 computer can't solve the problem? Is there any developer project you can fund for say $1 million ($400k for the computer, 600k for system IT time to transfer the data to the new computer) that would give the same return on investment?

$400k gets you an all RAIDed PCIe 4.0 SSDs + 4TBs of RAM, 128-core dual-socket EPYC or something. That __probably__ can run your monolith.

[dwheeler]

"Monolith" is not a problem. It's just a description of an architectural approach. Often switching to alternatives, like microservices, is a terrible idea: https://medium.com/swlh/stop-you-dont-need-microservices-dc7...

The question is: What do you actually need to do? I.e., what are your requirements?

It's all about trade-offs. If you can't identify at least one pro & one con to an approach you're considering, you don't adequately understand the approach you're considering.

[Sohcahtoa82]

You know what's worse than microservices?

What I've dubbed "nanoservices". Basically, a service that hosts a single function. At a previous role I had, the dev team decided that account registration, login, and password recovery each needed to be a separate microservice.

When they first described it to me, I thought they meant that maybe each was a separate AWS Lambda function behind a single API gateway or something, but no...each was in its own repo, and each was a separate container deployed into Kubernetes.

I can't imagine the amount of overhead creates to manage that.