So somehow you can't end up with the micro services version of spaghetti code? If an engineering organization can't handle managing a single codebase, why would you assume they would be good stewards of multiple codebases?

Not only that, but who takes on the configuration and orchestration complexity of micro services? I'm not saying they cannot work, but often a restructured monolith is still a better idea... I prefer to break off bottlenecks into services where practical. Such as doing image resizing in a separate service.

Breaking data structures apart often leads to it's own form of spaghetti.

Microservices allow you to scale your organization, not your application. For that particular use, microservices are absolutely better than monoliths.

I can say this based on four years working on a large multi-tenant service platform composed of several hundred microservices, held against a background of 24 years building software systems, including multi-million-line monoliths (good and bad).

If you're a small company, should you start with a microservices architecture? No. It is much harder to operate. Should you factor your monolith so it is easy to transition to microservices later? Yes. Your monolith will be of higher quality for doing so.

Change "micro-service" to "library" and you have a technology that scales equally well without introducing the additional failure modes and complexities of micro-services. That's how pretty much all open source software works. Open source software consists of thousands of libraries that people reuse for all kinds of purposes.

I'm not against smaller services... but I've seen people use them, "because" and break their data models into separate services where coordinating data then becomes weird to say the least.

I'm not against micro-services, I'm against making everything a microservice because one can.

You can, and you will. But the mental overhead in "rewrite this 500 line service in a way that doesn't suck" isn't that high. That's not true of a 700,000 line monolith.

Instead you have the overhead of "rewrite these 50 services to have an architecture that doesn't suck".

And that architecture is written down nowhere, it is implicit in the different individual services.

It's also an architecture that is now much more prone to failures, because while procedure calls essentially never fail, RPCs do. Or if they don't fail outright, have unpredictable latencies etc.

(I turned a microservices/SOA code-base into monolith back in 2003/2004. It worked wonders.)

Interestingly, RPCs failing is not really a problem at companies with heavy investment in microservice tooling. Everything is set up to retry transparently below the application layer. Obviously this costs in terms of infrastructure and latency but it's essentially transparent to the programmer.

It's still a problem, just not quite as big as one and often one that gets shunted off to a different team than the developers (eg. SRE or PMs). At Google one of the leading causes of cascading failures was RPC retries - service gets overloaded, RPCs start failing to return, client code automatically retries, service gets more overloaded, eventually everything grinds to a halt. Then you ameliorate that problem (eg. with timeouts or backpressure) and suddenly failing RPCs are visible to the application code again. You end up needing to make product decisions about what can fail, what can't, and what an acceptable level of latency is - for example, in search, if the Ad system doesn't return by the time the results do, the page just doesn't show ads. However, if a click on an Ad can't write to the logs, it blocks the redirect until it can because you can't just drop actions that you charged money for without ensuring the transaction goes through. If the RPC to either the cookie store or user database fails to go through, the page just won't show personalized results (and the rest of the search code needs to be prepared to fall back to not having that data as a result). If the search results themselves don't come back, the system retries until they do (and pages on-call SRE).

This can also introduce big problems with 95th-percentile latency, because the retries aren't free, they trade failure for slowness. In user-facing services this often isn't a problem, because the user eats the slowness and grumbles. But in services way down in the stack (eg. BigTable), it can be a big problem. High 95th-percentile latency can make services that previously weren't on the critical path suddenly part of the critical path; it can trigger timeouts in higher-level code; it can trigger retries in higher-level code; and it can cause large increases in load (with the possibility of further cascading failures) if those additional retries put some other service over its capacity limits.

TANSTAAFL. RPC failures still result in complexity, it's just that there are possible systems that can shunt that complexity into where it's less of a problem for the user. The only time you can outright ignore them is if you're a junior developer, though; anyone at senior/TL/architect level needs to think about them and be prepared.

> RPCs failing is not really a problem.

Hmm...

1. Software applications are written with little error-handling on networking errors. During a network outage, such applications may stall or infinitely wait for an answer packet, permanently consuming memory or other resources. When the failed network becomes available, those applications may also fail to retry any stalled operations or require a (manual) restart.

