DEV Community: Alao Abdul-zahir

🚀 Building a Multi-Environment, Auto-Scaling Web Platform with Terraform

Alao Abdul-zahir — Fri, 29 Aug 2025 23:29:38 +0000

Managing cloud infrastructure by hand can be messy, especially when juggling multiple environments like dev, staging, and prod. That’s where Terraform shines – it lets you define your infrastructure as code, making your deployments consistent, repeatable, and version-controlled.

In this post, I’ll walk you through building a production-ready web application infrastructure on AWS using Terraform. We’ll cover:

🔹 Multi-environment setup (dev & prod)
🔹 VPC with public/private subnets
🔹 Auto Scaling Group with EC2 instances
🔹 RDS database layer
🔹 Secure backend state management
🔹 Secrets scanning with git-secrets

🏗️ Project Overview

We’re building a simple yet scalable platform:

Internet
   ↓
Application Load Balancer (ALB)
   ↓
Auto Scaling Group (EC2 Instances)
   ↓
RDS Database (MySQL)

This setup ensures high availability, cost optimization, and easy environment promotion (from dev to prod).

📂 Project Structure

We organize Terraform code using modules for reusability:

terraform-web-platform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf
│       └── terraform.tfvars
├── modules/
│   ├── networking/
│   ├── compute/
│   ├── database/
│   └── monitoring/
└── README.md

🔑 Key Features

✅ Multi-Environment Setup – Each environment has its own state and variables.

✅ Terraform Modules – Networking, compute, database, and monitoring are modularized.

✅ Secure State Management – Remote state stored in S3 with DynamoDB locking.

✅ Auto Scaling – EC2 instances scale based on CPU utilization.

✅ Monitoring – CloudWatch metrics and alarms for visibility.

🛠️ Setup Instructions

1. Clone the Repo

git clone https://github.com/pojava/terraform-web-platform.git
cd terraform-web-platform

2. Configure AWS Credentials

aws configure

Provide your AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, region, and output format.

3. Initialize and Apply Terraform

cd environments/dev
terraform init
terraform plan
terraform apply

To deploy to production:

cd ../prod
terraform init
terraform plan
terraform apply

4. Check the Load Balancer

Once deployed, Terraform outputs the ALB DNS. Visit it in your browser to verify your app is live.

🔒 Security Practices

No Hardcoded Secrets: All sensitive values are managed through environment variables or AWS Secrets Manager.
git-secrets Installed: Prevents accidentally committing API keys.
.gitignore Applied: Ignores Terraform state and provider files.

🧹 Cleaning Up

When you’re done testing, destroy resources to avoid costs:

terraform destroy

📝 Lessons Learned

Using Terraform modules keeps your code DRY and maintainable.
Remote state locking prevents accidental overwrites during team deployments.
AWS Auto Scaling ensures your application stays resilient without overspending.

🔗 Useful Resources

🚀 Final Thoughts

This project shows how to go from zero to a production-ready, auto-scaling infrastructure using Terraform. By structuring code with modules and managing state securely, scaling your app becomes a breeze.

If you found this useful, ⭐️ the repo and drop a comment on Dev.to!

🔗 GitHub Repo

Deploying a Live Netlify Site with Deploying a Live Netlify Site with Terraform + HCP Terraform Remote State

Alao Abdul-zahir — Fri, 22 Aug 2025 22:27:22 +0000

🔹 The Idea: Simplicity + Reproducibility

Instead of manually spinning up a Netlify project, I wanted a fully automated pipeline:

Terraform provisions everything:
- Creates a GitHub repo for the static site.
- Configures Netlify hosting.
- Manages infrastructure and state remotely in HCP Terraform.
Push changes to GitHub → Netlify auto-deploys.

This setup means anyone can clone the Terraform code, set a few variables, and spin up their own live site—no manual clicks in the UI.

🔹 Architecture Overview

Terraform: Core IaC engine, manages all resources declaratively.
HCP Terraform (Terraform Cloud): Stores remote Terraform state, ensuring collaboration and state locking.
GitHub: Hosts both the Terraform code and the deployed static site.
Netlify: Automatically builds and serves the site from GitHub.

