BLOG

A Aplicação do Paradoxo de Teseu

Miniatura de Lori MacVittie
Lori MacVittie
Publicado em 23 de maio de 2016
navio-teseu

O estudo da filosofia, pelo menos no passado, envolveu fazer perguntas que parecem, superficialmente, irrelevantes. Afinal, será que é tão importante saber “se um navio que foi restaurado com a substituição de todas as peças de madeira” continua sendo o mesmo navio? Essa é a pergunta que Plutarco fez em Vida de Teseu e depois ficou conhecido como paradoxo de Teseu. Em termos mais gerais, pergunta-se “se um objeto que teve todos os seus componentes substituídos continua fundamentalmente o mesmo objeto ”. ( Navio de Teseu, Wikipédia )

Poderíamos perguntar a mesma coisa sobre microsserviços que, quando aplicados a aplicativos monolíticos existentes, buscam essencialmente restaurar o aplicativo substituindo funções por serviços complementares. As funções são pequenas (ou deveriam ser) por design e, portanto, o termo “micro” é aplicado aos serviços resultantes e desacoplados. As diferenças entre os dois podem ser vistas em termos de comunicação. Em uma aplicação monolítica, funções são invocadas referenciando um endereço específico na memória. Em um aplicativo baseado em microsserviços, funções (serviços) são invocadas referenciando um endereço IP específico na rede.

microservices-paradoxo

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

Mas suas funções comerciais permanecem consistentes e, de fato, se tivermos decomposto o aplicativo corretamente, o usuário não verá nenhuma diferença perceptível entre os dois. Pode-se argumentar que, da perspectiva do passageiro do navio de Teseu, não há diferença entre os dois. Nem deveria haver.

Mas os filósofos tendem a ir mais fundo e, assim como eles, nós também devemos ir, porque a diferença entre um aplicativo monolítico e um baseado em microsserviços é, de fato, muito importante para as operações.

A complexificação das operações de rede

Os microsserviços simplificam muitos aspectos do processo de desenvolvimento de aplicativos, mas, ao fazer isso, criam uma grande complexidade operacional. O número de conexões de rede entre as diferentes partes de um aplicativo baseado em microsserviços necessariamente requer sobrecarga associada no 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 pode achar frustrante, pois o posicionamento dos microsserviços e do serviço de balanceamento de carga tem um impacto muito real no desempenho com base em quantos segmentos na rede devem ser percorridos.

Políticas adicionais são repentinamente 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 aquelas necessárias para proteger outro serviço que gerencia preferências ou estado de sessão. A rede resultante de políticas de microssegurança certamente fornece muitos dos mesmos benefícios dos próprios microsserviços, ou seja, controle mais refinado e um tipo de simplicidade elegante, mas ao mesmo tempo se torna um pesadelo operacional, pois as políticas precisam repentinamente se mover com os serviços, onde quer que eles apareçam na arquitetura.

A implantação também se torna exponencialmente mais difícil, como passar de uma simples dança de passos de caixa para o mais complicado Flamenco, com muito mais passos e muito mais movimento na pista de dança (data center). Orquestração e automação se tornam um requisito para garantir a consistência e a previsibilidade necessárias 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 aplicativos precisam reconhecer que o navio não é o mesmo, não importa qual seja a visão a cinquenta mil pés. Parece simples: um aplicativo é simplesmente substituído por dez serviços. Pronto! O aplicativo foi recriado, assim como o navio de Teseu. Mas da perspectiva operacional este navio não é nada parecido. As junções (integração) no novo navio são completamente diferentes, o que pode alterar o atrito criado contra o mar (rede) e tende a fazer com que o navio navegue mais lentamente.

Os microsserviços ainda são emergentes. Eles não estão dominando o mundo (ainda), mas é importante reconhecer que não é uma questão tão simples quanto demolir a nave de Teseu e reconstruí-la. As equipes de operações de serviços de rede e segurança devem adotar a visão do filósofo em vez da visão do passageiro (usuário), porque o impacto na rede e na segurança é muito, muito diferente.