Continuiamo a scannarci sulla solita diatriba monolite vs microservizi. Tanti dicono che, quando si crea un nuovo sistema, è buona norma che la semplicità la faccia da padrone: complessità minima e velocità di sviluppo. E io sono d’accordissimo, "keep it simple stupid". Peccato che la semplicità venga sempre attribuita ai monoliti. Chi dice che debba essere complicato senza?
Innanzitutto, cosa sono i microservizi? Unità di lavoro costruite attorno ad un dominio di business, indipendentemente deployabili, con un proprio stato, di dimensioni contenute, disaccoppiate e coese. Penso che sia una definizione abbastanza condivisibile e qui faccio notare che non si parla di container Docker. Eppure, quando si parla di microservizi, si pensa sempre al cluster Kubernetes, che sì, è roba complicata. Probabilmente è un problema di terminologia, bisognerebbe distinguere meglio tra la teoria dei microservizi, in senso ampio, e un’architettura basata su container in esecuzione su un cluster.
Cos’altro potrebbero essere allora questi microservizi? Serverless, ad esempio. Rispolverando la definizione emanata qua su, scopriamo che in serverless la teoria dei microservizi rimane valida. Cos'è serverless in due parole? Un modello cloud in cui non dobbiamo gestire o fare provisioning di server. Ipotizzando di lavorare su public cloud provider, abbiamo i vantaggi di poterci concentrare sul prodotto, sfruttare modelli di prezzo on-demand, delegare un sacco di grane al provider, abbassare il costo del possesso e sfruttare un ampio ventaglio di servizi gestiti. Tutto ciò può portare semplicità, flessibilità e velocità senza pari. Porterò qualche caso studio prossimamente.
Non ho scomodato argomenti quali scalabilità e disponibilità, cavalli di battaglia di serverless, perché ciò su cui voglio puntualizzare è quella semplicità che si vuole attribuire ai monoliti a discapito dei microservizi. Come se i monoliti poi fossero semplici, ma meglio non scoperchiare questo vaso ora.
Come sempre, ci tengo a precisare che io non schifo i monoliti e nemmeno penso che serverless sia sempre la giusta strada. Infatti serverless può portare molte complicazioni: comunicazione asincrona, architetture event-driven, eventual consistency, complicanze sull’observability e così via. Ma il bello arriva proprio ora: serverless non è un prendere o lasciare. Lo usiamo dove vien più comodo e lo accantoniamo dove non serve (trovo molto interessante il caso di Prime Video dell’anno scorso, anche se ha fatto scalpore in senso negativo per via di qualche titolo bait).
Personalmente, credo che i vantaggi potenziali di serverless siano talmente alti da spingermi a pensare serverless-first, senza essere necessariamente serverless-only. Il vero problema, a dirla tutta, può essere la mancanza di cultura su serverless. Ma se quella cultura non la creiamo noi, che siamo l’IT, allora chi?