4 ms·

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh

> Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent? I always find this sentence to be a bit of a laugh. It's so commonly said (by either group of people with a dog in this fight) but seemingly so uncommonly thought of from the other group's perspective. People that prefer microservices say it's easier to change/rewrite code in a microservice because you have a clearly defined contract for how that service needs to operate and a much smaller codebase for the given service. 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. Who is right? I sure don't know. Probably monoliths for tenured employees that have studied the codebase under a microscope for the past few years already, and microservices for everyone else.

tklinglol 3y ago
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 :(
iterateoften 3y ago
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.
- starttoaster 3y ago
  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.
  - smaudet 3y ago
    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...
disintegore 3y ago
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.
protomolecule 3y ago
"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.
sanderjd 3y ago
> 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?".
- BHSPitMonkey 3y ago
  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.
  - sanderjd 3y ago
    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.
masterj 3y ago
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.

tklinglol 3y ago

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 :(

iterateoften 3y ago

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.

starttoaster 3y ago
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.
- smaudet 3y ago
  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...

disintegore 3y ago

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.

protomolecule 3y ago

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

sanderjd 3y ago

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

BHSPitMonkey 3y ago
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.
- sanderjd 3y ago
  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.

masterj 3y ago

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.