# [ $davids.sh ] · message #243
😢 Why does no one understand what "microservices" are... 😢
Sorry, but I'm losing my mind over the fact that for all 10 years of my career, I've heard the same nonsense a thousand times, and practically everyone describes "microservices" in such an ethereal way that you could start a religion around it... when in reality, it's extremely simple.
#microservice #monolith #distmon
@ [ $davids.sh ] · # 1468
. Monolith – shared codebase, multiple teams, shared resources, one application, internal communication
. Modular Monolith – shared codebase, multiple/one team, shared/separate resources, multiple applications, internal and external communication
. Microservices – separate codebase, one team, separate resources, multiple applications, external communication
. Application – a process (instance) running on a server, using some codebase to solve a set of business tasks. An application can have many instances.
. Team – a group of specialists who communicate regularly and develop the same applications.
. Codebase – short for "application codebase," meaning the code that describes the specific (unique) process for your application (synonyms – "business logic," "feature").
. Resources – infrastructure (DB, caches, fs, transport, etc.) reused between applications.
. Internal Communication – calling business logic within a single application by invoking a function from within the code.
. External Communication – calling business logic from another application using some form of transport (TCP, HTTP, MQ, 2IP, stdin, etc.).
. Monolith – multiple teams work on features within one codebase; to execute a feature, you can call a function from within the application itself, which might have been written by another team; at the same time, the entire codebase shares the same DB, cache, fs; it all runs as one application (but can be in multiple instances, for example, if cron jobs are separated).
. Modular Monolith – multiple or one team works on features within one codebase; to execute a feature, you can call a function from within the application or make a request to another application (for example, within the modular monolith); at the same time, you can share the same DB, cache, fs, or not; it all runs within multiple applications.
. Microservice – one team works on it; to execute a feature, you need to make a request to another microservice; its own DB, cache, fs; it all runs within multiple applications.
. Undoubtedly, there are other variations, but in 90% of cases, parts of a system can be classified this way.
. Your system can simultaneously consist of Microservices, Monoliths, and Modular Monoliths.
. The Modular Monolith is the most flexible option because it allows for the implementation of multiple applications that won't have to use inter-service communication (as you can simply call a function from within the code), and if necessary, you can also use inter-service requests.
(continued below)
@ [ $davids.sh ] · # 1469
. Each team creates its own modular monoliths
. Separate applications are not created "by eye" but only if (1) it needs to exist on a separate machine (e.g., in a specific geolocation), (2) it is stateful (holds sockets), (3) it implements a separate set of features (API for partners), (4) it requires dedicated hardware resources (CPU, GPU, RAM, network), (5) it uses code that interferes with the execution of another codebase (CPU-intensive)
. If, within the same team, some code needs to be extracted separately (most often due to security concerns), it is then turned into a microservice.
. If there are stateful applications or microservices, then we use inter-service communication; in other cases, we call features from within the application.
. That's all.
. "Monoliths are old news, let's go microservices" OR "We don't know how to organize a codebase so that multiple teams can work on it, let's go microservices"
. They divide the entire system into a bunch of microservices purely based on "I just see it that way"
. They struggle with inter-service communication, transactions, testing, and debugging
. New requirements come in that don't fit the current division
. They get caught in inter-service deadlocks
. They struggle with communication, transactions, testing, and debugging 10 times more
. (If they're lucky) They start merging microservices into modular monoliths
. (But most likely) They quit and leave this legacy for future developers who think: "Oh, microservices here! So that's how it should be. Awesome."
. The cycle of microservices and struggles begins anew
P.S.
I will show an example of each in a future post with a description of the Go boilerplate
@ [ $davids.sh ] · # 1471
And to everyone who has read this: I really dislike the name "distributed monolith" because, well... it's not "distributed"... it's more about the fact that we can run the same codebase in multiple different applications and not use inter-service communication, meaning it's more "partitioned," but that doesn't sound good either.
In short, I need your ideas, or maybe you've heard a different name.
@ Vassiliy ITK Kuzenkov · # 1472
There are also modular monoliths. I like how Polylith is structured https://polylith.gitbook.io/polylith/introduction/polylith-in-a-nutshell
@ [ $davids.sh ] · # 1473
Hmm, well "modular" sounds better, doesn't it?
(The funniest thing is, I have a second book that I'll be announcing soon, and I just looked and I'm calling them "modular monoliths" there too))
@ Nikita · # 1474
What's the 2nd book?
@ [ $davids.sh ] · # 1475
About best practices in web development and programming in general
I've already started writing and posted about it, which led to OOP, and now I've rewritten it from scratch and want to create a full-fledged presentation.
Don't worry, I haven't forgotten about OOP; we'll promote it too, and I'll definitely make your contribution public. I just wrote that one too quickly and am currently holding onto it.
@ Nikita · # 1476
It would also be great if someone could look at my code, otherwise I might have written complete nonsense 🌚🌚🌚
@ [ $davids.sh ] · # 1477
Don't worry, I wrote some crazy stuff there too, a lot of people saw it, and no one has noticed yet))
@ Nikita · # 1478
I actually noticed there at the end about a dog or something, and it's doing something wild there 🌚🌚🌚
@ Ivan ITK 🚫 · # 1488
I disagree a bit, but I'll re-read it carefully later and add more.
If I understood correctly, you mixed SOA and the concept of microservices into one pile, and then decided to separate them differently.
@ Ivan ITK 🚫 · # 1491
It seems like you've had a very bad experience with microservices, and there's a clear bias towards monoliths here. A simple example: if you create 100,500 monoliths deployed in a service mesh, you'll have what you described as microservices. This is because microservices are about an approach to organizing infrastructure, not code.
@ [ $davids.sh ] · # 1493
"and here there's clear bias towards monoliths." – rather, it's about modular monoliths being a more sensible initial solution for most projects + about reducing inter-service communication (as one of the reasons for excessive system complexity)
Because I very often encounter projects where people have broken all the code into microservices almost according to the data model and then suffer
"100500 monoliths" – it's very important to consider the system's scale; if it's so large that there can be conditional "100500" criteria for division, my article's criteria still work, but much more complex principles also start to apply there. I'm not considering this because it depends too much on the specific business context
"microservices are about an approach to organizing infrastructure, not code" – I still think that infrastructure is a consequence rather than a cause
But yes, we should discuss this in more detail to understand each other
@ [ $davids.sh ] · # 1496
For example: I was developing a very large system (GBs of data per day that needed to be processed in real-time), and we only needed 20 microservices to operate a bunch of departments and tons of business logic (an AI behavior management system).
And this is how the division of responsibility was used, but only because the responsibilities were very large and non-overlapping (for example, a microservice responsible for processing operator actions and a microservice responsible for calculating the financial model of a session) + pure Event Sourcing was used, which, in case of needing to get data from a third-party service, which happened quite often, allowed us to simply get the Event stream and recalculate them according to the service's interests.
@ Ivan ITK 🚫 · # 1497
I haven't seen more than 100 microservices on any average project. Usually, the number is around 50 or less. These entities are more than enough to build a lot of business logic. Therefore, there are no heaps of microservices unless you're some kind of Netflix, where the engineers aren't exactly role models either; they have plenty of mistakes in their blog posts.
And a funny point, I have several code processes on IoT, and they communicate via a data bus to perform seamless updates without resetting critical sockets to the hardware. Are these microservices already, or not yet? 😁
Regarding complexity in microservices, it's equivalent to any architectural pattern; you need to understand and have experience with what you're doing.
If you're building microservices just to separate responsibilities in code organization, then it's at least a strange architectural choice that affects many future engineering decisions. Because by separating code responsibilities, you separate infrastructure responsibilities with distributed tracing, transactions, locking, etc.
@ Ivan ITK 🚫 · # 1498
So, what's the problem, why was it bad for you?
@ [ $davids.sh ] · # 1501
It wasn't bad, it was wonderful)
But it worked because they had little overlap and often fell into the points on my list.
Yes, you could say that "little overlap" means "competently dividing responsibility," I'll think about how this could be reflected in the article.
@ [ $davids.sh ] · # 1508
Added the item "independence". It doesn't fully cover our discussion, but in conjunction with other items, it should answer the question.
