A Aplicação do Paradoxo de Teseu

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

O estudo da filosofia, pelo menos no passado, envolvia fazer perguntas que, à primeira vista, parecem, bem, irrelevantes. Afinal, será mesmo tão importante saber se “um navio restaurado por meio da substituição de cada uma de suas peças de madeira” continua sendo o mesmo navio? Essa foi a pergunta feita por Plutarco em Vida de Teseu e que, posteriormente, ficou conhecida como o paradoxo de Teseu. Em termos mais gerais, ela questiona “se um objeto que teve todos os seus componentes substituídos continua sendo, fundamentalmente, o mesmo objeto”. (Navio de Teseu, Wikipédia)

Poderíamos fazer a mesma pergunta sobre os microsserviços que, quando aplicados a aplicações monolíticas existentes, buscam essencialmente restaurar a aplicação substituindo funções por serviços complementares. Por definição, as funções são pequenas (ou deveriam ser), daí o uso do termo “micro” para os serviços desacoplados resultantes. As diferenças entre as duas abordagens podem ser analisadas em termos de comunicação. Em uma aplicação monolítica, as funções são invocadas por meio da referência a um endereço específico na memória. Em uma aplicação baseada em microsserviços, as funções (serviços) são invocadas por meio da referência a um endereço IP específico na rede.

Conceitualmente, os dois são iguais, diferindo apenas no mecanismo de invocação dos componentes funcionais individuais. Um diagrama resultante mostraria essencialmente pouca diferença, exceto pelo fato de que a “caixa” do monólito é um único servidor, enquanto a “caixa” dos microsserviços é todo o data center. Um usa endereçamento local; o outro, endereçamento de rede. O código de cada uma dessas funções poderia ser exatamente o mesmo, assim como a madeira do navio de Teseu.

Mas suas funções de negócio permanecem consistentes e, de fato, se tivermos decomposto corretamente a aplicação, o usuário não deverá perceber nenhuma diferença entre as duas. Pode-se argumentar que, do ponto de vista do passageiro do navio de Teseu, não há diferença entre elas. E nem deveria haver.

Mas os filósofos tendem a se aprofundar mais e, assim como eles, nós também devemos fazê-lo, pois as diferenças entre uma aplicação monolítica e uma baseada em microsserviços são, de fato, bastante importantes para as operações.

O aumento da complexidade das operações de rede

Os microsserviços simplificam muitos aspectos do processo de desenvolvimento de aplicações, mas, ao fazer isso, geram uma grande complexidade operacional. O número de conexões de rede entre as diferentes partes de uma aplicação baseada em microsserviços necessariamente acarreta uma sobrecarga associada ao gerenciamento das diversas características de rede necessárias: endereços IP, VLANs, tabelas NAT e muito mais. A escalabilidade também se torna um desafio que até mesmo Dijkstra poderia considerar frustrante, pois o posicionamento dos microsserviços e do serviço de balanceamento de carga tem um impacto bastante significativo no desempenho, dependendo de quantos segmentos da rede precisam ser percorridos.

De repente, políticas adicionais se tornam necessárias, pois as políticas de segurança aplicáveis a um serviço que acessa diretamente uma fonte de dados confidenciais não são as mesmas necessárias para proteger outro serviço que gerencia preferências ou o estado da sessão. A rede resultante de microp políticas de segurança certamente oferece muitos dos mesmos benefícios que os próprios microsserviços, ou seja, um controle mais granular e uma espécie de simplicidade elegante, mas, ao mesmo tempo, torna-se um pesadelo operacional, pois as políticas precisam passar a acompanhar os serviços onde quer que eles surjam na arquitetura.

A implantação também se torna, de repente, exponencialmente mais difícil, como passar de uma simples dança de passos básicos para o flamenco, muito mais complexo, com muito mais passos e movimentos pelo salão de dança (data center). A orquestração e a automação tornam-se necessárias para garantir a consistência e a previsibilidade exigidas para colocar todas as peças no lugar certo, no momento certo.

Os responsáveis por fornecer esses serviços de rede e segurança para as aplicações precisam reconhecer que o navio não é o mesmo, independentemente do que possa parecer em uma visão panorâmica. Parece simples: uma aplicação é simplesmente substituída por dez serviços. Voilà! A aplicação foi recriada, assim como o navio de Teseu. Mas, do ponto de vista operacional, esse navio não é nem um pouco igual. As junções (integrações) do novo navio são completamente diferentes, o que pode alterar o atrito com o mar (a rede) e fazer com que o navio navegue mais lentamente.

Os microsserviços ainda são uma tecnologia emergente. Eles não estão dominando o mundo (ainda), mas é importante reconhecer que não se trata simplesmente de desmontar o navio de Teseu e reconstruí-lo. As equipes de operações de serviços de rede e segurança devem adotar a perspectiva do filósofo, e não a do passageiro (usuário), pois o impacto sobre a rede e a segurança é muito, muito diferente.

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