Perché usare un approccio ai microservizi per la creazione di applicazioni

Per gli sviluppatori di software, il factoring di un'applicazione nelle parti del componente non è una novità. In genere, viene usato un approccio a livelli, con un archivio back-end, una logica di business di livello intermedio e un'interfaccia utente front-end. Ciò che è cambiato negli ultimi anni è che gli sviluppatori creano applicazioni distribuite per il cloud.

Ecco alcune esigenze aziendali mutevoli:

• Un servizio creato e reso operativo su larga scala per raggiungere i clienti in nuove aree geografiche.
• Offerta più rapida di funzionalità e caratteristiche che rispondano alle richieste dei clienti in modo agile.
• Utilizzo delle risorse migliorato per ridurre i costi.

Queste esigenze aziendali incidono sul modo di compilare le applicazioni.

Per altre informazioni sull'approccio di Azure ai microservizi, vedere Microservizi: una rivoluzione delle applicazioni basata sul cloud.

Approccio di progettazione monolitico e microservizi

Le applicazioni si evolvono con il trascorrere del tempo. Le applicazioni che hanno maggior successo si evolvono diventando utili per le persone. Le applicazioni non riuscite non si evolvono e alla fine sono deprecate. Ecco la domanda: quanto sai sui tuoi requisiti oggi e cosa saranno in futuro? Si supponga, ad esempio, di creare un'applicazione per la creazione di report per un reparto dell'azienda. Si è certi che l'applicazione si applichi solo nell'ambito dell'azienda e che i report non vengano mantenuti a lungo. L'approccio sarà diverso da quello di, ad esempio, la creazione di un servizio che offre contenuti video a decine di milioni di clienti.

A volte, ottenere qualcosa fuori dalla porta come modello di prova è il fattore di guida. L'applicazione può essere riprogettata in un secondo momento. C'è poco punto di over engineering qualcosa che non viene mai usato. D'altra parte, quando le aziende creano per il cloud, l'aspettativa è la crescita e l'utilizzo. La crescita e la scalabilità sono imprevedibili. Vogliamo creare rapidamente un prototipo pur sapendo che siamo in un percorso in grado di gestire il successo futuro. Questo è l'approccio di avvio snello: compilare, misurare, apprendere e ripetere.

Durante l'era del client/server, si è teso a concentrarsi sulla creazione di applicazioni a livelli usando tecnologie specifiche in ogni livello. Il termine applicazione monolitica è emerso per descrivere questi approcci. Le interfacce si trovavano di solito tra i diversi livelli e si usava una progettazione accoppiata più strettamente tra i componenti all'interno di ogni livello. Gli sviluppatori hanno progettato e fattoriato classi compilate in librerie e collegate tra loro in pochi file eseguibili e DLL.

Esistono vantaggi per un approccio di progettazione monolitico. Le applicazioni monolitiche sono spesso più semplici da progettare e le chiamate tra i componenti sono più veloci perché queste chiamate sono spesso tramite la comunicazione interprocesso (IPC). Inoltre, tutti testano un singolo prodotto, che tende a essere un uso più efficiente delle risorse umane. Lo svantaggio è che esiste un accoppiamento stretto tra livelli e non è possibile ridimensionare singoli componenti. Se è necessario eseguire correzioni o aggiornamenti, è necessario attendere il completamento del test da parte di altri utenti. È più difficile essere agili.

I microservizi affrontano questi svantaggi e sono più strettamente allineati ai requisiti aziendali precedenti. Ma hanno anche vantaggi e passività. I vantaggi dei microservizi sono che ognuno incapsula in genere funzionalità aziendali più semplici, che è possibile aumentare o ridurre le istanze, testare, distribuire e gestire in modo indipendente. Un vantaggio importante di un approccio ai microservizi è che i team sono guidati più da scenari aziendali che dalla tecnologia. Team più piccoli sviluppano un microservizio sulla base di uno scenario del cliente, usando le tecnologie che preferiscono.