Workflow looks like this:

Terraform Code → HCP Terraform (remote state) → GitHub Repo → Netlify → Live Site

Live Site: https://curious-pasca-da123e.netlify.app/

🔹 Why It’s Unique

No manual configuration: Terraform does the heavy lifting.
Secure Secrets Management:
- Netlify tokens stored as sensitive HCP workspace variables, not in the repo.
Re-runnable: Run terraform init/plan/apply with fresh creds, and everything just works.

🔹 Step-by-Step Setup

Here’s the high-level setup (full code is in the repo, not here):

Prerequisites

Terraform CLI installed
Netlify & GitHub accounts
HCP Terraform org + workspace (CLI-driven)

HCP Terraform Remote Backend

terraform { cloud { organization = "your-org" ... } } block points Terraform to HCP.
State stored remotely, enabling team collaboration.

Secrets in HCP Workspace

github_token and netlify_token set as sensitive variables in the workspace.
No secrets are ever committed.

Terraform Code

Declares:
- GitHub repo for the site.
- Netlify site linked to that repo.
- Simple HTML page and netlify.toml.

Deploy

   terraform init
   terraform plan
   terraform apply

Terraform provisions the repo, uploads files, links Netlify, and your site is live instantly.

🔹 Lessons Learned

Terraform + Netlify is underrated: You can treat front-end hosting as IaC.
HCP Terraform simplifies collaboration: State locking and workspace variables make teamwork painless.
Small IaC projects are great for practice: Even a static site helps you practice production-grade workflows.

🔹 Next Steps

Improve the site design and make it dynamic with environment variables via Terraform.
Explore integrating GitHub Actions for CI/CD to trigger Terraform runs.
Scale this pattern to multi-env (staging/prod) setups.

🔗 Links

🌍 Live Site: https://curious-pasca-da123e.netlify.app/
📂 Terraform Repo: https://github.com/pojava/hcp-netlify-terraform

🙌 Thanks & Tagging

Thanks to HashiCorp User Group (HUG) Ibadan for the challenge!
📌 Tagging: HUG Ibadan LinkedIn Page

💡 This post shows how easy it is to use Terraform to automate frontend hosting as if it were backend infra.
Would love feedback from the community—how would you extend this setup?

Serverless Computing: Building a Number Classification API with AWS Lambda and API Gateway

Alao Abdul-zahir — Fri, 07 Feb 2025 23:09:59 +0000

Serverless computing has revolutionized the way applications are developed and deployed by eliminating the need for traditional server management. This post explores the creation of a Number Classification API using AWS Lambda and API Gateway, a robust combination for building highly scalable and cost-effective serverless APIs.

The API is capable of returning mathematical properties for any given number, such as whether it’s a prime, perfect, or Armstrong number, along with other properties and a fun fact.

Why Serverless Computing?

Serverless architecture offers several advantages:

Scalability: Automatically handles request scaling without manual intervention.
Cost Efficiency: Pay only for the actual usage.
Focus on Development: Eliminate server maintenance and infrastructure concerns.

Solution Overview

The Number Classification API performs the following tasks:

Accepts a number via an HTTP GET request.
Determines whether the number is prime, perfect, or Armstrong.
Computes the sum of its digits.
Fetches an interesting mathematical fact using an external numbers API.
Returns a well-structured JSON response.

Architecture

User Request: A client (browser or app) sends a number to the API via an HTTP GET request.
API Gateway: Serves as the entry point, invoking the AWS Lambda function.
AWS Lambda: Executes the number classification logic and fetches fun facts.
External Numbers API: Provides mathematical trivia for the input number.
Response: The Lambda function returns a JSON response containing the computed results.

Step-by-Step Implementation

Step 1: Create the Lambda Function

Navigate to the AWS Lambda Console and create a new function.
Choose "Author from Scratch" and select Python as the runtime.
Upload the following Lambda code to the function:

Lambda Function Code

import json
import urllib.request

