"Mergulho em CDK" foi uma talk que realizei no último dia 06 de Novembro para o AWS Community Day Brasil onde procurei dar uma visão desta ferramenta de Infraestutura como Código, que oferece uma ótima experiência de desenvolvimento e torna a criação e gestão de stacks e aplicações na nuvem muito mais simples. Vou colocar aqui algumas notas dos meus slides e apofundar aqui e ali.

Um pequeno resumo geral do AWS Cloud Development Kit (CDK):

• Lançado em julho de 2019;
• Open source, escrito em TypeScript e compilado para diversas linguagens através do jsii;
• Linguagens com suporte hoje: TypeScript, JavaScript, Python, Java, C# e família .NET e Go;
• Utiliza linguagens de alto nível para criar e manter infraestrutura como código na AWS.

“Tudo em arquitetura de software é um trade-off”

“Depende”, é uma das leis fundamentais em arquitetura de software como articulado no livro “Fundamentals of Software Architecture” dos autores Mark Richards e Neal Ford. Por isso, um mergulho em CDK, ou em qualquer ferramenta na verdade, não seria completo sem olhar para seus trade-offs.

Em adição à rápida incorporação e deploy de componentes que mantenham seus requerimentos de segurança, compliance e governança, um dos pontos fortes do AWS CDK é a utilização de linguagens de alto nível, com o poder da Construct Library, que aproveitando integrações com suas IDEs e incorporando características como o uso de objetos, loops, condicionais, etc., tornam muito mais ágil o desenvolvimento. Muitas destas abstrações, possuem os chamado sensitive defaults, já incorporando muito das boas práticas. Usar técnicas de modelagem orientada a objetos funciona incrivelmente bem para infraestrutura, modelando de forma natural seu sistema. E por isso, torna simples a criação e compartilhamento de código como bibliotecas.

O paradigma de infra-estrutura, do qual a HCL (Hash Corp Language) utilizada pelo Terraform é um modelo que possui algumas características sócio-tecnológicas que permitiram sua popularidade, sendo sua expressividade um de seus motivos, como articulado por Ben Kehoe, AWS Serverless Hero no episódio 15 de aws.fm, citado neste tweet:

"It tends to be hard to write a CloudFormation template that does not do what you expect it to do, whereas that is the default state of a general-purpose programming language"

What amazing insights from @ben11kehoe 🤩

— Ian Mckay (@iann0036) November 4, 2021

Troca de contexto é um dos grandes inimigos da produtividade de uma pessoa desenvolvedora. É aqui que o AWS CDK entra. Tornando a colaboração entre Desenvolvimento e Operações ainda mais fluida e integrada. Para quem conhece o conceito de flow articulado por Mihaly Csikszentmihalyi em Flow : A psicologia do alto desempenho e da felicidade. Mihaly descobriu o flow, que é um estado mental de extrema concentração, onde nossas habilidades são refinadas e que existem em um contexto em que nossas habilidades são exigidas em grandes desafios, golden spot para os desafios de infra-estrutura e desenvolvimento.

A Dra. Nicole Forsgren, principal autora do excelente Accelerate: Building and Scaling High Performance Technology Organizations, continuando sua pesquisa em eficiência de entrega de software agora focou-se em explorar produtividade no nível do desenvolvedor. Em artigo de Março de 2021 na ACM Queue, delineou o The SPACE of Developer Productivity:

• Satisfação e bem-estar;
• Performance;
• Atividade;
• Comunicação & Colaboração;
• Eficiência & flow.

Flow é essencial para entregas eficientes de software e mudanças de contexto certamente impactam esse espaço mental de imensa satisfação pessoal e excelência de performance — o momento mágico em que literalmente mergulhamos em CDK!

Entretanto o versionamento do CDK ainda é um desafio. Ele possui ciclos insanos de releases, às vezes com dias entre uma versão e outra. Certamente necessário para dar conta dos mais de 200 serviços que atualmente a AWS oferece. E em breve, teremos uma grande mudança de organização e gestão das versões com a versão 2.0.

Três componentes básicos compõem o core framework de um projeto AWS CDK. Apps, stacks, and constructs. Para provisionar recursos de infra-estrutura, todos os construtos que representam recursos da AWS devem ser definidos, direta ou indiretamente, dentro do escopo de um construto de stack. Definições:

Apps contém todos os construtos que compartilham um contexto que presentam uma aplicação como um todo.

A unidade singular de deploy no AWS CDK, stacks definem todos os AWS recursos, como biuckets no Amazon S3 ou tabelas do DynamoDB, em uma aplicação CDK.

Os blocos básicos de construção de uma aplicação AWS, construtos representam um componente na cloud e incluem todos os elementos que o AWS CloudFormation necessita para gerá-lo.

Ao combinar os componentes básicos com a biblioteca AWS Construct, você pode agregar recursos AWS como construtos básicos ou de alto-nível.

Sua aplicação é logicamente definida como uma aplicação e representada pela classe App do AWS CDK e normalmente é a raíz da árvore de seus construtos. Composto de uma ou mais stacks, Apps podem contem um ou mais construtos.

Tipicamente se define uma instância de App no ponto de entrada de seu programa e então se definem os construtos onde o App é utilizado como o escopo principal.

Um construto ou construct, para usar o nome oficial e em inglês que faz parte da própria sintaxe da biblioteca, representa um único recurso da AWS, como um endpoint em uma Amazon VPC, ou ainda pode representar vários recursos de forma agregada como um único componente.

A composição de constructs permite que sejam definidos componentes reutilizáveis e compartilhar como qualquer outro código.

Constructs são implementados tendo a classe base Construct. Você define um construct ao instanciar a classe. Todos construtos podem receber até três parâmetros quando inicializados: scope, id e props, sendo este último opcional.

O primeiro argumento, scope, é o construct no qual este construto é criado. Em muitos casos, um construct é definido no contexto de si mesmo, o que significa na prática que você passa this para o primeiro argumento.

O segundo argumento, id, é o identificador local do construct que deve ser único dentro do escopo. O AWS CDK utiliza este identificador para calcular Id lógico do AWS CloudFormation para cada recurso definido dentro deste escopo.

O terceiro argumento, props, é objeto ou conjunto de propriedades de inicialização que são específicas a cada construct e definem sua configuração inicial.

O AWS CDK inclui a AWS Construct Library para assegurar que tenham acesso a todos os constructs e que possam herdar e criar seus próprios constructs, que se definem em níveis, identificados com L, de level.

O nível mais alto de abstração dos constructs. Auxiliam a completar tarefas comuns na AWS que utiliza vários recursos como casos de uso muito comum ou padrões de arquiteturas, como por exemplo, criar um cluster de containers no Fargate com um Application Load Balancer (ALB).

São mapeamentos de recursos AWS que oferecem defaults convenientes e reduzem a carga cognitiva de tudo que é necessário para acelerar o desenvolvimento.

O nível mais baixo de construct, são implementações diretas de recursos do AWS CloudFormation. Geralmenet possuem o nome no padrão Cfn*.

Stacks são uma unidade de deploy no AWS CDK. Todos os recursos da AWS definidos no escopo de uma stack, direta ou indiretamente são provisionados como uma unidade única e estão sujeitos às mesmas cotas do AWS CloudFormation, na data de publicação deste artigo, por exemplo, de 500 recursos. Sempre verifique a documentação oficial referenciada.

É importante se familiarizar-se com o AWS CDK Toolkit, uma CLI para interagir com sua aplicação. Através da mesma, será possível executar várias funções necessárias, como por exemplo, o CDK Bootstrapping.

Mudanças bem importantes virão na versão 2.0 que já tem alguns releases candidates e que iniciou seus testes com a comunidade. O CDK possui um rodamap público para acompanhar sua evolução.

Aspas não acidentais. No espírito de que “melhores práticas” são sempre contextuais, muitas vezes representativas de certas formas de trabalho e organização ou apenas convenções que a comunidade foi aderindo explícita e implicitamente.

A primeiro eu diria, é aderir ao AWS Well-Architected Framework desde o dia 0. Vai evitar grandes refatoramentos e até facilitar a gestão de expectativas de entregas.

A Azure também tem seu Well-Architected e podemos verificar os mesmos pilares.

Inclusive a Google Cloud possui seu conjunto em um framework que embora compartilhe os mesmos pilares, não possui o “Well-” como as outras sendo referenciado como Google Cloud Architecture Framework.

Tudo isso para mostrar que as três maiores Clouds públicas, ainda que de forma “independente”, observam os mesmos pilares e compartilham um conjunto de áreas importantes para a criação, desenvolvimento, operação e manutenção de aplicações na Cloud.

O AWS Well-Architected Framework define componente como o código, configuração e recursos da AWS que juntos entregam um requerimento. Um componente é muitas vezes a unidade de propriedade técnica e é descolada de outros componentes. O termo carga de trabalho (workload) é usado para identificar um conjunto de componentes que juntos entregam valor ao negócio. Uma carga de trabalho é geralmente o nível de detalhe em que negócios e líderes técnicos se comunicam.

Um app no AWS CDK mapeia-se para um componente.

Crie e compartilhe componentes como bibliotecas de código através de repositórios de artefatos como AWS CodeArtifact.

Trabalho em equipe deve ser sempre algo a se considerar na definição de uma ferramenta. Muitas vezes ignoramos os contextos sócio-tecnológicos, de carga cognitiva e outros, que possuem um impacto tremendo no trabalho. Para CDK um padrão que vem sendo defendido e aplicado é o de cada colaborador do projeto ter sua própria conta AWS onde faz os deploys em ambiente de desenvolvimento e então versionamento de mudanças que passa pelo tradicional code review, merge e então passa por todos os estágios de ambientes necessários na esteira CI/CD.

Modele sua aplicação em unidades lógicas de domínios baseados em Constructs, não Stacks. Stacks são uma unidade de deploy, e tendem a serem orientadas a aplicações específicas.Construir com base em Constructs confere mais flexibilidade.

Use Stacks para isolar unidades de deploys, como:

• DevStack
• StagingStack
• ProdStack

• Empregue Least Privilege desde o início;
• Evite variáveis de ambiente. Utilize o AWS Systems Manager Parameter Store
• Não mude o ID lógico de recursos com estado! Caso contrário, serão substituídos ou destruídos
• Aplique proteções de delete sempre que possível
• O ID lógico é derivado do id especificado ao instanciar o construct e sua posição na arvore do construct
• Entenda como Identificadores (Identifiers) funcionam!

• Testes de Snapshots testam o template sintetizado do AWS CloudFormation contra um template de baseline previamente salvos.
• Asserções específicas testa aspectos específicos, testes unitários de valores esperados ou ter certeza de que funcionalidades existentes não foram alteradas.
• Testes de validação ajudam a “falhar rápido” ao exibir erros antes mesmo de seu envio.

CDK possui bibliotecas de teste: assert e expect. Preferencialmente um teste deve verificar um e apenas um comportamento.

Testes são um assunto que precisam de um mergulho própio, mas aproveite a aderência e comunidade das linguagens suportadas e explore testar sua infraestrutura.

• Empregue os nomes gerados para recursos, não nomes físicos. Cada nome pode ser usado apenas uma vez em uma conta — este é um erro muito muito comum.
• Defina políticas de remoção e retenção de logs sempre que possível.
• Use cdk.context.json para evitar comportamentos não-determinístico.
• Empregue o AWS CDK para gerenciar roles e grupos de segurança (eg., grantRead())

Frameworks, bibliotecas, componentes e linguagem vivem por suas comunidades. As pessoas ao redor de determinada tecnologia. Sejam grandes organizações ou um grupo interessado de pessoas. Embora seja de alguma forma recente (2019), o CDK possui uma vibrante e ativa comunidade.

Matt Coulter e seu projeto CDK Patterns merece o reconhecimento por ser um dos primeiros, senão o primeiro repositório de patterns para o CDK, o que ajudou em sua popularização. A própria AWS, mas focada no serverless, criou uma iniciativa parecida, o ServerlessLand.

E este ano teremos o lançamento do The CDK Book de Matt Coulter, Thorsten Hoeger, Sathyajith Bhat e Matthew Bonig.

O CDK Day, anualmente organizado pelo, novamente, Matt Coulter traz sempre excelentes talks. Acompanhe o tweeter do evento para ser informados das edições e novidades. Seu mascote é a lontra chamada Pancake.

Existem na história da tecnologia vários killer apps. Programas ou sistemas que em um determinado momento, em uma determinada hora provocaram grandes mudanças e aceleração de adoção e uso mesmo quando iniciativas parecidas ou com “mais recursos” exista. A Google começou quando já havia mecanismos de busca. O Telegram nunca ultrapassou o Whatsapp. Para a web, sem sombra de dúvidas foi o navegador Netscape (o motivo de falarmos navegador inclusive é por que se chamava Netscape Navigator). O jQuery teve papel semelhante no uso de JavaScript e páginas com mais capacidades. O S3 foi um marco para o início da Cloud e a Lambda não foi apenas o grande catalizador do mercado de FaaS, Function as a Service, mas de todo um novo domínio conhecido como “serverless”.

Da mesma forma, IMHO (In My Humble Opinion, _na minha modesta opinião) eu acredito que o CDK é um killer app de Infraestrutura como Código. Onde estão o CDK da Azure e Google? Com estratégias multicloud se tornando cada vez mais comum, seria muito interessante ver algo se desenvolvendo nesse espaço.

No primeiro CDK Day teve um pequeno protótipo de CDK para Azure em que Andreas Heumaier também defendeu o desenvolvimento de CDK para não apenas a AWS e Azure mas outras Clouds. Hoje já temos o CDK para Terraform e cdk8s, Cloud Development Kit for Kubernetes.

E o CDK ganha mais e mais maturidade a cada dia. Um dos últimos, e grandes, lançamentos, foram os CDK Pipelines, que facilitaram ainda mais a criação de pipelines de entrega e deploy de aplicações CDK.

E este foi o roteiro da minha talk “Mergulho AWS Cloud Development Kit (CDK)” apresentada no AWS Community Day Brasil em 2021.