Olá, Habr! Apresento a sua atenção tradução do autor do artigo .
Numa altura em que o mundo da TI está gradualmente a evoluir para microsserviços e ferramentas como Kubernetes, apenas um problema se torna cada vez mais perceptível. Este problema - versões de microsserviços. Ainda assim, a comunidade de TI acredita que a situação actual é muito melhor do que geração anterior de tecnologia. No entanto, o versionamento de microsserviços é um problema muito complexo. Uma prova disso podem ser artigos como .
Se você ainda não entendeu o problema lendo este texto, deixe-me explicar. Digamos que seu produto consista em 10 microsserviços. Agora vamos supor que 1 nova versão seja lançada para cada um desses microsserviços. Apenas uma versão - espero que todos concordemos que este é um fato muito trivial e insignificante. Agora, porém, vamos dar outra olhada em nosso produto. Com apenas uma nova versão de cada componente, temos agora 1^2 - ou 10 permutações de como nosso produto pode ser composto.
Se ainda houver algum mal-entendido, deixe-me analisar a matemática. Portanto temos 10 microsserviços, cada um recebendo uma atualização. Ou seja, obtemos 2 versões possíveis para cada microsserviço (antiga ou nova). Agora, para cada um dos componentes do produto, podemos usar qualquer uma dessas duas versões. Matematicamente, é o mesmo que se tivéssemos um número binário de 10 dígitos. Por exemplo, digamos que 1 é a nova versão e 0 é a versão antiga - então uma permutação possível pode ser denotada como 1001000000 - onde o primeiro e o quarto componentes são atualizados e todos os outros não. Pela matemática sabemos que um número binário de 1 dígitos pode ter 4^10 ou 2 valores. Ou seja, confirmamos a escala do número com que estamos lidando.
Vamos continuar nosso raciocínio - o que acontecerá se tivermos 100 microsserviços e cada um tiver 10 versões possíveis? A situação toda se torna bastante desagradável - agora temos 10^100 permutações - o que é um número enorme. No entanto, prefiro rotular esta situação desta forma, porque agora já não nos escondemos atrás de palavras como “kubernetes”, mas sim enfrentamos o problema tal como ele é.
Por que estou tão fascinado por esse problema? Em parte porque, tendo trabalhado anteriormente no mundo da PNL e da IA, discutimos muito o problema da explosão combinatória há cerca de 5 a 6 anos. Só que em vez de versões tínhamos palavras individuais e em vez de produtos tínhamos frases e parágrafos. E embora os problemas da PNL e da IA permaneçam em grande parte sem solução, deve-se admitir que foram feitos progressos significativos nos últimos anos. (na minha opinião, poderiam ser feitos progressosоSeria melhor se as pessoas da indústria prestassem um pouco menos de atenção ao aprendizado de máquina e um pouco mais a outras técnicas - mas isso já está fora de questão).
Voltemos ao mundo do DevOps e dos microsserviços. Estamos diante de um grande problema, disfarçado de elefante na Kunstkamera - porque o que ouço com frequência é “basta pegar os kubernetes e o leme e tudo ficará bem!” Mas não, nem tudo ficará bem se ficar tudo como está. Além disso, uma solução analítica para este problema não parece aceitável devido à sua complexidade. Tal como na PNL, deveríamos primeiro abordar este problema estreitando o âmbito da pesquisa – neste caso, eliminando permutações desatualizadas.
Uma das coisas que pode ajudar é algo que escrevi no ano passado . Também é importante observar que um processo CI/CD bem projetado ajuda muito na redução da variação. No entanto, a situação atual com CI/CD não é boa o suficiente para resolver o problema das permutações sem ferramentas adicionais para contabilizar e rastrear componentes.
O que precisamos é de um sistema de experimentação na fase de integração, onde possamos determinar o fator de risco de cada componente, e também de um processo automatizado de atualização de vários componentes e testes sem intervenção do operador - para ver o que funciona e o que não funciona.
Esse sistema de experimentos poderia ser assim:
- Os desenvolvedores escrevem testes (esta é uma etapa crítica - porque caso contrário não temos critério de avaliação - é como rotular dados em aprendizado de máquina).
- Cada componente (projeto) recebe seu próprio sistema de CI - este processo está agora bem desenvolvido e a questão de criar um sistema de CI para um único componente foi amplamente resolvida
- O “sistema de integração inteligente” coleta os resultados de vários sistemas de CI e reúne projetos de componentes no produto final, executa testes e finalmente calcula o caminho mais curto para obter a funcionalidade desejada do produto com base nos componentes existentes e nos fatores de risco. Caso uma atualização não seja possível, este sistema notifica os desenvolvedores sobre os componentes existentes e quais deles estão causando o erro. Mais uma vez, o sistema de testes é de fundamental importância aqui – uma vez que o sistema de integração utiliza testes como critério de avaliação.
- Sistema CD, que então recebe os dados do Smart Integration System e realiza a atualização diretamente. Esta etapa encerra o ciclo.
Resumindo, para mim um dos maiores problemas agora é a falta de um “Sistema de Integração Inteligente” que ligue os vários componentes num produto e assim permita acompanhar como o produto como um todo é montado. Estarei interessado na opinião da comunidade sobre isso (spoiler - atualmente estou trabalhando em um projeto , que pode se tornar um sistema de integração muito inteligente).
Uma última coisa que quero mencionar é que, para mim, um monólito não é aceitável para nenhum projeto, mesmo de tamanho médio. Para mim, as tentativas de acelerar o tempo de implementação e a qualidade do desenvolvimento retornando a um monólito causam grande ceticismo. Em primeiro lugar, um monólito tem um problema semelhante de gerenciamento de componentes - entre as diversas bibliotecas que o compõem, porém, tudo isso não é tão perceptível e se manifesta principalmente no tempo gasto pelos desenvolvedores. A consequência do problema do monólito é a impossibilidade virtual de fazer alterações no código - e uma velocidade de desenvolvimento extremamente lenta.
Os microsserviços melhoram a situação, mas a arquitetura de microsserviços enfrenta o problema da explosão combinatória no estágio de integração. Sim, em geral, transferimos o mesmo problema da fase de desenvolvimento para a fase de integração. Porém, na minha opinião, a abordagem de microsserviços ainda leva a melhores resultados, e as equipes alcançam resultados mais rapidamente (provavelmente principalmente devido à redução no tamanho da unidade de desenvolvimento - ou tamanho do batch). No entanto, a mudança do monólito para os microsserviços ainda não trouxe melhorias suficientes ao processo - a explosão combinatória de versões de microsserviços é um enorme problema e temos muito potencial para melhorar a situação à medida que a resolvemos.
Fonte: habr.com