In altre parole, l'organizzazione non deve necessariamente standardizzarsi sulla tecnologia per mantenere applicazioni di microservizi. I singoli team proprietari dei servizi possono procedere come meglio credono, a seconda dell'esperienza del team stesso o della soluzione più appropriata al problema da risolvere. In pratica, è preferibile un set di tecnologie consigliate, ad esempio un particolare archivio NoSQL o un framework applicazione Web.

Lo svantaggio dei microservizi è che è necessario gestire entità più separate e gestire distribuzioni e controllo delle versioni più complesse. Il traffico di rete tra i microservizi aumenta, come le latenze di rete corrispondenti. Un sacco di servizi granulari e granulari possono causare un incubo delle prestazioni. Senza strumenti che consentono di visualizzare queste dipendenze, è difficile vedere l'intero sistema.

Gli standard rendono funzionante l'approccio ai microservizi specificando come comunicare e tollerare solo gli elementi necessari da un servizio, anziché contratti rigidi. È importante definire questi contratti in anticipo nella progettazione perché i servizi vengono aggiornati indipendentemente l'uno dall'altro. Un'altra descrizione coniata per la progettazione con approccio basato su microservizi è "SOA (Service Oriented Architecture) con granularità fine".

Al suo più semplice, l'approccio di progettazione dei microservizi riguarda una federazione disaccoppiata di servizi, con modifiche indipendenti a ogni standard e concordato per la comunicazione.

Man mano che vengono prodotte più applicazioni cloud, gli utenti hanno scoperto che questa scomposizione dell'applicazione complessiva in servizi indipendenti incentrati sullo scenario è un approccio migliore a lungo termine.

Confronto tra approcci allo sviluppo di applicazioni

1. Un'applicazione monolitica contiene funzionalità specifiche del dominio ed è in genere suddivisa in livelli funzionali come Web, business e dati.

2. È possibile ridimensionare un'applicazione monolitica clonandola in più server/macchine virtuali/contenitori.

3. Un'applicazione di microservizi separa le funzionalità in servizi più piccoli distinti.

4. La scalabilità orizzontale di questo approccio basato sui microservizi si ottiene con la distribuzione di ogni servizio in modo indipendente e la creazione di istanze di questi servizi in server/macchine virtuali/contenitori.

La progettazione con un approccio ai microservizi non è appropriata per tutti i progetti, ma è più allineata agli obiettivi aziendali descritti in precedenza. A partire da un approccio monolitico può essere utile se si sa che sarà possibile rielaborare il codice in un secondo momento in una progettazione di microservizi. In genere si inizia con un'applicazione monolitica e quindi la si suddivide lentamente in fasi, a partire dalle aree funzionali che devono essere maggiormente scalabili o agili.

Quando si usa un approccio ai microservizi, si compone l'applicazione di molti servizi di piccole dimensioni. Questi servizi vengono eseguiti in contenitori distribuiti in un cluster di computer. I team più piccoli sviluppano un servizio incentrato su uno scenario e testano in modo indipendente, versione, distribuzione e ridimensionano ogni servizio in modo che l'intera applicazione possa evolversi.

Che cos'è un microservizio?

Esistono diverse definizioni di microservizi. Ma la maggior parte di queste caratteristiche dei microservizi è ampiamente accettata:

• Incapsulano uno scenario aziendale o del cliente. Quale problema si risolve?
• Sono sviluppati da un piccolo team di progettazione.
• Scritto in qualsiasi linguaggio di programmazione, usando qualsiasi framework.
• Sono costituiti da codice e, facoltativamente, stati, entrambi con controllo delle versioni, distribuiti e ridimensionati in modo indipendente.
• Interagiscono con altri microservizi tramite interfacce e protocolli ben definiti.
• Disporre di nomi univoci (URL) usati per risolvere il percorso.
• Rimangono coerenti e disponibili in caso di errori.

Per riassumere:

