In diesem Artikel möchte ich darĂŒber sprechen, wie wir den Orchestrierungsansatz unseres Startup-Projekts geĂ€ndert haben, warum wir das getan haben und welche Probleme wir dabei gelöst haben. Dieser Artikel kann kaum den Anspruch erheben, einzigartig zu sein, aber ich denke dennoch, dass er fĂŒr jemanden nĂŒtzlich sein kann, da das Material im Prozess der Lösung des Problems von uns mit einem ordentlichen Knarren gesammelt wurde.
Was hatten wir und worĂŒber reden wir? Und wir hatten ein Start-up-Projekt mit einer etwa 2-jĂ€hrigen Entwicklungsgeschichte aus dem Werbebereich. Das Projekt wurde ursprĂŒnglich als Microservice erstellt und sein Serverteil wurde in Symfony + ein wenig Laravel, Django und nativen NodeJs geschrieben. Bei den Diensten handelt es sich im Wesentlichen um eine API fĂŒr mobile Clients (es gibt drei davon im Projekt) und unser eigenes SDK fĂŒr IOS (integriert in die Anwendungen unserer Kunden) sowie Webschnittstellen und verschiedene Dashboards dieser Kunden. Alle Dienste wurden ursprĂŒnglich dockerisiert und von Docker-Compose ausgefĂŒhrt.
Zwar wurde docker-compose nicht ĂŒberall verwendet, sondern nur in der lokalen Umgebung der Entwickler, im Test Server und innerhalb der Pipeline beim Erstellen und Testen von Diensten. In der Produktionsumgebung verwendeten wir Google Kubernetes Engine (GKE). DarĂŒber hinaus konfigurierten wir GKE zu Projektbeginn vollstĂ€ndig ĂŒber die WeboberflĂ€che, was recht schnell und, wie wir damals empfanden, komfortabel war. Der einzige automatisierte Prozess war das Erstellen von Docker-Images zum Starten der Dienste in GKE.
