RSWW 02 2023

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 19

Monoliths vs others

RSWW_02

dr inż. Mariusz Matuszek, 2023


Monolithic application
Designing architecture of the application


Simple applications, especially prototypes, are most often created in a
single project with the source code.

For applications where you need to separate the responsibilities /
expertise of application development professionals, you may need to
list layers such as views, models, and controllers.

This approach organizes the work of programmers and the system
code, but does not consider the efficiency or scalability of the system.
A Monolith
Monolithic application
Open questions


You should consider what such an application would look like if its
code would be very large.

What will the introduction of the new developer look like?

What will the introduction of the new functionality look like?

Is it possible for a single person to understand all the intricacies of
the written system for many years?
Monolithic application
Open questions

• Will there be more work related to introducing new functionalities or


current problems (so-called fire fighting)?
• How often will it be possible to implement subsequent versions at
the customer's site?
• How to ensure the scalability of such a system (granularity)?
• Will it be possible to freely select the technology in which to make
the system? What happens to information technology after 5-10
years?
Monolithic application
Basic improvements
Monolithic application
Basic improvements

• Does introducing layers solve all the problems?


• Single application (multiple responsibilities, different classes of
responsibility)
• Limited replication resolution = Limited scalability
• A crash generated in any fragment propagates to the rest of the
application
• The entire application works in the public layer
Monolithic application
Basic improvements

• Division due to implementation differences (views, controllers,


models),
• Division according to the areas of operation (frontend, backend),
• Division into many functional layers (! = Microservice)
How to create a flexible and efficient
system
3D perspective

Considering the information system in the space of three-
dimensional possibilities (3V - The Art of Scalability; M. Abbott, M.
Fisher):

OX axis: horizontal scaling of the system or its part;

OY axis: decomposition of the system into functional components
(the so-called system decomposition);

OZ axis: request partitioning;
How to create a flexible and efficient
system
Smart selecting approach

• We define the architecture of the system and its components in


accordance with the set requirements.
• This means that we do not use one, newest approach every time, eg
TypeScript or .NET Core 5.
• We select technology, architecture and communication methods to
meet the requirements and the encountered or expected difficulties.
Microservices
General information
• It assumes that the created system will consist of independent
modules (separate applications) for which communication methods
have been defined.
• In this approach, components have a strictly defined responsibility
and method of communication with other components.
• This leads to a reduction in the amount of code that is handled by the
team.
• Despite the size of the system, it is possible to continuously provide
new functionalities.
• It is possible to use the agile method and ensure continuous
deployments even for big computer systems.
Microservices
Dark side

• At the same time, the increase in the complexity of the system


architecture requires the use of additional tools and consideration of
problems that did not exist in monolithic environments.
• A distributed system requires a communication mechanism between
components.
• Requires an intermediary system or libraries that enable reliable
communication.
• You should take into account problems with data synchronization,
operating in an asynchronous environment with the assumption that
some components may not be available at the time of processing the
client's request.
Microservices
Additional conditions

• You should also particularly consider the method of deploying the


system to the servers and how to monitor the deployed components.
• When designing the method of implementation and maintenance of
the system, problems with coordination should be taken into
account.
• Services, i.e. system components, are to be easy to maintain and
develop.
• A microservice does not have to be micro, its size is a secondary
element rather than a determinant for architects.
The main disadvantage of monolithic
systems
Open question

• What kind of system do most applications use, but are very difficult
to scale?
The main disadvantage of monolithic
systems
• It is a database system that supports relational databases with
transactional behavior.
• IT systems mostly depend on a single database system instance.
• Thus, most of the operations are ultimately processed by the central
database query system.
What does the microservice style
propose?

In the case of microservice architectures, the use of separate
databases for individual components is rather considered.

Next, it is considered whether each component requires relational
data and transactional capability.

Note the potential error propagation in one of the system
components. What happens in the event of a possible memory leak?
The main disadvantages of the
microservice style

• There is no clear strategy for dividing the application into services. It


is very difficult to correctly identify services in the system.
• It is easy to make a mistake and create a system in a microservice
architecture in which the services correspond to the individual
modules of the monolithic system (which means you have problems
both generated by monolithic and microservice architectures).
• The testing and implementation process requires additional tools and
is usually much more difficult than in the case of monolithic systems.
The main disadvantages of the
microservice style

• The complexity of the entire system will be much greater and it will
be impossible to detect interface incompatibilities at the compilation
stage.
• Again, you need to use additional tools to include interface diagrams
during compilation.
• However, then you have to solve the problem of their propagation
between teams.
The End

You might also like