def classify_number(number):
    if number > 1:
        is_prime = all(number % i != 0 for i in range(2, int(number ** 0.5) + 1))
    else:
        is_prime = False

    is_perfect = sum(i for i in range(1, number) if number % i == 0) == number

    digits = [int(d) for d in str(number)]
    is_armstrong = sum(d ** len(digits) for d in digits) == number
    digit_sum = sum(digits)

    properties = []
    if is_armstrong:
        properties.append("armstrong")
    properties.append("even" if number % 2 == 0 else "odd")

    return is_prime, is_perfect, properties, digit_sum

def fetch_fun_fact(number):
    try:
        url = f"http://example.com/{number}/math"  # External API placeholder
        with urllib.request.urlopen(url) as response:
            return response.read().decode()
    except Exception:
        return "Unable to fetch fun fact at the moment."

def lambda_handler(event, context):
    try:
        number = int(event["queryStringParameters"]["number"])
        is_prime, is_perfect, properties, digit_sum = classify_number(number)
        fun_fact = fetch_fun_fact(number)

        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({
                "number": number,
                "is_prime": is_prime,
                "is_perfect": is_perfect,
                "properties": properties,
                "digit_sum": digit_sum,
                "fun_fact": fun_fact
            })
        }
    except (ValueError, KeyError):
        return {
            "statusCode": 400,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({
                "number": event["queryStringParameters"].get("number", "invalid"),
                "error": True
            })
        }

Step 2: Set Up API Gateway

Navigate to the API Gateway Console and create a new API.
Connect it to the Lambda function using Lambda Proxy Integration.
Deploy the API and obtain the endpoint URL.
Enable CORS (Cross-Origin Resource Sharing) for public access.

Testing the API

To test the API, use tools like Postman or simply visit the API URL in your browser.

Example Request (Placeholder)

GET https://example-api-url.com/classify-number?number=371

Example Successful Response (200 OK)

Error Response (400 Bad Request)

{
  "number": "invalid",
  "error": true
}

The project code is publicly available on GitHub.

Conclusion

Serverless computing allows developers to focus on building applications without worrying about infrastructure. By integrating AWS Lambda and API Gateway, a reliable and scalable Number Classification API was successfully built and deployed. This approach showcases the efficiency and versatility of serverless architecture for real-world applications.

My Experience Setting Up NGINX on Ubuntu in AWS – HNG DevOps Stage 0

Alao Abdul-zahir — Tue, 04 Feb 2025 23:04:34 +0000

NGINX Web Server Setup on Ubuntu EC2 Instance

As part of my DevOps Stage 0 task, I set up an NGINX web server on an Ubuntu EC2 instance in AWS to serve a custom HTML page. This project allowed me to revisit foundational DevOps practices and cloud infrastructure management.

1. Launch an EC2 Instance:

I created an Ubuntu 24.04 instance using the t2.micro type and configured security groups to allow SSH (port 22) and HTTP (port 80) traffic.

2. Connecting and Setting Up:

After connecting via SSH with the .pem key, I updated the package list and installed NGINX with:

sudo apt install nginx -y

I started and enabled NGINX to run on boot with:

sudo systemctl start nginx
sudo systemctl enable nginx

3. Configuring the Custom HTML Page:

I replaced the default page by editing:

/var/www/html/index.html

with my custom message and restarted NGINX to apply the changes:

sudo systemctl restart nginx

4. Testing the Setup:

I accessed the server via its public IP and verified that the page loaded correctly in a browser.

Insights and Challenges:

Cloud Infrastructure: Launching EC2 instances and configuring security groups enhanced my understanding of cloud computing basics.
Linux Administration: Navigating Ubuntu and managing NGINX solidified my skills in Linux server management.
Networking: Understanding how security groups and firewalls work in cloud platforms was key to resolving issues with HTTP traffic access.

Challenges Encountered:

I initially faced issues accessing the page via the public IP due to incorrect inbound traffic configuration. Once I allowed HTTP traffic on port 80, the problem was resolved.

Conclusion:

This task was foundational for cloud infrastructure, web server configuration, and Linux system management. It’s a critical skill for any DevOps engineer and has prepared me for more advanced topics such as automation and multi-region deployments.