In a large number of articles, sources microservices, among other things, are presented as a way to build a scalable solution. Let's look at some examples of why this is not the case. And we will also try to contribute to the age-old question:
Which is better: monolith or microservice?
Let's look at an example.
Let's say we have a microservice (lambda) A
that performs authorization requests "does the user have the right to perform an operation?"
Since such a microservice cannot exist in isolation, another microservice (lambda) exists in tandem with it B
, which stores a list of user-rights correspondences in the storage.
An approximate diagram of microservices (lambdas) is shown in the figure:
Both lambdas / microservices together form a classic Entity microservice: which encapsulates the work with the "users" entity.
As a result of changes in user data (registration of new users, restrictions on existing ones, etc.), the microservice B
"monitors" the relevance of data in the storage, which the microservice uses A
to fulfill authorization requests.
Simple diagram. It is simply arranged, it works reliably.
, , , . "" ?
CPU
A
io-read/select
CPU
B
io-write
CPU . , :
, A
B
?
A
. RO- :
A
, .
: , B
master- , (io-write)?
. , . multi-master:
X
, , - ( - Y
), .
:
. .
, :
CPU
IO
, . , .
. - ( ).
.
:
, , . . , ( ) . , .
? , , ? .
, , , - .
: vs
/FaaS, :
, MVP . - MVP . , , .
- MVP. , , .
? : , :
, ( , )
( )
- " , , ".
And, based on what has been written, the energy of the eternal dispute "monolith vs microservice" at the project launch stage should be directed towards the development of a data warehouse with an initial focus on scaling. And in the process of development, the monolith and microservice will have a very similar architecture. So similar that it will be difficult to distinguish them from each other.