Nós já vimos como Cloud Native está próximo de microsserviços. Agora é hora de pensar em colocar esses serviços em produção. Com fazemos isso?

Tecnologias Cloud Native permite a criação de aplicações escaláveis, resilientes, observáveis, e modernas em um ambiente extremamente dinâmico. Podendo serem executadas em clouds públicas, privadas ou híbridas.

O Stack Cloud Native é abrangente e possui diversas tecnologias diferentes para os mais variados desafios dessa jornada.

O landscape é um bom lugar para observarmos essas tencologias.

Em todas as áreas abordadas por tecnologias do stack Cloud Native existem padrões e influencias de doutrinas e linhas de pensamento.

Continuous Delivery ou Entrega Contínua é uma dessas linhas de pensamento que culminam em uma estratégia.

Continuous Delivery

O que é isso

Continuous delivery, geralmente abreviada como CD, é um conjunto de práticas nas quais as alterações de código são implantadas automaticamente em um ambiente de aceitação (ou, no caso de continuous deployment, em produção). O CD inclui procedimentos cruciais para garantir que o software seja testado adequadamente antes da implantação e fornece uma maneira de reverter as alterações, se necessário. A Continuous integration (CI) é o primeiro passo para a continuous delivery (ou seja, as alterações precisam ser mescladas de forma limpa antes de serem testadas e implantadas).

Problema que ele aborda

A implantação de atualizações confiáveis ​​torna-se um problema em escala. Idealmente, implantaríamos com mais frequência para oferecer melhor valor aos usuários finais. No entanto, fazê-lo manualmente se traduz em altos custos para cada alteração. Historicamente, para evitar esses custos, as organizações lançam com menos frequência, implantando mais alterações de uma só vez e aumentando o risco de que algo dê errado.

Como isso ajuda

As estratégias de CD criam um caminho totalmente automatizado para a produção que testa e implanta o software usando várias estratégias de implantação, como versões canary ou blue-green. Isso permite que os desenvolvedores implantem código com frequência, dando-lhes a tranquilidade de saber que a nova revisão foi testada. Normalmente, o trunk-based development é usado em estratégias de CD em oposição a feature branching ou pull requests.

Fonte: https://glossary.cncf.io/continuous-delivery/

Quando começar nosso processo de CI/CD/CD?

O primeiro contato

Em 2002 chamávamos pipelines de esteira. De 2002 a 2005 eu fazia parte do processo de publicação, ativamente, seja validando código, seja implantando nos ambientes não produtivos ou preparando pacote para a implantação em produção. No ambiente de produção nós não metíamos a mão, era de responsabilidade exclusiva do pessoal de Infraestrutura e Operações.

Entre 2005 e 2010 foram muitos projetos e na maioria esmagadora já havia algo definido, bastava seguir e conduzir as próximas etapas de projeto. Seja com restruturações, onde havia um papel mais disruptivo ou simples condução do projeto, fazendo o papel de força que brigava pela qualidade do produto produzido, mesmo que isso demandasse renegociação de demandas ou revisão daquilo que havia sido acordado.

A minha primeira implantação ponta-a-ponta

Já em 2010 comecei, eu mesmo, a criar minha própria infra de CI/CD quando fui apresentado ao Jenkins. Eram meus primeiros passos com minha própria infra de CI/CD nos projetos e clientes em que atuava. Naqueles primeiros projetos só pude tirar proveito da infraestrutura de CI/CD após metade do projeto.

Com a autonomia de saber construir minha própria infra de CI/CD em qualquer servidorzinho que sobrasse, ficou muito mais fácil driblar a burocracia de contratar serviços em nuvem para uma atividade que não traz receita diretamente. Naquele momento ainda encontrava dificuldade em tangibilizar os resultados de uma pipeline bem resolvido.

Se puder escolher, comece no dia 1!

Nos projetos subsequentes, trouxe a criação da infra e do pipeline para os primeiros dias dos projetos e isso mudou minha produtividade para sempre.

Aprendi que quanto antes conseguir usar CI/CD, maior é a redução de custos. Quanto mais cedo, maior o benefício. Isso não é para fazer ninguém desanimar se já estiver em fase avançada, viu?! Antes tarde do que nunca.

Mas se já estivermos no final do desenvolvimento, quase na hora de implantar, ainda dá para tirar vantagem?

Bom, esse projeto entrará em produção, certo?

Terá demandas de correções e evolução certo?

Então sim! Com toda certeza vale a pena.

Se deixar para depois, paga pedágio!

Se seu ambiente exige CI/CD e você deixar a adoção para o final do desenvolvimento, é quase certo que você tenha tomado algum tipo de decisão que precise ser revista, em função de algum impacto direto na forma como a implantação será realizada.

Ciclos rápidos evidenciam problemas de arquitetura

Do ponto de vista de arquitetura, um número maior de implantações exige uma certa ocupação prévia maior com resiliência, visto que seu próprio deployment é um causador de indisponibilidade. Afinal, a instância que está sendo substituída, durante o deployment pode estar processando algo de algum cliente. Isso não necessariamente se traduz em downtime, mas é um ponto de atenção. Se você não levar isso em conta pode ter dores de cabeça.

Não necessariamente todos os serviços cairão, mas em uma arquitetura frágil, há potencial para paralisar tudo.

Ter mais de uma instância de sua aplicação, ajuda. Ter um pipeline que se preocupa com isso, ajuda também. Mas há uma dose de engenharia para manter isso lado-a-lado sem produzir um rio de exceptions e aplicações zumbis.

No 12 Factors, mais especificamente no tópico Descartabilidade/Disposability temos o tema graceful shutdown sendo abordado e esse é um ponto importante, que impacta inclusive nas decisões de design e arquitetura, podendo até afetar as decisões de infraestrutura.

Note, diversos pontos se conectam, diversos assuntos se entrelaçam nessa jornada Cloud Native. Microservices, sendo implantados sob uma estratégia de Continuous Delivery, desenvolvidos e pensados com a cultura DevOps, e sendo implantados com Containers. É um pacote completo!

No próximo post

No próximo post da série vou abordar como DevOps e cloud native andam tão próximos…