by Daniel Pohl, Director of Product Management

Read the other posts in this series:

1. Part 1: IaC Makes Your AWS CI/CD Pipelines Run Smoothly
2. Part 2: Why IaC + CI/CD Pipelines Are Simpler for Containerized Applications
3. Part 3: IaC + CI/CD Pipelines for Applications on Amazon EC2
4. Part 4: IaC + CI/CD Pipelines for Kubernetes Apps (Amazon EKS)

A goal of modern software development teams is to rapidly and reliably build, test, and deploy applications. For cloud-native teams, this means not just automating application code delivery in a CI/CD pipeline, but also automating cloud infrastructure build-out.

In this four-part series, we’ll explore the benefits of Infrastructure as Code (IaC) within your existing CI/CD pipeline.  We’ll evaluate the pros and cons of different IaC & CI/CD strategies for applications either hosted on EC2 or within EKS containers.

This series strives to clearly explain the business value of each technical principle.  We begin this first part with CI/CD pipelines and Infrastructure as Code – thus laying the groundwork for the rest of this series.

What is a CI/CD Pipeline?

A Continuous Integration/Continuous Deployment (CI/CD) pipeline is an automated process that your software development team creates to deliver their software applications.

The CI/CD pipeline includes the necessary steps for transforming lines of code into executing applications.  These steps typically include building, testing, and releasing.

Historically, software development teams and their CI/CD pipelines only focused on the software application.  The infrastructure (whether physical or virtual) that hosted the application were merely a resource that the CI/CD deployment step would assume to exist.  In the past, separate teams owned the cloud infrastructure.

Today, cloud-native software development teams seek to remove assumptions by owning the full infrastructure stack that their software applications depend on.  These cloud-native teams want to control the delivery of this cloud infrastructure using the same CI/CD pipelines that control the delivery of their software applications.

What is Infrastructure as Code?

Cloud-native development teams define their needed cloud infrastructure in JSON syntax so this infrastructure definition can be version-controlled and stored alongside the software application code in GitLab or other source code repository.  This is called “Infrastructure as Code” (IaC).  Cloud infrastructure such as virtual servers, virtual networks, and API gateways can be defined as JSON code in the same ways that software application logic is written in code.  IaC removes the need for a dev team member to click through the AWS Management Console UI provisioning their needed cloud infrastructure (manual “click” sequences would be quite difficult to version control or automate).

Both AWS and Azure offer cloud-native teams the ability to define cloud infrastructure in Terraform or a cloud-specific IaC language (AWS CloudFormation, Azure ARM Templates).  All aspects of the cloud infrastructure available in the AWS Management Console or Azure Portal user interfaces can also be defined in code, such as Auto-Scaling maximums or the version of Ubuntu operating system on a Virtual Machine.

Logicworks has tooling and processes to more accurately create best-practice IaC based on your technical, commercial, and compliance requirements.  Our tools benefit from our proven Terraform, CloudFormation, and ARM template libraries that already have provided the IaC foundation for customers’ audited cloud systems.

Cloud-native teams integrate IaC into their CI/CD pipelines

Cloud-native software development teams code steps in their application’s CI/CD pipeline to dynamically provision the needed cloud infrastructure (as per the IaC definition) and then deploy the desired version of their application onto this infrastructure.

The CI/CD pipeline can easily be configured to launch cloned development or staging environments.  Cloud-native software developers commonly want their own separate developer-testing environment.  Or, a new pipeline step could automatically launch an independent staging environment for the InfoSec team to perform vulnerability testing.

In some cases, CI/CD pipelines launch separate production environments for each customer of the application.  This is a novel approach for creating multi-tenancy without re-architecting a legacy application originally created for only a single tenant.

If infrastructure changes are needed (e.g. higher Auto-Scaling limits or updated Ubuntu operating system version), the team does not make ad-hoc tweaks to the executing infrastructure.  Ad-hoc infrastructure tweaks are likely to be forgotten, thus causing some important difference between dev environments and production environments.

For example, the team might find that a certain performance problem is solved by upgrading the webservers from Ubuntu 20 to Ubuntu 20.04.  The team could simply apply this operating system patch to the existing webservers, but then the team would need to remember to apply the same patch to their staging and production environments.

Instead, cloud-native development teams make infrastructure changes (e.g. operating system patching) by updating their IaC.  This enforces that all infrastructure changes are committed to version control.

Once committed, the cloud-native team deploys changes (application logic, IaC, or both) using their CI/CD pipeline.  This combination of IaC and CI/CD pipelines guarantees that the correct combination of infrastructure version and application version are migrated from dev to staging to production.

This combined IaC and CI/CD pipeline process also provisions cloud infrastructure just-in-time, thus optimizing cloud costs. The cloud-native team can now rapidly and reliably develop, test, and deploy enhancements to both their application and its cloud infrastructure.

The cloud-native team can now rapidly and reliably develop, test, and deploy enhancements to both their application and its cloud infrastructure.

Benefits of a combined IaC and CI/CD pipeline process:

• Production environment guaranteed to match development and staging environments
• Changes to infrastructure trigger appropriate system testing
• Easy to revert to prior versions of both cloud infrastructure and application code
• Easy to deploy separate dev and staging environments for each developer or tester
• Optimize cloud costs by provisioning infrastructure immediately before code deployment

Stay tuned for Part 2 of this series next week: How IaC & CI/CD pipelines are different for EC2 Hosted Apps vs. Containerized Apps.