Choosing the software architecture consists in making fundamental structural choices that are difficult and expensive to change once implemented. Software architecture consists of the fundamental structures of a system and the methodology for creating these structures and systems.
We can essentially distinguish between three software architectural paradigms.
In a layered architecture, the structural design of the system is modeled according to the responsibilities of the fundamental parts of almost all applications that manage data.
These four layers are quite simple to connect, test and put into production. The limit of this architecture is constituted by performance, as the constraint due to the four layers makes the system indivisible and not very suitable for bearing large workloads.
Unlike the previous architecture, in the event architecture there is an entry point in the system that acts as the director of data traffic by collecting the incoming information and mapping it into an event.
The event constitutes a representation of the data, the description of something that happens in the system which is subsequently transmitted through specific information channels.
Applications consist of small components that receive events from these channels by intercepting the data according to their responsibility and subsequently re-transmitting it into the response channel.
This architecture allows you to achieve high performance on a large scale, but testing is very complex because, in order to replicate a situation, it may be necessary to reconstruct large quantities of events. Deploying the event handler can also be very complicated, as all services depend on it.
The microservice architecture sees a galaxy of independent applications for development and management that communicate with each other through protocols and languages such as http³and gRPC⁴. The specific protocol of integration between the applications is established before starting the communication.
This architecture allows you to create multiple entry points to the system and different interaction topologies without the constraint of a single central node. Every single service performs a specific functionality that can be atomic at will. Each microservice defines its own communication rules with the outside world and implements its own deployment cycle.
The advantages of decomposing an application into several smaller services are numerous:
To date, this is the architectural approach deemed most suitable for the cloud and containerization as described in my article “DevOps: From virtual machines to containers”⁵.
Disadvantage of this architecture are however the performance limits imposed by the use of the network in use and the protocol management overhead which can be comparable if not greater than the size of the data itself.