That is a very good point. In fact, good monolithic code layout is a precursor for microservices, as only once you have identified your boundaries and isolated your concerns can you begin splitting them out into their own services.
I will say this however - microservices might not solve the "spaghetti code problem", but it definitely helps isolate it. When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.
But you're probably not the person I should telling this, developers aren't usually in charge of that.
lijok wrote:
When we get consultants in to speedboat a new system, we give them their own separate service. Saves a lot of time and de-risks our beautiful monolith.
And on pricing specifically, both shitty and good consultancies charge about the same. The ones that charge well below market are an outlier that will guarantee bad product - those are to be avoided.
If hacker news is correct, microservices is the #1 worst idea of software engineering.
And whoever promotes them is either a kid with no experience or a complete moron.
If you have a problem with bad consultants then solve that. Trying to solve it by jumping into microservices you will just have bad consultants writing your microservices equally badly, or even worse.
One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.
If you think "why not restrict config actions" etc, it's because the dev can go there and tweak those actions too. And each step added means less velocity of development. It's a game of cat and mouse. With isolation, you can limit the blast radius and loss of revenue.
[...]
> One intern was told to deploy the app and I guess he made a mistake and updated k8 configs which deleted all the pods. Tell me how code reviews are supposed to catch it.
These sound contradictory to me. Part of having automated CI/CD, is not having to manually deal with k8s to do a regular deploy.
So you don’t have a staging environment to check config changes before deploying to prod? Or you don't put k8s manifests (or helm charts or whatever)in source control and just update prod through CLI? And you let interns do it alone?
Your problem isn't interns, it's a terrible deployment processs with weak controls. Even senior engineers are going to break prod regularly in conditions like that.
Our team spend most of the time designing fucked up messes that run over poorly designed APIs, slowly, that impact customers. If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues.
There are companies that are very successful and have split their service architecture into domain entities, called microservices.
Are they successful because or despite this decision?
Is both true in some sense?
A more natural way to split up a server architecture is to use computational boundaries. These are found by thinking of how data is processed and flows through the system as opposed to separation of high level domain concerns.
But this requires a computational design and not a domain/feature centric one.
The biggest problem with the whole IT industry is seeing outliers promoted as the successful path and people taking on faith arguments for technical decisions instead of rational decision making processes.
If your organisation doesn't look like that, you can only fail at microservices. Either the company restructures around the code, or the code looks like the company. Trying to make pasta from mash potatoes is doomed to fail.
Plus it's easier to run a hundred monoliths than it is to run 100 services. This is on the basis that running 100 instances of something the same with no inherent complexity in each instance is much easier to automate, build and manage than 100 things that are different and have to talk to each other.
Of all the reasons microservices are bad this isn't it. Your first point can be handled mostly automatically with half decent SRE tooling. Lock files on any modern language (including Python via poetry) fix dependency weirdness. Contract violations are a problem with your developers not the style of programming. As for performance I've been on both sides and being able to independently scale microservices via kubernetes is a god send. With proper tooling microservices work great.
The real problem with microservices is what you mentioned before that IMO. Complexity for complexity's sake. Some things are better as monoliths and some things are better as microservices. It's the same problem you see with normalization vs denormalization. Microservices are unambiguously faster in almost all cases. "Do one thing" means that one thing can be optimized to death, in isolation, without fear of interrupting other services. It also means team structures are easier to manage. Microservices don't mean pull in the entire universe of RESTful libraries and use exactly one feature for 1 or 2 endpoints.
But this introduces another problem:
A second managerial problem is that microservices are often used in scrappy startups with < 200 engineers. On any complicated platform this means one engineer might need to know how 10 services work. That's not feasible. You need to split it so a team owns a couple services and "does one thing right" (those services) and nothing else. It's the overapplication of microservices to every problem that is the source of most woes.
Startups will religiously apply microservices. The thought, of course, being that they can hire/fire faster and an outsourced engineer can probably pick up the necessary work quicker. Of course, this never happens, because instead of 10 microservices you have 300 and no one even knows where half of them are. 99% of the time it's not the pattern that is the problem. It's cargo culting. Just like everything else in the industry (looking at you electron, leetcode, functional programming, agile, etc).
It has it's purpose. It's almost universally over-applied owing to the cargo cult and holier-than-thou attitude of a lot of functional programmers. I see it happen in Python where comprehensions are often replaced with maps. While it is nice, the comprehension is more idiomatic and far more widely understood.
I have gone through the migration of monoliths to microservices (yes, at scale with multiple teams and requirements to scale individual components etc.) and it solved a lot of problems.
The benefits outweigh the costs in my opinion (and drastically so).
When people say "you can write well separated components in a monolith..." I can only say: of course you could, but you are not going to (and certainly not everybody at your giant ass company is going to).
I'm going to assume your monolith didn't require splitting things off for scaling purposes, and that a single team was working on it, otherwise, as I said I don't see a problem with services.
Let's also assume that you are not some manager that lead the transition but actually someone working day to day on the code, so you are talking from day to day experience rather than some made up fantasy. And let's assume that your team was able to figure out the microservices boundaries correctly for the current feature set that you support. Fine, now everything has been cleaned up and things are so much better.
Now, do you think you got to that point in your monolith because people that contributed to it are stupid? No, most of the time things start off clean (like your microservices architecture is now). But as time passes, and new requirements come in, the way you split things up in the beginning doesn't work well anymore. And you have a choice: refactor now or do some hack and push the mud ball down the line.
If your org wasn't able to keep a simple monolith clean with changing requirements, what makes you think that, now that the complexity of changing boundaries is 10x, things are going to be better in the future?
seem very confusing to grug"
Fundamentally, don't make life hard for yourself, or others.
The wisdom only applies to the places where it applies, and there is no wisdom there on telling where those places are.
Well, except for the problem of too much grug.
The best engineer (and not only, see that famous quote by Kurt von Hammerstein-Equord) often is the lazy one. It was a known notion that somehow disappeared around the turn of the millennium.
We're still around. We're just so far up the hierarchy now that the wisdom can't be pushed down easily.
Who's hiring grugs, the lazy programmers that try to do the most efficient thing in the least amount of work? I'm not smart enough to set up a whole georeplicated k8s cluster for your blog. I'll use Apache, maybe put Varnish if you get on the frontpage of HN, ok?
(Work smart, not hard. DevOps today is the exact opposite of that)
In my head MS works well for - Teams with different approaches. - Different tech stacks
I cannot think of another good reason in which MSs would be a better solution than a good monolith (and communication).
No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every time we get a new split.
That's how you use software scalability and create a simple, predictable ops environment.
(Well, ok, I'm having a hard time solving the first one with more code, but did hear this claim applied to it more than once, so I'm keeping it general.)
There is a huge amount of people that sees nothing wrong with my rationale up there. I don't get it either.
Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boilerplate and additional failure conditions.
If you think that microservices solve the "spaghetti code problem", well, good luck to you, you'll need it.