Neste artigo, gostaria de falar sobre como mudamos a abordagem de orquestração em nosso projeto de inicialização, por que fizemos isso e quais problemas resolvemos ao longo do caminho. Este artigo dificilmente pode ser considerado único, mas ainda assim acho que pode ser útil para alguém, pois no processo de solução do problema o material foi recolhido por nós com um rangido decente.
O que tínhamos e do que estamos falando? E tínhamos um projeto de start-up com aproximadamente 2 anos de história de desenvolvimento na área publicitária. O projeto foi originalmente construído como um microsserviço, e sua parte do servidor foi escrita em Symfony + um pouco de Laravel, Django e NodeJs nativos. Os serviços são basicamente uma API para clientes mobile (são 3 no projeto) e nosso próprio SDK para IOS (embutido nos aplicativos de nossos clientes), além de interfaces web e diversos dashboards desses mesmos clientes. Todos os serviços foram inicialmente dockerizados e executados pelo docker-compose.
É verdade que o docker-compose não foi usado em todos os lugares, mas apenas no ambiente local dos desenvolvedores, nos testes. servidor e dentro do pipeline durante a construção e teste de serviços. No ambiente de produção, utilizamos o Google Kubernetes Engine (GKE). Além disso, configuramos o GKE inteiramente por meio de sua interface web no início do projeto, o que foi bastante rápido e, como pensávamos na época, conveniente. O único processo automatizado foi a criação de imagens Docker para executar os serviços no GKE.
