In questo articolo vorrei raccontare come abbiamo cambiato il nostro approccio all'orchestrazione nel nostro progetto startup, perché lo abbiamo fatto e quali problemi abbiamo affrontato lungo il percorso. Questa non è una pretesa di originalità, ma penso comunque che possa essere utile a qualcuno, dato che durante il processo di risoluzione del problema abbiamo raccolto materiale con un buon impegno.
Cosa avevamo e di cosa si parla? Avevamo un progetto startup con circa 2 anni di storia di sviluppo nel settore della pubblicità. Il progetto era stato inizialmente concepito come un microservizio, e la parte server è stata scritta utilizzando Symfony, oltre a un po' di Laravel, Django e NodeJs nativo. I servizi consistono principalmente in API per i clienti mobili (che sono 3 nel progetto) e nel nostro SDK per iOS (integrato nelle applicazioni dei nostri clienti), oltre a interfacce web e vari dashboard per questi stessi clienti. Tutti i servizi sono stati inizialmente containerizzati con Docker e operavano sotto la gestione di docker-compose.
Tuttavia, docker-compose non era usato ovunque, ma solo nell'ambiente locale degli sviluppatori, nei test. server e all'interno del pipeline durante la costruzione e il test dei servizi. Nello ambiente di produzione abbiamo utilizzato Google Kubernetes Engine (GKE). La configurazione di GKE all'inizio del progetto è stata effettuata interamente attraverso la sua interfaccia web, il che è stato abbastanza veloce e, come ci è sembrato allora, comodo. Solo il processo di costruzione delle immagini Docker per l'avvio dei servizi in GKE è stato automatizzato.