https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

Infinite retries aren't "not really a problem". If the server isn't there or can't be reached, it isn't there or can't be reached. This is not a problem software/infrastructure can paper over transparently. You can try your best to mitigate, but that's hard, and often makes things worse.

I remember a colleague trying out CouchDB. His takeaway was that all error-recovery attempts by distributed CouchDB servers made things worse. So you could use it as a semi-decent single-instance DB, but mercy on your soul should you be so brazen as to attempt to use the distribution features.

> heavy investment in microservice tooling.

And what percentage of microservices is that?

> costs in terms of infrastructure and latency

>> Or if they don't fail outright, have unpredictable latencies

Hmm...

Yes, if we assume literally every microservice is just as bad as one monolith, that's true. That hasn't been my experience. Often time, the monolith encourages bad "new features", while the microservices seem to be more of a mixed bag.

Given the choice, I'd rather re-write 50 microservices in a heartbeat.

Well given the choice, and with 35+ years of software experience trying both, I'd rather re-write a monolith (by implementing 50 libraries) in a heartbeat.

And a micro-service architecture tends toward spaghetti code as well because... "people always tend toward writing spaghetti code." The only difference is at what layer everything gets all tangled up.

It's a function of people and constraints.

I have worked on many monoliths that were straightforward to maintain. Working on some right now. Spaghetti code is written by unskilled developers. It's quite simple really.

I think you've got cause and effect backwards. People almost always end up writing spaghetti code. They create monoliths on the way. But the problem is the people, not the monoliths.

Or look at it this way: Even if monoliths are the problem, well, the people wrote the monoliths...

Microservices don't disable spaghetti. They simply give you a means to cut it into pieces. A spaghetti monolith is many thousands of times worse than a spaghetti microservice.

You are doing the same thing OP did: Fundamentally misunderstanding the purpose of programming. It's an interface for humans to communicate with machines in a way that makes sense to humans.

If monoliths always end up being unmaintainable pieces of garbage, then monoliths aren't really designed for humans or our tendencies. That means monoliths are the problem... they don't adapt to human nature.

Nah, spaghetti monolith is much more navigable than ravioli SOA mess.

1) You have tooling.

2) Probably also shared conventions and libraries.

3) Everything is easy to find and run on single dev machine.

And no, monoliths almost never end up that way as long as they're internally modular. Services are just modules with less sharing and more overhead.

> Nah, spaghetti monolith is much more navigable than ravioli SOA mess.

How many monolithic 1,000,000+ line code basis have you navigated.

1) That's true of both. 2) That can be true or false of both. 3) That's covered by tooling?

> And no, monoliths almost never end up that way as long as they're internally modular.

Well your caveat is literally the problem this post is discussing. They usually aren't.

I've been a professional programmer for over 30 years; I'm pretty sure I don't fundamentally misunderstand the purpose of programming. Thanks for assuming that I'm stupid or ignorant, though. (For the record, I agree with your definition of the purpose of programming.)

You don't have to prove to me that monoliths are bad. I get it. (You don't have to prove to me that spaghetti is bad, either.) But you seem to have missed my point.

Monoliths don't just happen. They didn't just wind up in your server room because the roof leaked during rainy season. They didn't get delivered by FedEx by mistake, and your people went ahead and signed for them. No, the monoliths are there because people wrote them.

Why did people write them? 1. Because they didn't know better, and just fell into it. 2. Because they thought that was the best way to architect something. 3. Because they didn't take the time and effort to make something more modular.

People cause the monoliths. To fix monoliths, you have to fix the people problem, or you're going to continue to get monoliths.

35+ years here. Agree with you. And will add that a team of people making a mess of a monolith will make an even bigger mess of micro-services.

There is this other amazing technology that also makes it possible to cut large applications into manageable pieces and scale to any size. Even across organizations. It has been around for a very long time and has been "tested in combat". I am of course talking about "libraries". The technology that has allow the largest applications in the world to scale. For the last 50+ years.