My first gig out of school was a .net monolith with ~14 million lines of code; it's the best dev environment I've ever experienced, even as a newcomer who didn't have a mental map of the system. All the code was right there, all I had to do was embrace "go to definition" to find the answers to like 95% of my questions. I spend the majority of my time debugging distrubuted issues across microservices these days; I miss the simplicity of my monolith years :(

Not so much a ball of yarn but more like the cabling coming out of a network cabinet. It can be bad and a big mess if you let it, but most professionals can organize things in such a way that maintenance isn’t that hard.

Well, the point I was making was that the same can easily be true of microservice architectures. If you have people that don't know what they're doing architecting your microservices, you'll have a difficult time maintaining them without clear and strict service contracts.

It's not clear to me that we're ever comparing apples to apples in these discussions. It would seem to me that everyone arguing left a job where they were doing X architecture the wrong way and now they only advocate for Y architecture online and in future shops.

Functionally its the same stuff.

Both have boxes of stuff and the stuff talks to other stuff.

Logistically its a bit easier to scale the one where the boxes are married to closer to the hardware abstraction (microservices on instances) versus the one where boxes are married to the software abstraction (threads with memory), for the same reason one (monolith) is a lot faster (dev/process/latency) (at small scales) than the other (microservice).

You can scale both, really its mostly about fights about the tooling, process, and where your sec-ops decided to screw you over the most (did they lock down your environments or did they make it impossible to debug ports/get logs).

Practically, AWS is expensive, and they're bloated. Cluster environments that let you merge 1000 computers into 1 big supercomputer and have 1 million cores/terabytes of ram, come with different technical challenges that not as many people know how to overcome, or expensive hardware bills.

So I'd say if someone tells you it "has to be" one or the other they are blowing smoke. Micro-services were recently the hip-new-thing so it makes sense some really really bad nonsense has been written in them so people are rediscovering monoliths (and realizing the microservice people were snake-oil salesmen). In 10 years we'll realize again that some monoliths are really badly written and some people without a clue will re-write them as microservices...

I've noticed that a lot of industry practices demonstrate their value in unexpected ways. Code tests, for instance, train you to think of every piece of code you write as having at minimum two integrations, and that makes developers who write unit tests better at separating concerns. Even if they were to stop writing tests altogether, they would still go on to write better code.

Microservices are a bit like that. They make it extremely difficult to insert cross cutting concerns into a code base. Conditioning yourself to think of how to work within these boundaries means you are going to write monolithic applications that are far easier to understand and maintain.

"because you have a clearly defined contract for how that service needs to operate"

But if you need to change the contract the changes span the service and all of its clients.

> you just need to know each juncture where that strand weaves into other strands.

No I don't, that's what computers are for. It's why static analysis is good. Instead of knowing what calls what, you say, "yo, static analysis tool, what calls this?".

The comment you quoted is talking about the non-monolithic situations where static analysis tools cannot help you, e.g. when the callers are external and difficult to trace.

I don't think so? The full quote that I pulled out a piece of was:

> The monolith crowd claims it's easier to change/rewrite code in a monolith because it's all one big pile of yarn and if you want to change out one strand of it, you just need to know each juncture where that strand weaves into other strands.

I'm saying, in the monolith situation, with proper static analysis tooling - which even languages like python and ruby have nowadays - you don't "need to know" how all the strands weave into the other strands, you rely on the tooling to know for you.

And in my experience, static analysis tooling for navigating across service boundaries is, at the very least, far less mature, if not just entirely non-existent.

If an organization can't figure out how to factor out clearly-defined contracts within a single codebase and maintain that over time, adding a network hop and multiple codebases into that will not make it any easier.