Service Mesh guia final: Gerenciando as comunicações serviço a serviço na era dos microservices

Por volta de 2016, o termo "service mesh" pareceu surgir do nada nas áreas de microservices, computação cloud e DevOps. No entanto, como em muitos conceitos da computação, há realmente uma longa história do padrão e da tecnologia associados.

A chegada do service mesh deveu-se em grande parte a uma perfeita tempestade no cenário de TI. Os desenvolvedores começaram a criar sistemas distribuídos usando uma abordagem poliglota e precisavam da descoberta dinâmica de serviços. As operações começaram a usar infraestrutura efêmera e queriam lidar com as inevitáveis falhas de comunicação e aplicar políticas de rede. As equipes de plataforma começaram a adotar sistemas de orquestração de containers, como o Kubernetes, e queriam rotear dinamicamente o tráfego dentro e ao redor do sistema usando proxies de rede modernos baseados em API, como o Envoy.

Este artigo tem como objetivo responder a perguntas pertinentes de arquitetos de software e líderes técnicos, como: o que é um service mesh? Eu preciso de um service mesh? E como devo avaliar as diferentes ofertas/implementações de service mesh oferecidas?

O Pattern Service Mesh

O pattern service mesh está focado no gerenciamento de toda comunicação serviço a serviço em um sistema de software distribuído.

Contexto

O contexto para o padrão é duplo: primeiro, os engenheiros adotaram o padrão de arquitetura de microservice e estão construindo suas aplicações compondo vários serviços (idealmente de uso único e implementável independentemente) juntos. Segundo, que a organização adotou tecnologias de plataforma cloud native, como containers (por exemplo, Docker), orquestradores (por exemplo, Kubernetes) e proxies/gateways (por exemplo, Envoy).

Intenção

Os problemas que o pattern service mesh tenta resolver incluem:

• Eliminar a necessidade de criar uma biblioteca em uma linguagem específica para lidar com comunicação entre dois serviços individuais, ou com descoberta de serviços, roteamentos e requisitos de comunicação não funcional no nível de aplicação (Camada 7);
• Externalização da configuração de comunicação dos serviços, incluindo locais de rede de serviços externos, credenciais de segurança e metas de qualidade de serviço;
• Fornecer monitoramento passivo e ativo de outros serviços;
• Descentralizar a aplicação da política em um sistema distribuído;
• Fornecer padrões de observabilidade e padronizar a coleta de dados associados.
• Ativando o registro de solicitações (logs)
• Configurando o rastreamento distribuído;
• Coletando métricas

Estrutura

O pattern service mesh concentra-se principalmente no tratamento tradicional do que é chamado de tráfego baseado em chamada de procedimento remoto "leste-oeste" (RPC - Remote Procedure Call): a comunicação do tipo solicitação/resposta que se origina internamente em um datacenter e viaja de serviço para serviço. Isso contrasta com um gateway de API ou proxy, projetado para lidar com o tráfego "norte-sul": comunicação que se origina externamente e ingressa em um endpoint ou serviço dentro do datacenter.

Recursos do Service Mesh

Uma implementação de service mesh geralmente oferece um ou mais das seguintes recursos:

• Normaliza a nomeação e adiciona roteamento lógico (por exemplo, mapear o nome no nível de código "serviço do usuário" para o local específico da plataforma "AWS-us-east-1a/prod/users/v4");
• Fornece modelagem de tráfego (traffic shaping) e mudança de tráfego (traffic shifting);
• Manter o balanceamento de carga, geralmente com algoritmos configuráveis;
• Fornece controle de liberação de serviço (por exemplo, liberação de canary e divisão de tráfego);
• Oferece roteamento por requisição (por exemplo, sombreamento de tráfego, injeção de falha e roteamento de depuração);
• Adiciona confiabilidade da linha de base, como verificações de integridade, timeouts/deadlines, interrupção de circuito (circuit breaking) e nova tentativa (budgets);
• Aumenta a segurança, através de TLS (Transport Level Security) e políticas como ACLs (Listas de controle de acesso);
• Oferece observabilidade e monitoramento adicionais, como métricas de linha superior (volume de solicitações, taxas de sucesso e latências), suporte para rastreamento distribuído e a capacidade de "tocar" e inspecionar a comunicação serviço a serviço em tempo real;
• Permite que as equipes da plataforma possam configurar "padrões saudáveis" para proteger o sistema contra más comunicações.

Arquitetura service mesh: entendendo os bastidores

Um service mesh consiste em dois componentes de alto nível: um data plane e control plane. Matt Klein, criador do Envoy Proxy, escreveu um excelente artigo no tópico "service mesh data plane versus control plane".
De um modo geral, o data plane "faz o trabalho" e é responsável por "converter, encaminhar e observar condicionalmente todos os pacotes de rede que fluem "de e para" um [endpoint da rede]". Nos sistemas modernos, o plano de dados é normalmente implementado como proxy (como Envoy, HAProxy ou MOSN), que é executado fora de processo ao lado de cada serviço como um "sidecar".

Klein afirma que, dentro de um service mesh, o data plane "cuida de todos os pacotes/solicitações no sistema e é responsável pela descoberta de serviços, verificações de integridade, roteamento, balanceamento de carga, autenticação/ autorização e observabilidade". Há um trabalho em andamento no CNCF para criar uma Universal Data Plane API, com base nos conceitos da publicação anterior de Klein no blog The Universal Data Plane API. Esta proposta estende a xDS API que foi definida e implementada pelo Envoy e é suportada em outros proxies, como o MOSN.

Um control plane "supervisiona o trabalho" e pega todas as instâncias individuais do data plane - um conjunto de proxies laterais isolados sem estado - e as transforma em um sistema distribuído. O control plane não toca em nenhum pacote/request no sistema, mas permite que um operador humano forneça política e configuração para todos os control planes em execução no service mesh. O control plane também permite que a telemetria do data plane seja coletada e centralizada, pronta para o consumo por um operador; A Red Hat está trabalhando no Kiali apenas para este caso de uso.
O diagrama abaixo foi retirado da documentação da arquitetura do Istio, e embora as tecnologias rotuladas sejam específicas ao Istio, os componentes são gerais para toda a implementação do service mesh.

Arquitetura do Istio, demonstrando como o control plane e o proxy data plane interagem (cortesia da documentação do Istio).

Casos de Uso

Há vários casos de uso que um service mesh pode ser usado ou oferecer suporte.

Descoberta e roteamento dinâmicos de serviços

Um service mesh fornece descoberta dinâmica de serviços e gerenciamento de tráfego, incluindo sombreamento de tráfego (duplicação) para testes e divisão de tráfego para liberação de canary e experimentação do tipo A/B.

Os proxies usados em um service mesh geralmente reconhecem a "camada de aplicativo" (operando na camada 7 na pilha de rede OSI). Isso significa que as decisões de roteamento de tráfego e a rotulagem de métricas podem se basear nos dados nos cabeçalhos HTTP ou em outros metadados do protocolo da camada de aplicativo.

Confiabilidade de comunicação serviço a serviço

Um service mesh suporta a implementação e a aplicação de requisitos de confiabilidade, tais como novas tentativas de solicitação, timeouts, limite de taxa e interrupção de circuito (circuit-breaking). Um service mesh é frequentemente usado para lidar (ou encapsular) com as oito falácias da computação distribuída. Deve-se observar que um service mesh pode oferecer apenas suporte à confiabilidade a nível de comunicação (como repetir uma solicitação HTTP) , e em última instância, o serviço deve ser responsável por qualquer impacto relacionado ao negócio, como evitar várias solicitações HTTP POST (não idempotentes).

Observabilidade do Tráfego

