Nesta artigo, gostaria de explicar como mudamos nossa abordagem à orquestração em nosso projeto de startup, por que fizemos isso e quais problemas enfrentamos no caminho. Embora essa artigo não possa reivindicar ser único, ainda assim acredito que pode ser útil para alguém, pois durante o processo de resolução do problema, coletamos materiais com bastante rigor.
O que tínhamos e sobre o que estamos falando? Tínhamos um projeto de startup com cerca de 2 anos de histórico de desenvolvimento na área de publicidade. O projeto foi inicialmente construído como um microserviço, e sua parte de servidor foi escrita em Symfony, com um pouco de Laravel, Django e NodeJs nativo. Os serviços consistem principalmente em APIs para clientes móveis (são 3 no projeto) e nosso próprio SDK para IOS (incorporado nos aplicativos de nossos clientes), além de interfaces web e vários dashboards para esses mesmos clientes. Todos os serviços foram inicialmente dockerizados e funcionavam sob o gerenciamento do docker-compose.
No entanto, o docker-compose não foi utilizado em toda parte, apenas no ambiente local dos desenvolvedores, em teste servidor e dentro do pipeline durante a construção e teste dos serviços. Já no ambiente de produção, utilizamos o Google Kubernetes Engine (GKE). Além disso, a configuração do GKE no início do projeto foi realizada totalmente através de sua interface web, o que foi bastante rápido e, na época, nos pareceu conveniente. O processo automatizado aqui foi apenas a construção de imagens docker para iniciar os serviços no GKE.
