Service mesh

Uma service mesh, assim como o projeto open source Istio, é uma maneira de controlar como diferentes componentes de uma aplicação compartilham dados entre si. Diferentemente de outros sistemas de gerenciamento de comunicação, a service mesh é uma infraestrutura dedicada, incorporada diretamente nas apps. Essa camada de infraestrutura visível pode registrar o desempenho das interações entre os diferentes componentes da app, facilitando a otimização da comunicação e evitando o downtime conforme a aplicação evolui.

Cada componente da app é um "serviço" que depende de outros para atender às necessidades dos usuários. Se o usuário de uma app de vendas online deseja comprar um produto, ele precisa saber se continua disponível em estoque. Nesse exemplo, o serviço que se comunica com o banco de dados de inventário da empresa também precisa se comunicar com a página da web do produto que, por sua vez, precisa se comunicar com a seção do carrinho de compras online do usuário. Para agregar valor aos negócios, a loja online pode futuramente criar um serviço que oferece recomendações in-app de produtos. Para gerar as recomendações, esse novo serviço deverá se comunicar com um banco de dados de tags de produtos. Também precisará se comunicar com o banco de dados de inventário usado pela página do produto. Está claro que estamos falando de diversos componentes maleáveis e reutilizáveis.

Geralmente, as apps modernas são desmembrados desta maneira: como uma rede de serviços, cada um realizando uma função de negócios específica. Para um serviço executar sua função, provavelmente ele precisará solicitar dados de diversos outros serviços. Mas o que acontece se alguns serviços, como o banco de dados de inventário da loja, ficarem sobrecarregados? A service mesh resolve o problema, encaminhando as solicitações de um serviço para o próximo e otimizando como todos esses elementos funcionam juntos.

A arquitetura de microsserviços permite aos desenvolvedores fazer alterações nos serviços de uma app sem a necessidade de reimplantá-la totalmente. Diferentemente do desenvolvimento de apps em outras arquiteturas, os microsserviços são criados individualmente por diversas micro equipes, com flexibilidade para escolher as ferramentas e linguagens de codificação que desejam usar. Basicamente, os microsserviços são projetados de maneira independente e são intercomunicáveis. Dessa forma, a falha de um não resulta na interrupção completa da aplicação.

A essência dos microsserviços está na comunicação serviço a serviço. Não é necessária uma camada de service mesh para a comunicação poder ser codificada, mas conforme a complexidade da comunicação aumenta, ela se torna cada vez mais indispensável. No caso de apps nativas em nuvem baseadas em uma arquitetura de microsserviços, a service mesh é uma maneira de englobar inúmeros serviços discretos em uma aplicação funcional.

A service mesh não adiciona uma funcionalidade nova ao ambiente de execução da aplicação. Em qualquer arquitetura, as aplicações precisam de regras para especificar como as solicitações partem do ponto A, e são recebidas pelo ponto B. A service mesh difere porque retira a lógica que rege a comunicação intrasserviço do âmbito individual e a transfere para uma camada de infraestrutura.

Para isso ser possível, a service mesh deve ser incorporada à aplicação como uma matriz de proxies de rede. Proxy é um conceito já conhecido pela TI corporativa. Se você estiver usando seu computador do trabalho para acessar esta página, provavelmente utilizou um proxy:

1. A sua solicitação para acessar esta página partiu do seu computador e foi recebida primeiramente pelo proxy web da sua empresa.
2. Após ser autorizada pela medida de segurança do proxy, a solicitação foi enviada para o servidor que hospeda esta página.
3. Depois, esta página foi retornada ao proxy e novamente verificada pelas medidas de segurança.
4. Por fim, a página foi enviada do proxy para o seu computador.

Em uma service mesh, as solicitações são encaminhadas entre microsserviços utilizando proxies em uma camada de infraestrutura própria. Por esse motivo, os proxies que compõem uma service mesh são, às vezes, chamados de "sidecars", pois são executados paralelamente a cada serviço, não dentro dele. Juntos, esses proxies "sidecars", desacoplados de cada serviço, formam uma rede em malha.