Le applicazioni di microservizi sono costituite da piccoli servizi rivolti ai clienti, scalabili e sottoposti al controllo delle versioni indipendentemente, che comunicano tra di essi tramite protocolli standard e interfacce ben definite.

Scritto in qualsiasi linguaggio di programmazione, usando qualsiasi framework

Gli sviluppatori vogliono essere liberi di scegliere un linguaggio o un framework, a seconda delle competenze e delle esigenze del servizio che stiamo creando. Per alcuni servizi, è possibile sfruttare i vantaggi delle prestazioni di C++ sopra qualsiasi altra cosa. Per altri, la facilità di sviluppo gestito ottenuta da C# o Java potrebbe essere più importante. In alcuni casi, potrebbe essere necessario usare una libreria partner, una tecnologia di archiviazione dei dati o un metodo specifico per esporre il servizio ai client.

Dopo aver scelto una tecnologia, è necessario considerare la gestione operativa o del ciclo di vita e il ridimensionamento del servizio.

Consentono di sottoporre al controllo delle versioni, distribuire e ridimensionare indipendentemente codice e stato

Indipendentemente dal modo in cui si scrivono i microservizi, il codice e, facoltativamente, lo stato, deve distribuire, aggiornare e ridimensionare in modo indipendente. Questo problema è difficile da risolvere perché dipende dalla scelta delle tecnologie. Per il ridimensionamento, comprendere come partizionare (o partizionare) sia il codice che lo stato è complesso. Quando il codice e lo stato usano tecnologie diverse, comuni oggi, gli script di distribuzione per il microservizio devono essere in grado di ridimensionarli entrambi. Questa separazione riguarda anche l'agilità e la flessibilità, quindi è possibile aggiornare alcuni dei microservizi senza dover aggiornare tutti contemporaneamente.

Torniamo al confronto tra gli approcci monolitici e microservizi per un momento. Questo diagramma mostra le differenze negli approcci all'archiviazione dello stato:

Archiviazione dello stato per i due approcci

L'approccio monolitico, a sinistra, ha un singolo database e livelli di tecnologie specifiche.

L'approccio ai microservizi, a destra, presenta un grafico di microservizi interconnessi in cui lo stato è in genere limitato al microservizio e vengono usate varie tecnologie.

In un approccio monolitico, l'applicazione usa in genere un database singolo. Il vantaggio dell'uso di un database è che si trova in un'unica posizione, semplificando la distribuzione. Ogni componente può avere una tabella singola per l'archiviazione del relativo stato. La parte più difficile riguarda la necessità che il team separi scrupolosamente lo stato. Inevitabilmente, qualcuno sarà tentato di aggiungere una colonna a una tabella cliente esistente, eseguire un join tra tabelle e creare dipendenze a livello di archiviazione. In questo caso, non sarà possibile ridimensionare i singoli componenti.

Con l'approccio dei microservizi, ogni servizio gestisce e archivia il proprio stato. Ogni servizio è responsabile di ridimensionare sia il codice che lo stato insieme, in modo da soddisfare le richieste del servizio. Uno svantaggio è che quando è necessario creare viste o query dei dati dell'applicazione, è necessario eseguire query in più archivi di stato. Questo problema viene in genere risolto da un microservizio separato che crea una visualizzazione in una raccolta di microservizi. Se è necessario eseguire più query impromptu sui dati, è consigliabile scrivere i dati di ogni microservizio in un servizio di data warehousing per l'analisi offline.

Le versioni dei microservizi vengono eseguite. È possibile che diverse versioni di un microservizio vengano eseguite side-by-side. Una versione più recente di un microservizio potrebbe non riuscire durante un aggiornamento e deve essere eseguito il rollback a una versione precedente. Il controllo delle versioni è utile anche per i test A/B, in cui utenti diversi riscontrano versioni diverse del servizio. Ad esempio, è comune aggiornare un microservizio per un set specifico di clienti per testare nuove funzionalità prima di implementarla più ampiamente.

