Service mesh

Service mesh é uma camada de infraestrutura dedicada dentro de uma aplicação de software que lida com a comunicação entre serviços. Uma service mesh pode lidar com funções de roteamento de tráfego, segurança, observabilidade e resiliência, ao mesmo tempo em que abstrai essas complexidades de serviços individuais.

As aplicações modernas dependem de serviços que se comunicam entre si. Pense na última vez em que você acessou o site de uma loja. Provavelmente, você usou a barra de pesquisa do site para procurar produtos. Essa pesquisa representa um serviço. Talvez você até tenha visto recomendações de produtos relacionados ou adicionado um item ao carrinho. Ambos também são serviços. O serviço que se comunica com o banco de dados de inventário 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. O varejista também pode ter um serviço integrado à app com recomendações de produtos para os usuários. Para gerar as recomendações, esse serviço se comunicará com um banco de dados de tags de produtos. Ele também precisará se comunicar com o mesmo banco de dados de inventário que a página do produto precisava.

Geralmente, as aplicações modernas são desmembradas desta maneira: como uma rede de serviços, cada um realizando uma função 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, gerenciando a comunicação entre serviços e otimizando como todos esses elementos funcionam juntos.

A service mesh pode ser considerada um padrão de arquitetura de microsserviços. Os microsserviços são um estilo de arquitetura de aplicações em que um conjunto de serviços independentes se comunica por meio de interfaces de programação de aplicações (APIs) lightweight. Uma arquitetura de microsserviços representa uma abordagem nativa em nuvem à criação de software, em que cada função principal de uma aplicação pode existir de maneira independente. Diferentemente do desenvolvimento de apps em outras arquiteturas, os microsserviços podem ser criados de forma individual por diversas microequipes, com flexibilidade para escolher as ferramentas e linguagens de codificação que desejam usar. 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. O gerenciamento da arquitetura de microsserviços se torna mais complexo à medida que cresce. Se uma aplicação contém dezenas ou centenas de serviços interagindo entre si, surgem desafios em torno de falhas de rede, monitoramento e rastreamento, balanceamento de cargas de tráfego e proteção da comunicação entre diferentes microsserviços. Seria ineficiente abordar esses problemas apenas usando código personalizado. A service mesh é uma solução consistente para lidar com esses desafios sem precisar alterar o código de serviços individuais.

A service mesh gerencia a comunicação entre serviços usando um data plane e um control plane. A service mesh não adiciona uma funcionalidade nova ao ambiente de runtime 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 é diferente porque retira a lógica que rege a comunicação intrasserviço do âmbito individual e a transfere para uma camada de infraestrutura.

Para que isso seja possível, é necessário que a service mesh seja incorporada à aplicação como uma matriz de proxies de rede. Proxy é um conceito já conhecido. Se você estiver usando o computador do trabalho para acessar esta página, provavelmente utilizou um proxy. Veja como funciona:

1. Sua solicitação para acessar esta página partiu do seu computador e foi recebida 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. A página foi enviada do proxy para o seu computador.

Em uma service mesh, cada instância de serviço é pareada com um proxy sidecar que é executado com cada serviço e intercepta todo o tráfego de rede de entrada e saída. Cada proxy sidecar reside ao lado de um microsserviço e encaminha solicitações para e de outros proxies. O proxy lida com tarefas como roteamento de tráfego, balanceamento de carga, aplicação de políticas de segurança e coleta de dados de telemetria. Em vez de se comunicarem diretamente entre si, os serviços enviam solicitações pelo sidecar. Os sidecars controlam a comunicação entre serviços. Tudo isso compõe o data plane.

O control plane gerencia a configuração e a distribuição de políticas no data plane. O control plane também distribui regras de roteamento de tráfego, gerencia certificados de segurança entre serviços, configura componentes para aplicar políticas e coleta telemetria.

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. Isso 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.

Descubra mais sobre microsserviços

Istio é uma plataforma de service mesh open source que controla como os microsserviços compartilham dados entre si. Ela controla o fluxo de tráfego, aplica políticas e monitora as comunicações em um ambiente de microsserviços. Além disso, ela inclui APIs que permitem que o Istio se integre a qualquer sistema de políticas, telemetria ou plataforma de registro. O Istio pode ser executado em uma variedade de ambientes on-premises, na nuvem, em containers e virtuais.

A arquitetura do Istio é dividida entre o data plane e o control plane. O Istio usa proxies Envoy, que apresentam alto desempenho, são implantados como sidecars e mediam o tráfego para todos os serviços dentro da service mesh. No data plane, os desenvolvedores podem oferecer o suporte do Istio a um serviço implantando um proxy sidecar no ambiente.

A service mesh do Istio inclui um novo modo ambiente que eliminará a necessidade dos proxies sidecar na service mesh, substituindo-os por proxies no nível do nó e gateways intermediários chamados waypoints. Proxies waypoint são executados fora dos pods de aplicação e são gerenciados independentemente das aplicações.

Mais informações sobre o Istio no blog Red Hat Developer

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ível falhas. Em uma arquitetura de microsserviços complexa, é praticamente impossível localizar os problemas sem uma service mesh.

Estes são alguns dos benefícios em usar uma service mesh:

• Melhoria da segurança: a service mesh usa o Transport Layer Security (mTLS) para garantir a criptografia e segurança da comunicação entre serviços, assim como a proteção dos dados confidenciais do usuário. Isso adiciona uma camada extra de segurança sem exigir a adição manual de mais criptografia a cada serviço. Uma service mesh pode aprimorar o controle de acesso baseado em função (RBAC) e as políticas para proteger APIs, além de automatizar o gerenciamento de certificados e a rotação de chaves.
• Implementação de políticas: as service meshes incluem configuração centralizada para políticas de serviço, como cotas, limitação de taxa e autenticação e autorização. Elas oferecem controle sobre interações de serviço por meio de políticas de acesso. As políticas são aplicadas no nível do proxy, o que ajuda a criar consistência entre os serviços.
• Gerenciamento de tráfego:com a service mesh, suas aplicações podem gerenciar o tráfego para serviços individuais com base em condições de carga, versões e regras específicas do usuário. Por exemplo, se você estiver lançando uma nova versão do seu serviço de inventário, poderá usar uma implantação canário para enviar apenas 5% do tráfego ao novo serviço. Canário é uma implantação de teste menor. Se isso funcionar, você poderá aumentar o tráfego.
• Verificações de integridade e observabilidade: pode ser difícil visualizar como os microsserviços interagem em tempo real, mas, com uma service mesh, é possível implementar ferramentas de observabilidade integradas, como rastreamento distribuído e coleta de métricas. Os sidecars em uma service mesh coletam métricas (contagens de solicitações, latência, taxas de erro) e as enviam para o control plane ou ferramentas de monitoramento.
• Tolerância a falhas e maior resiliência: uma service mesh automatiza novas tentativas e fallbacks, o que pode ser útil quando os microsserviços encontram falhas. Se um serviço falhar ou não responder, a service mesh fará uma nova tentativa com base em regras predefinidas e poderá redirecionar o tráfego para serviços alternativos. Isso significa que a app pode lidar com falhas de maneira eficaz quando um serviço fica indisponível, garantindo que os usuários ainda tenham uma boa experiência. A service mesh também coleta dados sobre quanto tempo levou até que uma nova tentativa fosse bem-sucedida. Esses dados podem ser usados para aprimorar as regras futuras sobre o melhor tempo de espera, garantindo que o sistema não fique sobrecarregado com tentativas desnecessárias.

Com uma service mesh, as equipes de desenvolvimento e operações ficam mais preparadas para lidar com a migração de aplicações monolíticas para apps nativas em nuvem (coleções de aplicações de microsserviços pequenos, independentes e levemente acoplados). 

As organizações podem enfrentar desafios ao implementar uma service mesh, por exemplo:

• Complexidade e integração com sistemas existentes. Pode ser difícil configurar e gerenciar uma service mesh, assim como integrá-la aos sistemas atuais. As organizações podem enfrentar desafios se estiverem trabalhando em um ambiente grande e distribuído em sistemas multicloud e on-premises, ou se não tiverem usado anteriormente uma service mesh no ambiente.
• Requisitos de recursos e custos indiretos. As service meshes podem aumentar os custos indiretos operacionais do gerenciamento de aplicações porque cada instância de serviço agora tem um proxy sidecar, o que aumenta o uso de CPU e memória. Gerenciar e solucionar problemas, principalmente em implantações em larga escala, pode ser uma tarefa complexa. Como resultado, também pode ficar mais difícil manter o desempenho e a escala.
• Falta de habilidades. As pessoas da equipes precisam de treinamento para entender as funcionalidades, a configuração e as práticas recomendadas da service mesh. Falhas de depuração podem ser graves, especialmente quando surgem problemas devido a regras de roteamento complexas ou configurações incorretas de mTLS. Muitas organizações descobrem que suas equipes não têm experiência com a tecnologia da service mesh, o que pode apresentar desafios para começar e usar essas camadas de infraestrutura de forma eficaz.

O gateway de API é uma ferramenta de gerenciamento de APIs que fica entre um cliente e um conjunto de serviços de back-end. Nesse caso, o cliente é a aplicação no dispositivo de um usuário, e os serviços de back-end são aqueles que ficam no servidor de uma empresa. Um gateway de API é uma forma de separar a interface do cliente da implementação do back-end. Quando um cliente faz uma solicitação, o gateway de API a divide em várias solicitações, as direciona para os locais adequados, produz uma resposta e faz o monitoramento.

A service mesh protege a comunicação interna do serviço enquanto possibilita o tráfego externo por meio do gateway da API. A service mesh usada com um gateway de API pode garantir que as políticas sejam aplicadas uniformemente em todos os serviços internos. 

Leia mais sobre o Red Hat 3scale API management

A Red Hat oferece soluções integradas de gerenciamento de API, service mesh e plataforma de infraestrutura para você criar uma arquitetura abrangente de gerenciamento de serviços.O  Red Hat® OpenShift® Service Mesh oferece uma maneira uniforme de conectar, gerenciar e observar aplicações baseadas em microsserviços. Ele fornece insights comportamentais e controle sobre os microsserviços conectados pela rede na sua service mesh.

Integrado ao projeto open source Istio, o OpenShift Service Mesh oferece funções extras com a inclusão de outros projetos open source, como Kiali (console Istio) e Jaeger (rastreamento distribuído), viabilizando a colaboração com membros líderes da comunidade do Istio. Com o OpenShift Service Mesh, os desenvolvedores podem aumentar a produtividade com a integração de políticas de comunicações sem alterar o código das aplicações ou incorporar bibliotecas de linguagens específicas.

O Red Hat OpenShift Service Mesh é pré-instalado, testado e otimizado para o Red Hat OpenShift. Ele é compatível com funcionalidades específicas do OpenShift, como operadores e pipelines de integração e entrega contínuas (CI/CD). O suporte empresarial da Red Hat está incluído, assim como as atualizações e aplicações de patches regulares para garantir a segurança e estabilidade. O OpenShift Service Mesh funciona em vários clusters do Red Hat OpenShift, criando consistência em ambientes de nuvem híbrida ou multicloud.