In questo articolo vorrei parlare di come abbiamo cambiato l'approccio all'orchestrazione nel nostro progetto startup, perché lo abbiamo fatto e quali problemi abbiamo risolto lungo il cammino. Questa articolo difficilmente può vantare unicità, ma penso che possa essere utile a qualcuno, visto che durante il processo di risoluzione del problema abbiamo raccolto materiali con un certo scrupolo.
Cosa avevamo e di cosa si tratta? Avevamo un progetto startup con circa 2 anni di storia nello sviluppo nel settore della pubblicità. Inizialmente, il progetto è stato costruito come un microservizio, con la parte server scritta in Symfony + un po' di Laravel, Django e NodeJs nativo. I servizi consistono principalmente in API per clienti mobili (ce ne sono 3 nel progetto) e il nostro SDK per iOS (integrato nelle applicazioni dei nostri clienti), oltre a interfacce web e diversi cruscotti per questi stessi clienti. Tutti i servizi erano inizialmente dockerizzati e funzionavano sotto la gestione di docker-compose.
Tuttavia, docker-compose non è stato utilizzato ovunque, ma solo nell'ambiente locale degli sviluppatori, nel test server e all'interno della pipeline durante la costruzione e il testing dei servizi. Mentre nell'ambiente di produzione veniva utilizzato Google Kubernetes Engine (GKE). Inoltre, la configurazione di GKE all'inizio del progetto è stata effettuata interamente tramite la sua interfaccia web, il che è stato piuttosto veloce e, a quanto ci sembrava allora, comodo. Solo il processo di costruzione delle immagini docker per l'avvio dei servizi in GKE era automatizzato.
