BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Painel virtual: comunicação e governança de microservices usando service mesh

Painel virtual: comunicação e governança de microservices usando service mesh

Favoritos

Pontos Principais

  • Os frameworks service mesh são usados para manipular a comunicação serviço-a-serviço e oferecem uma plataforma para conectar, gerenciar, e proteger microservices.
  • O service mesh ajuda os desenvolvedores ao gerenciarem as funcionalidades que exigem codificação complexa, como decisões de roteamento, que são feitas em nível de mesh, não nas aplicações.
  • Ele também fornece as políticas de segurança que podem ser programadas no mesh. Por exemplo, pode-se configurar uma política que restrinja o tráfego de entrada da Internet a alguns serviços na mesh.
  • Frameworks mesh, como o Istio, funcionam perfeitamente em plataformas como o Kubernetes, mas há pontos a se considerar se usado em outras plataformas.
  • Proxies sidecar permitem o desacoplamento de suas aplicações dos aspectos operacionais do gerenciamento de comunicação de serviço de forma eficaz e confiável.

O service mesh é uma camada de infraestrutura dedicada à comunicação de serviço-a-serviço, e oferece uma plataforma para conectar, gerenciar, e proteger microservices.

O service mesh torna a comunicação entre microsserviços flexível e confiável. Ele fornece os recursos críticos necessários em ambientes de serviços distribuídos, como: resiliência, descoberta de serviço, balanceamento de carga, criptografia, autenticação e autorização, tolerância a falhas (por meio de nova tentativa de circuit breaker).

O InfoQ conversou com especialistas no assunto service mesh para saber mais sobre por que esses frameworks se tornaram componentes críticos de arquiteturas nativas de nuvem.

As seções abaixo fornecem detalhes dos integrantes do painel com os quais conversamos, perguntas que foram incluídas no painel virtual, e as respostas desses participantes.

Panelistas:

  • Matt Klein, Lyft
  • Dan Berg, IBM
  • Priyanka Sharma, Lightstep
  • Lachlan Evenson, Microsoft
  • Varun Talwar, Google
  • Yuri Shkuro, Uber
  • Oliver Gould, Buoyant

InfoQ: Poderia definir o service mesh e quais vantagens ele traz para áreas como interação e governança de microservices?

Matt Klein: Os dois problemas mais difíceis enfrentados pelos profissionais de microservices são a rede e a observabilidade, ou seja, como os serviços se comunicam de maneira confiável? Quando as coisas dão errado, como o problema pode ser rapidamente determinado e corrigido/ resolvido? Uma rede confiável de microservices e observabilidade requer uma infinidade de técnicas, incluindo descoberta de serviço, balanceamento de carga, timeouts, re-tentativas, circuit breakers, verificação de integridade, roteamento avançado, estatísticas, registro, rastreamento distribuído, e muito mais. Historicamente, a maioria das arquiteturas modernas construiu bibliotecas ricas em features em cada linguagem que a empresa usa para lidar com essas questões. Isso, por definição, exige a re-implementação e a manutenção de uma grande quantidade de funcionalidades sofisticadas em várias linguagens.

A ideia por trás do service mesh é usar um proxy "sidecar" fora do processo e executando ao lado de cada aplicação. Esse proxy implementa todas as necessidades sofisticadas de rede e observabilidade para uma arquitetura de microservices em um lugar único e com desempenho muito alto. Como o proxy implementa a funcionalidade necessária em um processo dedicado, ele pode funcionar junto com qualquer linguagem de aplicação. Quando cada aplicação tem um proxy sidecar associado e encaminha todo o tráfego através dele, a própria aplicação não precisa mais estar ciente dos detalhes da rede subjacente e pode tratá-la como uma abstração. Isso permite que os desenvolvedores se concentrem amplamente na lógica de negócios, independentemente das muitas linguagens que possam estar em uso na empresa.

Dan Berg: Service mesh é um termo usado para descrever a rede de microservices que compõem as aplicações e o gerenciamento das interações entre elas. Um exemplo disso é o Istio, uma tecnologia aberta que fornece uma maneira de os desenvolvedores conectarem, gerenciarem e protegerem de maneira transparente as redes de diferentes microservices - independentemente de plataforma, origem, ou fornecedor. O service mesh ajuda os desenvolvedores a serem mais produtivos ao mover a lógica complexa e propensa a erros do código da aplicação para o service mesh. Por exemplo, um service mesh gerencia roteamento e modelagem de tráfego, garante a comunicação segura entre serviços, captura a telemetria da rede, e a imposição de políticas de segurança para todos os serviços dentro do mesh. Ele garante maior resiliência de serviços com suporte de circuito integrado que lida com falhas de maneira elegante quando um serviço não consegue atingir seu destino.

Priyanka Sharma: Service mesh é uma camada de infraestrutura para comunicação de serviço-a-serviço. Ele garante a entrega confiável de suas mensagens em todo o sistema, e separa a lógica de negócios dos serviços, e são, em geral, chamados de sidecars ou proxies.

Como fragmentos de software em microservices, os service meshes passam de 'é bom ter' para essenciais. Com um service mesh, você não apenas garantirá comunicações de rede resilientes, mas também poderá gerenciar a observabilidade e o controle, sem alterar o tempo de execução da aplicação.

