Infrastructure-as-code-tooling updates - Cloud Development Kits
Have you looked at any of the Cloud Development Kits?
These are tools and frameworks for handling infrastructure-as-code with programming languages. It is a space that I predict will see a lot of growth. That space is not only for developer experts but either directly or indirectly by all sorts of roles that work with consistent and repeatable infrastructure provisioning.
This week includes a few Cloud Development Kit news items that certainly can be valuable!
AWS Cloud Development Kit
CDK Pipelines now generally available
The CDK team has worked on their higher-level packaging of continuous integration/continuous delivery pipeline for quite some time now. AWS has some services related to the CI/CD area, including CodePipeline, CodeBuild, CodeCommit, CodeDeploy, and CodeStar.
To be honest, the user experience with these services leaves a few things to be desired, in particular when it comes to trying to set up pipelines across multiple AWS accounts.
CDK Pipelines makes life much easier though if you choose to use these services that AWS provides for your pipeline needs. It is reasonably straightforward to set up a multi-account pipeline solution using CDK pipelines.
The API provided is not locked to a specific engine, thus anyone can implement other pipeline solutions using the same building blocks. The AWS CDK currently only comes with a ready-made implementation for CodePipeline+CodeBuild.
The generally available version comes in AWS CDK version 1.116.0 or later. If you have started to use AWS CDK 2.x, the corresponding version would be 2.0.0-rc.17. The announcement for CDK pipelines general availability is here
New to AWS CDK? Take at look at the AWS website, or their Github repository!
Cloud Development Kit for Terraform
CDKTF 0.5 has been released
The Cloud Development Kit for Terraform works with the same idea as AWS CDK but uses Terraform HCL instead for the underlying infrastructure declarative description (AWS CDK uses Cloudformation). It also fits in with the workflow used for Terraform and works with all Terraform providers. It supports Typescript, Python, Java, and C# (.NET) for implementation languages (also Go language is coming).
This new 0.5 release includes a conversion tool for existing HCL (Terraforms language to describe infrastructure) to CDKTF code, for all supported languages.
The release also includes a watch command intended for serverless production-like workloads. As you edit and change your code, CDKTF will continuously synthesize (generate HCL from code) and apply changes, to allow for a faster iterative workflow.
I think this is quite exciting to see these efforts, and it will be interesting to see how the adoption of CDKTF and its features will evolve. CDKTF is not as mature as AWS CDK yet, but it is making good progress. The announcement for release 0.5 is here.
New to CDK for Terraform? Check out the CDKTF webpage at Hashicorp Learn, or their Github repository! ### All CDKs
Construct Hub in developer preview
The underlying foundation for all the different CDK packages (AWS CDK, CDKTF, CDK8s) is a building block called a construct, used by all these frameworks to represent infrastructure resources. These can be simple constructs that map to a single cloud provider resource. These can also be more high-level constructs that combine different resources into a package that is easier to manage.
Construct Hub is a website that is intended as a one-stop place to find constructs for various patterns and solutions. This includes the official construct libraries from AWS and Hashicorp, as well as 3rd party constructs. Anyone can provide additional constructs to Construct Hub.
There is even a construct to build a construct hub website, so it could also be used for internal/corporate constructs. The announcement about the Construct Hub developer preview is here.
Notes
I am a fan of these Cloud Development Kits. If used right, I think they will provide a lot of value to cloud infrastructure management. They can work well with teams responsible for both infrastructure and application development.
They can also work well with separated responsibilities for application, and infrastructure development, and operations. They can also work well with separated responsibilities for application, and infrastructure development, and operations.
The key here is to develop suitable constructs and components with the right abstractions for each team. They get the lego bricks that work for them and make them productive.
I am sure we will see more interesting use patterns with these types of constructs in the future, and not only for developers.
Until next time,
/Erik