O AWS Cloud Development Kit (CDK) se tornou, em sua curta história, uma ferramenta de infraestrutura como código bem popular. E não é surpreendente demais o por que - o AWS CDK permite que engenheiros usem linguagens de programação mais ricas para definir a infraestrutura, ao invés de ter que usar JSON ou YAML. Com linguages de programação, há melhores ferramentas, melhores abstrações e muito mais. Meu velho amigo e colega Gregor Hohpe usou a frase "Infraestrutura-como-código-real" para delinear entre ferramentas como o AWS CDK (e Pulumi) versus CloudFormation (e Terraform).

Passei um tempo no último ano trabalhando em alguns projetos usando o CDK. Vivenciei em primeira mão o poder que temos no uso do TypeScript para definir uma implementação complicada na AWS. No geral, acho que se você tem uma equipe bastante pequena e tem propriedade no código do aplicativo, no código de infraestrutura, e a implementação em produção dessa aplicação, vale a pena considerar o AWS CDK (eu o usaria!).

No entanto, ainda tenho grandes preocupações com o CDK. Algumas delas são aparentes (falta de suporte no console da AWS). Mas muitas das minhas preocupações estão relacionadas à operacionalidade a longo prazo. Eu acho que escolher CDK requer fazer uma troca: melhor eficiência para desenvolvedores no curto prazo versus dores de cabeça para engenheiros de operações nos próximos anos.

Neste artigo, compartilho meus pensamentos - positivos e negativos - sobre o CDK e, para tomadores de decisão técnicos, espero que essas idéias ajudem você a fazer suas próprias escolhas sobre quais ferramentas de infraestrutura usar.

O bom

Super poderes de linguagens de programação

Além do CDK, a maneira de implementar infraestrutura na AWS, com apenas ferramentas da AWS, é através do CloudFormation (e o SAM ajuda um pouco). O problema é: precisamos usar YAML ou JSON para definir os templates e nenhum dos dois são particularmente amigáveis quando se trata de construir qualquer coisa com alta complexidade.

O CDK, por outro lado, permite que engenheiros usem JavaScript, TypeScript, Python, Java ou C# para definir a infraestrutura (com mais linguagens à caminho). Por causa disso, escrever CDK é muito mais eficaz do que escrever CloudFormation, pelos seguintes motivos:

• Os editores modernos orientam os engenheiros usando autocompletação e capturam muitos bugs desde o início usando verificação de sintaxe.
• Estruturas das linguagem, como iteração e chamadas de função, permitem que abstrações sejam feitas dentro da definição de infrastructure de uma "pilha".
• Código compartilhado entre várias "pilhas" também fica simples de se fazer. Usando técnicas já conhecidas de linguagens de programação, permitindo criar padrões entre várias "pilhas".
• O código da infraestrutura pode ser testado em unidade.

Entusiasmo de engenheiros

Sem surpresa, engenheiros tendem a preferir escrever CDK ao invés de YAML! E assim, com a escolha do CDK, vem a boa vontade e um benefício de recrutamento - ambos úteis para a administração.

Além disso, esse entusiasmo é aparente na comunidade fora de infraestrutura. É difícil para as pessoas ficarem particularmente empolgadas com CloudFormation, mas com o CDK estamos vendo conferências dedicadas, contribuições de código aberto e muito mais - e tudo isso suporta e ajuda o trabalho da sua própria equipe.

O ruim

Depuração em tempo de execução

O CDK não é "um serviço" da AWS. Não no sentido normal. Você não pode ir ao AWS Console e acessar visualizações do CDK. Isso porque o CDK é predominantemente um cliente: uma abstração lateral sobre o CloudFormation.

Isso significa que, enquanto você escreve CDK de modo eficaz, a implementação e depuração do CDK em tempo de execução é uma história diferente.

Isso é imediatamente óbvio quando você olha para um aplicativo CDK no único local em que existe no AWS Console: dentro do painel de controle do CloudFormation. Todos os seus recursos bem abstraídos são subitamente achatados em um número grande de definições de recursos da AWS. Todos com nomes gerados e difíceis de ler. E quando as coisas dão errado (coisas vão dar errado) você ainda precisa de alguém na equipe que entenda CloudFormation.

Meta-responsabilidades contínuas

O problema do CDK não ter um painel específico na nuvem, não limita sua depuração. Como ele é uma ferramenta de abristação do lado do cliente, coloca muito mais responsabilidades em uma equipe de desenvolvimento do que normalmente na AWS, por exemplo:

• Os ambientes criados para desenvolvimento e produção devem ser mantidos. Por exemplo, as versões corretas do CDK e o ambiente da linguagem de programação devem ser mantidos durante toda a vida útil do aplicativo. Com CloudFormation/SAM, a AWS é responsável por fornecer esse ambiente.
• CDK requer um "bootstrap" no ambiente para ser configurado e isso tem que ser mantido para cada conta usada na AWS. Esses detalhes que cruzam aplicação e infraestrutura requer uma atenção cuidadosa.
• Se você estiver usando JavaScript/TypeScript para CDK, precisará atualizar suas versões do Node com bastante frequência, devido ao ciclo de suporte do Node.js (as versões LTS do Node.js são suportadas apenas por 2,5 anos). Isso pode ser um pouco problemático se o código do seu aplicativo foi escrito usando um idioma que tenha suporte mais longo (por exemplo, Java), mas você está usando TypeScript como um padrão organizacional para usar CDK.
• Ao contrário de um serviço AWS comum, a equipe do CDK já está optando por fazer as principais alterações na versão do CDK. Isso pode levar a dores de cabeça quando as atualizações precisam ser aplicadas:

Passei algumas horas tentando atualizar meu aplicativo CDK v1 para usar a v2. Nunca precisei atualizar meus modelos YAML. -- Wayne, @iluvgs400

O assustador

Como desenvolvedor, eu amo o CDK. Sou muito mais rápido do que com o CloudFormation.

Mas se eu colocar meu chapéu de CTO e pensar no CDK como uma escolha estratégica para uma organização, as coisas ficam mais obscuras.

Requisitos de operações a longo prazo

Embora o momento emocionante de um projeto de software seja quando há muita atividade acontecendo, a verdade é que a maioria projetos de software industrial que tenham algum sucesso tendem a entrar em um "modo de manutenção" a longo prazo. Novas implementações são menos frequentes e o conjunto de indivíduos que cuidam do aplicativo muda com o tempo.

O que acontece com um aplicativo CDK nesse contexto? Tenho várias preocupações, além daquelas que mencionei acima.

• Qual é o custo de manutenção do código CDK? Como o CDK usa uma linguagem de programação "regular", ele abre a possibilidade de soluções com abstrações em toda a organization. O que acontece com uma biblioteca CDK customizada para a organização quando a equipe de operações altera os requisitos fundamentais sobre como uma empresa está usando o AWS, por exemplo uma mudança na arquitetura VPC? Esse desenvolvedor ainda está empregado pela empresa? E se não qual engenheiro de operações precisará descobrir como o código funciona?
• Da mesma forma, quantas linguagens de programação os engenheiros de operações devem saber para executar uma manutenção? Tradicionalmente, mesmo que uma empresa use várias linguagens de programação para um aplicativo, do ponto de vista operacional, um engenheiro normalmente pode conviver com o conhecimento de bash/Python ou PowerShell. Mas se as equipes de aplicativos escolherem a linguagem de programação que a infrastructure terá baseado no aplicativo, isso terá consequência nos engenheiros operacionais, que agora precisam conhecer Python, JavaScript, Java, Go, TypeScript, e qualquer outra língua que o CDK permite, e tudo isso, para dar suporte ao portfólio de produtos de uma organização.
• O que acontece com aplicativos para os quais uma equipe não atualiza os ambientes CDK regularmente, por exemplo aqueles que vão 3 anos entre atualizações? Ficarão essas aplicações bloqueadas pois é necessário fazer alterações significativas no CDK Bootstrap na conta que estão usando? A versão do Node.js que eles usam ainda estará disponível? O que acontece no caso de uma necessidade urgente para atualizar a aplicação devido a um problema de segurança?

Suporte da AWS ao CDK a longo prazo

Como já descrevi, o CDK não é um "serviço AWS" no sentido normal: Não há uma API, não há um painel de controle na sua conta da AWS. Embora isso possa mudar com o tempo, se não acontecer, isso cria a pergunta: Até que ponto a AWS continuará a suportar o CDK? Claro, CDK tem uma página oficial de marketing, mas SAR tem um também e tem sido ignorado nos últimos dois anos (e SAR pelo menos tem um painel de controle no AWS Console).

Isso cria outras perguntas:

• Quão estável será o CDK à longo do prazo? Já vimos uma grande atualização de V1 para V2 e V1 não receberá mais atualizações de segurança a partir de 2023. Elimiar algo tão rápido é incomum no ecossistema da AWS.
• O CDK continuará recebendo investimentos significativos da AWS? Como não há um painel de controle do CDK, podemos imaginar que poderia facilmente ser engolido se perder o entusiasmo. Isso é um problema para algo que precisará ser atualizado para manter o suporte em suas ferramentas de fundamentos (por exemplo, Node.js LTS)
• Em um assunto relacionado, o CDK continuará a oferecer suporte a novos serviços e recursos da AWS em tempo hábil?
• Os problemas existentes com CDK (por exemplo a falta de suporte de tempo de execução na nuvem) será abordada?

Você deve usar CDK ou não?

No último ano, ouvi falar de muitas empresas mudando para CDK, em grande parte suspeito porque os desenvolvedores seniores querem usá-lo e estão fazendo suas vozes serem ouvidas. E como é um produto AWS "suportado oficialmente", há uma certa expectativa de que seja mantido ao longo do tempo na mesma medida que EC2 e S3.

Mas, devido à natureza fundamental do CDK ser uma ferramenta de abstração do lado do cliente, e não uma ferramenta na nuvem, eu acho que a expectativa é falsa ou, pelo menos, ainda está para ser comprovada. Isso traz à tona todas as preocupações de longo prazo - que mencionei aqui.

Se você deve usar CDK ou não, depende de como as preocupações listadas aqui podem impactá-lo ao longo do tempo. Por exemplo se você estiver usando CDK em um pequeno número de aplicativos, onde os próprios aplicativos são atualizados com frequência, e as equipes são as mesmas que estão construindo o aplicativo, então acho que o CDK é uma boa ideia. De novo, eu mesmo usaria CDK para esse tipo de configuração organizacional.

No entanto, eu provavelmente não usaria CDK nos seguintes cenários:

• Onde um aplicativo é atualizado com pouca frequência/já está "no modo de manutenção".
• Onde uma equipe de desenvolvimento do aplicativo é uma equipe separada da responsável pela implementação em produção.

Espero que com o tempo, a AWS faça do CDK uma ferramenta padrão estável, e mantida para implementação de infraestrutura. Mas por enquanto a escolha de usar o CDK é aquela que favorece os desenvolvedores no curto prazo, enquanto eu temo dar uma dor de cabeça considerável às equipes de operações aa longo prazo, sem manutenção contínua significativa.

Créditos

• AWS CDK - The Good, The Bad and the Scary, escrito originalmente por Mike Roberts