Os service meshes facilitam para que as empresas adotem microservices com ferramentas consistentes entre as equipes de desenvolvimento. Desenvolvedores individuais podem se concentrar em seus serviços e deixar que o mesh cuide das comunicações da camada de rede, bem como do ferramental em torno dos microservices.

Lachlan Evenson: Service mesh é um conjunto de aplicações que permite a comunicação uniforme de serviço-a-serviço em arquiteturas de microservices. Eles permitem que desenvolvedores e operadores de microservices interajam com os serviços dependentes de maneira prescrita e esperada. Isso ajuda na governança, fornecendo uma única interface e um único ponto de imposição de política para toda a comunicação, em vez de implementações sob medida ou padronizadas.

Varun Talwar: Service mesh é um padrão de arquitetura pelo qual todas as comunicações de serviço e funções comuns necessárias aos microservices são tratadas uniformemente por uma camada de plataforma (código externo). Quando uma camada de plataforma como essa pode uniformemente implementar funções comuns de rede como roteamento e balanceamento de carga, funções de resiliência como re-tentativas e timeouts, e funções de segurança como autenticação, autorização e monitoramento, e rastreamento de nível de serviço, ela pode facilitar significativamente o trabalho de desenvolvedores de microservices e habilitar uma infraestrutura inteligente que pode permitir que as empresas gerenciem em uma abstração de serviços mais alta (independente da rede e infraestrutura subjacentes).

Yuri Shkuro: O termo "service mesh" não é acurado. Na interpretação direta, ele poderia ser usado para descrever tanto a rede de microservices que compõem as aplicações distribuídas quanto as interações entre elas.

No entanto, recentemente, o termo tem sido aplicado principalmente a uma camada de infraestrutura dedicada a lidar com a comunicação de serviço-a-serviço, geralmente implementada como proxies de rede leves (sidecars) que são implantados ao lado do código da aplicação. O código da aplicação pode tratar qualquer outro serviço na arquitetura como um componente lógico único em execução em uma porta local no mesmo host. Ele libera o código de ter que saber sobre a topologia complexa de aplicativos nativos modernos da nuvem. Ele também permite que as equipes de infraestrutura concentrem sua energia na implementação de recursos avançados como roteamento, descoberta de serviços, quebra de circuitos, novas tentativas, segurança, monitoramento, etc. em um único componente sidecar, em vez de suportá-los em várias linguagens de programação e estruturas típicas de aplicativos modernos.

Oliver Gould: Um service mesh é uma camada de infraestrutura dedicada a tornar a comunicação em tempo de execução entre microservices segura, rápida, e confiável. No Twitter, aprendemos que essa comunicação é um determinante crítico do comportamento em tempo de execução da aplicação, mas, se você não estiver lidando com isso explicitamente, acabará com um sistema frágil e complexo. Um service mesh fornece ao operador o controle necessário para depurar e gerenciar essa comunicação. Se você desejar ir mais fundo, publicamos um texto detalhado sobre o que é um service mesh e por que você precisa de um, que pode ser encontrado aqui.

InfoQ: O padrão Enterprise Service Bus (ESB) tem sido popular nos últimos anos, especialmente em modelos SOA (Service Oriented Architecture). Como contrastar o padrão do service mesh com o que o ESB oferece?

Klein: Eu não vou debater as diferenças entre SOA e microservices, ou o ESB versus o service mesh. Para ser sincero, acho que há realmente pouca diferença e as mudanças de nome são principalmente impulsionadas por fornecedores que tentam diferenciar novos produtos. Computação e engenharia em geral são impulsionadas por mudanças iterativas. Nos últimos anos, a maioria das comunicações de SOA/microservices foi movida para o REST e IDLs (Interface Definition Languages) mais recentes, como Thrift e gRPC. Os desenvolvedores favoreceram a simplicidade por meio de chamadas de rede direta de bibliotecas em processo versus barramentos de mensagens centralizados. Infelizmente, a maioria das bibliotecas em processo em uso não estão solucionando suficientemente os pontos problemáticos operacionais que surgem ao executar uma arquitetura de microservices (Finagle e Hystrix/Ribbon são exceções, mas exigem o uso da JVM). Eu vejo service mesh como realmente apenas uma visão moderna da arquitetura do ESB, adaptada às tecnologias e processos que são agora aprovadas pelos profissionais de microservices.

Berg: Em alto nível, um ESB e um service mesh parecem ser similares na medida em que gerenciam a comunicação entre um conjunto de serviços. No entanto, existem diferenças fundamentais. Uma diferença importante é que as mensagens são enviadas para um ESB que determina para qual terminal enviar a mensagem. O ESB é um ponto centralizado para tomar decisões de roteamento, realizar transformações de mensagens, e gerenciar a segurança entre serviços.

Um service mesh, por outro lado, é uma abordagem descentralizada em que os proxies do lado do cliente são programados por meio do plano de controle do service mesh para gerenciar o roteamento, a segurança, e a coleta de métricas. Assim, o service mesh tira as principais responsabilidades da aplicação em vez de encapsular a funcionalidade dentro de um sistema centralizado, como um ESB. Isso torna o service mesh mais resiliente e se aprimora em um sistema altamente distribuído, como visto em aplicativos nativos da nuvem

Devido à abordagem do lado do cliente usada com o service mesh, é possível ter regras de roteamento, recursos de imposição de políticas, e recursos de resiliência muito mais sofisticados, como circuit breakers, do que o que pode ser obtido com um ESB. Outra diferença importante é que a lógica da aplicação não sabe que está embutida em um service mesh. O mesh se ajusta para adotar aplicações. Com um ESB, a lógica deve ser ajustada para participar do ESB.

Priyanka: ESBs e service meshes têm muito em comum, particularmente o motivo pelo qual foram construídos. Os ESBs se tornaram populares na era SOA - eles gerenciavam as comunicações de rede e também cuidavam de parte da lógica de negócios. Eles foram construídos pela mesma razão que estamos criando service meshes hoje: à medida que o número de serviços aumenta, a consistência e a confiabilidade em todo o sistema são necessárias, e um proxy de barramento de mensagens/sidecar é uma ótima maneira de conseguir isso.

Os service meshes são diferentes dos ESBs porque são criados especificamente para arquiteturas de microservices nativas na nuvem.

Os ESBs não funcionam bem no mundo da computação em nuvem. Eles assumem grande parte da lógica de negócios dos serviços e retardam o desenvolvimento do software, criando outra dependência e um silo organizacional.

Resumindo, eu diria que service meshes são a evolução da próxima geração da tecnologia ESB. Os principais motivadores são os mesmos, mas a implementação é mais sofisticada e feita sob medida para a era nativa da nuvem.

Evenson: Assim como o ESB é sinônimo de SOA,o service mesh o é para microservices. A principal diferença é o escopo e o tamanho dos serviços implementados pelo ESB e pelo service mesh. O ESB é muito maior em termos de conjunto de recursos e suporte ao sistema de backend. Ele normalmente se concentra em grandes empresas e padrões e protocolos da indústria, enquanto os service meshes são leves o suficiente para agregar valor aos primeiros microservices.

Talwar: ESBs lidavam com uma arquitetura centralizada, onde uma peça central carregava toda a inteligência para tomar decisões. Com o passar do tempo, a peça central tornou-se complicada e não se encaixa em uma arquitetura de microservices, em que cada equipe/serviço deseja configurar, testar, implantar e dimensionar seus serviços em um ritmo rápido.

A nova arquitetura de service meshes representa uma inversão do padrão SOA de "endpoints ineficientes, canais inteligentes (grandes aplicativos hierárquicos monolíticos)" para "endpoints inteligentes (funções específicas de serviço), canais ineficientes."

Shkuro: A relação entre o ESB e o service mesh é semelhante a relação entre aplicações baseadas em monolíticos e microservices. Ambas servem a uma função semelhante, a principal distinção é em como elas estão fazendo isso. O ESB é um sistema único instalado entre todos os outros serviços da arquitetura. Ele fornece um único ponto de controle sobre cada troca de mensagens entre serviços. Ele também introduz um ponto único de falha e aumenta a latência de todas as comunicações. Em contraste, um service mesh implementado via sidecars executa as mesmas funções, mas de maneira distribuída e descentralizada. Um plano de controle de service mesh fornece a mesma autoridade centralizada de políticas e decisões de roteamento que o ESB, embora não esteja no caminho crítico de cada solicitação. O plano de dados é implementado pelos sidecars ao lado do código da aplicação. Por exemplo, em uma configuração típica do Kubernetes cada instância do microservice é executada em um conjunto ao lado de sua própria cópia do sidecar de service mesh. Todo o tráfego dentro e fora do microservice passa por essa instância do sidecar, sem dependências rígidas de outros subsistemas centralizados.

Gould: As metas não são tão diferentes, mas as prioridades e os detalhes da implementação são extremamente diferentes. Os ESBs tendem a ser implementados como um único ponto de falha centralizado, enquanto um service mesh como o Conduit usa proxies sidecar para serem explicitamente descentralizados e escalonáveis.

Além disso, é possível usá-lo em apenas uma pequena parte de uma aplicação, o que significa que a adoção pode ser incremental e não requer um bloqueio total da arquitetura. Por fim, o service mesh está fortemente focado nos aspectos operacionais da comunicação e tenta evitar qualquer percepção real dos detalhes da lógica de negócios do aplicativo. Os objetivos do service mesh são operacionais, não arquiteturais, ou integracionais.

InfoQ: Quem na empresa deve se preocupar com um service mesh? Isso é algo que um desenvolvedor típico deve estar ciente ao implantar aplicações?

Klein: A ideia por trás do service mesh é tornar a rede essencialmente abstrata para os desenvolvedores de aplicações. Os desenvolvedores ainda precisam entender os conceitos gerais de rede, como tentativas, timeouts, roteamento, etc. (já que estarão envolvidos com a configuração), mas não precisam saber como são implementados. Assim, o desenvolvedor típico deve se preocupar com o service mesh, pois isso significa que eles podem excluir muitos códigos de rede e de observação únicos e obter uma solução uniforme, mais rica em recursos, e mais confiável de graça!

Berg: Usando o service mesh e uma plataforma de nuvem forte, as empresas menores podem criar aplicativos e recursos que anteriormente apenas as grandes empresas poderiam dedicar recursos, sob o modelo tradicional de usar código personalizado e reconfigurar cada servidor. A nuvem, o service mesh, e o microservices dão aos desenvolvedores a flexibilidade de trabalhar em diferentes linguagens e tecnologias, resultando em maior produtividade e velocidade.