Como um service mesh está no caminho crítico para todas as solicitações tratadas no sistema, também pode fornecer "observabilidade" adicional, como rastreamento distribuído de uma solicitação, frequência de códigos de erro HTTP, latência global e serviço a serviço. Embora seja uma frase muito usada em demasia no espaço corporativo, os service mesh são frequentemente propostos como um método para capturar todos os dados necessários para implementar uma visualização de "single pane of glass" dos fluxos de tráfego em todo o sistema.

Segurança de Comunicação

Um service mesh também suporta a implementação e imposição de requisitos de segurança transversais, como fornecer identidade de serviço (por meio de certificados x509), permitindo a segmentação de serviço/rede no nível do aplicativo (por exemplo, "serviço A" pode se comunicar com o "serviço B", mas não com "serviço C") garantindo que toda a comunicação seja criptografada (via TLS) e garantindo a presença de tokens de identidade válidos no nível do usuário ou "passaportes".

Antipatterns

Muitas vezes, é um sinal de amadurecimento da tecnologia quando surgem antipadrões de uso. Os services mesh não são exceção.

Muitas Camadas de Gerenciamento de Tráfego (Tartarugas Até Lá Embaixo)

Esse antipatterns ocorrem quando os desenvolvedores não estão alinhados com as equipes da plataforma ou de operações, e duplicam a lógica de manipulação de comunicação existente no código que está sendo implementado agora por meio de um service mesh. Por exemplo, uma aplicação que implementa uma política de retry no código, além de uma política de novas tentativas a nível de comunicação (wire-level) fornecida pela configuração do service mesh. Esse antipattern pode levar a problemas como transações duplicadas.

Service Mesh (Bala de Prata)

Não existe uma "bala de prata" em TI, mas os fornecedores às vezes são tentados a ungir novas tecnologias com esse rótulo. Um service mesh não resolverá todos os problemas de comunicação com microservices, orquestradores de containers como o Kubernetes ou rede cloud. Um service mesh visa facilitar apenas a comunicação serviço a serviço (leste-oeste), e há um custo operacional claro para implantar e executar uma malha de serviço.

Enterprise Service Bus (ESB) 2.0

Durante a era pré-microservices da arquitetura orientada a serviços (SOA), os Enterprise Service Buses (ESB) implementaram um sistema de comunicação entre os componentes de software. Alguns temem que muitos dos erros da era ESB sejam repetidos com o uso de dos service mesh.

O controle centralizado da comunicação oferecido via ESBs claramente tinha valor. No entanto, o desenvolvimento das tecnologias foi conduzido por fornecedores, o que levou a vários problemas, como: falta de interoperabilidade entre ESBs, extensão personalizada dos padrões do setor (por exemplo, adição de configuração específica do fornecedor ao esquema compatível com WS- *) e alto custo. Os fornecedores de ESB também não fizeram nada para desencorajar a integração e o acoplamento rígido da lógica de negócios no barramento de comunicação.

Implantação do Big Bang

Existe uma tentação geral em TI e acreditar que uma abordagem big bang para implantação é a abordagem mais fácil de gerenciar, mas, segundo as pesquisas da Accelerate e do State of DevOps Report, esse não é o caso. Como uma implementação completa de um service mesh significa que a tecnologia está no caminho crítico para lidar com todas as solicitações do usuário final, uma implantação big bang é altamente arriscada.

Implementações e produtos Service Mesh

A seguir, é apresentada uma lista não exaustiva das implementações atuais de service mesh:

• Linkerd
• Istio
• Consul
• Kuma
• Maesh
• AWS App Mesh

Comparações entre Service Mesh: Qual Service Mesh?

O crescimento do service mesh está extremamente rápido e, portanto, qualquer tentativa de criar uma comparação ficará rapidamente desatualizada. No entanto, existem várias comparações. Deve-se tomar cuidado para entender o viés da fonte (se houver) e a data em que a comparação foi feita.

• https://layer5.io/landscape
• https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/ (correto em maio de 2019)
• https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/ (atualizado em outubro de 2019)
• https://servicemesh.es/ (última publicação em fevereiro de 2020)

