Civil war: monolite vs microservizi
Nel 2009 Netflix ha dovuto affrontare diverse difficoltà, tra cui quella per cui la sua infrastruttura non riusciva a tenere il passo con la domanda dei servizi di streaming video in rapida crescita. L’azienda ha deciso di migrare la propria infrastruttura IT dai data center privati a un cloud pubblico e sostituire la sua architettura monolitica con un’architettura di microservizi.
L’unico problema era che il termine “microservizi” non esisteva e il suo funzionamento non era ben conosciuto.
Netflix è infatti diventata una delle prime aziende di alto profilo a migrare con successo da un’architettura monolitica a un’architettura di microservizi basata su cloud.
Un’architettura monolitica è un modello tradizionale di un programma software, costruito come un’unità unificata, autonoma e indipendente dalle altre applicazioni.
La parola “monolite” è spesso attribuita a qualcosa di grande e glaciale, che non è lontano dalla verità di un’architettura monolitica per la progettazione del software.
Un’architettura monolitica è infatti intesa come un sistema singolare e di grandi dimensioni con un codice sorgente che unisce insieme tutte le esigenze aziendali. Per apportare una modifica a questo tipo di applicazione è necessario aggiornare l’intero stack accedendo alla codebase e creando e distribuendo una versione aggiornata dell’intero prodotto. Ciò rende gli aggiornamenti più complessi, e che possono richiedere molto tempo.
Credits to N-iX
I monoliti possono essere utili nelle prime fasi della vita di un progetto per facilitare la gestione del codice, il sovraccarico cognitivo e la distribuzione. Ciò consente di rilasciare tutto nel monolite in una volta, o nel caso in cui si abbia bisogno di un’architettura semplice e che non abbia necessita di scalare, se non verticalmente.
Credits to scylladb.com
Un’architettura basata su microservizi è un metodo che si basa su una serie di servizi distribuibili in modo indipendente.
Questi servizi hanno una propria logica aziendale e un database con un obiettivo specifico. L’aggiornamento, il test, la distribuzione e il dimensionamento avvengono all’interno di ciascun servizio.
I microservizi non riducono la complessità, ma rendono qualsiasi complessità visibile e più gestibile separando le attività in processi più piccoli che funzionano indipendentemente l’uno dall’altro e contribuiscono all’insieme complessivo.
L’adozione dei microservizi spesso va di pari passo con la filosofia #DevOps, poiché costituiscono la base per pratiche di rilascio continuo (in inglese continuous delivery), che consentono ai team di adattarsi rapidamente alle esigenze degli utenti.
Disclaimer: questo post non intende definire l’una o l’altra architettura come migliore: sono due tipologie di architetture estremamente diverse, ognuna con pro e contro che devono essere attentamente valutati a seconda del caso d’uso.
Per saperne di più, leggi il capitolo dedicato alle architetture de “Il Libro Open Source”.
