In natura, essere più grandi non sempre vuol dire avere la meglio. E sebbene il grande squalo bianco possa essere il terrore degli oceani, ci sono molti casi in cui un banco di pesci ha maggiori capacità di sopravvivere e prosperare come gruppo rispetto a qualsiasi organismo a sé stante. Di fatto, il successo della collaborazione è un tema comune in tutto il regno animale: colonie di formiche, alveari, branchi di lupi e via dicendo beneficiano tutti della collaborazione all'interno di sistemi liberamente connessi per distribuire il controllo e raggiungere obiettivi comuni. Se un membro della colonia, dell'alveare o del branco dovesse venir meno, il resto del gruppo può continuare a funzionare e sopperire alla perdita.
I microservizi adottano questo approccio e lo applicano allo sviluppo di software e all'architettura di sistema. L'idea alla base è che spesso è più veloce, più facile, più sicuro e più efficiente creare diverse funzioni di componenti o servizi separatamente piuttosto che installare la stessa funzionalità in un sistema autonomo e completamente interconnesso. Esaminiamo più da vicino i microservizi e i relativi attributi, vantaggi e difficoltà.
L'approccio migliore per capire cosa sono i microservizi è identificare innanzitutto cosa non sono. Esistono diverse differenze tra i microservizi e altri approcci organizzativi. In questo caso confrontiamo i microservizi con l'architettura monolitica tradizionale, nonché con la più recente architettura orientata al servizio (Service-Oriented Architecture, SOA).
Come suggerisce il nome, i monoliti sono grandi applicazioni unificate in cui ogni componente è ampiamente interconnesso e dipendente dai componenti adiacenti. I monoliti costituiscono l'approccio tradizionale allo sviluppo, dove tutte le funzioni vengono gestite e svolte da un'unica posizione e dove tutto viene creato da un'unica base del codice. Qualsiasi modifica che sviluppatori e sviluppatrici potrebbero voler implementare nelle strutture monolitiche andrà naturalmente a modificare l'intero stack. Anche attività come i test si applicano all'intero stack; pertanto le modifiche vengono raggruppate in una versione di grandi dimensioni che può richiedere un tempo relativamente lungo dall'inizio alla fine. I microservizi differiscono dai monoliti in quanto sono composti da una serie di componenti più piccoli, autonomi e liberamente connessi. Le modifiche possono essere implementate sui singoli componenti senza influire su altri servizi all'interno dell'applicazione.
La distinzione tra microservizi e architettura SOA è più sottile. Tuttavia, sebbene entrambi si basino su componenti riutilizzabili che possono essere applicati secondo una logica modulare a diverse applicazioni, l'architettura SOA non mostra la stessa granularità. Se i microservizi sono containerizzati fino al punto in cui ogni servizio esegue solamente un'unica funzione, ciascun componente SOA può essere un sottosistema completo responsabile di una serie di funzionalità aziendali. Inoltre, l'architettura SOA ottimizza la condivisione e le dipendenze dei componenti, mentre i microservizi tentano semplicemente di ridurre il più possibile questi aspetti.
In genere i microservizi presentano le seguenti caratteristiche:
Poiché i microservizi sono concepiti come una raccolta di servizi separati e indipendenti, possono essere facilmente sottoposti a test come componenti autonomi. I problemi all'interno dei componenti si possono isolare rapidamente senza dover testare interi sistemi e applicazioni e poi impiegare grandi quantità di tempo nel tentativo di isolare problemi specifici.
Per operare in sinergia, i microservizi devono mantenere la comunicazione tra loro. Fatta questa premessa, si tratta di una connessione libera, in cui le modifiche implementate in un servizio non influiscono direttamente sugli altri.
Anziché avvalersi di archivi di dati condivisi tra i servizi, ogni componente mantiene il proprio archivio di dati. In questo modo si evita l'associazione accidentale di servizi diversi e si assicura che le modifiche non influiscano accidentalmente su altri servizi indipendenti.
I singoli servizi vengono modificati e distribuiti nell'ambiente di produzione senza dover impiegare altri servizi. Tutte le distribuzioni all'interno del sistema vengono gestite in questo modo, velocizzando enormemente il miglioramento di un microservizio.
I microservizi fanno uso di team interfunzionali, organizzati sulla base di un unico scopo aziendale. Questi team sono spesso composti da sviluppatori/trici, ingegneri/e di database, tester, ingegneri/e di infrastruttura e altre figure, tutte con l'obiettivo di sviluppare prodotti specifici basati su più servizi indipendenti.
Nei microservizi, ogni servizio indipendente è in grado di ricevere, elaborare e rispondere alle richieste. Tutto è notevolmente semplificato rispetto a molti dei sistemi più tradizionali, in cui l'instradamento complesso e i livelli di applicazione delle regole aziendali possono rallentare il processo.
Per causare il collasso completo di un sistema di microservizi, essenzialmente dovrebbero andare in errore contemporaneamente tutti i servizi indipendenti. Affidandosi a servizi liberamente connessi, un sistema può continuare a funzionare quasi a capacità ottimale anche in caso di errore di uno dei suoi servizi. Poiché i servizi sono decentralizzati, la perdita di uno di essi ha un impatto minimo o nullo sui servizi adiacenti.
Poiché i microservizi sono di natura modulare, è relativamente facile aggiungerne di nuovi quando necessario. Ciò consente alle organizzazioni di adattare i sistemi attuali a nuovi utilizzi e di ridimensionarli in modo da soddisfare le mutevoli esigenze.
Quando sviluppano un nuovo servizio, le organizzazioni hanno la libertà di scegliere tra diversi stack tecnologici. Allo stesso tempo, i nuovi stack tecnologici possono essere utilizzati anche quando si apportano modifiche ai servizi esistenti.
L'approccio modulare e containerizzato utilizzato nello sviluppo dei microservizi li rende particolarmente adatti all'integrazione con DevOps e CI/CD (integrazione continua e consegna continua). Poiché ogni servizio viene trattato come unità isolata, più team possono lavorare separatamente per sviluppare le funzionalità contemporaneamente, applicando i principi DevOps e spostando rapidamente i progetti attraverso pipeline CI/CD.
Sebbene sia possibile che i microservizi comunichino direttamente tra loro, molte aziende preferiscono integrare i gateway API per utilizzarli come livelli intermedi per l'instradamento delle richieste, un'autenticazione aggiuntiva e una migliore sicurezza. La comunicazione API può essere particolarmente efficace quando i microservizi stabiliscono lo stato per la prima volta.
I microservizi rappresentano un cambiamento rispetto all'architettura di sviluppo tradizionale e offrono numerosi vantaggi rispetto agli approcci organizzativi più convenzionali. Tra questi:
I microservizi consentono a piccoli team indipendenti di agire in contesti chiaramente definiti. In questo modo si ottengono maggiori risultati in meno tempo ed è possibile rispondere con più agilità ai cambiamenti imprevisti.
I microservizi suddividono applicazioni e sistemi complessi in componenti più piccoli e semplici. I team di sviluppo possono individuare più facilmente le differenze tra i servizi e apportare gli aggiornamenti e i miglioramenti necessari.
Anziché essere vincolati a un unico linguaggio o stack tecnologico, i team di sviluppo hanno la libertà di scegliere le soluzioni, gli strumenti o le risorse migliori per ogni singola funzione, senza doversi preoccupare dell'impatto sulla comunicazione tra i servizi.
Poiché le applicazioni basate su microservizi sono altamente modulari, possono essere sviluppate e distribuite con relativa facilità. I team possono coordinarsi per lavorare simultaneamente su singoli componenti di piccole dimensioni, ognuno dei quali può essere distribuito in modo indipendente.
Nella tradizionale architettura delle applicazioni, soddisfare le esigenze in continua evoluzione significa spesso scalare l'intera applicazione. I microservizi consentono ai team di sviluppo di reindirizzare le risorse verso la scalabilità dei soli servizi e componenti applicabili, migliorando la velocità di scalabilità e riducendo i costi.
In caso di errore di un microservizio, quelli adiacenti non vengono influenzati. Ciò significa che le applicazioni basate su microservizi tendono a non arrestarsi in modo anomalo. Se uno o più componenti riscontrano errori, l'applicazione continuerà a funzionare con funzionalità ridotte fino a quando il servizio interessato non potrà essere riparato.
Poiché ogni servizio è autonomo e progettato per eseguire in modo indipendente una funzione specifica, i team di sviluppo possono riutilizzare e riciclare i servizi per l'uso in diverse applicazioni. I componenti possono funzionare come "blocchi di base", riducendo notevolmente la necessità di creare un nuovo codice da zero per ogni nuovo progetto.
Maggiore agilità, maggiore riusabilità e distribuzione semplificata contribuiscono a ridurre i cicli di sviluppo e accelerare il time to market. Ciò ha il potenziale di migliorare i profitti aziendali e offrire un'esperienza utente più positiva.
I vantaggi apportati dai microservizi comportano anche alcune difficoltà. In questo caso, esaminiamo più da vicino alcune delle possibili sfide che le organizzazioni devono affrontare durante l'implementazione di un approccio basato sui microservizi:
Passare ai microservizi significa identificare e catalogare tutte le dipendenze tra loro. A causa delle dipendenze, il completamento di una singola versione può portare direttamente alla necessità di implementare altre versioni, creando frustrazione e dispendio di tempo.
Un fattore chiave dei microservizi è che ogni componente ha un proprio database isolato. Tuttavia, ogni nuovo database comporta una maggiore complessità di gestione. Più servizi e più database vengono utilizzati, meno comodo è gestire i dati stessi.
Quando si aggiornano le applicazioni alle nuove versioni utilizzando i microservizi, è possibile che la compatibilità con le versioni precedenti venga compromessa. Le soluzioni (utilizzare la logica condizionale o avere più versioni live per diversi clienti), possono essere eccessivamente complesse in termini di manutenzione e gestione.
I microservizi sono progettati per semplificare la distribuzione. Tuttavia, lavorare con un gran numero di componenti indipendenti può essere molto difficile. L'automazione può aiutare a risolvere questo problema.
La registrazione può diventare difficile quando ogni servizio utilizza il proprio database. Potrebbe essere necessario stabilire soluzioni di registrazione centralizzate. Analogamente, il monitoraggio e la gestione di ciascun servizio possono risultare infattibili senza una vista centralizzata e un'unica fonte di riferimento affidabile.
Con centinaia di microservizi potenzialmente incorporati in un'unica applicazione, il debug tradizionale non è una via percorribile.
Mentre l'architettura di microservizi offre ai team una discreta indipendenza, i problemi che riguardano più di un servizio all'interno di un'applicazione possono richiedere una comunicazione e un coordinamento dettagliati tra team per essere risolti.
Poiché le applicazioni dei microservizi sono sistemi distribuiti, non è così raro che i team duplichino inconsapevolmente le attività. Ciò può comportare uno spreco di energie e applicazioni inefficienti.
Oltre alle sfide descritte in precedenza, le organizzazioni devono essere consapevoli di alcuni problemi al momento di prendere in considerazione l'adozione di un'architettura di microservizi:
Sebbene si tratti di un approccio all'architettura di sviluppo molto diffuso, i microservizi sono generalmente gli strumenti ideali per riparare e rivedere le applicazioni esistenti diventate troppo complesse e difficili da gestire. Non hanno la stessa efficacia se utilizzati come punto di partenza. Se l'approccio tradizionale non ha raggiunto livelli ingestibili, in realtà non si tratta di un monolite che necessita di essere ristrutturato.
Come qualsiasi altra cosa, un servizio può essere suddiviso in parti più piccole. Inoltre, sebbene i microservizi siano granulari e costituiti da funzioni limitate progettate per supportare un'intera parte, è possibile che la situazione sfugga di mano. Al contrario, molte aziende scoprono che iniziare con servizi più grandi e poi suddividerli in microservizi solo quando diventano lenti da distribuire o troppo complessi da gestire aiuta a garantire che la soluzione non si scosti dai potenziali guadagni.
Un sistema ampio e distribuito può facilmente andare fuori controllo. Per garantire l'efficacia dei microservizi, le organizzazioni devono incorporare la distribuzione avanzata e l'automazione del monitoraggio, oltre ai servizi cloud gestiti. Ciò può aiutare a semplificare la transizione ai microservizi.
ServiceNow® offre supporto negli aspetti di gestione dei servizi creati utilizzando i microservizi e nell'integrazione con metodologie e strumenti utilizzati nelle fasi di compilazione, come i processi CI/CD e altre soluzioni DevOps.
Dato il potenziale numero elevato di microservizi e la loro natura transitoria, ServiceNow offre opzioni per popolare automaticamente il CMDB e Service Graph per tenere traccia delle relazioni tra servizi e mantenerne la definizione. Questo fa parte della nostra soluzione IT Operations Management, che offre anche funzionalità più ampie di gestione cloud.
Come per qualsiasi codice sviluppato con le pratiche DevOps, la velocità (ovvero fornire il percorso più rapido possibile tra sviluppo e sistema di produzione) è un obiettivo comune per la manutenzione dei microservizi. Tuttavia, poiché le organizzazioni più grandi o regolamentate devono mantenere uno stretto controllo sulle modifiche, IT Service Management Professional include la funzionalità DevOps Change Velocity che si collega alla pipeline CI/CD, raccoglie informazioni durante il processo di sviluppo e le utilizza congiuntamente a criteri definiti in precedenza per automatizzare il processo di gestione dei cambiamenti.
Infine, ServiceNow offre moltissime funzionalità che possono essere utilizzate da applicazioni interne ed esterne in modo simile ai microservizi, oltre a supportare l'integrazione con microservizi esterni come parte dei workflow ServiceNow.
La Now Platform include funzionalità principali che ti consentono di digitalizzare i workflow in modo semplice ed efficiente e di implementarli dove richiesto.