Arrivano i microservice Quando sbarazzarsi dei monoliti. E quando no

Molte aziende hanno lasciato che il loro software crescesse nell’arco di lunghi periodi di tempo. E si sono trovate a scegliere tra l’aggiunta di nuove funzionalità e il mantenimento della qualità

Quello dei microservice è un tema scottante. Sul quale è tutto un fiorire di opinioni, di discussioni in conferenze e di post sui blog. Io stesso ho iniziato a fare microservice tre anni e mezzo fa, quando stavo progettando un sistema per una compagnia di assicurazioni. Da allora, su questo tema ho tenuto spesso conferenze, ho pubblicato numerosi articoli e tenuto molti corsi di formazione. Di solito, chiedo a chi partecipa ai miei corsi se dispongono di un grande sistema monolitico del quale vorrebbero liberarsi. Nella maggior parte dei casi, ovviamente ce l’hanno. Non sarebbero venuti alle mie conferenze, né mi avrebbero invitato a tenere corsi se non fosse stato così. E c’è più di un buon motivo per cui si intende abbandonare i monoliti. Vediamo alcuni esempi pratici, tratti dalla vita reale.

I monoliti – Uno dei miei clienti gestiva gran parte del suo software di produzione su un mainframe. Il codice era stato scritto in un interessante dialetto Cobol, con 18 milioni di righe di codice. Solo mantenere in vita il mainframe costava più di un milione di euro all’anno. Senza contare che la maggior parte dei programmatori di Cobol sono ormai in vista del pensionamento. Un’altra società con cui ho lavorato ha iniziato con due ragazzi, di cui uno ha scritto codice. In VBA. Quando la società ha cominciato a crescere, hanno migrato a Visual Basic. Attualmente, l’azienda impiega oltre 20 sviluppatori e scrive codice sia in C# sia in VB.NET.

Il prodotto è cresciuto a quasi 4 milioni di righe di codice. Un ultimo esempio. Nel corso di 12 anni, una terza società ha scritto 3 milioni di righe di applicazione di codice. In PHP. La complessità del database e le numerose domande di codice on top rendono difficile aggiungere nuove funzionalità.

Le analogie – Diverse aziende, diversi scenari. Ma ciò che mi ha colpito è il numero di somiglianze presenti in questi scenari: 1) In tutte e tre le aziende, diverse persone avevano lavorato su questi sistemi per molti anni, con inevitabili differenze in termini di intuizioni, idee architetturali e stili di coding. 2) Di conseguenza, nel corso del tempo l’architettura si è sfilacciata ed è divenuta sempre più difficoltosa da mantenere o estendere. 3) Non ci sono test automatici (unità o integrazioni) in nessuno di questi scenari. Con il Cobol posso capirlo, ma con linguaggi più moderni come Java, C#, VB.NET o PHP, non c’è nessuna scusa.

In tutti e tre gli scenari, aggiungere nuove funzionalità è diventato praticamente impossibile. Come mi hanno spiegato i tester: «Per ogni bug che risolviamo, ne introduciamo uno nuovo».

Serve velocità – Ma allora cosa è andato storto in questi esempi? Le chiare analogie in questi scenari indicano un possibile fallimento dell’architettura. Queste aziende hanno lasciato che il loro software crescesse nell’arco di lunghi periodi di tempo: vent’anni, o dodici anni. E si sono trovate continuamente a scegliere tra l’aggiunta di nuove funzionalità e il mantenimento della qualità. Se vuoi avere un codice che sia nel tempo manutenibile, dovrai trovare un buon equilibrio tra caratteristiche e qualità.

La rana bollita – C’è una vecchia metafora che si adatta al comportamento di tali società: la sindrome della rana bollita. Se una rana viene messa di colpo in acqua bollente, salterà fuori. Ma se viene messa in acqua tiepida che poi viene portata lentamente a bollore, non avverte il pericolo e verrà bollita viva. Anche se si tratta di una leggenda, come metafora è abbastanza azzeccata. Le aziende sembrano sempre aver bisogno di crescere. C’è sempre bisogno di velocità. Il business tira sempre fuori più caratteristiche di quanto i team riescano ad aggiungere ai sistemi. Di conseguenza, le aziende spesso optano per i benefici a breve termine invece che per quelli a lungo termine, cioè per le nuove funzionalità invece che per la manutenibilità. «Aggiungeremo i test più avanti». Oppure: «Lasciamo alcuni “to do” nel codice, e più avanti li aggiusteremo». Ma il problema è che il tuo codice non si rompe quando lo crei per la prima volta: si rompe dieci o quindici anni dopo. E in posti che non avresti mai pensato. Questo è lo stato in cui di solito trovo le aziende: rane bollite che mi chiedono di aiutarle a sbarazzarsi dei loro monoliti non manutenibili, nei quali l’architettura è un pasticcio e non ci sono test automatici, oppure il sistema non scala bene e a ogni variazione di codice il sistema crolla da un’altra parte.

