Sviluppare microservizi aiuta a garantire una migliore flessibilità e maggiori prestazioni applicative. Ma attenzione, avvertono gli esperti: i microservizi aggiungono complessità alla programmazione impattando su attività fondamentali come, ad esempio, l’individuazione dei servizi, i test, la gestione della rete e il monitoraggio. Aggiungendo progressivamente alle applicazioni ulteriori microservizi gli sviluppatori devono essere consapevoli che un’architettura distribuita impatterà sulle routine di gestione.
Sviluppare microservizi: 4 cose da sapere
Sia nello sviluppo che nella gestione dei microservizi si nascondono alcune sfide. Di seguito quali sono e come è possibile risolvere le criticità.
#1 Troppi aspetti da monitorare
A far cadere un’applicazione monolitica possono concorrere diverse cause. Può essere un’interruzione della rete, un bug del software o un errore del sistema. Un’architettura di microservizi assicura che un’applicazione funzioni anche in caso di guasto di un singolo servizio. Questa maggiore tolleranza agli errori ha però un suo prezzo.
La natura disaccoppiata dei microservizi rende particolarmente complessa l’identificazione dei guasti mediante monitoraggio manuale e metodi di prova. Inoltre, quando i team non sono in grado di identificare un problema, rischiano di perdere la funzionalità dell’applicazione o di causare errori di servizio simultanei.
La risposta a questo problema è un programma di monitoraggio completo e automatizzato. Questo non significa eliminare i metodi manuali: quando ci sono così tanti servizi da tracciare, avere il supporto di un sistema di controllo automatico potenzia i livelli di attenzione.
#2 Controllo delle varie release
Il controllo delle versioni è una delle più grandi criticità per chi sceglie di sviluppare microservizi. I team progettano, programmano e distribuiscono microservizi indipendenti l’uno dall’altro. Questa attività crea un problema quando si tratta di controllare le varie release perché la compatibilità del servizio può andare persa da una versione all’altra. Per questo è importante assicurarsi che sia possibile tornare alla versione precedente di un servizio nel caso in cui qualcosa vada storto.
Progettare un’applicazione basata su microservizi, garantendo il supporto per più versioni di un servizio, richiede la presenza di una logica di routing che consentirà all’applicazione di supportare più versioni dei microservizi mentre si è in fase di esecuzione.
#3 Coordinamento della scalabilità
Per ridimensionare un’applicazione monolitica è necessario ridimensionare l’intera applicazione.
Per ridimensionare un’applicazione basata su microservizi, invece, è sufficiente ridimensionare solo alcuni componenti, ottimizzando in questo modo l’utilizzo delle risorse. Tuttavia, questo modello di scalabilità non è esente da criticità.
Per ridimensionare con successo ogni singolo servizio è fondamentale identificare prima i microservizi che devono ridimensionare e mantenere la compatibilità. Per questo gli esperti suggeriscono di coordinare i componenti sottostanti la scalabilità del servizio andando a identificare in modo proattivo quali sono le parti specifiche dell’applicazione che vanno ridimensionate. Tenendo sempre per buona la regola aurea di fare in modo di poter tornare alla versione precedente di un servizio nel caso in cui qualcosa non vada come sperato.
#4 Esigenze di prestazioni elevate
Le prestazioni sono probabilmente una delle maggiori sfide per chi si trova a sviluppare microservizi.
Le applicazioni basate su microservizi, infatti, consumano più risorse e comportano un carico maggiore per i server rispetto alle applicazioni monolitiche. Il che, tradotto, significa che saranno necessari dei server aggiuntivi. Queste richieste di risorse rendono ancora più fondamentale l’efficienza del sistema di codifica così come la comprensione delle dipendenze specifiche tra due o più microservizi. In questo caso il consiglio è di tenersi pronti ad aumentare rapidamente la capacità del server in caso di richieste ad alte prestazioni. Ricordandosi poi di ridimensionare le risorse quando finisce il picco per evitare di sprecare la potenza dei server.
