32 tecnologias para uma PoC de Microsserviços na AWS

Em 2020, decidi consolidar em um único software tecnologias que eu vinha estudando em separado e conceitos que, por vezes, se apresentavam somente em teoria.

Essas tecnologias encontram-se na imagem abaixo. Clique na imagem para expandi-la.

Imagem inspirada no landspace da CNCF.

À seguir, o texto explicando o projeto, a arquitetura e o software.

Projeto

A estrutura abaixo da descrição do projeto foi inspirada no conteúdo da página 115 do PMBOK – 4ª Edição.

Escopo

O escopo do projeto consiste em criar um software para materializar alguns conceitos de microsserviços. Por isso, adotei o termo PoC (proof of concept).

Com o objetivo de criar um software mais próximo possível da realidade e atendendo às restrições do projeto, criei uma empresa fictícia chamada Deltacare que atua no mercado de seguro saúde. Utilizei o domínio de seguros porque eu trabalhei nele e conheço alguns de seus processos e regras de negócio.

Exclusão

Embora fundamental para um projeto com microserviço, devido as restrições do projeto, encontra-se fora de escopo:

Backend For Frontend: Para minimizar e segmentar chamadas do frontend para o backend (mais info: BFF);
Log centralizado: Para investigar transações entre microsserviços, mesmo das instâncias que foram finalizadas (mais info: Amazon CloudWatch | Cloud Logging | Elastic Stack);
APM: Para minimizar problemas na experiência de usuário (mais info: New Relic | Dynatrace | Elastic APM);
Teste de carga: Para minimizar problemas na experiência de usuário (mais info: JMeter | Gatling | k6);
Teste de integração: Para garantir que os componentes de uma API funcionem integrados (mais info: REST Assured);
Teste funcional/tela/E2E: Para garantir que o comportamento do software atenda aos critérios de aceitação (mais info: Selenium | Cypress | Playwright);
BDD: Para minimizar problema de comunicação entre os especialistas de negócio e times do projeto para entender os requisitos funcionais e não-funcionais (mais info: Introdução | Cucumber | BDD in Action);
BPM: Para minimizar problema de comunicação entre os especialistas e analistas de negócio para entender o comportamento da empresa (mais infos: CBOK);
DDD: Para minimizar a falta de sinergia entre negócio e tecnologia (mais infos: PPP-DDD | I-DDD);
Arquitetura Empresarial: Para minimizar a falta de sinergia entre negócio e tecnologia (mais infos: TOGAF | ArchiMate | Archi);
Chaos Engineering: Para minimizar problema inesperado em produção quando um componente possui um comportamento diferente do comum (mais infos: Princípios | Traffic Management);
Estratégias de Deployment: Para minimizar o risco de novas entregas em produção (mais infos: Conceitos | Canary Release | Feature Toogles | Exemplos);
Branching workflows: Para melhorar e padronizar o trabalho de programadores no mesmo repositório (mais info: Conceitos | git-flow);
Richardson Maturity Model: Para padronizar e melhor a qualidade de REST APIs (mais infos: Conceitos).

Considerando esses itens:

As pipelines não possuem teste de carga, teste de integração e teste funcional/tela/E2E;
Os diagramas/viewpoints aqui apresentados não possuem uma linguagem definida (ArchiMate ou C4 Model, por exemplo).

Entrega

Os códigos encontram-se no Github. https://github.com/delta-care

As imagens encontram-se no Dockerhub. https://hub.docker.com/u/deltacare

Os projetos de análise encontram-se no SonarCloud. https://sonarcloud.io/organizations/delta-care/projects

Restrição

O projeto não possuiu financiamento além do meu. Desse modo, restringiu-se à execução do menor tempo e custo possível.

Sobre tempo, foi pouco mais de 8 semanas. Sobre custo, foi $64 dólares. A distribuição do custo por dia e serviço utilizado encontra-se abaixo.

Utilizei os serviços da AWS. O serviço EC2 esteve ligado somente quando utilizado (somente uma máquina). Fiz o mesmo com o RDS, com exceção de alguns dias.

Premissa

Não encontrada.

Arquitetura

O software para o domínio do problema em questão poderia ser perfeitamente criado por um monolito bem estruturado e, se necessário, quebrado em microsserviços posteriormente.

No entanto, o objetivo é a criação de um software com arquitetura de microsserviços independente se o domínio do problema exige ou não tal arquitetura.

Então, a arquitetura resultante está representada na imagem abaixo.

Imagem inspirada no eShop da Microsoft.

Componentes

As duas partes envolvidas de traços azul representam a esquerda o usuário, no qual encontra-se logado e já baixou os arquivos da SPA, e a direita o ambiente da AWS, com todos os componentes rodando e gerenciados pelo Kubernetes e Istio (detalhes na seção OPS abaixo).

Os seis componentes envolvidos de traços cinzas são os quais armazenados no Github da Deltacare.

Os quatros componentes de API possuem losango porque sua arquitetura representa a arquitetura de portas e adaptadores ou hexagonal.

Padrões

Como o texto do Chris Richardson não possui uma boa imagem, utilizei abaixo a imagem de outro texto. Os padrões marcados em vermelho são os quais utilizei.

OPS

O primeiro passo do projeto foi criar o código da infraestrutura, conforme explicado abaixo. O resultado encontra-se aqui.

Pacotes

O script 01-install-pkg.sh instala o Terraform e Ansible. Utilizei Ubuntu 18.04 LTS em minha máquina.

Terraform

Com o Terraform instalado, rodei o script 02-create-ec2.sh que, utilizando o script ./terraform/main.tf, cria uma máquina na AWS atendendo as exigências do Kubernetes.

Ansible

Com o Ansible instalado, rodei o script 03-conf-env.sh que, utilizando o inventário ./ansible/inventory/aws_ec2.yaml, executa os passos abaixo na máquina criada pelo Terraform.

Instalar Docker;
Instalar Kubernetes;
Instalar Istio;
- Instalar Grafana
- Instalar Jaeger
- Instalar Prometheus
- Instalar Kiali
- Criar gateway Istio
  - Host
    - kiali.ops.deltacare.xyz
    - grafana.ops.deltacare.xyz
    - prometheus.ops.deltacare.xyz
    - jaeger.ops.deltacare.xyz
  - Porta
    - 80
    - 443
- Criar virtual service Istio
  - URIs das ferramentas
Configurar ambiente de operação (ops);
- Criar namespace “ops”
- Instalar Keycloak
- Instalar Jenkins e suas roles
- Criar gateway Istio
  - Host
    - sso.deltacare.xyz
    - jenkins.ops.deltacare.xyz
  - Porta
    - 80
    - 443
- Criar virtual service Istio
  - URIs das ferramentas
Configurar ambiente de desenvolvimento (dev);
- Criar namespace “dev”
- Criar gateway Istio
  - Host
    - dev.deltacare.xyz
  - Porta
    - 80
    - 443
- Criar virtual service Istio
  - URIs das APIs e SPA
Configurar ambiente de produção (prd).
- Criar namespace “prd”
- Criar gateway Istio
  - Host
    - app.deltacare.xyz
  - Porta
    - 80
    - 443
- Criar virtual service Istio
  - URIs das APIs e SPA

AWS ACM

Nesse momento na AWS, possuo uma máquina criada pelo Terraform e com pacotes instalados pelo Ansible.

Nesse passo, utilizei o serviço ACM para criar os certificados SSL/TLS para habilitar as rotas HTTPS na porta 443 configuradas anteriormente pelo Istio (que utiliza o Envoy Proxy). A imagem abaixo apresenta o painel do ACM.

AWS ELB

O próximo passo foi utilizar o serviço ELB para criar um load balancer para ficar “na porta de entrada” do back-end recebendo e redirecionando requisições nas portas 80 e 443, conforme imagem abaixo.

Note que cada listener possui, além da porta e protocolo, a rule que define a rota que será utilizada pelo load balancer. Cada rota possui uma ou mais instâncias do serviço EC2 que será escolhida para receber a requisição na sua porta configurada. Tal porta corresponde ao ingress gateway do Istio configurado anteriormente pelo Ansible.

AWS Route 53

O próximo passo foi utilizar o serviço Route 53, que é o serviço de DNS da AWS, para configurar a relação entre nome de domínio versus nome do load balancer, conforme imagem abaixo.

AWS RDS

O próximo passo foi utilizar o serviço RDS para configurar o banco de dados MySQL de cada API no ambiente dev e prd, conforme imagem abaixo.

AWS MSK

O objetivo era usar o serviço Amazon MSK para adicionar a funcionalidade de mensagem assíncrona, mas acabei por baixar o Kafka e iniciar manualmente o servidor do Kafka e o serviço do Zookeeper.

AWS ElastiCache

O objetivo era usar o serviço Amazon ElastiCache com Redis, mas acabei por baixar o Redis e iniciá-lo via Docker.

Resultado

O resultado da atividade de ops está representada na imagem abaixo.

O load balancer ouvindo nas portas 80 e 443, recebendo requisições com *.deltacare.xyz e encaminhando-as para um EC2 (no caso, tenho somente uma máquina EC2) na porta do ingress gateway Istio.

O Ansible criou três namespaces Kubernetes. O “ops” para as ferramentas de operação. O “dev” para o ambiente de desenvolvimento. O “prd” para o ambiente de produção. Ambos na mesma máquina para atender a restrição de custo do projeto. Isso não é recomendado em um ambiente empresarial.

SPA

Framework

Para criar a SPA (Single Page Application), escolhi o framework Vue por já ter utilizado em outros projetos.

Bibliotecas

Como o projeto não possui requisitos de design, utilizei o Vuetify por já possuir componentes prontos de design que utiliza material design.

Para criação de gráficos, utilizei o Vue-ApexChart por já possuir componentes modelados para Vue e com um design atraente.

Para realizar requisições ao back-end, utilizei o famoso Axios.

Para realizar autenticação e autorização, utilizei keycloak. Uma solução madura que se encontra no landspace do CNCF.

Artefatos

À seguir, uma breve descrição dos artefatos da SPA armazenados no Github.

/helm: Contém os componentes Kubernetes e Istio necessários para instalar a SPA;
/src: Contém o código-fonte da SPA;
- /assets: Favicon.
- /components: Menu e toolbar usados pelas telas da SPA.
- /injects: Bibliotecas injetadas no main.js do Vue. No caso, axios e keycloak.
- /mixins: Javacript para definir o title das telas.
- /modules: Telas da SPA.
  - /router: Definição da rota de cada tela.
  - /services: Definição dos serviços usados em cada tela.
  - /views: Definição da view de cada tela.
- /plugins: Bibliotecas injetadas como plugin no main.js do Vue. No caso, vuetify e vuelidate (não usei).
- /router: Definição principal das rotas.
- /store: Definição simples para o title das telas.
- /utils: Definição de métodos comuns.
- App.vue: Arquivo principal de view.
- main.js: Arquivo principal de script.
Dockerfile: Definição da imagem usando node e nginx;
Jenkinsfile: Definição do pipeline (sem executar teste funcional, conforme descrito no item Exclusão);
entrypoint.sh: Shellscript usado no Dockerfile para injetar as variáveis de ambiente e seus valores no index.html da SPA ;
- Atualmente, enquanto escrevo esse texto, para mudar valor de variável de ambiente usado pelo Vue há necessidade de recompilar o código. Sendo assim, esse shellscript foi necessário (mais info) para não ser necessário recompilar o código ao mover a SPA de um ambiente (dev, por exemplo) para outro (prd, por exemplo). Assim, atendendo aos critérios de The Twelve-Factor App.
nginx.conf: Configuração personalizada do Nginx para servir a SPA. Esse arquivo é injetado no Nginx via Dockerfile.

Testes

Não foram criados para atender as Restrições desse projeto. Porém, são imprescindíveis em um ambiente empresarial.