O InfoQ sempre recomenda que os adeptos do service mesh realizem suas próprias diligências e experimentações.

Tutoriais de Service Mesh

Para engenheiros ou arquitetos que desejam experimentar várias implementações de service mesh, estão disponíveis os seguintes tutoriais, playgrounds e ferramentas:

• Layer 5 Meshery - um plano de gerenciamento de de vários service mesh
• Solo's SuperGloo - uma plataforma de orquestramento de service mesh
• KataCoda Istio tutorial
• Consul service mesh tutorial
• Linkerd tutorial

História do Service Mesh

O InfoQ acompanha o tópico que agora chamamos de service mesh desde o final de 2013, quando o Airbnb lançou o SmartStack, que oferecia um mecanismo de descoberta de serviço (usando HAProxy) para a arquitetura emergente de "microservices". Muitas das organizações "unicórnio" anteriormente rotuladas estavam trabalhando em tecnologias semelhantes antes dessa data. Desde o início dos anos 2000, o Google estava desenvolvendo sua estrutura Stubby RPC que evoluiu para gRPC, e o Google Frontend (GFE) e o Global Software Load Balancer (GSLB), cujos traços podem ser vistos no Istio. No início dos anos 2010, o Twitter começou a trabalhar no Finagle, desenvolvido em Scala, do qual surgiu o service mesh Linkerd.

No final de 2014, a Netflix lançou um conjunto inteiro de utilitários baseados em JVM, incluindo o Prana, um processo "sidecar" que permitia que os serviços de aplicativos escritos em qualquer linguagem se comuniquem via HTTP entre instâncias. Em 2016, a equipe do NGINX começou a falar sobre "The Fabric Model", que era muito semelhante a um service mesh, mas exigia o uso de seu produto comercial NGINX Plus para implementação.

Outros destaques da história do service mesh incluem os lançamentos do Istio em maio de 2017, Linkerd 2.0 em julho de 2018, Consul Connect e SuperGloo em novembro de 2018, Service Mesh Interface (SMI) em maio de 2019 e Maesh e Kuma em setembro de 2019.

Até mesmo service meshs que surgiram fora das empresas unicórnios, como o Consul da HashiCorp, inspiraram-se na tecnologia mencionada, muitas vezes com o objetivo de implementar o conceito de "GIFEE" CoreOS coined; Infraestrutura do Google para todos.

Para aprofundar a história de como o conceito moderno de service mesh evoluiu, Phil Calçado escreveu um artigo abrangente "Pattern: Service Mesh".

Explorando o (Possível) futuro dos Service Meshes

Como a tecnologia do service mesh ainda está na fase inicial de adoção, há muito espaço para trabalhos futuros. Em termos gerais, existem quatro áreas de interesse particular: adicionar suporte para casos de uso além do RPC, padronizar a interface e operações, empurrar o service mesh ainda mais para a estrutura da plataforma e criar planos de controle humano eficazes para a tecnologia dos services meshes.

Kasun Indrasiri explorou "The Potential for Using a Service Mesh for Event-Driven Messaging", no qual ele discutiu dois principais padrões arquiteturais emergentes para implementar o suporte a mensagens em um service mesh: o protocolo proxy sidecar e o HTTP bridge sidecar. Esta é uma área de desenvolvimento ativa na comunidade de service mesh, com o trabalho para apoiar o Apache Kafka no Envoy atraindo uma quantidade considerável de atenção.

Christian Posta já havia escrito sobre tentativas de padronizar o uso de service mesh em "Towards a Unified, Standard API for Consolidating Service Meshes". Este artigo também discute o Service Mesh Interface (SMI) anunciado recentemente pela Microsoft em parceria da KubeCon EU. O SMI define um conjunto de APIs comuns e portáteis que visa fornecer aos desenvolvedores interoperabilidade em diferentes tecnologias de service mesh, incluindo Istio, Linkerd e Consul Connect.