Um desenvolvedor típico deve estar ciente de que está participando de um service mesh e entender que está se comunicando com outros serviços no mesh. Eles devem aceitar o fato de que o service mesh os ajuda a evitar recursos que exigem codificação complexa, como decisões de roteamento, porque isso é feito no nível do mesh, e não na própria aplicação. Isso acaba permitindo que o desenvolvedor seja mais produtivo. As informações de telemetria, bem como a capacidade de injetar falhas, são uma poderosa ferramenta de desenvolvimento para detectar problemas e, finalmente, eliminá-los da aplicação.

Priyanka: As equipes de infraestrutura e plataforma costumam ser as pessoas que projetam e implementam service meshes nas empresas de software. É fundamental que essas equipes e suas lideranças de engenharia trabalhem juntas na melhor estratégia e implementação para a empresa.

Embora os service meshes melhorem a produtividade dos desenvolvedores de aplicações separando a comunicação de rede dos serviços, eles devem estar cientes da descoberta de serviço específica e dos recursos de observação oferecidos. Isso ajudará os desenvolvedores a saber o que funcionará automaticamente e qual funcionalidade eles precisam personalizar. Por exemplo, se o service mesh for instrumentado com o OpenTracing, os desenvolvedores terão a garantia de observabilidade de nível superior em todo o sistema. Eles podem, então, optar por instrumentar seus serviços com o OpenTracing para obter traços mais detalhados de bugs ou degradações de desempenho.

Evenson: Um service mesh deve ser transparente para o desenvolvedor, e os serviços que ele fornece são tratados como um recurso da plataforma. No entanto, o pessoal de operação/sustentação terão interesse nos service meshes, já que eles são outra peça da pilha que requer cuidado e atenção.

Talwar: Um dos aspectos interessantes do service mesh é que ele reúne diversas partes interessadas, como o desenvolvedor, o operador, a segurança de produção, operações de rede, CIO, CTO, etc. Para o desenvolvedor, quando o service mesh é bem implementado, ele não precisa escrever código para muitas funções comuns (idealmente apenas lógica de negócios) e a implantação no mesh cuida das funções (por meio de políticas) em tempo de execução.

Shkuro: A solução de service mesh é normalmente de propriedade da equipe de infraestrutura/rede. Um desenvolvedor típico não precisa saber muito sobre isso. Eles podem precisar saber que para fazer uma solicitação ao serviço X, é preciso enviá-lo para a porta Y local reservada para esse serviço, ou enviar todas as solicitações para a mesma porta, mas que deve indicar o serviço de destino via cabeçalho HTTP, ou uma API especial do framework RPC. É claro que, em muitas empresas o mesmo desenvolvedor também é a pessoa de plantão por esses serviços, o que significa que também é útil estar ciente de como monitorar o processo sidecar em caso de um problema. Na Uber, temos uma ferramenta que cria um dashboard automaticamente para cada serviço exibindo métricas de muitos componentes de infraestrutura usados pelo serviço, incluindo métricas geradas pelo processo sidecar, como contagens de solicitações e erros, histogramas de latência de solicitações, etc.

Gould: A empresa deve se importar porque ele traz uma camada de padronização para as operações em tempo de execução, semelhante ao modo como o Docker e o Kubernetes fornecem a padronização das operações em tempo de execução. Os operadores de plataforma (o pessoal que trouxe o Docker e o Kubernetes para as empresas) adoram o service mesh porque isso os tira do caminho crítico para depurar e operar microservices.

Os desenvolvedores (e, em geral, os proprietários de serviços) se beneficiam porque podem separar seu código da aplicação da lógica operacional que pertence ao tempo de execução. O mesh fornece recursos operacionais que permitem aos desenvolvedores mover-se mais rapidamente, com menos medo de quebrar coisas.

InfoQ: Como as soluções de service mesh suportam a resiliência em termos de novas tentativas de serviço, timeouts, circuit breaker, recuperação de falhas, etc.?

Klein: O proxy sidecar implementa uma vasta gama de recursos avançados, como service discovery, balanceamento de carga, novas tentativas, timeouts, circuit breakers, roteamento com reconhecimento de zona, etc., em benefício da aplicação. Esses recursos são muito difíceis de serem implementados corretamente, e as bases de dados de microservices são geralmente repletas de versões com erros ou incompletas. É substancialmente mais eficiente descarregar esse tipo de funcionalidade em uma única entidade que pode ser implementada uma vez, com alto desempenho, e substancialmente controlada.

Berg: As funcionalidades de aplicações que estão fortemente acopladas à rede, como circuit breakers e timeouts, são explicitamente separadas do código de serviço/lógica de negócios, e o service mesh facilita essas funcionalidades na nuvem e fora da caixa.

Os sistemas distribuídos em grande escala têm uma característica chave: há muitas chances de que pequenas falhas localizadas se transformem em falhas catastróficas em todo o sistema.

O service mesh foi projetado para proteger contra essas escalações usando a agilidade e a portabilidade das ferramentas de nuvem, como containers, para eliminar a carga e falhar rapidamente quando os sistemas subjacentes se aproximam de seus limites.