Interagiscono con altri microservizi tramite interfacce ben definite e protocolli.

Negli ultimi 10 anni sono state pubblicate informazioni estese che descrivono i modelli di comunicazione nelle architetture orientate ai servizi. Di solito la comunicazione tra servizi usa un approccio REST con i protocolli HTTP e TCP e XML o JSON come formato di serializzazione. Dal punto di vista dell'interfaccia, si tratta di adottare un approccio di progettazione Web. Tuttavia, non è consigliabile impedire l'uso di protocolli binari o formati di dati personalizzati. Tenere presente che gli utenti avranno più tempo a usare i microservizi se questi protocolli e formati non sono disponibili in modo aperto.

Hanno un nome (URL) univoco usato per risolvere il percorso

Il microservizio deve essere indirizzabile ovunque venga eseguito. Se si pensa alle macchine e a quale computer esegue un determinato microservizio, le cose possono andare male rapidamente.

Così come il DNS risolve un URL particolare in un computer specifico, il microservizio deve avere un nome univoco per consentire l'individuazione della sua posizione attuale. I microservizi necessitano di nomi indirizzabili indipendenti dall'infrastruttura in cui sono in esecuzione. Ciò implica che vi sia un'interazione tra il modo in cui il servizio viene distribuito e il modo in cui viene individuato perché è necessario un registro del servizio. Quando un computer ha esito negativo, il servizio del Registro di sistema deve indicare dove è stato spostato il servizio.

Rimangono coerenti e disponibili in caso di errori.

Affrontare gli errori imprevisti è uno dei problemi più difficili da risolvere, specialmente in un sistema distribuito. Gran parte del codice scritto come sviluppatori è per la gestione delle eccezioni. Durante i test, viene inoltre dedicato più tempo alla gestione delle eccezioni. Il processo è più coinvolto rispetto alla scrittura di codice per gestire gli errori. Cosa accade quando il computer in cui è in esecuzione il microservizio ha esito negativo? È necessario rilevare l'errore, che è un problema difficile da solo. È anche necessario riavviare il microservizio.

Per la disponibilità, un microservizio deve essere resiliente agli errori e in grado di riavviare in un altro computer. Oltre a questi requisiti di resilienza, i dati non devono essere persi e i dati devono rimanere coerenti.

La resilienza è difficile da raggiungere quando si verificano errori durante l'aggiornamento di un'applicazione. Il microservizio, che interagisce con il sistema di distribuzione, non deve essere ripristinato. Deve determinare se può continuare a passare alla versione più recente o eseguire il rollback a una versione precedente per mantenere uno stato coerente. È necessario considerare alcune domande, ad esempio se sono disponibili computer sufficienti per continuare a procedere e come ripristinare le versioni precedenti del microservizio. Per prendere queste decisioni, è necessario il microservizio per generare informazioni sull'integrità.

Segnalano integrità e diagnostica

Potrebbe sembrare ovvio ed è spesso trascurato, ma un microservizio deve segnalarne l'integrità e la diagnostica. In caso contrario, si hanno poche informazioni sull'integrità dal punto di vista delle operazioni. Correlare gli eventi di diagnostica in un set di servizi indipendenti e gestire le differenze di orario dei computer per comprendere l'ordine degli eventi è difficile. Nello stesso modo in cui si interagisce con un microservizio usando protocolli e formati dati concordati, è necessaria una standardizzazione della modalità di registrazione delle informazioni sull'integrità e degli eventi di diagnostica che, alla fine, si traduce in un archivio di eventi che possono essere visualizzati e su cui si possono eseguire query. Con un approccio basato su microservizi, team diversi devono concordare un unico formato di registrazione. È necessario un approccio coerente alla visualizzazione degli eventi di diagnostica nell'applicazione nel suo complesso.

L'integrità è diversa dalla diagnostica. Per integrità si intende la segnalazione dello stato corrente da parte del microservizio per consentire l'esecuzione di azioni appropriate. Un esempio efficace riguarda l'interazione con i meccanismi di aggiornamento e distribuzione per assicurare la disponibilità. Anche se un servizio potrebbe essere attualmente non integro a causa di un arresto anomalo del processo o di un riavvio del computer, il servizio potrebbe essere ancora operativo. L'ultima cosa necessaria consiste nel peggiorare la situazione avviando un aggiornamento. L'approccio migliore consiste nell'analizzare prima o consentire il ripristino del microservizio. Gli eventi di integrità di un microservizio consentono di prendere decisioni informate e favoriscono in effetti la creazione di servizi con funzionalità di riparazione automatica.

Linee guida per la progettazione di microservizi in Azure

Per indicazioni sulla progettazione e la creazione di microservizi in Azure, visitare il Centro architetture di Azure.

Service Fabric come piattaforma di microservizi

Azure Service Fabric è emerso quando Microsoft ha eseguito la transizione dalla distribuzione di prodotti boxed, in genere monolitici, alla distribuzione di servizi. L'esperienza di creazione e gestione di servizi di grandi dimensioni, ad esempio Azure SQL Database e Azure Cosmos DB, ha formato Service Fabric. La piattaforma si è evoluta nel tempo man mano che sono stati adottati più servizi. Service Fabric doveva poter essere eseguito non solo in Azure, ma anche autonomamente nelle distribuzioni di Windows Server.

L'obiettivo di Service Fabric è risolvere i problemi difficili della creazione e dell'esecuzione di un servizio e dell'uso efficiente delle risorse dell'infrastruttura, in modo che i team possano risolvere i problemi aziendali usando un approccio basato su microservizi.

Service Fabric consente di creare applicazioni che usano un approccio basato sui microservizi offrendo:

• Piattaforma con servizi di sistema per distribuire, aggiornare e trovare servizi, rilevare e riavviare i servizi con problemi, inoltrare messaggi, gestire lo stato e monitorare l'integrità.
• Possibilità di distribuire applicazioni in esecuzione in contenitori o come processi. Service Fabric è una struttura per la gestione di contenitori e processi.
• API di programmazione produttive che consentono di creare applicazioni come microservizi: ASP.NET Core, Reliable Actors e Reliable Services. Ad esempio, è possibile ottenere informazioni su integrità e diagnostica o sfruttare la disponibilità elevata predefinita.

Service Fabric è indipendente dal modo in cui si crea il servizio ed è possibile usare qualsiasi tecnologia. Ma offre API di programmazione predefinite che semplificano la compilazione di microservizi.

Migrazione di applicazioni esistenti a Service Fabric

Service Fabric consente di riutilizzare il codice esistente e di modernizzarlo con nuovi microservizi. Esistono cinque fasi per la modernizzazione delle applicazioni ed è possibile avviare e arrestarsi in qualsiasi fase. Le fasi sono:

1. Iniziare con un'applicazione monolitica tradizionale.
2. Migrare. Usare contenitori o eseguibili guest per ospitare codice esistente in Service Fabric.
3. Modernizzare. Aggiungere nuovi microservizi insieme al codice in contenitori esistente.
4. Innovare. Suddividere l'applicazione monolitica in microservizi in base alle esigenze.
5. Trasformare le applicazioni in microservizi. Trasformare le applicazioni monolitiche esistenti o creare nuove applicazioni greenfield.

Tenere presente che è possibile iniziare e arrestarsi in una di queste fasi. Non è necessario passare alla fase successiva.

Di seguito vengono esaminati esempi per ognuna di queste fasi.

Migrazione
Per due motivi, molte aziende eseguono la migrazione di applicazioni monolitiche esistenti in contenitori:

• Riduzione dei costi, a causa del consolidamento e della rimozione dell'hardware esistente o a causa dell'esecuzione di applicazioni ad alta densità.
• Contratto di distribuzione coerente tra sviluppo e operazioni.

Le riduzioni dei costi sono semplici. In Microsoft molte applicazioni esistenti vengono incluse in contenitori, con conseguente risparmio di milioni di dollari. La distribuzione coerente è più difficile da valutare ma altrettanto importante. Significa che gli sviluppatori possono scegliere le tecnologie adatte, ma le operazioni accetteranno solo un unico metodo per la distribuzione e la gestione delle applicazioni. Riduce le operazioni dalla necessità di gestire la complessità del supporto di tecnologie diverse senza forzare gli sviluppatori a scegliere solo determinati. In pratica, ogni applicazione viene inserita in contenitori in immagini di distribuzione autonome.

Per molte organizzazioni il processo termina qui. Hanno già i vantaggi dei contenitori e Service Fabric offre l'esperienza di gestione completa, tra cui distribuzione, aggiornamenti, controllo delle versioni, rollback e monitoraggio dell'integrità.

Modernizzare
La modernizzazione è l'aggiunta di nuovi servizi insieme al codice in contenitori esistente. Se si intende scrivere nuovo codice, è consigliabile eseguire piccoli passaggi per il percorso dei microservizi. Ciò potrebbe significare l'aggiunta di un nuovo endpoint API REST o di una nuova logica di business. In questo modo, si avvia il processo di creazione di nuovi microservizi e si pratica lo sviluppo e la distribuzione di tali microservizi.

Innovazione
Un approccio basato su microservizi è in grado di gestire eventuali cambiamenti nelle esigenze aziendali. In questa fase, è necessario decidere se iniziare a suddividere l'applicazione monolitica in servizi o innovando. Un esempio classico è quando un database usato come coda del flusso di lavoro diventa un collo di bottiglia di elaborazione. Se il numero di richieste del flusso di lavoro aumenta è necessario suddividere in scala il carico di lavoro. Prendere questo particolare elemento dell'applicazione che non sta ridimensionando o che deve essere aggiornato più frequentemente e suddividerlo come microservizio e innovazione.

Trasformare le applicazioni in microservizi
In questa fase, l'applicazione è completamente costituita da microservizi (o suddivisi in). Per raggiungere questo punto, è stato effettuato il percorso dei microservizi. È possibile iniziare da qui, ma a tale scopo senza una piattaforma di microservizi che consenta di richiedere un investimento significativo.

I microservizi sono appropriati per l'applicazione in uso?

È possibile. In Microsoft, man mano che più team hanno iniziato a creare per il cloud per motivi aziendali, molti di essi hanno realizzato i vantaggi derivanti dall'adozione di un approccio simile a un microservizio. Bing, ad esempio, usa da anni microservizi. Per altri team, l'approccio basato su microservizi era una novità. I team riscontravano problemi difficili da risolvere ed estranei alle loro aree di competenza principali. Questo è il motivo per cui Service Fabric ha acquisito trazione come tecnologia per la costruzione di servizi.

L'obiettivo di Service Fabric è ridurre le complessità della creazione di applicazioni di microservizi in modo che non sia necessario eseguire tutte le riprogettazioni costose. Iniziare con piccole soluzioni, ridimensionarle secondo le esigenze, deprecare servizi, aggiungerne di nuovi ed evolversi secondo le esigenze di utilizzo del cliente. È anche evidente che devono essere ancora risolti molti altri problemi per rendere i microservizi più accessibili per la maggior parte degli sviluppatori. I contenitori e il modello di programmazione degli attori sono esempi di piccoli passaggi in tale direzione. Si è certi che verranno introdotte altre innovazioni per semplificare l'approccio ai microservizi.

Passaggi successivi

• Microservizi: una rivoluzione delle applicazioni basata sul cloud
• Centro architetture di Azure: Creazione di microservizi in Azure
• Procedure consigliate per applicazioni e cluster di Azure Service Fabric
• Panoramica della terminologia di Service Fabric