In this article, I would like to discuss how we changed our approach to orchestration in our startup project, why we did it, and what challenges we faced along the way. While this article may not claim uniqueness, I believe it can be useful to some, as we gathered material during the problem-solving process with considerable effort.
What did we have and what is this all about? We had a startup project with approximately two years of development history in the advertisement field. The project was originally designed as microservices, with the server side written in Symfony, along with some parts in Laravel, Django, and native NodeJs. The services mainly consist of APIs for three mobile clients (which are part of the project) and our own SDK for iOS (integrated into our customers' applications), as well as web interfaces and various dashboards for these customers. All services were initially containerized and operated under docker-compose.
However, docker-compose was not used everywhere, only in the local environment of developers, testing server and within the pipeline during the building and testing of services. In the production environment, we used Google Kubernetes Engine (GKE). Notably, we set up GKE at the beginning of the project entirely through its web interface, which was quite quick and, as we thought at the time, convenient. The only automated process was the building of docker images for launching services in GKE.