Tudo isso é feito no proxy do lado do cliente (sidecar) disponível na aplicação. O sidecar é responsável por encaminhar uma solicitação para um serviço em que outro proxy de sidecar recebe a solicitação antes de encaminhar para a aplicação. Quando a solicitação está sendo feita, o proxy tropeçará automaticamente no circuit breaker e redirecionará potencialmente o tráfego para outra versão quando o serviço upstream não estiver acessível. Falhas podem ocorrer devido a tempos limite mal definidos entre os serviços. Um service mesh como o Istio ajuda a evitar experiências ruins do usuário e interrupções de tempos de espera porque ele permite que você injete falhas diretamente no mesh, permitindo que você teste e valide os tempos limite de conexão sem precisar adivinhar.

Evenson: O componente de plano de dados do service mesh fica no caminho de todas as comunicações de dados em todos os microservices. Dado esse posicionamento, eles estão cientes da malha de dados e, portanto, podem tomar decisões direcionadas por políticas que ofereçam suporte a recursos de resiliência.

Talwar: Os service meshes têm duas partes. Plano de dados e plano de controle. Planos de dados acionados por API conectáveis, como o Envoy (usado no Istio), permitem a configuração de novas tentativas e tempos limites para que possam ser configurados e alterados facilmente. O Envoy também tem a capacidade de definir a configuração de disjuntores, bem como verificações de integridade grosseiras e refinadas de todas as instâncias no pool para balanceamento de carga e roteamento de instâncias de falha/alta latência. Veja mais detalhes aqui.

Shkuro: Muitos desses recursos podem variar entre implementações específicas do service mesh. As técnicas em si não são novas, mas muitas ainda são uma área ativa de pesquisa e inovação.

O que é especial sobre service meshes é que eles abstraem essas preocupações do código do aplicativo e encapsulam em uma única camada de infraestrutura.

Isso mantém o código da aplicação leve e permite que os desenvolvedores de service mesh façam iterações rapidamente e desenvolvam as melhores soluções de classe para esses problemas. Por exemplo, considere o problema dos failovers. Quando um determinado serviço em uma determinada zona de disponibilidade enfrenta problemas, geralmente a abordagem mais segura para a recuperação é transferir o tráfego para outra zona de disponibilidade, desde que ele tenha capacidade excessiva suficiente. O service mesh pode fazer isso de forma completamente transparente para o restante dos serviços na arquitetura, alterando algumas configurações em seu plano de controle. Suportar esse recurso de failover em todos os serviços seria muito mais difícil.

Gould: O recurso de confiabilidade mais importante fornecido por um service mesh é o balanceamento de carga da Camada 7. Ao contrário dos balanceadores de carga L3 / L4, os service meshes, como o Conduit, estão cientes dos metadados por solicitação e podem ajudar a rotear automaticamente instâncias lentas ou com falha, falhas de rack, etc.

Uma vez que esses balanceadores de carga estejam cientes dos Objetivos de Nível de Serviço (geralmente em termos de latência e taxa de sucesso), eles podem tomar decisões incrivelmente inteligentes sobre quando o tráfego não deve ser enviado para uma determinada instância.

O service mesh também pode tentar novas solicitações automaticamente para a aplicação, se isso for seguro. Observe, no entanto, que novas tentativas podem piorar as interrupções: você pode ficar preso em loops de repetição de longa duração que vinculam recursos e podem causar falhas em cascata em todo o sistema. Por isso, é importante parametrizar corretamente, por exemplo, aplicar uma abordagem baseada em orçamento para novas tentativas, como fizemos no Linkerd. Isso melhora drasticamente o comportamento do pior caso.

InfoQ: Como um service mesh suporta os recursos de segurança, como autenticação e autorização? Como isso pode ajudar na aplicação de políticas de segurança em tempo de execução?

Klein: Embora a maioria das equipes de segurança diga que deseja autenticação e autorização entre serviços, pouquíssimas empresas acabam implementando esta solução em escala. Isso ocorre porque a autenticação e a autorização do sistema são problemas muito difíceis! O service mesh ajuda muito nesse sentido. A autenticação pode ser implantada com relativa facilidade usando técnicas como mTLS e SPIFFE. Os desenvolvedores de aplicações/segurança precisam especificar a política, mas não precisam se preocupar sobre como a criptografia e a autenticação subjacentes são implementadas. Da mesma forma, os proxies sidecar podem usar dados de autenticação derivados de sessões mTLS para conduzir a autorização no nível de roteamento L7. Por exemplo, especificar que service_a só pode ser acessado pelo serviço A, e que service_b só pode ser acessado pelo serviço B.

Berg: Isso decorre de alguns fatores-chave. Um service mesh tem um componente que gerencia a autorização dentro do mesh. Esse componente de autenticação é responsável por programar os proxies do lado do cliente para estabelecer automaticamente a confiança entre os serviços no mesh usando TLS mútuo (segurança da camada de transporte). Se desenvolvidos adequadamente, esses certificados terão uma vida útil curta, de modo que, se um serviço for comprometido, haverá apenas uma pequena janela de violação de segurança antes de o certificado ser reciclado, tornando o original inútil.

Um service mesh tem políticas de segurança que podem ser programadas no mesh. Por exemplo, você pode configurar uma política que restrinja o tráfego de entrada da Internet a alguns serviços no mesh. Se você quiser permitir somente o tráfego de entrada da Internet para o serviço A, todos os outros tráfegos de entrada na Internet serão rejeitados se desviarem para um serviço diferente de A, pois o proxy do lado do cliente intercepta todo o tráfego de entrada e saída para as aplicações. Um service mesh impõe uma forte declaração de identidade entre os serviços e limita as entidades que podem acessar um serviço. Tudo isso é feito sem alterar uma linha do código do aplicativo.

Priyanka: Os Service meshes criam mais flexibilidade e controle em tempo de implementação, porque menos suposições são incluídas no código do aplicativo. Eu acho que seria melhor que os provedores de service mesh do Painel falassem sobre suas implementações específicas para resiliência e autenticação.

Evenson: O plano de controle do service mesh só pode fornecer features que são inerentemente suportadas na plataforma em que o service mesh está sendo executado. No caso de um service mesh em execução no Kubernetes, a autenticação e a autorização são expressas no service mesh e convertidas nos recursos subjacentes do Kubernetes, onde são aplicadas.

Talwar: Uma vez que os service meshes interceptam toda a comunicação de serviço-serviço, eles podem criptografar e autenticar fortemente toda a comunicação sem envolvimento do desenvolvedor (grande vantagem) e também permitir políticas de autorização para quem pode chamar quem. Como todo o tráfego está fluindo pelo plano de dados do service mesh, garantir a criptografia para todos os protocolos suportados / encapsulados e permitir ou barrar o ingresso ou saída para cada serviço pode ser imposto pelo service mesh.

Shkuro: Um grande benefício da abordagem sidecar é que sua identidade poderia ser usada de forma intercambiável com a identidade do microservice, porque a política de rede nos containers pode ser configurada de modo que o microservice não seja acessível por qualquer outro meio exceto o sidecar. Isso permite mover muitas preocupações de segurança para o sidecar e padronizá-las em toda a empresa.

A autenticação pode ser feita exclusivamente pelo sidecar, por exemplo, encerrando todo o TLS no sidecar e usando a comunicação não criptografada entre a aplicação e o sidecar. A identidade do chamador pode ser passada para o código da aplicação por meio do cabeçalho de solicitação confiável, caso precise executar autorização avançada adicional. Algumas formas simples de autorização, como "somente o serviço X tem permissão para acessar meu endpoint Y" também podem ser movidas completamente para o processo de sidecar e controladas por meio de políticas centralizadas. Essas políticas podem até ser atualizadas em tempo de execução sem afetar o código da aplicação.

Gould: Uma vez que a orquestração esteja pronta, via Kubernetes, por exemplo, as abordagens tradicionais de segmentação de rede para a identidade começam a quebrar. O service mesh possibilita que os serviços recuperem uma maneira consistente e segura de estabelecer identidade em um datacenter e, além disso, façam isso com base em operações primitivas criptográficas fortes em vez de em topologia de implementação. O Conduit, por exemplo, pode fornecer ou integrar-se às Autoridades Certificadoras para automatizar a distribuição de credenciais TLS para serviços, de forma que quando dois serviços habilitados pelo mesh se comunicam, eles têm uma forte prova criptográfica de seus pares. Uma vez estabelecidas essas primitivas, elas podem ser usadas para construir políticas de controle de acesso.

InfoQ: Qual é a rampa de acesso para alguém que está aprendendo e implantando service meshes hoje? Quais arestas devem ser aparadas?

Klein: Para ser honesto, ainda é cedo. A implantação bem-sucedida de um service mesh em uma grande arquitetura de microservices é possível, mas ainda requer um pouco de conhecimento de topologia de redes e sistemas. Como escrevi extensivamente, uma implantação de service mesh é composta pelo "plano de dados" e o "plano de controle". O plano de dados passa por todos os pacotes e executa o balanceamento de carga, tentativas, timeouts, etc. O plano de controle coordena todos os planos de dados fornecendo configurações para descoberta de serviço, tabelas de rotas, etc. Planos de dados como o Envoy, HAProxy, e NGINX são robustos e totalmente prontos para produção. No entanto, desenvolver e implementar um plano de controle e as configurações associadas que funcionem para uma empresa é, na verdade, a parte difícil.

O Envoy é uma ferramenta usada em um grande número de tipos de implantação. Isso significa que ele tem uma variedade estonteante de opções que, para os não iniciados, podem ser muito intimidantes. Infelizmente, a adaptabilidade geralmente não vai de encontro a facilidade de uso. Por outro lado, os planos de controle que estão mais ligados às práticas e ferramentas de desenvolvimento de uma empresa provavelmente terão menos opções, mais opiniões, e serão mais fáceis para a maioria dos desenvolvedores entender e usar. Assim, com o passar do tempo, acredito que, como as arquiteturas de microservices padronizam ferramentas como o Kubernetes, o service mesh será uma experiência mais "fora da caixa" por meio de projetos de planos de controle como o Istio que são construídos sobre o Envoy.

Berg: Semelhante à adoção de uma estratégia de nuvem, um service mesh é rico em recursos e funções, mas pode ser esmagador se você tentar usar todos os seus recursos no primeiro dia. Deve-se adotar o service mesh em pequenas porções para evitar asfixia. Por exemplo, se você deseja visibilidade da complexidade dos microservices, adote um service mesh apenas para telemetria, não para segurança ou roteamento. Comece de maneira simples e aumente o uso do service mesh conforme suas necessidades crescem.

Priyanka: Com base no que ouvimos da comunidade de usuários finais do OpenTracing, service meshes são uma tecnologia bem-vinda que torna os microservices mais robustos. Atualmente, as pessoas estão gastando tempo para entender todas as opções, e quanto mais material educacional (como este artigo) estiver disponível, melhor.

Evenson: Isso realmente depende do service mesh. Um bom recurso é que você não precisa alterar sua aplicação para suportar o service mesh. A forma com que os desenvolvedores têm que modificar as definições de infraestrutura para implantar o componente do plano de dados do service mesh de modo que ele possa se orquestrar o caminho de todas as comunicações de dados é uma das arestas brutas a serem aparadas.

Talwar: Hoje, os service meshes como o Istio funcionam perfeitamente em plataformas como o Kubernetes, mas existem arestas ásperas ao usá-lo em outras plataformas. Outra área de foco deve ser para os usuários tentarem incrementalmente várias partes do Istio, como apenas a segurança, o monitoramento, ou a resiliência sem a carga cognitiva de entender outras partes do Istio. Acho que mais trabalho nessas duas áreas fará com que o Istio seja mais digerível e amplamente utilizável. Uma outra dificuldade é o desempenho bem testado e a estabilização do ambiente de produção se protegendo das possíveis vulnerabilidades que podem afetar o ambiente, que é o trabalho que está em andamento agora mesmo no projeto de Istio.

Shkuro: O Kubernetes e o Istio tornam a implantação do service mesh bastante direta, mas para muitas empresas que não usam o Kubernetes há uma curva de aprendizado. Para começar, o sistema de implantação usado na empresa precisa suportar a capacidade de executar mais de um container como uma unidade lógica de uma instância de serviço (o conceito de "pod" no Kubernetes). Como alternativa, o processo de service mesh pode ser executado como um agente único no host, o que ainda resolve alguns dos problemas, como roteamento e descoberta de serviço, mas torna os outros recursos como segurança e autenticação impossíveis.

De algumas conversas informais que tive com outras empresas, executar o plano de controle para o service mesh é provavelmente a parte mais difícil. O plano de controle precisa ser profundamente integrado ao restante da arquitetura, por exemplo, ele precisa estar ciente das implantações de serviço para controlar a descoberta de serviços, a verificação de integridade, o balanceamento de carga/failovers. O projeto Istio está dando grandes passos para abstrair a funcionalidade do plano de controle.

Gould: Estamos apoiando a Linkerd em produção há quase dois anos. Aprendemos muito sobre as arestas mais ásperas: algumas coisas que esperávamos aprender, mas muitas vezes coisas que só são óbvias em retrospectiva. Uma lição surpreendente foi que, embora o Linkerd seja excelente em altíssima escala, muitos usuários se beneficiariam muito com uma abordagem reduzida otimizada pela simplicidade em vez de potência máxima e flexibilidade máxima. Deveria ser fácil começar com um service mesh! Queremos reduzir a complexidade do gerenciamento de serviços distribuídos, e não adicioná-la. Esse insight levou ao nosso recente trabalho com o Conduit, e se tudo que você precisa para começar a utilizá-lo não estiver em nosso guia com orientações de como iniciar, eu adoraria saber o motivo.

De maneira mais geral, acho que a armadilha de adotar um service mesh é tentar fazer muita coisa de uma só vez. A adoção do service mesh precisa ser incremental em sua criticidade e no escopo dos problemas que ele resolve. É um novo tipo de ferramenta, e as adoções mais bem-sucedidas que vimos foram incrementais. Nosso conselho é mantê-lo tão simples quanto o possível.

InfoQ: Poderia falar sobre o padrão de projeto sidecar e quais recursos de plataforma podem ser implementados com sua utilização?

Klein: Como falei anteriormente, o proxy sidecar é a chave para abstrair a rede das aplicações. Consideramos a rede localhost como confiável. Usando essa suposição, a aplicação só precisa estar ciente de seu proxy sidecar, e o proxy pode manipular todo o resto (além da propagação de contexto).

Berg: O sidecar é um proxy do lado do cliente que é implantado com cada aplicação (isto é, container). Um serviço que possui implantações com o sidecar ativa automaticamente o serviço com o mesh. Ele é conceitualmente anexado a aplicação pai e a complementa fornecendo recursos de plataforma. Assim, o sidecar fornece um ponto de controle de rede crítico. Com esse padrão de design, seu microservice pode usar o sidecar como um conjunto de processos dentro do mesmo container do microservice ou como um sidecar em seu próprio container para aproveitar recursos como roteamento, balanceamento de carga, resiliência (como quebra de circuito e novas tentativas), monitoramento de profundidade, e controle de acesso.

Priyanka: O padrão Sidecar é basicamente o padrão Plugin ou Driver, só que para plataformas. Ao abstrair os detalhes da implementação da aplicação para rede, métricas, criação de log, e outros subcomponentes que possuem interfaces padrão, os operadores obtêm mais controle e flexibilidade na forma como criam sua implantação.

Evenson: O projeto sidecar permite que você manipule o ambiente de execução do Linux sem precisar alterar o código da aplicação. Normalmente, um componente de plano de dados de service mesh é implementado como um sidecar e o roteamento para esse namespace de rede no kernel do Linux é modificado para rotear todo o ingresso/saída por meio do componente de plano de dados.

Talwar: Sidecar é um padrão em que uma imagem de co-processo/container fica ao lado da aplicação e pode atuar como um parceiro confiável que pode ser atualizado independentemente e gerenciado por uma equipe separada, mas compartilha seu ciclo de vida com a aplicação. Os recursos de plataforma que um sidecar pode executar incluem registro, relatórios, autenticação, verificações de políticas para cota, etc.

Shkuro: Não há acordo estrito na indústria sobre o que constitui um padrão Sidecar. Por exemplo, Brendan Burns, do Google, consideraria o sidecar service mesh que discutimos aqui como um exemplo do padrão Ambassador, porque se preocupa apenas com o modo como a aplicação se comunica com o resto do mundo, enquanto a documentação do Microsoft Azure usa uma definição mais generosa que inclui muitas tarefas periféricas, incluindo abstração de plataforma, comunicação por proxy, configuração, registro, etc. Pessoalmente, eu prefiro a última definição, onde o padrão Ambassador é uma subclasse do padrão Sidecar.

Em essência, o padrão Sidecar recomenda extrair funcionalidades comuns de aplicações de negócios e empacotá-las em outro processo executado em um container sidekick. É um princípio bem conhecido de decomposição. Ao extrair as partes comuns em containers reutilizáveis, liberamos as aplicações de ter que reimplementar esses recursos, potencialmente em várias linguagens de programação. É semelhante a dividir as aplicações monolíticas herdadas em microsserviços separados, exceto que o ciclo de vida do sidecar é o mesmo que o do serviço pai e os usamos principalmente para funções relacionadas à infraestrutura.

Gould: Fundamentalmente, um sidecar é apenas outro container. Não é nada mágico. Com os proxies de sidecar podemos gerenciar a lógica operacional o mais próximo possível da aplicação sem estarmos realmente dentro do código. A ideia do service mesh é dissociar as aplicações dos aspectos operacionais do gerenciamento da comunicação de serviço de forma eficaz e confiável. Com o padrão sidecar, podemos fazer coisas como fornecer e validar identidade para aplicações, já que o sidecar necessariamente tem o mesmo nível de privilégios do serviço para o qual ele é proxy. Essa é a maior diferença entre os sidecars ou, por exemplo, implantações por host.

Sobre os integrantes deste painel

Matt Klein é engenheiro de software na Lyft e arquiteto da Envoy. Matt vem trabalhando em sistemas operacionais, virtualização, sistemas distribuídos, redes e tornando os sistemas fáceis de operar por mais de 15 anos em uma variedade de empresas. Alguns destaques incluem liderar o desenvolvimento do proxy de ponta C++ L7 do Twitter e trabalhar em computação de alto desempenho e redes na Amazon EC2.

Dan Berg é engenheiro de renome na unidade de nuvem da IBM. Daniel Berg é responsável pela estratégia técnica e pela implementação da plataforma de containers e microservices disponível na IBM Cloud. Nessa função, Daniel tem um profundo conhecimento de tecnologias de containers, incluindo Docker e Kubernetes, e possui vasta experiência na criação e operação de serviços nativos em nuvem e altamente disponíveis. Ele também é um dos principais colaboradores do projeto de service mesh do Istio.

Priyanka Sharma é uma empreendedora apaixonada por construir produtos para desenvolvedores e desenvolvê-los por meio de comunidades de código aberto. Ela atualmente dirige o 'Open Source Partnerships', na LightStep, e é colaboradora do projeto OpenTracing, um projeto CNCF que fornece APIs livres de padrões de fornecedores para rastreamento distribuído. Ela atua como consultora de startups nas indústrias HeavyBit, uma aceleradora de produtos para desenvolvedores. Você pode seguí-la no Twitter @pritianka.

 Lachlan Evenson é um evangelista e defensor de aplicações nativas na nuvem. Ele passou os últimos dois anos e meio trabalhando com o Kubernetes e possibilitando jornadas nativas na nuvem. Ele acredita em código aberto e é um membro ativo da comunidade. Lachlan dedica muito de seu tempo ajudando a tornar os projetos nativos de nuvem a rodarem bem no Azure.

 

Varun Talwar é Product Manager no Google Cloud; ele pode ser encontrado em @grpcio e @IstioMesh

 

 

Yuri Shkuro é engenheiro de equipe da Uber Technologies, trabalhando com rastreamento, confiabilidade, e desempenho de sistemas distribuídos. Yuri é coautor do padrão OpenTracing (um projeto CNCF) e líder tecnológico da Jaeger, o sistema de rastreamento distribuído de código aberto da Uber.

 

Oliver Gould é CTO e cofundador da Buoyant, onde lidera os esforços de desenvolvimento de código aberto para os projetos de service mesh Linkerd e Conduit. Antes de ingressar na Buoyant, ele era engenheiro de infraestrutura de pessoal no Twitter, onde era o líder tecnológico das equipes de Observabilidade, Tráfego e Configuração e Coordenação. Ele é o criador do Linkerd e um dos principais colaboradores da Finagle, a biblioteca RPC de alto volume usada no Twitter, Pinterest, Soundcloud, e muitas outras empresas.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT