Mcroservices at the very least require very high investment into proper CI/CD and observability. If you are not willing to allocate resources to get those right things are going to go badly.
It's not microservice or monolith; it's cognitive load
111–120 of 195 posts
Re: It's not microservice or monolith; it's cognitive load
#112Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordinat…
I often have had the feeling that people tend to try to solve code-organisation issues with microservices. Sure you can code a tangled mess in a monolith, but adding TCP connections and Kubernetes to the problems you have probably won't make things better. Instead, rewriting some code to use whatever applicable design pattern probably will make it better.
An analogy that comes to mind is looking for a new house. Most people can't see through the current decoration and furniture of a house and imagine themselves living there in their own style. So real estate agents try to get rid of as many personal items and clutter.
It seems to me that many developers can't imagine how to refactor an existing messy monolith into a tidy monolith, but they can imagine an empty repository.
Re: It's not microservice or monolith; it's cognitive load
#113Earlier quoted context omitted.
Perhaps it is easier to understand when you remember that service is not a technical term? People provide service. In the macro economy, service comes from other companies. If you integrate an LLM into your application, you may use the services of OpenAI. If you integrate payment processing into your application, you may use the services of Stripe. Microservices are just like services, except offered within a micro e…
With no or minimal communication how is it possible to build anything new? In real world if you need to build something new and it requires 10 different companies to do that, it would be virtually impossible.
The same way the economy has always built something new. We have thousands of years of experience in doing that.
You don’t try to build something new with 10,000 developers, if that’s where you have become confused.
Re: It's not microservice or monolith; it's cognitive load
#114Earlier quoted context omitted.
> Can you elaborate on this? What is the primary benefit of running 100-300 components vs a monolith specifically with a 12 person team? > More directly, what's wrong with a monolith at the dozen person team size? Great question. It's honestly a hard question to answer because the real answer requires tacit knowledge, but I'll try anyway because you asked. I'll link a couple articles of longer form writing that may h…
I don't intend this to be mean, but in some parts this reads as satire.
Yes, thought so as well. "Instead of a single search and replace we get to a flow state and create an automated script to do it for all our repositories. Due to flow state productivity grains are immense. Of course we will manually check 400 times if the script did correct work, but we enjoy that each time."
Re: It's not microservice or monolith; it's cognitive load
#115Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordinat…
A lot of factors come together whenever the term Microservie or Monolith arises: - Monolith has implicitly replaced the word "Legacy" system - Microservices were (/are still) the cool thing to do in a conference driven industry. They were championed by big tech because they desire granular and flexible deployment systems (whereas in smaller products your code just needs to run and everything else is just overhead). H…
> Monolith has implicitly replaced the word "Legacy" system
Indeed, one couldn't possibly recommend a Monolith in 2023/4. A macroservice on the other hand ...
Right. I'm off to polish my conference talk notes
Re: It's not microservice or monolith; it's cognitive load
#116IMO: write everything in Rust. If a dependency is not in Rust, rewrite in Rust.
Carmack has a rant about Meta’s stack for the Quest being in different languages and being a pain. Having worked in heavily-split stacks I don’t want to run into these again.
Re: It's not microservice or monolith; it's cognitive load
#117I’m sure that in every case, one or the other will be better for business for technical reasons.
Re: It's not microservice or monolith; it's cognitive load
#118I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…
I think technical debt comes from not cleaning up/refactoring once you’re done. Also, doing this work requires to have a good understanding of the codebase as well as its style/cohesion.
I’m wondering if ML will get good enough to produce PR reviews that comment on style and refactoring opportunities to match the codebase’s spirit.
Re: It's not microservice or monolith; it's cognitive load
#119I totally agree... the real question is how to reduce cognitive load. Try to get a system that can fit in your head, although I have totally failed to achieve this myself. But it is a goal!
Create self-contained frameworks and libraries by extracting code that starts becoming heavy and could be useful by its own. These are the useful abstractions.
Constantly seek to specify, document, and simplify the protocols you implement. The clearer the ideas, the cleaner the implementation.
Strive to use a single programming language.
Organize your code like you would organize a city or a book.
Re: It's not microservice or monolith; it's cognitive load
#120It’s hard to enforce api contracts between components of a monolith. And when performance tanks, it’s hard to pin the root cause to a component. Both of these could probably be fixed by tooling. Could be z as fun research project or maybe a company.
That’s why Meta has thrift and Google has grpc.