Scenario
Quando si parla di innovazione in termini di sviluppo applicazioni e modalità di rilascio, negli ultimi anni l’approccio a microservizi è quello che sta andando per la maggiore. Tale approccio, infatti, si differenzia dal quello tradizionalmente usato ossia quello monolitico. L’approccio monolitico prevede che tutte le librerie usate e i vari componenti di un’applicazione siano generalmente compilati in un unico eseguibile che poi viene opportunamente distribuito su macchine tradizionalmente fisiche.
L’approccio a microservizi invece prevede che le varie parti che compongono un’applicazione siano separate tra loro e interconnesse per garantire: flessibilità, eseguibili leggeri e resilienza. In questo caso, i vari microservizi sono distribuiti su macchine virtuali o Docker Container.
Ogni microservizio ha vita propria ed è sviluppato per interagire con gli altri e permettere il funzionamento complessivo dell’applicazione. Nel caso in cui un microservizio sviluppato su macchine virtuali o Container abbia degli errori o interrompa la sua esecuzione, è necessario intervenire manualmente. Kubernetes è un servizio che permette di controllare il ciclo di vita dei microservizi in maniera automatizzata e semplificata.
Ogni microservizio in Kubernetes è rappresentato tipicamente da un Pod che esegue al suo interno uno o più Docker Container. La strategia di Kubernetes è quella di riavviare i Pod nel caso in cui l’esecuzione di questi si interrompa, quindi questi devono essere pensati come dei servizi stateless. Anche la componente database (siano essi MySQL, Postgres, etc.) è governata attraverso un microservizio e quindi un Pod, però un database è per definizione un processo stateful, quindi in caso di riavvio del Pod che lo esegue, si perderebbero tutti i dati che questo possedeva, al meno di politiche di backup e restore che comunque possono non soddisfare i requisiti necessari al corretto funzionamento applicativo.
Nel caso di un’architettura MySQL InnoDB sarebbero introdotte diverse complessità nella manutenzione, update e amministrazione dell’applicazione. Un esempio è la necessità di controllare la sequenza di attivazione e spegnimento dei nodi. Si conclude quindi che gestire tali attività attraverso il solo paradigma Kubernetes diventa una pratica troppo complessa da sostenere.