Falácia da composição (por que fazer deploy em produção é tão difícil)

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Uma das regras fundamentais para que o DevOps funcione bem na entrega de software é “testar desde cedo e com frequência”. De fato, parte do domínio de CI/CD (Integração Contínua/Entrega Contínua) envolve a geração de builds e a realização de testes automatizados nesses builds. Não apenas em componentes individuais, mas em toda a aplicação.

O Desenvolvimento Orientado a Testes (TDD) é um dos métodos; outro consiste simplesmente em integrar os testes unitários e de sistema ao próprio processo de compilação e lançamento. Os testes funcionais e de regressão são indispensáveis e, em ambientes altamente ágeis, muitas vezes são acionados por um simples “commit” no repositório.

Assim, espera-se que, quando o software for “entregue” às pessoas responsáveis por sua implantação no ambiente de produção, haja um alto grau de confiança de que ele esteja pronto.

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

O muro por cima do qual o software é entregue ao ambiente de produção (e não se engane: esse muro ainda existe) é onde frequentemente esbarramos no que a filosofia chama de “falácia da composição”. Essa falácia lógica costuma ser aplicada a argumentos e provas, mas, curiosamente, é o software que serve de base para uma explicação simples desse “mau argumento”, apresentada pelo autor Ali Almossawi em O Livro dos Maus Argumentos (que recomendo enfaticamente a aspirantes a filósofos e campeões de debates de todas as idades):

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

Cada módulo deste sistema de software foi submetido a um conjunto de testes unitários e passou em todos eles. Portanto, quando os módulos forem integrados, o sistema de software não violará nenhuma das invariantes verificadas por esses testes unitários. Na realidade, a integração de partes individuais introduz novas complexidades em um sistema devido a dependências que, por sua vez, podem criar outras possibilidades de falha. -- https://bookofbadarguments.com/ p. 46

Agora, na etapa final do processo de CI/CD, o software não está necessariamente sujeito 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, assim que entra em produção, voltamos à estaca três. Não podemos presumir, com base nesses testes, que o sistema continuará funcionando conforme o esperado. Isso porque a definição da aplicação acaba de mudar, passando a abranger não apenas seu software e suas plataformas, mas também os componentes de rede e de serviços de aplicação necessários para fazê-la funcionar, por assim dizer, e entregá-la às telas de consumidores e usuários corporativos ávidos.

A rede e os serviços de aplicativos afetam o caminho de dados que as solicitações e respostas precisam percorrer. Muitos desses serviços, embora não todos, podem de fato modificar essas solicitações e respostas de maneiras que os desenvolvedores não previram. Portanto, é possível (e muitas vezes provável) que, uma vez no ambiente de produção — mesmo que cada serviço e componente do aplicativo tenha sido rigorosamente testado —, o aplicativo apresente uma falha. Um erro. Cometa um engano.

Isso ocorre porque caímos na falácia da composição no ambiente de produção. Embora os desenvolvedores de aplicativos (e as equipes de DevOps) compreendam essa falácia e a abordem nos testes de pré-produção, ainda deixamos muitas vezes de reconhecer que a integração na camada de rede continua sendo uma integração e pode, de fato, afetar a integridade operacional do sistema como um todo.

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

Só que não vamos fazer isso, e tanto eu quanto você sabemos disso. Isso porque o ambiente de produção é compartilhado, e testes rigorosos nesse ambiente aumentam o risco de danos colaterais a recursos e sistemas compartilhados, o que pode causar indisponibilidades. Indisponibilidades significam menos lucros e produtividade, e ninguém quer ser responsabilizado por isso. É muito mais fácil realizar em produção os testes individuais que forem possíveis e, depois, culpar os desenvolvedores quando algo quebrar ou não funcionar como prometido.

Em última análise, esse é um dos fatores silenciosos que impulsionam a revolução do software que está tomando conta das redes de produção. Antigamente, era muito difícil e caro replicar e manter um ambiente de testes que correspondesse ao ambiente de produção. Parte dessa infraestrutura compartilhada é cara e ocupa muito espaço. Duplicar essa rede não é sensato nem do ponto de vista financeiro nem operacional.

Mas a introdução e a posterior adoção de software, graças à computação em nuvem e à virtualização, começaram a destacar a ideia de que a replicação de redes baseadas em software não só é acessível, como também é mais fácil graças a conceitos como infraestrutura como código. Além disso, é possível replicá-la, realizar testes nela e desativá-la — o que significa que os recursos também podem ser reutilizados para fazer o mesmo com outras aplicações.

Ainda não chegamos lá, mas estamos cada vez mais perto. A integração de serviços virtuais (baseados em software) de rede e de aplicações ao pipeline de CI/CD é, na verdade, muito mais concreta do que alguns imaginam. Serviços tradicionalmente baseados em infraestrutura (de rede) — balanceamento de carga, roteamento de aplicações e segurança de aplicações web — estão sendo amplamente integrados ao ciclo de desenvolvimento de software graças à sua incorporação em ambientes como arquiteturas baseadas em contêineres. Por serem soluções baseadas em software, elas podem ser incluídas pelo menos na fase de testes do processo de build, aumentando assim a confiança de que a implantação em produção não introduzirá falhas ou erros.

Com base nesse software, a aplicação do conceito de “infraestrutura como código” vai ainda mais longe. Quando políticas e configurações podem ser elaboradas e ajustadas durante os ciclos de compilação e lançamento e, em seguida, implantadas em produção com poucas ou nenhuma alteração, estamos definitivamente mais perto de eliminar as falácias de composição existentes no ambiente de produção.

Quanto mais esses serviços — os mais centrados em aplicações entre os serviços de aplicações — forem integrados à fase de testes de CI/CD, maior será a confiança de todos no sucesso da implantação em produção.

Porque outra falácia que existe hoje é a de que testar em “produção” significa testar os “sistemas de produção”. Muitas vezes, isso não inclui os serviços de aplicativos que compõem o caminho dos dados em produção. É preciso incluí-los para que possamos reduzir os erros àqueles realmente incomuns e, de fato, ter tempo e recursos para resolvê-los.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie