Terraform vs CI/CD for Serverless Deployments
The Misalignment Between Infrastructure and Application Lifecycles
It’s crucial to understand that the lifecycle of infrastructure and applications are inherently different. While infrastructure changes are typically infrequent, application updates can occur multiple times a day. For instance, your network configuration might remain stable for a year, yet an application update could require immediate rollback if it introduces a bug. This necessitates a more frequent and agile release process for applications compared to infrastructure, which cannot be efficiently managed with the same toolset.
Terraform’s Strengths in Infrastructure Management
Terraform, an open-source Infrastructure as Code (IaC) tool by HashiCorp, excels in defining, arranging, and managing infrastructure. Its widespread adoption across industries is due to its ability to automate deployments across various cloud providers like AWS, Azure, and GCP, as well as platforms like Heroku and GitHub. But the critical question is: what should you manage with Terraform?
Terraform is particularly effective for defining the desired configuration state of core infrastructure components such as networking, IAM, buckets, SQL databases, secrets, DNS, and load balancers. These components form the backbone of your systems and typically require less frequent updates.
The Unique Nature of Application Deployment
With the advent of AI-powered coding tools, the tech industry has become more competitive, emphasizing rapid development cycles. Delivering new features multiple times a week—or even daily—is now a baseline requirement. This demand for speed necessitates a shift in software delivery methods, prioritizing fast, reliable, and automated deployment processes that can quickly roll back changes if necessary.
Case Study: Google Cloud’s Cloud Run
Consider Google Cloud’s serverless platform, Cloud Run, which allows you to run containers at scale. We can evaluate deployment workflows through Terraform versus a continuous deployment approach using GitHub Actions.
See all related items in my repository: here.
Terraform Deployment Example
In the Terraform configuration snippet below, we define our Cloud Run service. Once satisfied with the setup, running terraform apply applies the changes. However, deploying a new application version entails building and pushing a Docker image to the Artifact Registry, renaming it correctly, and modifying the Terraform variable.
resource “google_cloud_run_v2_service” “cloud managed service” {
name = OUR.cloud_run_service_name
location = OUR.region
entrance = “INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER”
deletion_protection = FAKE
model {
service_account = OUR.sa_cloud_run
containers {
picture = OUR.image_container
env {
name = “GCP_PROJECT_ID”
value = OUR.project_id
}
env {
name = “INPUT_DATASET”
value = OUR.input_dataset
}
env {
name = “OUTPUT_DATASET”
value = OUR.output dataset
}
env {
name = “API_KEY”
source_value {
secret_key_ref {
secret = OUR.api_key_secret_name
version = OUR.api_key_secret_version
}
}
}
}
}
}
CI/CD with GitHub Actions Example
The following configuration deploys a cloud service via the gcloud CLI in GitHub Actions. Committing and pushing code changes to the GitHub repository triggers the CI/CD pipeline, building and deploying a new Docker image to Artifact Registry, and updating the Cloud Run service—all from a single source.
PICTURE=${{ env.GCP_REGION }}-docker.pkg.dev/${{ env.GCP_PROJECT_ID }}/cloud-run/app:${{ github.sha }}
gcloud run deployment ${{ env.PROJECT }}
–image=$IMAGE
–region=${{ env.GCP_REGION }}
–platform=managed
–memory=1Gi
–no-allow-unauthenticated
–ingress=internal and cloud load balancing
–account-service=${{ env.SERVICE_ACCOUNT_RUNTIME }}
–set-env-vars GCP_PROJECT_ID=${{ env.GCP_PROJECT_ID }}
–set-env-vars INPUT_DATASET=${{ env.INPUT_DATASET }}
–set-env-vars OUTPUT_DATASET=${{ env.OUTPUT_DATASET }}
–set-secrets API_KEY=API_KEY:latest
Limitations of Terraform for Application Deployments
While Terraform can deploy cloud services, it blurs the line between infrastructure and application management. Separate teams often manage these areas, causing potential delays and state-locking issues. Workspace management becomes complex and noisy, especially when dealing with multiple environments.
To address these challenges, some suggest creating more Terraform workspaces to avoid interference, but this can increase complexity and management difficulty.
A Practical Solution: Separation of Concerns
After years of experience, I advocate using IaC tools like Terraform for infrastructure management while employing CI/CD pipelines, such as GitHub Actions, for application releases. This division allows different teams to focus efficiently on infrastructure and applications, simplifies tracking of deployed application versions, and facilitates seamless environment releases. It also enhances secret management security and simplifies rollback procedures.
In summary, Terraform is best suited for infrastructure, not application deployment.
For further reading, visit the original article here.
“`