Buttarsi sui microservice? – Dato che l’espressione è stata coniata quasi quattro anni fa, le aziende ora credono che i microservice risolveranno i loro problemi e che porteranno cose buone, in quanto componenti piccoli e indipendenti che consentono di scalare e scrivere un codice gestibile e testabile.

Tuttavia, l’implementazione di microservice comporta anche molte domande alle quali è necessario trovare una risposta lungo il percorso, come per esempio:

• Cosa rende un componente un microservice?
• Come integro tutti questi piccoli componenti indipendenti?
• Come progettare le interfacce di questi componenti, le API?
• Cosa significa essere RESTful?
• Come progettare l’implementazione dei miei componenti?
• Come faccio a organizzare l’autorizzazione e l’autenticazione?
• Quali tecnologie posso utilizzare per costruire, testare e distribuire i miei microservice?
• Come posso impostare e mantenere le pipeline di deployment automatizzato?
• Posso integrare i miei microservice con altri sistemi più tradizionali?
• Ultimo ma non meno importante: i microservice implicano che il sistema è distribuito. Quindi, come posso organizzare l’integrità e la coerenza dei miei dati se uno dei servizi non è temporaneamente disponibile?

Nel complesso, i microservice sono una scelta architettonica interessante se si intende eliminare il monolite, ma hanno anche alcune conseguenze non secondarie. Trovare le risposte giuste alle domande appena viste, specifiche per la propria azienda, può essere una sfida. È per questo che bisogna intraprendere seriamente il percorso verso i microservice. Ci vuole tempo, fatica e preferibilmente esperienza. Se non sei stato in grado di tenere in ordine l’architettura, il codice e i test negli ultimi 15 anni, pensi di poter implementare i microservice, che sono un’architettura ancora più difficile?

Ma hai davvero bisogno dei microservice adesso? – Sono convinto che i microservice siano l’architettura giusta per questa epoca altamente scalabile. I loro vantaggi non sono pochi: migliorano la scalabilità e consentono di distribuire singole parti piccole e sostituibili in tutta l’infrastruttura. Ma aggiungono anche un altro livello di complessità all’infrastruttura stessa: pensiamo alla progettazione di API RESTful, o all’autorizzazione e all’autenticazione, oppure ancora alle nuove infrastrutture (cloud) e al fatto che adesso state costruendo sistemi distribuiti.Tuttavia, alla maggior parte delle rane che bollono mancano il tempo e l’esperienza per operare tali migrazioni su larga scala dei loro prodotti, ed è per questo che dovrebbero indagare se hanno bisogno di migrare adesso ai microservice. Ci sono molti aspetti dei microservice che già da soli forniscono molti miglioramenti, senza dover per forza ricorrere a tutto il pacchetto completo:

• Fanno aderire a un approccio più agile.
• Migliorano la collaborazione in team e comprendono sia le attività sia le operazioni.
• Migliorano il design modulare dei monoliti.
• Aumentano i test automatizzati, rendendo meno difficile il refactoring a un design più modulare.
• Impostano le pipeline per il deployment automatizzato, che consentono di passare a implementazioni più regolari, eliminando così tutti i tipi di attività di distribuzione manuale.

Forse la sfida principale è migliorare la qualità e la manutenzione del codice. O ridurre il time to market. O forse innovare più velocemente. In questi casi, le tecniche elencate sopra aiuteranno a ottenere risultati senza necessità di passare direttamente ai microservice in una sola volta.

Quindi? Stai pensando di spostarti verso nuove architetture? Verso i microservice? O verso il serverless? L’importante è cominciare sempre rispondendo alla domanda: “che cosa mi serve davvero per migliorare?”. E solo dopo aver risposto a questa domanda si migliorerà gradualmente. E si eviterà di entrare a far parte della prossima generazione di rane bollite.