Oito razões pelas quais o futuro do escalonamento de contêineres está no service mesh

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

Os microsserviços são ótimos para acelerar o desenvolvimento, mas a complexidade dessas arquiteturas está na comunicação entre os serviços da qual eles dependem.

Neste momento, existem pelo menos três opções de arquitetura diferentes para escalar microsserviços em contêineres. Cada uma se baseia — como toda escalabilidade — em um balanceador de carga baseado em proxy. Cada uma apresenta seu próprio conjunto de desafios. Vários deles decorrem do simples fato de que a escalabilidade em ambientes de contêineres costuma depender de tabelas de IP e da capacidade limitada delas de lidar com qualquer elemento acima das camadas de rede tradicionais (ou seja, IP e TCP).

Todos esses proxies oferecem a mesma funcionalidade principal: dimensionar os serviços distribuídos por todo o ambiente de contêineres. O curioso é que os serviços são estruturas efêmeras. Na verdade, eles não existem — exceto nos arquivos de recursos (configuração) que os definem. O problema para as soluções de dimensionamento baseadas em tabelas de IP é que esses serviços são estruturas da camada 7 (HTTP), muitas vezes atuando como o “backend” de uma única chamada de API, em vez de uma aplicação inteira.

Os aplicativos, como os conhecemos, podem parecer, do ponto de vista do cliente, uma estrutura única e integrada. Na realidade, eles são compostos por muitos microsserviços diferentes (e distribuídos). Alguns desses serviços são exclusivamente internos, projetados para serem usados por outros serviços. Isso significa que há muita comunicação entre serviços dentro do ambiente conteinerizado.

Você precisa de roteamento L7 (HTTP) nesses ambientes, pois tudo funciona por meio de APIs sobre HTTP/HTTP2. Também é necessário adotar uma postura de segurança consistente, com autenticação e aplicação de políticas. Nada disso será possível com uma abordagem baseada em tabelas de IP.

Como geralmente acontece, o código aberto vem ao resgate. Várias malhas de serviço de código aberto surgiram para enfrentar esses desafios. Assim como ocorre com muitos projetos de código aberto, essas malhas de serviço (como Istio) estão sendo ampliadas por projetos como o Aspen Mesh com recursos (e suporte) que oferecem soluções de nível empresarial.

Esses esforços ampliados estão focados em solucionar os oito desafios que as organizações enfrentam ao implantar microsserviços em contêineres.

Estes são os oito desafios e como uma malha de serviços pode superá-los:

1. Build – Este é um dos desafios para os quais uma malha de serviços tem pouco a oferecer, além de integrar políticas às cadeias de ferramentas de CI/CD e garantir um modelo declarativo de configuração, para que a malha de serviços possa ser tratada como infraestrutura como código.
2. Teste e integração – Uma malha de serviços pode ajudar nesse aspecto, garantindo políticas consistentes entre os ambientes de desenvolvimento, teste, produção etc. Algumas organizações estão buscando eliminar completamente as implantações em etapas. Essa abordagem funcionou bem no passado, mas é um dos obstáculos que introduzem latência no processo de implantação. Essas organizações buscam uma forma de implantar serviços diretamente em produção e usar mecanismos de direcionamento de tráfego e reversão para lidar com falhas.
3. Versionamento – Uma malha de serviços pode atuar como um gateway de API básico para rotear o tráfego com base em variáveis como a versão da API e até mesmo converter versões para auxiliar durante os períodos de transição entre versões da API. Nem sempre é possível forçar a atualização dos clientes – especialmente no caso de aplicativos voltados ao consumidor –, o que significa que podem chegar solicitações para várias versões. Uma malha de serviços pode converter solicitações de versões mais antigas da API para a versão mais recente, ajudando a reduzir os custos e a sobrecarga de manter várias versões da mesma API.
4. Implantação – Com sua capacidade de se comunicar fluentemente via HTTP, uma malha de serviços é o lugar ideal para viabilizar implantações Blue/Green, testes canário e o direcionamento de tráfego.
5. Registro de logs – O registro distribuído de logs é sempre um desafio, ainda mais em ambientes nos quais as instâncias permanecem ativas por períodos de tempo muito variáveis. Uma malha de serviços oferece um local comum e centralizado para implementar o registro de logs, além da capacidade de executar funções como o rastreamento de requisições.
6. Monitoramento – O monitoramento está no cerne da escalabilidade. Embora as aplicações possam implementar determinadas funções (novas tentativas, circuit breaking etc.) para lidar com a inevitável falha de um serviço, isso impõe à aplicação uma responsabilidade que ela não deveria precisar assumir. Uma malha de serviços assume a responsabilidade pela comunicação entre serviços e oferece um ponto central para o monitoramento. O objetivo é concentrar-se no MTTD e no MTTR em produção, pois operar em produção é difícil e falhas são inevitáveis.
7. Depuração – Quanto mais complexo é um sistema, mais difícil é depurá-lo. Uma malha de serviços pode auxiliar na análise da causa raiz, fornecer estatísticas e notificações antes da ocorrência de falhas usando análises e telemetria, além de colocar contêineres em quarentena em vez de encerrá-los, para que possam ser examinados minuciosamente. Isso é particularmente útil nos casos em que a falha ocorre devido a vazamentos lentos de memória.
8. Rede – A rede continua sendo essencial para os contêineres, talvez ainda mais do que em ambientes menos complexos. O desejo de abstrair os serviços dessa rede significa que há muitos componentes dinâmicos que você não quer implementar em cada serviço: descoberta de serviços, gerenciamento de SSL e certificados, circuit breakers, novas tentativas, monitoramento de integridade etc. O objetivo dos microsserviços era “programar localmente, programar em pequena escala”. Introduzir a necessidade de incluir funções relacionadas à rede torna os microsserviços excessivamente complexos e gera dívidas arquitetônicas e técnicas adicionais. Uma malha de serviços assume essas funções e oferece a escalabilidade e a segurança desejadas sem prejudicar o desenvolvimento.

A malha de serviços é uma evolução empolgante que combina os princípios modernos da nuvem e dos contêineres com bases sólidas de escalabilidade. A expectativa é que a malha de serviços ganhe força à medida que, ao longo de 2018, aumentem a adoção de contêineres e a demanda por escalabilidade e suporte de nível empresarial.

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