O tópico de integração de services meshes com a plataforma de gerenciamento pode ser dividido em dois subtópicos.

Primeiro, está sendo realizado um trabalho para reduzir a sobrecarga da rede introduzida por um service mesh data plane. Isso inclui o kit de desenvolvimento data plane (DPDK - Data Plane Development Kit), que é uma aplicação de espaço do usuário que "ignora as camadas pesadas da pilha de redes do kernel do Linux e se comunica diretamente com o hardware da rede" e trabalha com a equipe da Cilium que utiliza o filtro de pacotes Berkley estendido (eBPF) no kernel do Linux para "funcionalidade muito eficiente de rede, aplicação de políticas e balanceamento de carga". Outra equipe está mapeando o conceito de um service mesh para o corpo de dados (payloads) úteis L2/L3 com o Network Service Mesh, como uma tentativa de "re-imaginar a virtualização da função de rede (NFV) de maneira cloud native".

Segundo, existem várias iniciativas para integrar service meshes com maior acoplamento às plataformas cloud públicas, como visto na introdução do AWS App Mesh, GCP Traffic Director e do Azure Service Fabric Mesh.

A equipe da Buoyant está liderando os esforços no desenvolvimento de planos mais eficazes ao controle humano, centrado para a tecnologia do service mesh. Recentemente lançaram o Dive, um "control plane de equipe" com base em SaaS para equipes de plataforma que operam o Kubernetes. O Dive adiciona funcionalidade de alto nível, focada no ser humano, sobre o service mesh do Linkerd e fornece um catálogo de serviços, um log de auditoria do lançamento das aplicações, uma topologia de serviço global e muito mais.

FAQ

O que é um Service Mesh?

