Lidando com os desafios da arquitetura de microsserviços em ambientes híbridos com Google Anthos

Em um passado não muito distante…

Uma grande parte das empresas tinha como espinha dorsal um sistema responsável por informatizar diversas tarefas de diferentes setores: financeiro, contabilidade e comercial. Colaboradores de cada setor acessavam determinado conjunto de funcionalidades de um mesmo sistema a fim de realizar as suas tarefas. Em alguns casos, até mesmo os clientes possuíam o seu próprio conjunto de funcionalidades no mesmo sistema.

Por baixo dos panos, esse tipo de sistema possuía uma arquitetura conhecida como monolítica. De forma resumida, trata-se de uma única base de código que precisava ser compilada e implantada por inteiro. Não por acaso, o termo tem origem em grandes monólitos naturais.

 
   

 
   

Monólito Natural Monólito Sistêmico

Esse tipo de arquitetura atendia – e ainda atende – determinados tipos de sistemas. No entanto, em muitos casos, com cenários de alto volume de requisições onde flexibilidade, escalabilidade, disponibilidade e velocidade de implantação fazem muita diferença para o negócio, esse modelo de arquitetura passou a ser um fator limitante.

O início de uma nova era

Na última década, um novo padrão de arquitetura de software tem se popularizado bastante. Ele determina que as necessidades sistêmicas de uma empresa não precisam nem devem ser atendidas por uma unidade monolítica. Esse padrão arquitetural defende uma solução composta por vários serviços, cada um com o seu repositório de código, sua responsabilidade bem definida, demanda de escalabilidade e requisitos de disponibilidade. Essa é a arquitetura de microsserviços.

Os benefícios oferecidos pela nova proposta vão desde a redução do esforço para manter e evoluir um microsserviço, pois uma vez que estamos falando de vários serviços, cada um com a sua responsabilidade bem definida, não é mais necessário que todos tenham conhecimento do sistema como um todo.

A nova arquitetura mudou a forma como criamos sistemas:

 
   

 

 

Monólito Microsserviços

Entre os diversos fatores que têm colaborado para a popularização desse padrão arquitetural, duas tecnologias merecem destaque especial:

 O Docker:

Solução de conteinerização de aplicações que permite a otimização do consumo de recursos computacionais, favorece a implantação de serviços coesos e simplifica a transição de aplicações entre ambientes, além de outros benefícios.

O Kubernetes:

Solução de gerenciamento de containers Docker que permite automatizar uma série de tarefas relacionadas à sua administração, bem como a escalabilidade e resiliência desse tipo de tecnologia.

Juntando tudo isso, passamos a ter um poderoso arsenal para a construção de soluções:

  • Serviços com o escopo de responsabilidades bem definido.
  • Implantação através de containers Docker que são facilmente portáveis entre ambientes.
  • Administração dos containers otimizada através de clusters Kubernetes.

Com grandes poderes vêm novas grandes responsabilidades

Com o novo padrão arquitetural, um desafio foi posto à mesa: manter e evoluir um ambiente de microsserviços, tarefa cujo fator de complexidade aumenta exponencialmente à medida que os novos serviços são desenvolvidos.

 
   

 
   

Implantação inicial Algum tempo depois

Dentre as novas preocupações, podemos destacar as seguintes:

Comunicação: a interface de comunicação entre os microsserviços muitas vezes se dá através de APIs REST que demandam governança.

Segurança: autenticação e autorização entre os microsserviços e também entre o seu ambiente e o exterior. O serviço A pode chamar o serviço B? Quais recursos podem ser consumidos?

Observabilidade da malha de microsserviços: como coletar as informações de telemetria de cada serviço? Como compilar as informações de todos os microsserviços para fins de análise?

Infraestrutura: administrar o ecossistema que sustenta soluções baseadas em microsserviços é uma tarefa complexa, e muitas vezes exige uma revisão de cultura, como administração de clusters Kubernetes, pipelines de CI/CD, atualizações de segurança, monitoramento de recursos, gerenciamento de certificados, atualizações de firewall e a lista vai longe…

Software, Rede, Segurança, Monitoramento

É possível mitigar o esforço necessário para o gerenciamento do ambiente através da adoção da nuvem.

Os principais provedores de cloud oferecem soluções gerenciadas que desoneram, e muito, as empresas. Boa parte das preocupações listadas acima acabam sendo delegadas para o provedor de nuvem.

Infelizmente essa não é uma opção 100% viável para muitas empresas. Em alguns casos, seja por limitações estruturais, particularidades do negócio, requerimentos do órgão regulamentador ou por outras razões, o que acaba acontecendo é a adoção de um ambiente híbrido: parte on-premises e parte cloud.

Conseguindo migrar 100% da solução para a nuvem ou não, outras questões aparecem: Qual cloud provider escolher? Como manter minha solução agnóstica ao provedor de nuvem de modo a evitar o vendor lock-in? Como manter minha solução rodando em nuvem e on-premises ou mesmo em mais de uma nuvem? Como garantir a segurança da minha solução em um ambiente híbrido multi-cloud e garantir uma observabilidade consolidada?

Nem canivete suíço nem Silver Tape

Para endereçar todos os problemas listados, a Google lançou a plataforma Google Anthos. Uma solução para a administração centralizada de aplicativos conteinerizados implantados em ambientes híbridos e multi-cloud. A ferramenta oferece framework de service mesh, administração de certificados, gestão centralizada de cluster Kubernetes tanto on-premises quanto em diversos cloud providers.

A imagem abaixo ilustra as atividades que podem ser endereçadas para o Anthos:

Vamos entrar um pouco nos detalhes dos componentes da plataforma Anthos.

GKE – Google Kubernetes Engine

Solução Kubernetes cloud totalmente gerenciada, oferecida no modelo PaaS pela Google Cloud. É a solução já disponível na GCP. Clusters do GKE podem ser administrados através do Anthos conforme o esperado.

GKE OnPrem – Google Kubernetes Engine On-Prem

Distribuição do Google Kubernetes Engine para execução on-premises. Foi projetada para ser implantada em cluster VMware vSphere e não requer nenhum hardware em especial.

Sua administração se dá através do painel do Google Anthos, porém não se faz necessário expor um IP público no cluster on-prem. A comunicação se dá através de um agente (GKE Connect Agent).

GKE On-Prem

Anthos Service Mesh

De forma macro, a Service Mesh abstrai dos desenvolvedores preocupações relacionadas às redes. Tópicos como descoberta de serviço, gestão de tráfego, autenticação/autorização e coleta de informações relacionadas ao tráfego deixam de consumir esforço do desenvolvedor e passam a ser tratadas de forma padronizada através da service mesh.

O Anthos usa o Istio como framework de Service Mesh, que é composto pelos seguintes componentes:

Envoy Proxy: Componente responsável por intermediar a comunicação entre serviços.

Pilot: Faz a administração das configurações junto aos proxies.

Mixer: Realiza a coleta de informações de tráfego entre os serviços. Ele é capaz de exportar essas informações para ferramentas como Grafana para fins analíticos. Além disso, o Mixer também é responsável por garantir que as regras de conectividade sejam respeitadas.

Citadel: Responsável pela emissão de certificados a serem utilizadas pelos proxies com o intuito de garantir autenticação e autorização nas comunicações. Vale mencionar que o Citadel viabiliza mutual TLS entre os serviços contribuindo muito para um ambiente seguro.

Visão alto nível do Istio e seus componentes

Abordando um pouco mais sobre autenticação e autorização

Autenticação se refere a identificação de uma entidade. Por exemplo: O que é esse serviço? Quem é esse usuário?

Autorização se refere ao que determinada entidade pode fazer. Como: Quais funcionalidades o usuário com o perfil admin pode realizar? E o usuário com perfil analista, o que ele pode fazer?
O Anthos endereça a autenticação entre serviços através de uma estratégia chamada Mutual TLS ou mTLS. Através desse padrão, além do consumidor do serviço conseguir validar a identidade de quem está expondo o mesmo, o inverso também passa a ser viável.

Já falando de autenticação e autorização de usuários via browser ou consumidores externos de APIs, o Anthos viabiliza a tarefa através de integração com o serviço Cloud IAP. O Cloud IAP é uma solução de gerenciamento de acessos que suporta o padrão OAuth2 entre outras características.

Gerenciamento de ambiente

Através do Google Anthos é possível definir SLO’s por serviço em execução.

Um SLO ou Service Level Objective nos diz como informações relacionadas à performance de um serviço devem ser interpretadas, em relação aos possíveis impactos para o negócio. Latência nas requisições do serviço A podem gerar impactos negativos para os usuários enquanto uma degradação, do mesmo nível ou até mais severa, no serviço B pode não ser algo crítico.

Um exemplo: a latência ideal para o serviço consultar-cotação é de até 2ms. Enquanto para o serviço consultar-histórico é de até 15ms. Definidas essas variáveis, podemos definir, por exemplo, que 95% das requisições ocorridas durante o dia deverão estar dentro desse range para cada serviço, a fim de que a aplicação seja considerada OK. Qualquer discrepância irá gerar notificações e ações precisarão ser realizadas.

Cada serviço deve ter sua SLO definida de acordo com a sua importância para o negócio.

 M4A – Migrate For Anthos

 Migrar aplicações legadas para uma arquitetura mais moderna tende a ser uma tarefa cara e demorada.

O Anthos oferece uma alternativa interessante para lidar com aplicações legadas enquanto elas não podem ser migradas, o Migrate for Anthos. Trata-se de uma ferramenta que viabiliza a migração de sistemas legados em execução em máquinas virtuais para containers gerenciados. Em muitos casos, as aplicações podem ser migradas com zero ou mínima alteração no código.

Neste vídeo temos um exemplo em que uma aplicação legada construída com java, Spring e Weblogic em execução em máquina virtual é convertida para uma imagem Docker.

Com esse procedimento, mesmo uma aplicação legada, pode usufruir de diversos benefícios oferecidos pela plataforma Anthos como: possibilidade de implantação em ambiente on-premises e em nuvens públicas, escalabilidade oferecida pelo Kubernetes, coleta de informações de telemetria, controle de tráfego e segurança através da service mesh.

Assim como aplicações mais modernas, um monólito pode passar a ser monitorado através de um painel único na GCP. Em muitos casos, tudo isso é viável com zero ou com mínima alteração no código da aplicação legada.

Referências

[Google Anthos]

https://cloud.google.com/anthos?hl=pt-br

[GKE On-prem]

https://cloud.google.com/anthos/gke/docs/on-prem/1.0/concepts/overview

[Hybrid Cloud Infrastructure Foundations with Anthos]

https://www.coursera.org/learn/hybrid-cloud-infrastructure-foundations-anthos

[Istio]

https://istio.io/latest/

[Modernizando uma aplicação Java com Anthos]

https://www.youtube.com/watch?v=XeQFSTMFYao

[Cloud IAP]

https://cloud.google.com/iap

[Google Cloud]

https://cloud.google.com/

[Whitepaper – Anthos under the hood]

https://inthecloud.withgoogle.com/content-anthos/dl-cd.html