Microservizi e architettura monolitica a confronto

Le organizzazioni possono trarre vantaggio sia da un'architettura monolitica che da un'architettura di microservizi, in base a una serie di fattori diversi. Se si sceglie un'architettura monolitica per le attività di sviluppo, il vantaggio principale è costituito dall'elevata velocità di sviluppo dovuta alla semplicità di avere un'applicazione basata su una base di codice.

I vantaggi dell'architettura monolitica includono:

Facile distribuzione: un file o una directory degli eseguibili rende la distribuzione più agevole.

Sviluppo: le applicazioni compilate con una base di codice sono più semplici da sviluppare.

Prestazioni: in un repository e in una base di codice centralizzati, un'API può spesso eseguire la stessa funzione svolta da più API nell'architettura di microservizi.

Test semplificati: dal momento che un'applicazione monolitica è un'unità singola e centralizzata, i test end-to-end possono essere eseguiti più rapidamente rispetto a quelli delle applicazioni distribui

Debug agevole: dal momento che il codice si trova in un'unica posizione, è più semplice seguire una richiesta e trovare un ticket.

Come nel caso di Netflix, le applicazioni monolitiche possono essere piuttosto efficaci finché non diventano troppo grandi e la scalabilità si trasforma in una sfida. Apportare una piccola modifica in una singola funzione richiede la compilazione e il test dell'intera piattaforma, procedura che va contro l'approccio Agile preferito dagli sviluppatori di oggi.

Gli svantaggi dell'architettura monolitica includono:

Velocità di sviluppo ridotta: un'applicazione monolitica e di grandi dimensioni rende lo sviluppo più complesso e lento.

Scalabilità: non è possibile eseguire la scalabilità dei singoli componenti.

Affidabilità: gli eventuali errori in un modulo potrebbero influire sulla disponibilità di tutta l'applicazione.

Barriera all'adozione della tecnologia: le modifiche del framework o del linguaggio influiscono sull'intera applicazione, diventando spesso dispendiose in termini di costi e tempo.

Mancanza di flessibilità: un monolite è vincolato dalle tecnologie già in uso nel monolite stesso.

Distribuzione: una minima modifica a un'applicazione monolitica richiede una nuova distribuzione dell'intero monolite.

Un'architettura di microservizi, nota anche semplicemente come microservizi, è un metodo architettonico che si basa su una serie di servizi distribuibili in modo indipendente. Questi servizi hanno una propria logica aziendale e un proprio database con un obiettivo specifico. Le attività di aggiornamento, test, distribuzione e ridimensionamento avvengono all'interno di ciascun servizio. I microservizi scompongono le principali preoccupazioni aziendali e specifiche del contesto in basi di codice indipendenti e separate e, anche se non riducono la complessità, la rendono visibile e più gestibile separando i task in processi più piccoli in grado di funzionare in modo indipendente gli uni dagli altri e contribuire all'insieme generale.

I microservizi sono alla base delle pratiche di continuous delivery che consentono ai team di adattarsi rapidamente ai requisiti degli utenti ed è per questo che la loro adozione va spesso di pari passo con l'approccio DevOps.

Atlassian ha intrapreso la strada verso i microservizi nel 2018, dopo aver affrontato le sfide legate alla crescita e alla scalabilità con Jira e Confluence. Ci siamo resi conto che le nostre architetture monolitiche a tenant singolo in esecuzione on-premise non sarebbero state in grado di adattarsi alle esigenze di crescita future.

Abbiamo deciso di riprogettare Jira e Confluence e trasferirli da un sistema monolitico, con stato e a tenant singolo ad applicazioni cloud senza stato e multi-tenant ospitate da Amazon Web Services (AWS), che nel tempo avremmo scomposto in microservizi. Il progetto è stato denominato Vertigo (ossia vertigine) dopo che un ingegnere senior ha affermato che, sebbene gli piacesse molto, questa idea gli faceva venire le vertigini. È stato il più grande progetto di infrastruttura che abbiamo svolto finora. La transizione ad AWS ha richiesto due anni, con la migrazione di oltre 100.000 clienti in poco più di 10 mesi senza interruzioni del servizio. Ci siamo inoltre impegnati a scomporre i servizi in microservizi.

I microservizi non sono assolutamente la soluzione ottimale a tutti i problemi, tuttavia sono in grado di risolvere un discreto numero di problemi dei software e delle aziende in crescita. Dal momento che un'architettura di microservizi è costituita da unità eseguite in modo indipendente, ogni servizio può essere sviluppato, aggiornato, distribuito e ridimensionato senza influire sugli altri servizi. Gli aggiornamenti software vengono eseguiti con maggiore frequenza, in modo più affidabile e con prestazioni e tempo di attività migliorati. Siamo passati dal rilascio di aggiornamenti una volta alla settimana a due o tre volte al giorno.

Con la crescita di Atlassian, i microservizi ci consentono di adattare team e posizioni geografiche in modo più affidabile suddividendo le linee di proprietà dei servizi. Prima di partire con il progetto Vertigo, Atlassian contava cinque diversi centri di sviluppo in tutto il mondo. Questi team distribuiti erano vincolati da un monolite centralizzato e dovevamo supportarli in modo autonomo. I microservizi ci offrono questa possibilità.

Tra i vantaggi di Vertigo vi sono maggiore velocità di distribuzione, ripristino di emergenza, costi ridotti e prestazioni più elevate. Tutto ciò ci consente di raggiungere più rapidamente l'obiettivo offrendo al contempo ulteriore valore incrementale ai clienti.

Inoltre, più in generale, i microservizi semplificano ai team l'aggiornamento del codice e accelerano i cicli di rilascio grazie alla continuous integration e continuous delivery (CI/CD). I team possono sperimentare con il codice ed eseguire il rollback in caso di problemi.

