Il primo passo nel cammino di spostare le applicazioni monolitiche di Kubernetes
Feb 2, 2018 · 4 min leggere
In tutta la mia carriera di ingegneria del software, una delle più importanti domande che ho imparato a chiedere ad un collega è “che Cosa significa $qualcosa significa per te?”. Costringe l’altro ingegnere a valutare le implicazioni dell’uso di una determinata parola. Seguendo le prime applicazioni monolitiche in movimento alla chiamata Kubernetes, volevo passare alcuni minuti a parlare di cosa sia un’applicazione monolitica. O almeno, cosa significa per me.
Questo è uno spazio interessante che ha bisogno di una certa attenzione. Mentre il funzionamento di un microservizio stateless su Kubernetes è relativamente semplice, il funzionamento di una grande applicazione stateful ha ancora molta strada da fare. Capire cos’è un’applicazione monolitica sarà il primo passo per semplificare il processo di migrazione.
Per definire un’applicazione monolitica dobbiamo prima comprendere i componenti di un’applicazione a cui teniamo. I tre componenti che ci interessano saranno l’interfaccia utente, il livello di accesso ai dati e l’archivio dati.
L’interfaccia utente è il punto di ingresso dell’applicazione ed è anche il punto del programma con cui un utente interagirà. Questa potrebbe essere una funzione main (), un sito web, un servizio web o vari altri punti di ingresso.
Il livello di accesso ai dati è il livello del programma che avvolgerà un archivio dati. In genere il livello di accesso ai dati gestirà problemi come l’autenticazione con un archivio dati e la sanificazione dei dati prima che vengano persistiti nell’archivio dati.
L’archivio dati è la parte più fondamentale del sistema ed è responsabile della memorizzazione di informazioni arbitrarie (dati) e del recupero. Questo componente è comunemente solo un database.
Questi tre componenti costituiscono un tipo molto comune di applicazione chiamata applicazione stateful. Il che significa che l’applicazione memorizza e manipola i dati nel tempo. Quindi diciamo che l’applicazione ha stato. Ancora più importante, che lo stato dell’applicazione può cambiare nel tempo.
Nel caso di un’applicazione monolitica, osserviamo comunemente più strati dell’applicazione strettamente accoppiati tra loro. Nell’esempio seguente possiamo vedere che l’interfaccia utente e il livello di accesso ai dati sono raggruppati insieme. Questo di solito viene fatto tramite un repository di codice di grandi dimensioni, ed entrambi questi livelli probabilmente dipenderanno dall’altro per essere in atto per l’esecuzione. Inoltre l’interfaccia utente e i livelli di accesso ai dati in genere sono raggruppati nello stesso processo in fase di runtime. Significa che comunicano sullo stesso sistema, utilizzando le risorse di sistema (memoria e cicli di calcolo) per interagire con altre parti del sistema.
al contrario, un microservice applicazione sarebbe composta di piccoli componenti modulari che possono essere facilmente scambiati. Questo offre un concetto di componibilità per un operatore ed è un segno che si sta lavorando con microservizi invece di un’applicazione monolitica. L’esempio seguente illustra un’applicazione flessibile e modulare. Si noti che in questo modello possiamo eseguire i componenti più piccoli in modo indipendente e utilizzare una rete per collegare il nostro sistema insieme. Questo approccio è molto più scalabile.
Quindi cos’è un’applicazione monolitica? È un’applicazione software a livello singolo in cui l’interfaccia utente e il codice di accesso ai dati sono combinati in un unico programma su un’unica piattaforma. È anche un’applicazione che esegue più componenti nello stesso processo, sullo stesso sistema.
Andando avanti cerchiamo di capire le sfumature della migrazione di applicazioni monolitiche a Kubernetes e speriamo che questo sia un primo passo prezioso nel nostro viaggio. Poiché il processo è relativamente privo di documenti, abbiamo in programma di condividere le lezioni apprese, in modo che tutti possano trarne beneficio.
