DEV Community: Samuel Joseph

My Top 5 Terraform Practices from Real World Projects

Samuel Joseph — Sat, 24 May 2025 01:03:01 +0000

1. Use Remote State with State Locking
"Local state is fine - until it isn't."
Storing Terraform state files locally is a recipe for drift and disaster when working in teams or automating with CI/CD. Always use remote state with locking mechanisms enabled.
Preferred setup:
Use Terraform Cloud, AWS S3 + DynamoDB, or Azure Storage + Blob Locking. Locking prevents race conditions in concurrent terraform apply executions. It also provides visibility and collaboration for teams.

Example (AWS):
terraform { backend "s3" { bucket = "my-tf-state" key = "dev/network/terraform.tfstate" region = "us-west-2" dynamodb_table = "my-tf-locks" encrypt = true } }

2. Modularize for Reusability and Consistency
"If you're copying and pasting Terraform code, you're doing it wrong."
Modules help reduce code duplication and make infrastructure reusable across environments or projects. I've created core modules for VPCs, security groups, IAM roles, and ECS clusters, then customized them via inputs.
Benefits:

Faster provisioning.
Enforces organizational standards.
Easier onboarding for new engineers.

Structure tip:
modules/ vpc/ ecs/ iam/ environments/ dev/ prod/

Keep your modules clean and version-controlled. Avoid over-engineering; start simple and refactor as you scale.3. Use Workspaces or Explicit Folder-Based Separation
For smaller projects, Terraform workspaces can help manage multiple environments (e.g., dev, qa, prod) using the same code base. However, for complex setups, I prefer explicit directory separation.
Why folder-based separation often wins:
Easier CI/CD integration.
Less risk of accidental environment switches.
Better GitOps alignment.

Example structure:
live/ dev/ main.tf prod/ main.tf
Combine this with strong naming conventions and tagging strategies to avoid resource confusion.

4. Enforce Code Quality and Policy-as-Code
Terraform lets you define infrastructure as code, so treat it like software.
Use tools like:
tflint and terraform fmt for style and syntax.
checkov or tfsec for security and compliance scanning.
Sentinel or OPA (Open Policy Agent) for policy-as-code.

Integrate these checks into your CI/CD pipelines to catch issues early.
Example GitHub Actions snippet:

name: Terraform Format run: terraform fmt -check -recursive
name: Run TFLint run: tflint --recursive

Tag Everything and Document Inputs/Outputs When you return to a Terraform project after 6 months, or when someone else does,tags and documentation save the day. Best practices: Use consistent tagging across all resources (owner, environment, project, cost center). Document module inputs and outputs with descriptions. Use terraform-docs to generate README files for module

Example:
variable "environment" { description = "The environment to deploy (e.g. dev, prod)" type = string } output "vpc_id" { description = "The ID of the created VPC" value = aws_vpc.main.id }

Final Thoughts
These five practices; remote state, modularization, environment separation, code quality enforcement, and documentation, aren't just "nice to have." They're foundational. They've helped me avoid downtime, scale teams, and build resilient cloud platforms.

If you're starting out with Terraform, start with one or two of these and iterate. If you're already deep into IaC, consider how your current workflows align with these principles.

What are your top Terraform lessons from the field? I'd love to hear them.

Terraform #IaC #DevOps #CloudEngineering #InfrastructureAsCode #AWS #Azure #GCP #DevOpsBestPractices #CloudAutomation #TerraformModules #CICD #CloudInfrastructure #TerraformTips #DevOpsLife #TechLeadership

[Boost]

Samuel Joseph — Mon, 12 May 2025 21:47:15 +0000

Samuel Joseph

May 12 '25

Why Your Cloud Strategy Keeps Failing (And How I Fixed It)

#devops #cloudcomputing #terraform #leadership

Comments

3 min read

Why Your Cloud Strategy Keeps Failing (And How I Fixed It)

Samuel Joseph — Mon, 12 May 2025 21:39:14 +0000

Let’s be honest: most cloud “strategies” I come across aren’t really strategies — they’re glorified lift-and-shifts.

On paper, migrating to the cloud promises flexibility, scalability, and cost savings. But in reality? Many organizations just copy their on-prem setup into AWS, Azure, or GCP — and call it done.

As someone who’s spent years helping companies build scalable, secure, and cloud-native infrastructure across multi-cloud environments, I’ve seen this mistake over and over. But one project in particular made this painfully clear.

The Lift-and-Shift That Didn’t Shift Anything
I had just joined a mid-sized financial services company as a Cloud Transformation Lead. Leadership proudly told me they were “70% in the cloud.” That should’ve been a good sign, right?

But what I found was this:
1.All their web, app, and database servers were provisioned on EC2 instances — configured almost exactly like their legacy setup.

2.They managed access using manually configured Security Groups and Network ACLs — trying to mimic their old firewall rules.

3.Scaling decisions were triggered manually: CloudWatch alarms were set to ping when CPU utilization went above 80% or dropped below 30%, at which point someone had to manually launch or terminate instances.

4.All developers operated under IAM user credentials in a single shared AWS account - no role-based access, no federation, no real audit trail.

To them, this was “cloud.” To me, this was a rented data center — with all the old problems, now in a shinier interface. It wasn’t a cloud strategy. It was a technical translation with none of the cloud-native benefits.

How We Fixed It: From LIFT and SHIFT to CLOUD NATIVE
I knew we had to shift our thinking — this wasn’t about fixing servers, it was about fixing mindset, processes, and architecture. Here’s how we turned it around:

🔵 From Manual Scaling → Auto-Scaling

Replaced reactive CPU alerts with Auto Scaling Groups + intelligent policies.
Added Application Load Balancers for dynamic traffic distribution.
Result: Infrastructure scaled automatically — no human intervention needed.

🔵 From IAM Users → Federated, Role-Based Access

Integrated AWS SSO with their identity provider.
Moved to least-privilege IAM roles(mapped to teams/functions).
Result: Tighter security, easier audits, no more credential sprawl.

🔵 From ClickOps → Infrastructure-as-Code

Rewrote every security group, subnet, and alarm in Terraform.
Infrastructure became version-controlled, peer-reviewed, and auditable.
Result: No more “who changed what?” panic.

🔵 From EC2-Centric → Cloud-Native

Containerized apps → ECS + Fargate (no more patching EC2).
Let AWS handle scaling, provisioning, and maintenance.
Result: Faster deployments, lower ops overhead.

The Results
Deployment times dropped from weeks to under an hour

◼️Scaling became predictable and automatic

◼️Developers no longer fought over IAM policies or waited for infra

◼️We cut compute costs without sacrificing performance

Most importantly; The cloud stopped being someone else’s job. It became part of how every team delivered value.

Final Thought
Your cloud strategy isn’t failing because the cloud is broken. It’s failing because you’re treating the cloud like your old data center.

If you’re still managing users manually, reacting to CPU alarms, and spinning up EC2s for every new service — you haven’t transformed. You’ve just migrated your problems.

I’ve helped lead this change. I’ve lived through the mess. And I can tell you this: “Real cloud transformation happens when you stop lifting and start rethinking.”

Let’s Connect
I’m Samuel Joseph, and I help companies turn their cloud chaos into clarity. If you’re stuck in a costly, rigid, or outdated cloud setup, let’s talk.

DevOps #CloudComputing #CloudStrategy #AWS #Azure #GCP #Terraform #Leadership