In breve, i vantaggi dei microservizi sono:

Agilità: promuovi metodi di lavoro Agile con team di piccole dimensioni che rilasciano distribuzioni frequenti.

Scalabilità flessibile: se un microservizio raggiunge la capacità di carico, è possibile distribuire rapidamente nuove istanze di tale servizio nel cluster che lo accompagna per ridurre la pressione. La nostra infrastruttura è adesso multi-tenant e senza stato, i clienti sono distribuiti su più istanze e siamo in grado di supportare istanze di dimensioni molto più elevate.

Continuous deployment: i nostri cicli di rilascio sono adesso più frequenti e veloci. Prima, gli aggiornamenti venivano rilasciati una volta alla settimana, mentre adesso da due a tre volte al giorno.

Elevate capacità di manutenzione e test: i team possono sperimentare nuove funzioni e fare ed eseguire il rollback se qualcosa va storto. Ciò semplifica l'aggiornamento del codice e accelera il time-to-market delle nuove funzioni. Inoltre, è semplice isolare e correggere gli errori e i bug nei servizi individuali.

Distribuzione indipendente: dal momento che i microservizi sono unità individuali, rendono possibile la distribuzione rapida, semplice e indipendente delle singole funzioni.

Flessibilità della tecnologia: le architetture di microservizi danno ai team la libertà di scegliere gli strumenti che preferiscono.

Affidabilità elevata: puoi distribuire le modifiche di un servizio specifico senza il pericolo di arrestare l'intera applicazione.

Team più soddisfatti: i team Atlassian che lavorano con i microservizi sono molto più contenti poiché hanno maggiore autonomia e possono occuparsi della compilazione e della distribuzione senza dover attendere settimane per l'approvazione di una pull request.

Quando siamo passati da un numero ridotto di basi di codice monolitiche a un numero più elevato di sistemi e servizi distribuiti alla base dei nostri prodotti, sono sorte delle complessità impreviste. Inizialmente abbiamo avuto delle difficoltà nell'aggiungere nuove funzionalità alla stessa velocity e con la stessa sicurezza che avevamo in passato. I microservizi possono aggiungere ulteriore complessità che porta a un'estensione dello sviluppo o a una crescita rapida e non gestita. Può essere difficile determinare le relazioni tra i diversi componenti, chi possiede un determinato componente software o come evitare interferenze con i componenti dipendenti.

Con Vertigo, abbiamo compilato una funzionalità comune su cui si sarebbero basati i prodotti esistenti e quelli creati o acquisiti in futuro. Nel caso delle aziende di prodotti singoli, i microservizi potrebbero non essere necessari.

Gli svantaggi dell'architettura di microservizi includono:

Estensione dello sviluppo: i microservizi aggiungono ulteriore complessità rispetto all'architettura monolitica, dal momento che vi sono più servizi in più posizioni creati da più team. Se l'estensione dello sviluppo non è gestita correttamente, si traduce in velocità di sviluppo ridotta e in scarse prestazioni operative.

Costi di infrastruttura esponenziali: ogni nuovo microservizio può avere i propri costi per suite di test, playbook di distribuzione, infrastruttura di hosting, strumenti di monitoraggio e molto altro.

Sovraccarico organizzativo aggiunto: i team devono aggiungere un ulteriore livello di comunicazione e collaborazione per coordinare gli aggiornamenti e le interfacce.

Sfide legate al debug: ogni microservizio ha il proprio set di log, il che complica ulteriormente il debug. In più, un singolo processo aziendale può essere eseguito su più macchine, rendendo il debug ancora più difficoltoso.

Mancanza di standardizzazione: senza una piattaforma comune, può esserci una proliferazione di linguaggi, standard di registrazione e monitoraggio.

Poca chiarezza sulla proprietà: il numero di servizi che vengono introdotti è direttamente proporzionale ai team che li eseguono. Nel tempo, diventa difficile sapere quali sono i servizi disponibili che un team può utilizzare e chi contattare per richiedere assistenza.

Molti progetti iniziano come monoliti per poi evolversi in un'architettura di microservizi. Man mano che vengono aggiunte nuove funzioni a un monolite, potrebbe cominciare a diventare complicato avere più sviluppatori che lavorano su una singola base di codice. I conflitti di codice diventano più frequenti e il rischio che gli aggiornamenti a una funzione possano introdurre bug in una funzione non collegata aumenta. Quando prendono piede questi schemi indesiderati, potrebbe essere il momento di prendere in considerazione la migrazione ai microservizi.

Di seguito sono riportate alcune delle best practice che abbiamo appreso dal nostro processo di migrazione:

A gennaio 2016 avevamo in totale circa 15 microservizi. Adesso ne abbiamo più di 1300. Abbiamo trasferito 100.000 clienti nel cloud, costruito nel frattempo una nuova piattaforma, trasformato la nostra cultura e creato nuovi strumenti. I nostri team sono più soddisfatti e autonomi e la cultura DevOps è più solida che mai.

I microservizi potrebbero non essere la soluzione più adatta a tutti. Un monolite legacy può funzionare alla perfezione e potrebbe non valere la pena di scomporlo. Ma, via via che le organizzazioni crescono e le richieste sulle applicazioni aumentano, l'architettura di microservizi potrebbe essere la giusta soluzione.

Dal momento che i microservizi con architetture distribuite sono di tendenza per molte organizzazioni, Atlassian ha sviluppato Compass per aiutare le aziende a gestire la complessità delle architetture distribuite man mano che si ampliano. Si tratta di una piattaforma di sviluppo estensibile che riunisce i dati separati di tutti i risultati tecnici e della collaborazione tra i team in un'unica posizione centrale e ricercabile.