from k8s to PaaS for a Smarter Cloud

Migrare un’applicazione da Kubernetes a Platform as a Service con un approccio Cloud Smart.

Kubernetes

Kubernetes (spesso abbreviato in k8s) è ormai diventato lo strumento standard per effettuare il deploy di applicazioni in Cloud.

Kubernetes è un sistema di orchestrazione e gestione di Containers, basato su un concetto di Infrastructure as Code (IaC). Per effettuare il deploy di una nostra applicazione, basterà quindi dare in pasto al suo engine una serie di file contenenti codice YAML, nei quali viene descritta l’architettura e i componenti della nostra applicazione.
Sarà poi Kubernetes a occuparsi del deployment, scalabilità e monitoraggio.

Platform as a Service

Per comprendere che cosa si intende con Platform as a Service (Paas), confrontiamo le tre tipologie di servizi Cloud:

• Software as a Service (SaaS): software applicativo pronto all’uso, come Google Calendar o Office 365
• Platform as a Service (PaaS): software non applicativo, come MongoDB, RabbitMQ,…
• Infrastructure as a Service (IaaS): infrastruttura in cloud, virtual machine gestite da cloud provider o storage, come AWS EC2 o AWS S3

Il PaaS si colloca quindi a metà tra le tre tipologie di servizi. Richiede l’intervento di uno sviluppatore o un esperto per essere utilizzato e senza alcun intervento non ha nessun tipo di logica applicativa o di business al suo interno.

Perché Paas

Scegliere un servizio PaaS ci offre una serie di vantaggi, grazie ai Cloud Provider:

• Scalabilità: automatica o schedulata, senza l’intervento di sviluppatori
• Manutenzione: i Cloud Provider si occupano di aggiornamenti e backup, spesso automaticamente
• Integrazione: l’integrazione tra più servizi PaaS o verso un servizio PaaS è estremamente semplice
• Riduzione costi: i costi dei servizi PaaS sono spesso basati sull’utilizzo. Il rischio di sprechi è molto basso

Approccio alla Migrazione

La migrazione dell’applicazione è stata divisa in tre fasi:

• Analisi: capire l’architettura dell’applicazione e il suo funzionamento interno
• Replicazione: replicare l’installazione su un diverso cloud provider, con la stessa architettura
• Sostituzione: sostituire i componenti problematici dell’applicazione con PaaS

Architettura iniziale dell’Applicazione

L’architettura della nostra applicazione si divide principalmente in due sezioni: I Web Services che contengono la nostra logica applicativa, e una serie di software di terze parti come MongoDB (un DataBase non relazionale), RabbitMQ (una coda dati) e un’implementazione di un Network File System (un FileSystem distribuito).

Dopo aver analizzato e replicato l’installazione della nostra applicazione, abbiamo deciso di sostituire i componenti che facevano parte della seconda categoria con servizi PaaS.

Migrazione da NFS ad AWS EFS

Per quanto riguarda il Network FileSystem, è stata effettuata una migrazione verso AWS Elastic FileSystem (EFS).
EFS è un filesystem che scala automaticamente e offre un metodo di pagamento basato sull’utilizzo. Questo ci permette di risolvere i nostri problemi di scalabilità e ridurre a zero lo spreco di risorse.

Nell’immagine precedente si può vedere il cambio di architettura dovuto alla migrazione ad EFS: si passa da un singolo Pod che funziona da NFS-server, diventando un central point of failure, a una serie di mount presenti in ogni nodo del cluster Kubernetes che garantiscono l’accesso in locale al filesystem da parte di ogni Pod applicativo.

Migrazione da RabbitMQ ad AmazonMQ

RabbitMQ, un software usato per la gestione di code dati, è stato sostituito dal PaaS AWS AmazonMQ.
La sostituzione ha permesso di esternalizzare l’infrastruttura di RabbitMQ, risolvendo problemi di scalabilità, manutenzione e aggiornamento del software.

Per connettere la nuova istanza di AmazonMQ alle applicazioni interne al cluster, è stato utilizzato un Service Kubernetes, che ci permette di manipolare il networking interno al cluster per avere un DNS che punta all’endpoint di AmazonMQ

Migrazione da MongoDB ad Atlas MongoDB

L’ultima sostituzione riguarda MongoDB, che è stato sostituito con Atlas MongoDB.
Precedentemente alla migrazione, veniva inoltre usato un servizio di monitoraggio e backup di MongoDB chiamato MongoDB Cloud Manager. La sostituzione ha permesso di esternalizzare la gestione dell’infrastruttura di MongoDB, e di ottenere monitoring e backup dallo stesso servizio PaaS, riducendo i costi e la complessità dell’infrastruttura.

Anche qui, come per AmazonMQ, è stato utilizzato un Service Kubernetes per gestire la connessione al PaaS Atlas MongoDB.

Architettura finale dell’Applicazione

Dopo la migrazione, l’architettura della nostra applicazione risulta molto simile, ma con una grande differenza: tutti i servizi non proprietari e quindi non applicativi sono stati esternalizzati dal cluster Kubernetes, lasciandoci quindi più tempo e risorse per concentrarci sullo sviluppo delle nostre applicazioni, senza doverci preoccupare della manutenzione e aggiornamenti di software di terze parti.

Per vedere la registrazione dello speech di questo intervento, CLICCA QUI.