Um service mesh é uma tecnologia que gerencia todo o tráfego de serviço a serviço "leste-oeste" em um sistema de software distribuído (potencialmente baseado em microservice. Fornecendo operações funcionais focadas nos negócios, como roteamento e suporte não-funcional, por exemplo, impor políticas de segurança, qualidade de serviço e limitação de taxa. É tipicamente (embora não exclusivamente) implementado usando sidecar proxies através dos quais todos os serviços se comunicam.

Como uma service mesh difere de um API gateway?

Um service mesh gerencia todo o tráfego de serviço a serviço "leste-oeste" em um sistema de software distribuído (potencialmente baseado em microservice). Fornecendo operações funcionais focadas nos negócios, tais como roteamento e suporte não-funcional, por exemplo, impor políticas de segurança, qualidade de serviço e limitação de taxa.

Um API gateway gerencia todo o tráfego de entrada "norte-sul" em um cluster e fornece suporte adicional para requisitos de comunicação multifuncional. Atua como o único ponto de entrada em um sistema e permite que várias APIs ou serviços ajam de forma coesa e forneçam uma experiência uniforme ao usuário.

Se estou implantando microsserviços, preciso de um service mesh?

Não necessariamente. Um service mesh adiciona complexidade operacional à stack de tecnologia e, portanto, normalmente é implantado apenas se a organização estiver com problemas para dimensionar a comunicação serviço a serviço ou se tiver um caso de uso específico a ser resolvido.

Preciso de um service mesh para implementar a service discovery com microservices?

Não. Um service mesh fornece uma forma de implementar service discovery. Outras soluções incluem bibliotecas específicas de linguagem (como Ribbon e Eureka ou Finagle)

Um service mesh adiciona sobrecarga/latência à minha comunicação serviço a serviço?

Sim, um service mesh adiciona pelo menos dois passos extras na rede, quando um serviço está se comunicando com outro serviço (o primeiro é do proxy que lida com a conexão de saída da fonte e o segundo é do proxy que lida com a conexão de entrada do destino). No entanto, esse passo de rede adicional geralmente ocorre na interface de rede host local ou loopback e adiciona apenas uma pequena quantidade de latência (na ordem de milissegundos). Experimentar e entender se esse é um problema para o caso de uso deve fazer parte da análise e avaliação de um service mesh.

Um service mesh não deve fazer parte do Kubernetes ou da "plataforma cloud native" na qual os aplicativos estão sendo implantados?

Potencialmente. Há um argumento para manter a separação de interesses nos componentes da plataforma cloud native (por exemplo, o Kubernetes é responsável por fornecer a orquestração do container e um service mesh é responsável pela comunicação serviço a serviço). No entanto, está em andamento o trabalho de inserir a funcionalidade de service mesh nas soluções modernas de plataforma como serviço (PaaS).

Como implementar, ou implantar um service mesh?

A melhor abordagem seria analisar os vários produtos de service mesh (veja acima) e seguir as diretrizes de implementação específicas para o service mesh. Em geral, é melhor trabalhar com todas as partes interessadas e implantar de forma incremental qualquer nova tecnologia na produção.

Posso construir meu próprio service mesh?

Sim, mas a pergunta mais pertinente é, você deveria? A construção de um service mesh é uma competência essencial da sua organização? Você poderia fornecer valor aos seus clientes de uma maneira mais eficaz? Você também está comprometido em manter seu próprio service mesh, corrigi-lo por problemas de segurança e atualizá-la constantemente para aproveitar as novas tecnologias? Com a variedade de ofertas de service mesh comerciais e de código aberto que estão agora disponíveis, é mais provável que seja mais eficaz usar uma solução existente.

Qual equipe deve ser responsável pelo service mesh em uma organização de entrega de software?

Normalmente, a equipe de plataforma ou operações possui o service mesh, juntamente com o Kubernetes e a infraestrutura do pipeline de entrega contínua. No entanto, os desenvolvedores configuram as propriedades do service mesh e, portanto, as duas equipes devem trabalhar juntas. Muitas organizações estão seguindo a liderança da vanguarda cloud, como Netflix, Spotify e Google, e estão criando equipes de plataformas internas que fornecem ferramentas e serviços para equipes de desenvolvimento focadas em produtos de ciclo completo.

O Envoy é um service mesh?

Não. O Envoy é um proxy nativo cloud que foi originalmente projetado e construído pela equipe da Lyft. O Envoy é frequentemente usado como um data plane do service mesh. No entanto, para ser considerado um service mesh, o Envoy deve ser usado em conjunto com um control plane para que esse conjunto de tecnologias se torne um service mesh. O control plane pode ser tão simples quanto um repositório centralizado de arquivos de configuração e um coletor de métricas, ou um abrangente/complexo como o Istio.

As palavras "Istio" e "service mesh" podem ser usadas de forma intercambiável?

Não. O Istio é um tipo de service mesh. Devido à popularidade do Istio quando a categoria de service mesh estava surgindo, algumas fontes estavam confundindo o Istio e o service mesh. Essa questão da conflação não é exclusiva do service mesh - o mesmo desafio ocorreu com a Docker e a tecnologia de containers.

Qual service mesh devo usar?

Não há uma resposta única para esta pergunta. Os engenheiros devem entender seus requisitos atuais e as habilidades, recursos e tempo disponíveis para sua equipe de implementação. Os links de comparação de service mesh acima fornecerão um bom ponto de partida para a exploração, mas recomendamos vivamente que as organizações experimentem pelo menos duas implementações de service mesh para entender quais produtos, tecnologias e fluxos de trabalho funcionam melhor para eles.

Posso usar um service mesh fora do Kubernetes?

Sim. Muitos services meshes permitem a instalação e o gerenciamento de data plane proxies e control plane associados em uma variedade de infraestruturas. O HashiCorp's Consul é o exemplo mais conhecido disso, e o Istio também está sendo usado experimentalmente com a Cloud Foundry.

Recursos adicionais

• InfoQ Service Mesh homepage
• The InfoQ eMag - Service Mesh: Past, Present, and Future
• The Service Mesh: What Every Software Engineer Needs to Know about the World's Most Over-Hyped Technology
• Service Mesh Comparison
• Service Meshes

Glossário

API Gateway: Gerencia todo o tráfego de entrada (norte-sul) em um cluster e fornece mais. Ele atua como o único ponto de entrada em um sistema e permite que várias APIs ou serviços ajam de forma coesa e forneçam uma experiência uniforme ao usuário.

Consul:Um service mesh baseado em Go da HashiCorp.

Control plane: Pega todas as instâncias individuais do data plane (proxies) e as transforma em um sistema distribuído que pode ser visualizado e controlado por um operador.

Data plane: Um proxy que converte, encaminha e observa condicionalmente todos os pacotes de rede que fluem "de" e "para" um endpoint de rede de serviço.

Tráfego Leste-Oeste: Tráfego de rede em um datacenter, rede ou cluster Kubernetes. Os diagramas de rede tradicionais foram desenhados com o tráfego de serviço a serviço (inter-data center) fluindo da esquerda para a direita (leste a oeste) nos diagramas.

Envoy Proxy: Um proxy de serviço de código-fonte aberto, projetado para aplicativos cloud native. O Envoy é frequentemente usado como o data plane dentro de um service mesh.

Tráfego de entrada: Tráfego de rede originado fora do cluster do datacenter, da rede ou do Kubernetes.

Istio: Service mesh baseado em C ++ (data plane) e Go (control plane) criado originalmente pelo Google e IBM em parceria com a equipe Envoy da Lyft.

Kubernetes: Uma estrutura de orquestração e agendamento de containers hospedada no CNCF originada no Google.

Kuma: Um service mesh baseado em Go da Kong.

Linkerd: Um service mesh desenvolvido em Rust (data plane) e Go (control plane) derivado de um framework de comunicação baseada na JVM do Twitter.

Maesh: Um service mesh baseado em Go da Containous, os mantenedores do gateway da API Traefik.

MOSN: Um proxy baseado em Go da equipe Ant Financial que implementa as APIs xDS (Envoy)

Tráfego Norte-Sul: Tráfego de rede que entra em um datacenter, rede ou cluster Kubernetes. Os diagramas de rede tradicionais foram desenhados com o tráfego de entrada que entra no data center na parte superior da página e desce (norte para sul) na rede.

Proxy: Um sistema de software que atua como intermediário entre os componentes de um endpoint.

Segmentação: Dividindo uma rede ou cluster em várias sub-redes.

Service mesh: Gerencia todo o tráfego de serviço a serviço (leste-oeste) em um sistema de software distribuído (potencialmente baseado em microservice). Fornece operações funcionais, como roteamento e suporte não-funcional, por exemplo, imposição de políticas de segurança, qualidade de serviço e limitação de taxa.

Service Mesh Interface (SMI): Uma interface padrão em andamento para services meshes implantados no Kubernetes.

Política de service mesh: Uma especificação de como uma coleção de serviços/endpoints tem permissão para se comunicar entre si e com outros endpoints de extremidade da rede.

Sidecar: Um padrão de implantação, no qual um processo, serviço ou container adicional é implantado juntamente com um serviço existente (pense na motocicleta sidecar)

Painel de vidro único (Single pane of glass): Uma interface do usuário ou console de gerenciamento que apresenta dados de várias fontes em uma exibição unificada.

Modelagem de tráfego (Traffic shaping): Modificação de fluxo de tráfego em uma rede, por exemplo, limitação de taxa ou perda de carga.

Mudança de tráfego (Traffic shifting): Migração de tráfego de um local para outro.

Sobre o Autor

Daniel Bryant está liderando a mudança nas organizações e na tecnologia. Seu conhecimento técnico atual concentra-se em ferramentas 'DevOps', plataformas de nuvem/contêiner e implementações de microsserviços. Daniel é um líder dentro da London Java Community (LJC), contribui para vários projetos de código aberto, escreve para sites técnicos conhecidos como InfoQ, DZone e Voxxed e apresenta-se regularmente em conferências internacionais como QCon, JavaOne e Devoxx.