I denne artikel vil jeg gerne fortælle om, hvordan vi ændrede tilgangen til orkestrering på vores startup-projekt, hvorfor vi gjorde det, og hvilke problemer vi løste undervejs. Denne artikel kan næppe hævde at være unik, men alligevel tror jeg, at den kan være nyttig for nogen, da materialet i processen med at løse problemet blev indsamlet af os med en anstændig knirken.
Hvad havde vi, og hvad taler vi om? Og vi havde et opstartsprojekt med en cirka 2-årig udviklingshistorie fra annonceområdet. Projektet blev oprindeligt bygget som en mikroservice, og dets serverdel blev skrevet i Symfony + lidt Laravel, Django og native NodeJs. Tjenesterne er grundlæggende et API til mobile klienter (der er 3 af dem i projektet) og vores eget SDK til IOS (indbygget i vores kunders applikationer), samt webgrænseflader og forskellige dashboards for de samme kunder. Alle tjenester blev oprindeligt dockeriseret og drevet af docker-compose.
Sandt nok blev docker-compose ikke brugt overalt, men kun i det lokale miljø af udviklere, på testserveren og inde i pipelinen, når man byggede og testede tjenester. Men i produktionsmiljøet blev Google Kubernetes Engine (GKE) brugt. Desuden lavede vi GKE-konfigurationen i starten af projektet fuldstændigt gennem dens webgrænseflade, som var ret hurtig og, som det så ud for os dengang, praktisk. Kun processen med at bygge docker-billeder til at køre tjenester i GKE blev automatiseret her.