231–240 of 356 posts
Uber is really not a good example. Many Uber engineers created services for the sake for claiming their territories or for sheer stupidity. On the other hand, managing services in Netflix was a non-event, and people really exercised their judgement carefully when it came to creating a new service. Yeah, I'm saying Uber's problem was cultural and organizational, not technical.
Earlier quoted context omitted.
Could you give some non trivial examples of architectures or techniques in software engineering that work regardless of the context?
good naming Maybe that is not "architecture" or "technique" but is is definitely not trivial and is important in almost any context -- but also probably not what you were going for.
ed: or rather what constitutes a good name is
I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…
I agree completely. The current FAA outage is a good example of this. What if the system responsible for NOTAMs was the same system responsible for sending system outage messages. They weren’t so that status could be communicated while mitigation was done on a system with unrelated concerns. At the same time, a few person startup should probably focus on what allows them to deliver the fastest. I’ve seen that work wi…
We had a disk array go sideways, which is when we learned that some dumb motherfucker had put our wiki on the same SAN with production traffic. You know, the wiki where you keep all your run books for solving production issues? Everyone was furious and that team lost some prestige that day. How dumb do you have to be?
Earlier quoted context omitted.
> No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. This is…
Funny, I was thinking of linking to that page myself in support and decided against it. I particularly was thinking of: "What does this muddy code look like to the programmers in the trenches who must confront it? Data structures may be haphazardly constructed, or even next to non-existent. Everything talks to everything else. Every shred of important state data may be global. There are those who might construe this…
Oh sure they can, just call it “the DB”. Shared state between services/components is the most debilitating mistake I’ve had to deal with over the years. It doesn’t matter if it’s a monolithic, shared memory desktop app or a highly distributed architecture with central storage.
Earlier quoted context omitted.
Modules are for organising your code, services are for organising processes on the OS, and micro-services are for organising teams of developers
You can organize teams of developers around services.
Earlier quoted context omitted.
You could say this about any criticism of mainstream practice. This is not a rebuttal and contains no new information. Actually, I lied - this post is actually a strawman: it contains the information that you actually didn’t understand the point of the article. He is referring to people who have deployed microservices when they needed modules, not people who deployed microservices when they needed microservices.
TBH, his definition of "module" brings it awfully close to microservice.
This is not the first thread on the topic.
And considering the number of people actively defending microservices, like it's debates about iPhone vs Android over a decade ago - I'm going to say that too many people can't rationally look at this at this point. Too many emotions flying around.
I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…
I might think that, depending on the context.
Are you a multinational with thousands of monkeys at thousands of typewriters? Of course you shouldn't have everything in one system!
Are you a five person startup, out of which only three write code? Knowing nothing else, I'd suggest everything in one system.
No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…
"The entire point of the big ball of mud is that there are no meaningful divisions in the code.... Everything uses everything willy-nilly....not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed"
...then OK, perhaps the developers who caused the state you describe above would not cause the exact same problems with microservices -- but will they really move fast any not cause a mess given ANY kind of environment?
The state you describe is not normal of monoliths by any stretch.
It may be normal of old legacy systems with 5 generations of programmers on it. Also I believe microservices will have other kind of problems, but still deep problems, after 5 generations of programmers.
If preventing people from running in the completely wrong direction of the goal is your main concern -- why even be in the race at that point. Find new people to work with.
If you personally had success rewriting a Ball of Mud into microservices, consider if perhaps the "rewrite" is the important word (as well as quality of developers involved), not whetyer the refactor was to a new monolith or new microservices.
Microservices with boundaries drawn wrong can cause you to need to spend 20 programmers do the job of 1 programmer. Perhaps the mud looks different from a Big Ball, but it is still mud.
Earlier quoted context omitted.
This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...
And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales…
Microservice advocates championed this fallacy, implemented it... but now, when it's time for critical retrospective - it's not their failure.