GSP699

Introduzione

Perché eseguire la migrazione da un'applicazione monolitica a un'architettura a microservizi? La suddivisione di un'applicazione in microservizi presenta i seguenti vantaggi, la maggior parte dei quali deriva dal fatto che il legame fra i microservizi non è rigido:

• I microservizi possono essere testati e distribuiti in modo indipendente. La facilità di deployment è direttamente proporzionale alle dimensioni dell'unità da distribuire.
• I microservizi possono essere implementati utilizzando linguaggi e framework diversi. Per ogni microservizio, si è liberi di scegliere la tecnologia più adatta al caso d'uso specifico.
• I microservizi possono essere gestiti da team diversi. Le linee di demarcazione tra microservizi facilitano l'assegnazione di un team a uno o più microservizi.
• Il passaggio ai microservizi consente di allentare le dipendenze tra i team. Ciascun team sarà interessato soltanto alle API dei microservizi da cui dipende il proprio lavoro e non dovrà preoccuparsi di come sono implementati quei microservizi, dei loro cicli di release e così via.
• È più facile progettare la gestione degli errori. Dal momento che i confini tra servizi sono chiari, è più semplice stabilire cosa fare quando un servizio non è disponibile.

Alcuni svantaggi rispetto ai monoliti:

• Un'app basata su microservizi è costituita da una rete di servizi diversi che spesso interagiscono in modi che non sono ovvi, pertanto la complessità generale del sistema tende ad aumentare.
• A differenza dei componenti interni di un monolite, i microservizi comunicano su una rete. In alcuni casi questo aspetto può essere percepito come un rischio per la sicurezza. Istio risolve questo problema criptando automaticamente il traffico tra microservizi.
• A causa delle latenze tra i servizi, può essere difficile raggiungere lo stesso livello di prestazioni offerto da un approccio monolitico.
• Il comportamento del sistema non dipende dal singolo servizio, ma da molti servizi e dalle loro interazioni. Per questo motivo, l'osservabilità del sistema, ossia la comprensione del suo funzionamento in ambiente di produzione, risulta più difficile. Istio risolve anche questo problema.

In questo lab eseguirai il deployment di un'applicazione monolitica esistente su un cluster Google Kubernetes Engine e quindi la suddividerai in microservizi. Kubernetes è una piattaforma utilizzata per la gestione, l'hosting, la scalabilità e il deployment di container. I container rappresentano un modo portabile per confezionare ed eseguire codice. Sono particolarmente indicati per i pattern a microservizi, in cui ciascun microservizio può essere eseguito nel proprio container.

Diagramma dell'architettura dei nostri microservizi

Per iniziare, suddividi il monolite in tre microservizi, uno per volta. I microservizi sono Orders, Products e Frontend. Crea un'immagine Docker per ciascun microservizio utilizzando Cloud Build, quindi esegui il deployment dei microservizi ed esponili su Google Kubernetes Engine (GKE) selezionando il tipo di servizio Kubernetes LoadBalancer. Eseguirai questa operazione per ciascun servizio, scorporando allo stesso tempo ciascuno dal monolite mediante refactoring. Durante questo processo sia il monolite sia i microservizi saranno in esecuzione fino alla fine, quando potrai eliminare il monolite.

Che cosa imparerai a fare:

• Suddividere un monolite in microservizi

• Creare un cluster Google Kubernetes Engine

• Creare un'immagine Docker

• Eseguire il deployment delle immagini Docker su Kubernetes

Prerequisiti

• Un account Google Cloud Platform con accesso amministrativo per creare progetti o un progetto con ruolo di Proprietario progetto.

• Conoscenza di base di Docker e Kubernetes