Dal monolite ai microservizi
Alberto ha iniziato riportando una citazione del CTO di Amazon Verner Vogels:
Failures are given, and everything will eventually fail over time
Non c’è nulla che non si guasti, tutto prima o poi si guasta. Bisogna quindi essere pronti a gestire queste situazioni, e i motivi sono molteplici:
- Crescita esponenziale di microservizi e architetture distribuite nel cloud.
- Il Web, la rete, è cresciuto, diventando più complesso. Pensate alle miriadi di applicazioni e processi che lo compongono.
- Oggi più che mai dipendiamo tutti sempre di più da servizi web (compreso questo meetup, organizzato con Zoom e diretta streaming su YouTube).
- Data la complessità crescente dei sistemi, è molto più complesso trovare un guasto in un sistema. Rispetto a qualche anno fa, non abbiamo più tutti i pc di una rete a portata di mano. Tutto è nel cloud. Dopotutto “Riavviare Microsoft Azure non è come riavviare un server che abbiamo a disposizione nel nostro ufficio”, come dice Alberto in un esempio.
- Interruzioni di sistemi così complessi e distribuiti causano grosse perdite per le aziende.
Che cosa è successo in questi ultimi 20 anni?
Anni fa la gestione di un sistema era on-premise, ovvero si installava il sistema dal cliente e si gestiva la ridondanza (2). Come scritto prima, tutte le componenti del nostro sistema erano a portata di mano. Eventuali fermi macchina e le manutenzioni si effettuavano in loco…era quindi “facile” gestire un guasto. Le applicazioni erano grossi monoliti, certo, ma tutto era gestibile in maniera circoscritta.
Poi è arrivato il cloud.
Utenti non più connessi attraverso la classica Intranet bensì con Internet. E’ cambiato tutto. Anche le applicazioni si sono spostate nel cloud, portando ad un considerevole aumento del carico di lavoro dei servizi stessi.
E pian piano i microservizi si sono sostituiti ai monoliti.
Quali caratteristiche deve avere un’architettura per essere definita a microservizi? Alberto ci propone la risposta data a suo tempo da Martin Fowler:
We cannot say there is a formal definition of the microservices architectural style, but we can attempt to describe what we see as common characteristics for architectures that fit the label.
Non esiste una definizione formale, però vengono stilate una serie di caratteristiche comuni:
- Componentisation via services
- Organized around business capabilities
- Decentralized data management
- Products not projects
- …
- Designed for failure
Soffermiamoci sull’ultima di queste caratteristiche. Ovvero un’architettura che deve essere progettata per fallire.
Come si progetta un qualcosa affinché possa fallire?