So how does that all help me, who is seeing "microservices AWSGCPAzure EDA" job ads exclusively, not a single regular job ad anymore. It's all hypeshit shit shit.
Monoliths are not dinosaurs
161–170 of 243 posts
Re: Monoliths are not dinosaurs
#162Earlier quoted context omitted.
“we have 100 people so require 20 microservices”. More like 3 people requiring 13 microservices
I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.
Micro service hell happens with new apps that are designed from scratch.
Re: Monoliths are not dinosaurs
#163Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
> Complexity can neither be created nor destroyed, only moved somewhere else. I have to say that this short quote is not the whole story; for example it's ridiculously common for artificial complexity to be introduced into a system, like using microservices on a system that gets 1k users a day. In which case, it is sometimes possible to remove complexity, because you are removing the artificial complexity that was ad…
I think that quote makes sense if you assume that the complexity is required. Over-engineering is a whole different topic.
The problem is that the shops that move from monoliths to distributed systems are under the impression that all of their problems are now magically over "because microservices".
Re: Monoliths are not dinosaurs
#164Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn'…
This is a very nice academic theory, but in real life you get half-assed, half-implemented hairballs that suck out your will to live if you have to untangle that.
Re: Monoliths are not dinosaurs
#165Earlier quoted context omitted.
Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."
That just makes it a tautology. It basically says “essential complexity exists”.
Maybe but it still useful to know that essential complexity exists and to identify it in your project.
Re: Monoliths are not dinosaurs
#166Earlier quoted context omitted.
Micro-services are currently on trend so hard to argue with unless you are a founder. Maybe the best thing to do for the industry in general is go absolutely nuts with microservices. Factor projects so every method is a separate service / lambda. If anyone complains, use the single responsibility principal to snuff out all opposition. Once we've explored this to its logical conclusion the pendulum will swing back to…
I got tired of arguing against microservices just like I got tired of arguing against SPAs and multi-repos. And at least with one of them, the pendulum has already started swinging back. The cool-kids (aka "javascript hipster devs") have re-discovered the concept of a monorepo and are pushing for it hard, making it seem like some sort of new concept with fancy tooling. It'd be funny if it wasn't so caricatured and a…
>> re-discovered the concept of a monorepo
Monorepo and monolith are somewhat orthogonal. The desire to use a monorepo likely stems from wanting to emulate Google.
Re: Monoliths are not dinosaurs
#167You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Sure you could, but it would take a much longer time and you'd miss lots of functionality. How long would it take you to build user registration / verification / password recovery / 2fa / sso / profile editing / spam registration prevention / etc. ? How long would it take instead to include some Laravel module which does all of that? If you're building a service with some purpose, do you really want to spend days wri…
How many hours spent on battling Laravel to do what you want? How many hours spent on upgrading Laravel versions?
Framework solves a general problem, but we try to solve a specific problem, thus it will always be a mismatch, frameworks usually solves that with a combination of magic and opaque abstraction layers.
Frameworks works best for short running projects, long running projects tend to outgrow the framework.
Prefer libraries over frameworks.
Re: Monoliths are not dinosaurs
#168I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…
Could you elaborate on what you mean by "natural fault lines"? The rest of that paragraph seems to refer to performance -- is that the criterion? Do the natural fault lines shift if you manage to optimise the performance of a component, so that it starts scaling at the same rates as its neighbours?
It is hard to say without understanding the system. In my own case it is auth, output (1D,2D,3D), logging and sim but that is meaningless outside of my application's context.
Re: Monoliths are not dinosaurs
#169Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn'…
We've been here before with object oriented programming which was supposed to introduce a world of reusable, composable objects, even connected by CORBA if you wanted to run them remotely.
Re: Monoliths are not dinosaurs
#170Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
We will be going back. After the last binge, torching through piles of cash to do resume-driven development, companies are now looking to be lean. You can't really survive if you are doing microservices and trying to actually build something with a team cut by 75%.
I am already seeing this newly discovered love of simple, fast monoliths and the developer ergonomics they offer. What is old is new again - we are at the beginning of this cycle. The older generation learned that "complexity kills", the new generation is beginning to get it as well.