Which architecture for our software?

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.

Layered architecture

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.

• Business logic is contained in the sections of code comprising the algorithms essential to solving problems in the face of simple inputs and outputs.
• The presentation layer takes care of representing the user in a comprehensible form (web interfaces, shell¹, API², hardware devices).
• The persistence layer manages the flow of data between one database and another.
• Fourth and final layer is made up of databases.

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.

Event architecture

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.

Microservice architecture

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:

• Modularity: this makes the application easier to understand, develop and test;
• Scalability: since microservices are implemented and distributed independently of each other, i.e. executed within independent processes, they can be monitored and scaled independently;
• Integration of heterogeneous and legacy systems: microservices are considered a means of modernizing existing monolithic legacy software applications through an incremental approach;
• Distributed development: parallels the development allowing small autonomous teams to develop, distribute and scale their respective services independently. Microservice-based architectures facilitate continuous integration, delivery and implementation.

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.

¹ https://en.wikipedia.org/wiki/Shell_(computing) 
² https://en.wikipedia.org/wiki/Application_programming_interface
³ https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol 
⁴ https://en.wikipedia.org/wiki/GRPC
⁵ https://www.digital4pro.com/en/2020/07/14/devops-from-virtual-machines-to-containers/

Bibliografy:

• DevOps Guida per integrare Development e Operations e produrre software di qualità, Fabio Mora
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Robert C. Martin