BT

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

Contribuir

Tópicos

Escolha a região

Início Artigos API Gateways e Service Meshes: abrindo a porta para a modernização de aplicações

API Gateways e Service Meshes: abrindo a porta para a modernização de aplicações

Favoritos

Pontos Principais

  • A modernização de aplicações, dissociando-as da infraestrutura subjacente na qual estão executando, pode permitir a inovação (transferindo cargas de trabalho para a nuvem ou serviços externos baseados em ML), reduzir custos, e melhorar a segurança.
  • As estruturas de tecnologia de contêiner e orquestração, como o Kubernetes, separam as aplicações da malha de computação, mas também precisam ser dissociados na infraestrutura de rede.
  • Um API Gateway pode dissociar aplicações de consumidores externos, roteando dinamicamente solicitações de usuários finais e terceiros para várias aplicações internas, independentemente de onde elas são implantadas no data center.
  • Um service mesh desacopla aplicações de consumidores internos, fornecendo transparência do local, roteando dinamicamente solicitações internas de serviço a serviço, independentemente de onde elas estejam expostas na rede.
  • O API gateway e o service mesh, ambos empoderados pelo Envoy Proxy, podem ser usados para rotear do usuário final para os serviços implementados no servidor bare metal, VMs, e Kubernetes. Essa combinação de tecnologias permite uma abordagem incremental da migração de aplicações e pode fornecer tráfego criptografado de ponta a ponta (TLS), além de maior observabilidade.

Um dos principais objetivos ao modernizar os sistemas de software é desacoplar aplicações da infraestrutura subjacente na qual eles estão executando. Isso pode oferecer muitos benefícios, incluindo: promoção da inovação, por exemplo, migrar cargas de trabalho para tirar proveito dos serviços de ML e big data na nuvem, redução de custos através da alocação mais eficiente de recursos ou da colocação de aplicações; e aprimorando a segurança através do uso de abstrações mais apropriadas ou da atualização e correção de componentes mais eficientes.

O uso de containers e estruturas de orquestração como o Kubernetes pode dissociar a implantação e execução de aplicações do hardware subjacente. No entanto, nem tudo pode ser migrado para esse tipo de plataforma e, mesmo que possam, as empresas geralmente desejam que esse seja um processo incremental. Portanto, é necessária uma camada adicional de abstração que dissocie o roteamento de tráfego da infraestrutura de rede: na borda, por meio de um ingress ou API gateway, e em um datacenter, por meio do service mesh.

Na Datawire, trabalhamos em estreita colaboração com a equipe HashiCorp nos últimos meses e lançamos recentemente uma integração entre o Ambassador API gateway e o Consul service mesh. A combinação dessas duas tecnologias permite que o roteamento de tráfego das aplicações seja totalmente dissociado da implantação e infraestrutura de rede subjacentes. Usando o poder do Envoy Proxy, ambas as tecnologias fornecem roteamento dinâmico da borda e serviço-a-serviço entre bare metal, VMs, e Kubernetes. A integração também permite TLS de ponta-a-ponta e adiciona suporte para outros requisitos multifuncionais.

Modernização de aplicações: separando infraestrutura e aplicações

Muitas empresas estão realizando programas de "modernização de aplicações" como parte de uma iniciativa maior de transformação digital. Os objetivos são muitos, mas geralmente focam em aumentar a capacidade de inovar por meio da modularização da funcionalidade e da integração com serviços de ML e big data na nuvem, melhorando a segurança, reduzindo custos e implementando recursos adicionais de observabilidade e resiliência no nível da infraestrutura. Um esforço de modernização de aplicações é frequentemente acompanhado de uma mudança em direção a padrões de arquitetura moderna de alta cardinalidade que se esforçam para serem pouco acoplados, como microservices e FaaS (função como serviço), e a adoção de uma abordagem de DevOps ou responsabilidade compartilhada para trabalhando.

Um dos principais objetivos técnicos da modernização de aplicações é dissociar aplicações, serviços, e funções da infraestrutura subjacente. Várias abordagens para isso estão sendo promovidas pelos fornecedores de nuvem.

  • A AWS Outposts leva os serviços e modelos operacionais da AWS para o datacenter existente do usuário, por meio da instalação de hardware personalizado totalmente gerenciado pela AWS.
  • O Azure Stack é uma extensão dos serviços do Azure que permite aos usuários criar e executar consistentemente aplicativos híbridos na nuvem do Azure e em seu próprio hardware local.
  • O Google Anthos estende os principais serviços de GCP para a infraestrutura de um usuário ou outra nuvem por meio de uma camada de abstração baseada em software e plano de controle associado.

Outros projetos, como Ambassador, Consul, Istio, e Linkerd, têm como objetivo desenvolver as abstrações existentes baseadas em contêineres e independentes de nuvem para implantação, além de fornecer uma camada adicional de abstração na rede para permitir a dissociação de aplicativos e infraestrutura. O Docker popularizou o uso de contêineres como uma unidade de implantação, e o Google reconheceu que a maioria dos aplicativos foi implantada como uma coleção de contêineres, que eles chamaram de pod no Kubernetes.

Aqui, os contêineres compartilham um espaço de nome da rede e do sistema de arquivos e os contêineres utilitários que fornecem coleta de log ou métrica podem ser compostos com aplicações. A funcionalidade comercial implantada nos pods é exposta através de uma abstração de "serviço", que fornece um nome e um ponto de extremidade de rede. O uso dessa abstração permite que a implantação e a liberação sejam separadas. Várias versões de um serviço podem ser implantadas a qualquer momento e a funcionalidade pode ser testada ou liberada roteando seletivamente o tráfego para os pods de back-end (por exemplo, tráfego de "sombreamento" ou "canary releasing"). Esse roteamento dinâmico é normalmente obtido por meio de proxies, tanto na borda (um "proxy de borda" ou "gateway API") quanto entre serviços (os proxies entre serviços, que coletivamente são chamados de service mesh).

Um dos maiores desafios para muitas organizações é implementar esse desacoplamento de aplicações e infraestrutura sem interromper os usuários finais e as equipes internas de desenvolvimento e operações. Devido à diversidade de infraestrutura e aplicações dentro de uma área de TI típica da empresa - pense em mainframe, bare metal, VMs, contêineres, COTS, aplicativos de terceiros, SaaS, microsserviços internos, etc. - um objetivo principal é estabelecer um caminho claro que permite modernização e migração incrementais de aplicativos herdados para uma infraestrutura mais nova, como Kubernetes e serviços em nuvem.

Modernização e migração, sem interrupções: a função do API Gateway e do Service Mesh

O Envoy Proxy, que é open source, conquistou o mundo da infraestrutura moderna e por um bom motivo: esse proxy nasceu na era focada no protocolo nativo na nuvem e no protocolo Layer-7 (aplicação) e, portanto, lida com todas as características da infraestrutura moderna e dos casos de uso de desenvolvedor / operador associados de maneira muito eficaz e eficiente.

Organizações de usuários finais como Lyft, eBay, Pinterest, Yelp, e Groupon, em combinação com todos os principais fornecedores de nuvem, estão usando o Envoy na borda e serviço-a-serviço para implementar descoberta, roteamento, e observabilidade de serviços. Fundamentalmente, eles costumam usar o Envoy para conectar a comunicação entre o velho mundo dos mainframes e aplicações baseadAs em VM para os serviços mais modernos baseados em contêiner.

Embora o plano de dados (a própria implementação do proxy de rede) seja extremamente poderoso, o plano de controle, a partir do qual o proxy é configurado e observado, possui uma curva de aprendizado acentuada. Assim, surgiram outros projetos open source para simplificar a experiência do desenvolvedor de usar o Envoy. O Ambassador API gateway, da Datawire, é um proxy de borda empoderado pelo Envoy, que fornece um plano de controle simplificado para configurar o Envoy quando usado para gerenciar o ingress ou o tráfego "norte-sul". O Consul service mesh, da HashiCorp, é um plano de controle para comunicação serviço-a-serviço ou tráfego "leste-oeste", e isso suporta o Envoy dentro de sua gama de configurações de proxy conectáveis.

A principal promessa do uso dessas duas tecnologias é que elas permitem que as aplicações sejam executadas em qualquer lugar enquanto permanecem disponíveis e conectados a usuários externos e internos

  • Um API gateway dissocia a composição e a localização da aplicação de consumidores externos. Ele roteia dinamicamente solicitações externas de usuários finais, aplicativos móveis, e terceiros para vários aplicativos internos, independentemente de onde eles estão implantados.
  • Um service mesh desacopla aplicações de consumidores internos, fornecendo transparência de local. Ele roteia dinamicamente solicitações internas de serviço a serviço para vários aplicativos, independentemente de onde eles são implantados

Ambassador e Consul: roteamento para VMs, Containers, e muito mais

Uma implantação típica do Consul consiste em vários servidores Consul (fornecendo

alta disponibilidade) e um agente Consul em cada nó. O Consul atua como a "fonte da verdade" da configuração para todo o data center, rastreando os serviços e configurações disponíveis, os terminais e armazenando secrets para a criptografia TLS. Ao usar o Consul para descoberta de serviço, o Ambassador pode rotear de um endpoint voltado para o usuário, ou API do tipo REST, para qualquer serviço Consul no datacenter, esteja ele em execução no bare metal, VMs, ou Kubernetes.

O Consul também pode rotear de maneira transparente o tráfego de serviço-a-serviço por meio de proxies Envoy (usando o padrão de serviço "side-car"), o que garante que o tráfego de ponta-a-ponta seja totalmente protegido com TLS. O Ambassador serve como um ponto comum de entrada para aplicações e serviços, fornecendo funcionalidade transversal para o tráfego norte-sul, como autenticação do usuário, limitação de taxa, gerenciamento de API, e terminação TLS.

O Consul atua como service mesh e permite que a definição de nomes de serviço forneça transparência local, e que a política-como-código (policy-as-code) seja especificada declarativamente para preocupações de segurança transversais definidas, como "segmentar" a rede. Proteger a comunicação serviço-a-serviço com regras de firewall ou tabelas IP não é escalável em configurações dinâmicas e, portanto, a segmentação de serviços é uma nova abordagem para proteger serviços por meio de sua identidade, em vez de depender de propriedades específicas da rede; grupos de segurança complicados baseados em host e listas de controle de acesso à rede são evitados em favor da definição de políticas de acesso usando nomes de serviço.

Começando

O Ambassador usa um formato de configuração declarativo criado nas anotações do Kubernetes. Para usar o Consul para descoberta de serviço, primeiro você registra o Consul como um resolvedor por meio de uma anotação colocada em um serviço Kubernetes:

apiVersion: ambassador/v1
kind: ConsulResolver
name: consul
address: consul-server
datacenter: dc3

O Ambassador agora pode ser configurado para rotear para qualquer serviço usando o formato de configuração padrão baseado em anotação. Todos os recursos do Ambassador, como gRPC, tempos limite, e balanceamento de carga configurável, são totalmente suportados. O exemplo abaixo demonstra um mapeamento entre /foo/e o proxy do serviço foo (“foo-proxy”) registrado no Consul:

apiVersion: ambassador/v1
kind: Mapping
prefix: /foo/
service: foo-proxy
timeout_ms: 5000
resolver: consul-server
tls: consul-tls-cert
load_balancer:
  policy: round_robin 

Embora opcional, a propriedade tls define o contexto do TLS que o Ambassador usa para se comunicar com o proxy do serviço Consul. O Ambassador sincroniza certificados TLS por meio da API Consul automaticamente. Para garantir que todo o tráfego seja seguro, o próprio serviço deve ser configurado para receber apenas tráfego do proxy do serviço Consul, por exemplo, configurando o serviço em um pod Kuberntes para vincular ao endereço de rede local ou configurando a VM subjacente para aceitar apenas a comunicação de entrada através da porta que o proxy está ouvindo

Existem vários benefícios adicionais ao implementar o Ambassador e o Consul em seu datacenter. O uso de um proxy compatível com a Camada 7, como o Envoy na borda, significa que protocolos modernos como HTTP/2 e gRPC serão balanceados corretamente (uma ótima discussão sobre por que o uso dos balanceadores de carga da Camada 4 não é apropriado neste caso de uso, veja o post "We rolled out Envoy at Geckoboard"). O Consul também fornece primitivas adicionais que são úteis na criação de sistemas distribuídos, como um armazenamento de valores-chave, que também inclui a capacidade de observar entradas, bloqueios distribuídos e verificações de integridade, além de oferecer suporte a vários datacenters prontos para o uso.

Tecnologias relacionadas

A IBM, o Google, e várias outras organizações e indivíduos fundaram o projeto Istio para fornecer um plano de controle simplificado para o Envoy, focado na comunicação entre serviços. Mais tarde, o projeto adicionou o conceito de "gateway" para gerenciar o ingress, que ainda está em evolução. Atualmente, o Istio suporta apenas a implantação no Kubernetes, mas o suporte adicional à plataforma está no roteiro. A Buoyant criou o service mesh Linkerd, que embora focado principalmente no gerenciamento de tráfego leste-oeste, também fornece integrações com proxies norte-sul populares. A equipe do API gateway da Kong também possui uma solução de service mesh em estágio inicial que é alimentada por NGINX.

Fique atento ao lançamento do service mesh "Big Bang"

Através do meu trabalho na Datawire, conversei com várias empresas que tentaram lançar um service mesh em toda a empresa. As operações de rede são sem dúvida um dos últimos bastiões da entrega de software que permaneceu relativamente centralizado - mesmo com a adoção da nuvem e da rede definida por software (SDN) - e às vezes isso leva ao pensamento de que qualquer tecnologia de rede deve ter um gerenciamento central. Em geral, esse tipo de abordagem ao implantar um service mesh não correu bem.

Não parece razoável orquestrar todos os engenheiros de uma grande empresa para mover todos os aplicativos em massa para um service mesh. Em vez disso, uma abordagem incremental à adoção parece mais prática, e acredito que isso deve começar na borda (edge). Depois que uma empresa consegue descentralizar a configuração e o lançamento de aplicativos e produtos expostos externamente e também aprender como tirar proveito da funcionalidade oferecida pelos proxies modernos, esse é um ponto de partida ideal para continuar implementando um service mesh incrementalmente para serviços internos.

A primeira iteração de implantação de um service mesh geralmente é focada no roteamento. Como demonstrei nas configurações do Ambassador e do Consul acima, depois de ter um proxy de borda moderno instalado, você pode migrar seletivamente o roteamento de tráfego para os serviços registrados no Consul, independentemente de onde ou como eles são implantados. Depois que o roteamento estiver concluído, poderá adicionar gradualmente um proxy Consul ao lado de cada um dos seus serviços e rotear o tráfego com segurança (usando TLS) da borda para cada terminal de serviço. É completamente aceitável ter uma combinação de serviços implementando TLS e algum texto sem formatação em um data center. O objetivo geralmente é proteger todo o tráfego e, usando a combinação Ambassador e Consul, é possível implementar a criptografia de ponta-a-ponta do tráfego, do usuário final ao serviço, de forma incremental.

Conclusão

Neste artigo, discuti as motivações para dissociar aplicações da infraestrutura como parte de um programa de modernização de aplicações. Explorei como a implantação de um API gateway integrado com um service mesh podem fornecer um caminho incremental para rotear o tráfego de usuários finais para serviços novos e existentes, independentemente de onde essas aplicações estão implantados. Se e quando as aplicações forem migradas para plataformas mais recentes, sua identidade usada para rotear o tráfego da borda para o serviço ou serviço-a-serviço permanecerá a mesma. Além disso, existem vários outros benefícios com a implementação dessa solução de gateway-para-malha (service mesh), incluindo criptografia de tráfego de ponta-a-ponta e observabilidade aprimorada das métricas de rede no nível da aplicação, globalmente e serviço-a-serviço.

Mais detalhes sobre a integração do Ambassador e do Consul podem ser encontrados na documentação do Ambassador, e um tutorial pode ser encontrado na documentação do Consul.

Sobre o autor

Daniel Bryant trabalha como consultor técnico independente e arquiteto de produtos na Datawire. Seu conhecimento técnico se concentra nas ferramentas DevOps, nas plataformas de nuvem / contêiner e nas implementações de microservices. Daniel é um Java Champion e contribui para vários projetos open source. Ele também escreve para InfoQ, O’Reilly, e TheNewStack, e se apresenta regularmente em conferências internacionais como OSCON, QCon e JavaOne. Em suas grandes quantidades de tempo livre, ele gosta de correr, ler e viajar. .

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT