Conheça o Cloud Native Trail Map
Saiba como iniciar sua jornada Cloud Native!
Me siga no twitter @gutocarvalho e acompanhe meus posts sobre Cloud Native e CI/CD.
Siga a CD Foundation e Cloud Native Foundation no twitter.
Revisor: Ricardo Pegoraro
Passo 1: Containerização
Aqui nesse passo a ideia é atuar para que sua aplicação rode em containers. No futuro é interessante pensar em desacoplar sua APP para rodar pequenas partes do seu software de forma separada usando o conceito de microserviços.
Normalmente nesse passo usamos Docker e escrevemos os primeiros Dockerfiles.
Passo 2: Construir sua esteira CI/CD
Neste passo a ideia é criar uma esteira para que essa faça o build da sua imagem automaticamente quando houver uma atualização no seu código. Essa esteira deve fazer o build, testar sua app e fazer o deploy para staging e depois para produção, já rodando sua aplicação em uma plataforma de containers.
Aqui algumas pessoas já estão usando um pouco de docker-compose para facilitar o uso de Docker.
Um excelente solução para construir sua esteira é usar o projeto ArgoCD.
Passo 3: Começar a orquestrar sua APP
Aqui a ideia é ir além do Docker, começando a utilizar um orquestrador de containers como Kubernetes ou Nomad. Utilizando um orquestrador você já vai rodar suas apps em um ambiente mais robusto, com estrutura de cluster com diversos benefícios como disponibilidade, escalabilidade, descoberta e muito mais.
É importante escolher uma distribuição certificada pela CNCF e usar ferramentas adequadas para armazenar suas imagens e empacotar sua aplicação.
Sugestões de ferramentas são Kubernetes para o cluster de containers, HELM para empacotamento de suas apps e Harbor para armazenamento de suas imagens.
Mudando para um cluster você terá que ajustar suas esteiras para que o deploy seja feito neste novo ambiente, na esteira você também vai adicionar um passo para armazenar a imagem no registry e empacotar sua APP no formato HELM.
Passo 4: Observabilidade e Análise
Do passo 1 ao passo 3 você estará se preparando para entrar no universo Cloud Native, se chegou no passo 3 já é uma grande vitória. Entrar no passo 4 significa que você já atingiu uma certa maturidade para rodar seu software e agora precisa de dados para melhorar e manter tudo funcionando da forma mais adequada.
Aqui vamos pensar em monitoração, métricas, logs e tracing de aplicações.
Para monitoramento geralmente utilizamos o prometheus para coletar e consolidar os dados, o grafana para visualizar esses dados em dashboards, para logs podemos usar o fluentd e para tracing o opentracing.
Usamos essas ferramenta para ver se tudo está funcionando, para avaliar a saúde de nossa aplicação e sua performance, afinal, não tem como melhorar algo se não temos métricas para comparar a evolução – ou regressão - de alguma coisa.
Passo 5: Service Proxy, Discovery and Mesh
Bom agora que já temos nossa APP rodando em um cluster Kubernetes, com pipeline para entregar software, monitoramento e métricas de nosso software é hora de pensarmos em usarmos mais de nossos clusters.
Podemos explorar mais os recursos de serviço discovery, service mesh e load balancing, cada qual em seu quadrado para ajudar nossa aplicação a se manter consistente e escalar.
As sugestões aqui são Envoy (Proxy), CoreDNS (Discovery) e Linkerd (Mesh).
Passo 6: Network Policy & Security
Pensar em rede segurança é importante, manter seu cluster seguro é essencial. O kubernetes oferece recursos muito flexíveis para fazer o design de sua rede interna, e além disso, temos excelentes ferramentas para tratar da segurança de nosso cluster, desde a segurança de acesso aos recursos do cluster, configurações do cluster indo até a avaliação de vulnerabilidades das APPs rodando.
APPs para ajudar: CNI (rede), OPA (Policy) e Falco (security).
Passo 7: Storage e Banco de dados distribuídos
Quando a gente precisa de mais resiliência e disponibilidade para nossos bancos, rodar o banco no cluster começa a fazer muito sentido, em especial se compararmos com um banco rodando em uma arquitetura single-instance.
Temos tecnologias Cloud Native para por exemplo rodar bancos de dados com o MySQL de forma distribuída no cluster como o Vitess, temos ainda projetos como o CrunchyData para rodar um ambiente HA de Postgres (completo) em nosso cluster.
A parte de persistência de dados também ganha uma atenção especial, no caso de banco de dados ou de qualquer outra aplicação “stateful” que necessite persistir dados.
Para atender a demanda de persistir dados temos soluções robustas como LongHorn e OpenEBS que são soluções de block-storage que podem ser utilizadas combinados com o Vitess, CrunchyData ou qualquer outra app.
Temos ainda soluções de storage de objetos como Minio e CEPH que são compatíveis com aplicações S3-Like, dentre outras soluções.
Além de tecnologias de bancos de chave-valor como ETCd que consegue armazenar e distribuir dados através dos nós do nosso cluster.
Passo 8: Stream e mensageria
Existem excelentes soluções como NATs e gRPC para rodar em nossos clusters. O gRPC é uma solução universal de framework RPC e o NATS é um sistema de mensageria que nasceu na era Cloud Native.
Passo 9: Container Registry e Runtime
Armazenar imagens de suas aplicações e dependências se torna fácil com Harbor.
Quer experimentar algum outro runtime diferente de Docker? Temos opções como Containerd, e CRI-O que podem substituir a altura e manter seus padrões cloud-native sem perder código já feito para o Docker.
Passo 10: Distribuição de software
Caso precise distribuir software de forma segura, o projeto Notary, baseado no TUF (The Update Framework) pode te ajudar.
Quer ver o mapa atualizado?
https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.png
[s]
Guto
--
Este post é do tipo #MindNotes, entenda aqui.
Se gostou manda um alo no twitter @gutocarvalho.