What is the name of AWS native infrastructure as code solution to repeatable deployments?

Introduction to IaC and AWS Native tools like CloudFormation and CDK

1. Introduction to Infrastructure as Code (IaC)

IaC is a methodology that allows us to define, through coding, the resources that make up our infrastructure and the relationships between them. 

Managing the infrastructure as if they were pieces of source code is one of the fundamental principles of the DevOps philosophy since it allows us to take advantage of the best practices associated with software design refined during years of development, to leverage them to provision and manage infrastructure. This way, we can manifest our infrastructure through code files that will be reusable, shareable and versionable, ensuring that the environments created are more robust, reliable, easy to maintain and manage and, above all, repeatable. 

2. Declarative Model vs Imperative Model

The main difference between the declarative model and the imperative model is to be able to distinguish between the ‘What’ and the ‘How’.

With a declarative paradigm, the focus is the end goal, the flow of the program and the underlying logic are of lesser importance. An example would be “I want three instances”.

With an imperative paradigm, control structures are built and logic is paramount. For example, “Build one instance and repeat until there are three”.

As they don’t have an underlying logic in the code, declarative scripts (which in the case of Infrastructure as Code are akin to text files specifically formatted in YAML or JSON) tend to be longer but also easier to read and therefore to maintain and build.

On the other hand, imperative scripts are not necessarily difficult to write, but having embedded logic makes maintaining them belong in the same category as maintaining software, requires attention to the interactions between program components, and is generally somewhat more time-consuming to maintain.

3. CloudFormation

AWS’ own IaC tool, CloudFormation is a native service that automates the deployment of resources in AWS and uses templates to declare resources. It is the vendor’s recommendation to provision infrastructure in different environments or accounts and manage resources, although it is not the only one that can be used. CloudFormation plays an important role in helping us distribute solutions regardless of environment, account or region. 

Learning CloudFormation is not complicated once some basic concepts of the service (Templates, Stacks, Change Sets) are understood and the user is able to adapt to the syntax of the configuration files. By mastering this, complex solutions can be deployed, replicated and distributed in a very short time. It is a free service and only incurs expenses with the services and resources deployed, making it a tool that manages our infrastructure without any charge for the service as such.

When for some reason it is not possible to deploy the infrastructure and there is any inconsistency in the deployment process, the system can perform automatic rollbacks: CloudFormation attempts to undo any changes that may have occurred during the execution and return the infrastructure to its pre-deployment state, including checking dependency between resources before deletion or upgrading.

A Drift detection feature analyses what we want to deploy and what we currently have deployed and is very useful to detect cases of click ops in an environment, which is quite difficult to perform in a large infrastructure.

4. CDK

CDK uses a programming language that minimizes traditional configuration files. This results in less code that does the same or more using the language of choice for our IaC: whether it is TypeScript, Python or JavaScript. By writing less code maintenance is reduced, it is easier to share it and above all it makes it easier and faster to grasp. A good example of this can be the creation of networking resources for an account or the maintenance of an API with many endpoints in Api Gateway.

The common factor of all programming languages supported by CDK is that they get along excellently with object oriented programming, this allows for more abstraction and inherits benefits of this paradigm beyond portability and reusability of our code as is the ability to create pieces of architecture that reduce complexity to the user without compromising flexibility and configuration required; also being able to easily extend specific functionalities on demand without much effort.

I must confess that when I first got to CloudFormation I liked it and I adapted quickly, it helped me and I enjoyed using it but: when I got introduced to CDK, and after passing the first entry barrier I  without hesitation preferred CDK. I can do the same as CloudFormation, only faster and better. I can use loops and conditionals as well as call the AWS API when synthesizing the stack to create dynamic resources. What I liked most is that I do not have to leverage documentation to create a resource; everything is included in the library. Any modern editor / IDE can look up within the library to see everything I need to use it, besides the autocompletion is a big plus and if we put it together with the typing that helps us to know the type of expected argument makes that you hardly have to leave the editor environment to look for information. [Enrique Alonso]

Packaging the solution or infrastructure product and making a delivery that can be used by anyone with very little configuration is achieved through CDK Constructs. They are used to create resources such as an S3 Bucket or an entire infrastructure such as an API with persistence and a Cloudfront distribution. We can create our own Constructs according to requirements and thus apply the DRY concept because if a solution is consistently reused we can package it and distribute it to different work teams.

CDK includes a testing library which is usable for code assertions, however it is prepared so that it can be tested and depending on the language used, it can be combined with the currently used test suite. With pytest functionality can be extended from an internal CDK test library with more complex test cases. In fact, the recommendation from AWS is that the tests are to be kept uncomplicated, evaluating simple code behaviors, but as the Stacks grow and with them complexity, the ideal scenario is that the tests are able to recognise if there are negative consequences to our modifications so they can be fixed before testing.

5. Drawbacks

• Both CDK and CloudFormation are AWS’s own tools for creating IaC for their own platform, so we will have optimal integration and great support, this also means solutions are not portable outside AWS.
• Library in constant development: currently the version changes of the library are constant and depending on your perspective, this can be considered a drawback. Both services are under development and these are risks to be weighed. With optimism, we can argue that new features and corrections continuously added, and that both AWS and the community are working to make it the standard for IaC in AWS. 

• 

• Cloud Engineer en Keepler Data Tech: “I'm a curious developer, I like to automate and solve problems, coding and learn something new every day. I'm a fan of good practices and I try to apply them as much as I can, I love APIs, communicating services between them and if it can be serverless, much better.”

  View all posts

• Cloud Architect at Keepler: "I'm interested in IT strategy with a focus on Governance and Architecture as well as the ideas behind them. But in my heart I'm an engineer who loves building stuff. When I'm not in front of a computer, I enjoy music and teaching."

  View all posts

Related Posts