Falácia da composição (por que a implantação na produção é tão difícil)

Uma das regras fundamentais que faz o DevOps funcionar bem para entregar software é “testar cedo, testar frequentemente”. De fato, parte do domínio CI/CD (Integração Contínua/Entrega Contínua) é o de compilações e testes automatizados dessas compilações. Não apenas de componentes individuais, mas de todo o aplicativo.

O Desenvolvimento Orientado a Testes (TDD) é um método; outro é simplesmente a integração de testes unitários e de sistema como parte do próprio processo de construção e lançamento. Testes funcionais e de regressão são essenciais e, em ambientes altamente ágeis, geralmente são acionados por um simples “commit” no repositório.

Portanto, seria de se esperar que, quando o software fosse “entregue” às mãos dos responsáveis pela implantação na produção, houvesse grande confiança em sua prontidão.

Claro que se houvesse, eu não estaria escrevendo este post, estaria?

O muro sobre o qual o software é entregue à produção (e não se engane, esse muro ainda existe) é onde frequentemente esbarramos no que é conhecido na filosofia como a “falácia da composição”. Essa falácia lógica é geralmente aplicada a argumentos e provas, mas curiosamente é o software que forma a base de uma explicação simples desse “mau argumento” pelo autor Ali Almossawi em The Book of Bad Arguments (que eu recomendo fortemente para filósofos iniciantes/campeões de debates de todas as idades):

Falácia informal, suposição injustificada, composição e divisão

Cada módulo neste sistema de software foi submetido a um conjunto de testes de unidade e passou em todos eles. Portanto, quando os módulos são integrados, o sistema de software não violará nenhuma das invariantes verificadas por esses testes unitários . A realidade é que a integração de partes individuais introduz novas complexidades a um sistema devido a dependências que podem, por sua vez, introduzir vias adicionais para falhas potenciais. -- https://bookofbadarguments.com/ p.46

Agora, no estágio final do processo de CI/CD, o software não está necessariamente propenso a essa falácia. Ele foi submetido não apenas a testes unitários, mas também a testes de integração dessas unidades para formar um “sistema” ou aplicativo completo.

No entanto, quando ele entra em produção, voltamos à estaca zero. Não podemos presumir que o sistema continuará a operar conforme o esperado com base nesses testes. Isso ocorre porque a definição do aplicativo mudou para abranger não apenas seu software e plataformas, mas também os componentes de rede e serviço de aplicativo necessários para fazer o aplicativo funcionar, por assim dizer, e entregá-lo às telas de consumidores ansiosos e usuários corporativos.

Os serviços de rede e de aplicativos afetam o caminho de dados ao longo do qual as solicitações e respostas devem percorrer . Muitos, mas não todos, desses serviços podem de fato modificar essas solicitações e respostas de maneiras que os desenvolvedores não previram. Assim, é possível (e muitas vezes provável) que, uma vez no ambiente de produção – mesmo que cada serviço individual e componente do aplicativo tenham sido rigorosamente testados – o aplicativo apresente uma falha. Um fracasso. Cometa um erro.

Isso ocorre porque caímos na falácia da composição no ambiente de produção. Embora os desenvolvedores de aplicativos (e DevOps) entendam essa falácia e a abordem em testes de pré-produção, muitas vezes ainda deixamos de reconhecer que a integração na camada de rede ainda é integração e pode, de fato, impactar a integridade operacional do todo.

A resposta parece óbvia: bem, então vamos testar em produção!

Só que não faremos isso, e você e eu sabemos que não faremos. Porque a produção é um ambiente compartilhado, e testes rigorosos em um ambiente de produção aumentam o risco de danos colaterais a recursos e sistemas compartilhados, o que pode causar interrupções. Interrupções significam menores lucros e produtividade, e ninguém quer ser responsável por isso. É muito mais fácil executar os testes individuais possíveis na produção e depois apontar o dedo para os desenvolvedores quando algo quebra ou não funciona como anunciado.

Este é, em última análise, um dos motores silenciosos da revolução do software que está devorando as redes de produção. Antigamente, era muito difícil e caro replicar e manter um ambiente de teste que correspondesse ao ambiente de produção. Parte dessa infraestrutura compartilhada é cara e ocupa muito espaço. Duplicar essa rede não é financeiramente nem operacionalmente sensato.

Mas a introdução e a subsequente adoção de software graças à computação em nuvem e à virtualização começaram a trazer à tona a noção de que a replicação de redes baseadas em software não é apenas acessível, mas mais fácil graças a conceitos como infraestrutura como código. Além disso, você pode replicá-lo, testá-lo e desmontá-lo, o que significa que os recursos podem ser reutilizados para fazer o mesmo em outros aplicativos também.

Ainda não chegamos lá, mas estamos chegando perto. A integração de serviços de rede e aplicativos virtuais (software) no pipeline de CI/CD é, na verdade, muito mais real do que alguns imaginam. Tradicionalmente, serviços baseados em infraestrutura (rede) – balanceamento de carga, roteamento de aplicativos, segurança de aplicativos da web – estão sendo altamente integrados ao ciclo de construção de software graças à sua integração em ambientes como arquiteturas baseadas em contêineres. Como soluções baseadas em software, elas podem ser incluídas pelo menos na fase de testes do processo de construção e, assim, aumentar a confiança de que a implantação na produção não introduzirá falhas ou erros.

Com base nesse software, a aplicação de “ infraestrutura como código ” vai ainda mais longe. Quando políticas e configurações podem ser projetadas e ajustadas durante os ciclos de construção e lançamento e, então, implantadas na produção com pouca ou nenhuma alteração, estamos definitivamente mais perto de eliminar as falácias de composição que existem na produção.

Quanto mais esses serviços — os mais centrados em aplicativos — forem integrados à fase de testes de CI/CD, mais confiança todos poderão ter em uma implantação de produção bem-sucedida.

Porque a outra falácia que existe hoje é que testar contra “produção” significa “sistemas de produção”. Ele geralmente não inclui os serviços de aplicativo que formam o caminho de dados na produção. É necessário, para que possamos reduzir os erros aos realmente esotéricos e realmente termos tempo e recursos para corrigi-los.