Um proxy sidecar reside ao lado de um microsserviço e encaminha solicitações para outros proxies. Juntos, esses sidecars formam uma rede em malha.

Sem a service mesh, é necessário codificar cada microsserviço com a lógica que rege a comunicação de serviço a serviço, resultando em menos tempo para que os desenvolvedores se concentrem nas metas de negócios. Além disso, a falta da malha dificulta a identificação de falhas na comunicação, pois a lógica que rege a comunicação entre serviços fica oculta dentro de cada serviço.

Cada serviço novo adicionado à aplicação ou nova instância de um serviço existente executado em um container significa uma complicação a mais para o ambiente de comunicação e introduz novos pontos para possíveis falhas. Em uma arquitetura de microsserviços complexa, é praticamente impossível localizar onde os problemas ocorrem sem uma service mesh.

Isso deve-se ao fato de que a service mesh também captura todos os aspectos da comunicação de serviço a serviço como métricas de desempenho. Com o passar do tempo, é possível aplicar os dados fornecidos pela service mesh às regras de comunicação entre serviços para aumentar a eficiência e a confiabilidade das solicitações de serviço.

Por exemplo, se um determinado serviço falhar, a service mesh coletará os dados sobre o tempo até a retomada da atividade. Conforme os dados sobre períodos de falha de um determinado serviço se acumulam, é possível escrever regras para determinar o tempo de espera ideal antes de fazer uma nova tentativa. Isso garantirá que o sistema não seja sobrecarregado com tentativas desnecessárias.

Se a sua empresa estiver criando microsserviços, provavelmente sua equipe já antecipou algumas necessidades futuras, como rápida escalabilidade e adição de novas funcionalidades para satisfazer às necessidades dos clientes. Geralmente, depois de um ano, a arquitetura de microsserviços tem um aspecto muito diferente do inicial. Em um primeiro momento, as bibliotecas incorporadas aos microsserviços precisam conseguir lidar com a comunicação serviço a serviço com o mínimo de interrupção das operações. Se a sua empresa aproveitar todo o potencial dos microsserviços, expandindo a escalabilidade e as funcionalidades, a eficiência da comunicação poderá ser afetada. Com o passar do tempo, os problemas aumentam à medida que os serviços ficam sobrecarregados com solicitações e os desenvolvedores precisam gastar mais tempo codificando a lógica em cada serviço.

Com uma service mesh:

• Os desenvolvedores podem focar em agregar mais valor aos negócios, em vez de se ocuparem com a conexão entre serviços.
• O rastreamento distribuído de solicitações por meio do Jaeger forma uma camada de infraestrutura visível paralela aos serviços. Dessa forma, é mais fácil reconhecer e diagnosticar os problemas.
• As aplicações ficam mais resilientes ao downtime, já que a service mesh pode rotear as solicitações para não passarem pelos serviços com falhas.
• As métricas de desempenho oferecem sugestões sobre como otimizar a comunicação no ambiente de execução.

Comece a se planejar para o futuro: teste uma service mesh no Red Hat® OpenShift® Service Mesh. Aproveite uma maneira consistente de conectar, gerenciar e visualizar aplicações baseadas em microsserviços. Isso inclui informações de funcionamento e controle sobre os microsserviços em rede na service mesh. O OpenShift Service Mesh está disponível gratuitamente no Red Hat OpenShift.

O componente automation mesh do Red Hat Ansible Automation Platform oferece um framework simples e confiável de service mesh para escalar a automação. Com uma camada de comunicação flexível e multidirecional, o automation mesh possibilita que a empresa opere ainda mais em escala global. Com menos sensibilidade à latência e interrupção da conexão, além de recursos de peering nativo, você vai além com muito mais confiabilidade, em comparação com outras plataformas de automação no mercado atual. Com funcionalidades de segurança como autenticação e criptografia TLS e controles de acesso extras, você pode confiar no Red Hat Ansible Automation Platform para ultrapassar os limites das possibilidades em todo o estado da sua TI empresarial.

Leia mais sobre as funcionalidades do Red Hat Ansible Automation Platform