Oito razões pelas quais o futuro dos contêineres de dimensionamento é o Service Mesh

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

Existem, atualmente, pelo menos três opções arquitetônicas diferentes para dimensionar microsserviços em contêineres . Cada um é baseado - assim como toda escala - em um balanceador de carga baseado em proxy. Cada um tem seu próprio conjunto de desafios. Vários deles decorrem do simples fato de que a escala dentro de ambientes de contêineres geralmente depende de tabelas de IP e sua fluência limitada com qualquer coisa acima das camadas de rede tradicionais (ou seja, IP e TCP).

Todos esses proxies fornecem a mesma funcionalidade principal: dimensionar os serviços distribuídos por todo o ambiente do contêiner. O mais louco é que os serviços são construções 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 construções de camada 7 (HTTP), geralmente servindo como “backend” para uma única chamada de API em vez de um aplicativo inteiro.

Os aplicativos, como os conhecemos, podem parecer, do lado do cliente, uma construção única e holística. Na realidade, eles são compostos de muitos microsserviços diferentes (e distribuídos). Alguns desses serviços são puramente internos, projetados para serem usados por outros serviços. O que significa muita comunicação de serviço para serviço dentro do ambiente em contêiner.

Você precisa de roteamento L7 (HTTP) nesses ambientes porque tudo são APIs sobre HTTP/HTTP2. Você também precisa de uma postura de segurança consistente, autenticação e aplicação de políticas. Nada disso vai acontecer com uma abordagem baseada em tabelas de IP.

Como geralmente acontece, o Open Source vem em nosso socorro. Vários service meshes de código aberto surgiram para enfrentar esses desafios. Como é o caso de muitos projetos de código aberto, essas malhas de serviço (como o Istio ) estão sendo expandidas por projetos como o Aspen Mesh, com recursos (e suporte) que fornecem soluções de nível empresarial.

Esses esforços expandidos estão focados em resolver 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. Construir – Este é um dos desafios que uma malha de serviço tem pouco a oferecer além de integrar políticas com cadeias de ferramentas de CI/CD e garantir um modelo declarativo de configuração para que a malha de serviço possa ser tratada como infraestrutura como código.
2. Teste e integração – Uma malha de serviço pode ajudar aqui, garantindo uma política consistente entre 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 insere latência no processo de implantação.  Essas pessoas estão procurando uma maneira de implantar serviços diretamente na produção e empregar mecanismos de direcionamento de tráfego e reversão para lidar com falhas.  
3. Controle de versão – O Service Mesh 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 traduzir versões para ajudar durante os períodos de transição de versão da API. Atualizações de clientes – especialmente para aplicativos no espaço do consumidor – nem sempre podem ser forçadas, o que significa solicitações para várias versões. Uma malha de serviços pode traduzir solicitações de versões mais antigas da API para as mais recentes, ajudando a reduzir os custos e a carga de manutenção de várias versões da mesma API.
4. Implantar – Com sua capacidade de falar HTTP fluentemente, uma malha de serviço é um ótimo lugar para habilitar implantações Blue/Green , testes canary e direcionamento de tráfego.
5. Registro – O registro distribuído é sempre um problema, e é ainda mais preocupante em ambientes onde as instâncias vivem por períodos de tempo altamente variáveis. Uma malha de serviço oferece um local comum e centralizado para implementar o registro, bem como a capacidade de executar funções como rastreamento de solicitações.
6. Monitoramento – No centro da escala está o monitoramento. Embora os aplicativos possam implementar certas funções (novas tentativas, interrupção de circuito, etc.) para lidar com a falha inevitável de um serviço, isso coloca um fardo no aplicativo que ele não deveria precisar suportar. Uma malha de serviço assume o fardo da comunicação entre serviços e fornece um local para monitoramento. O objetivo é focar no MTTD e MTTR na produção, porque a execução na produção é difícil e o fracasso é inevitável.
7. Depuração – Quanto mais complexo for um sistema, mais difícil será depurá-lo. Uma malha de serviço pode auxiliar na análise da causa raiz, fornecer estatísticas e notificações pré-falha usando análise e telemetria, e colocar contêineres em quarentena em vez de eliminá-los para que possam ser examinados minuciosamente. Isso é particularmente útil em casos em que a falha é causada por vazamentos lentos de memória.
8. Rede – A rede continua sendo essencial para contêineres, talvez mais do que em ambientes menos complexos. O desejo de abstrair serviços dessa rede significa que há muitas partes móveis que você não deseja implementar em todos os serviços: Descoberta de serviços, gerenciamento de SSL e certificados, disjuntores, novas tentativas, monitoramento de integridade, etc. O objetivo dos microsserviços era “codificar localmente, codificar em pequena escala”. A introdução da necessidade de incluir funções relacionadas à rede incha os microsserviços e introduz dívida arquitetônica e técnica adicional. Uma malha de serviço assume essas funções e oferece a escala e a segurança desejadas sem atrapalhar o desenvolvimento.

A malha de serviços é uma evolução empolgante que combina princípios modernos de nuvem e contêineres com as bases sólidas de escala. Espere ver o service mesh ganhar força à medida que 2018 continua a testemunhar uma adoção crescente de contêineres e uma demanda por escala e suporte de nível empresarial.