Microsserviços - explosão combinatória de versões

Olá Habr! Apresento a você a tradução do artigo Microservices - Explosão Combinatória de Versões .

Numa época em que o mundo da TI está gradualmente migrando para microsserviços e ferramentas como o Kubernetes, apenas um problema está se tornando mais perceptível. Esse problema é uma explosão combinatória de versões de microsserviço. No entanto, a comunidade de TI acredita que a situação atual é muito melhor do que o inferno das Dependências da geração anterior de tecnologias. No entanto, o controle de versão dos microsserviços é um problema muito complexo. Uma das provas disso pode ser encontrada em artigos como "Devolva meu monólito para mim" .

Se você está lendo este texto e ainda não entende o problema, deixe-me explicar. Suponha que seu produto consiste em 10 microsserviços. Agora, suponha que para cada um desses microsserviços 1 nova versão seja lançada. Somente a versão 1 - espero que todos concordemos que esse é um fato muito trivial e insignificante. Agora, no entanto, dê uma olhada no nosso produto novamente. Com apenas uma nova versão de cada componente, agora temos 2 ^ 10 - ou 1024 permutações de como nosso produto pode ser composto.

Se ainda houver algum mal-entendido, deixe-me expandir a matemática. Portanto, temos 10 microsserviços, cada um recebe uma atualização. Ou seja, obtemos 2 versões possíveis para cada microsserviço (antigo ou novo). Agora, para cada um dos componentes do produto, podemos usar uma dessas duas versões. Matematicamente, é o mesmo que se tivéssemos um número binário de 10 caracteres. Por exemplo, digamos que 1 seja a nova versão e 0 seja a versão antiga - então uma permutação possível pode ser designada como 1001000000 - onde o 1º e o 4º componentes são atualizados, mas o restante não. Da matemática, sabemos que um número binário de 10 caracteres pode ter 2 ^ 10 ou 1024 valores. Ou seja, confirmamos a escala do número com o qual está lidando.

Continuamos a discussão - e o que acontece se tivermos 100 microsserviços e cada um tiver 10 versões possíveis? Toda a situação está se tornando muito desagradável - agora temos 10 ^ 100 permutações - e esse é um número enorme. No entanto, prefiro descrever essa situação assim, porque agora não estamos nos escondendo atrás de palavras como “kubernetes”, mas estamos enfrentando o problema como ele é.

Por que esse problema é tão fascinante para mim? Em parte porque, trabalhando anteriormente no mundo da PNL e da IA, discutimos muito do problema de explosão combinatória há cerca de 5 a 6 anos. Somente em vez de versões, tínhamos palavras separadas e, em vez de produtos, tínhamos sentenças e parágrafos. Embora os problemas da PNL e da IA ​​permaneçam em grande parte por resolver, devemos admitir que houve um progresso significativo nos últimos anos.(na minha opinião, o progresso poderia ser usado para diminuir se as pessoas da indústria prestassem um pouco menos de atenção ao aprendizado de máquina e outras técnicas um pouco mais - mas isso não é o tópico).

Voltarei ao mundo de DevOps e microsserviços. Estamos diante de um enorme problema, disfarçado de elefante na Kunstkamera - porque o que ouço com frequência é "apenas pegue kubernetes e leme, e tudo ficará bem!" Mas não, tudo não ficará bem se tudo for deixado como está. Além disso, uma solução analítica para esse problema não parece aceitável em vista da complexidade. Como na PNL, devemos primeiro abordar esse problema restringindo o escopo da pesquisa - nesse caso, eliminando permutações obsoletas.

Uma das coisas que pode ajudar - escrevi no ano passadosobre a necessidade de manter um spread mínimo entre as versões estabelecidas para os clientes . Também é importante observar que um processo de CI / CD bem desenvolvido é muito útil na redução de variações. No entanto, o estado atual das coisas com CI / CD não é bom o suficiente para resolver o problema de permutação sem ferramentas adicionais para registrar e rastrear componentes.

O que precisamos é de um sistema de experimentos no estágio de integração, onde possamos determinar o fator de risco para cada componente e também ter um processo automatizado para atualizar vários componentes e testes sem a intervenção do operador - para ver o que funciona e o que não funciona.

Esse sistema de experimentos poderia ser assim:

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

Resumindo, para mim, um dos maiores problemas agora é a falta de um "Sistema de Integração Inteligente" que vincule os vários componentes ao produto e, assim, permita que você acompanhe como o produto como um todo é composto. Estarei interessado nos pensamentos da comunidade sobre isso (spoiler - atualmente estou trabalhando no projeto Reliza , que pode se tornar um sistema de integração inteligente).

Uma última coisa que quero mencionar é que, para mim, um monólito não é aceitável para qualquer projeto de tamanho mínimo. Para mim, há um grande ceticismo em relação às tentativas de acelerar o tempo de implementação e a qualidade do desenvolvimento, retornando ao monólito. Em primeiro lugar, o monólito tem um problema semelhante de gerenciamento de componentes - entre as várias bibliotecas em que consiste, mas tudo isso não é tão perceptível e se manifesta principalmente no tempo que os desenvolvedores gastam. A consequência do problema do monólito é o fato de que é impossível fazer alterações no código - e a velocidade de desenvolvimento é extremamente lenta.

Os microsserviços melhoram a situação, mas a arquitetura dos microsserviços enfrenta o problema de uma explosão combinatória no estágio de integração. Sim, em geral, mudamos o mesmo problema - do estágio de desenvolvimento para o estágio de integração. No entanto, na minha opinião, a abordagem de microsserviço 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 no tamanho do lote ). No entanto, a transição do monólito para microsserviços ainda não proporcionou uma melhoria suficiente do processo - a explosão combinatória de versões de microsserviços é um grande problema e temos grande potencial para melhorar a situação à medida que ela é resolvida.