Abdur Rahim

Business Problem

Deployments were manual and inconsistent. Failures often surfaced only after code reached production, with no automated safety net — no security scanning, no approval gate — before a change shipped to customers.

Architecture

A GitHub Actions / Jenkins workflow triggers on merge to main: build and unit test, run a Trivy vulnerability scan on the built image, hold at a manual approval gate, deploy to AWS EC2 behind NGINX, run a post-deploy health check, then notify the team via Discord/Telegram.

Implementation

The pipeline is defined entirely as code (YAML workflow), secrets are managed via encrypted CI variables rather than hard-coded values, and deployment scripts are idempotent so a re-run never leaves the environment in a half-applied state.

Technologies Used

Challenges

Balancing deployment speed against safety — too many manual gates slows the team down, too few lets risky changes slip through unnoticed.

Results

Deploy frequency increased, most failures are now caught pre-production by the automated scan and gate, and mean-time-to-detect dropped thanks to post-deploy health checks and automated alerting.

Lessons Learned

A human approval gate before production isn't friction, it's the cheapest insurance policy in the pipeline. Automating the boring parts — build, test, scan — frees that human judgment for the one decision that actually needs it.

Business Problem

Incidents were routinely discovered by users before the team noticed, and there was no historical metrics data to diagnose recurring performance issues.

Architecture

Node Exporter and application metrics feed Prometheus, which powers Grafana dashboards and alert rules. Sentry handles application error tracking and Uptime Kuma runs external synthetic uptime checks; all three route into a shared alerting channel.

Implementation

Alert thresholds were defined around SLOs — request latency and error rate, not just raw CPU/memory — with role-specific Grafana dashboards for infrastructure versus application health, and rules tuned iteratively to cut false positives.

Technologies Used

Challenges

Early alert rules fired too often on transient blips, which trained the team to start ignoring pages — the opposite of the intended outcome.

Results

Incidents are now detected automatically within minutes instead of relying on user reports, and historical dashboards are used to right-size infrastructure and catch slow regressions before they become outages.

Lessons Learned

Alert fatigue is a bigger risk than under-alerting. Tuning thresholds around real SLOs, rather than arbitrary resource limits, is what makes an on-call rotation sustainable.

Business Problem

New environments took days to stand up correctly, configuration drifted between servers over time, and standing up an environment relied on tribal knowledge rather than documentation.

Architecture

Terraform provisions cloud resources — networking, compute, security groups — while Ansible handles configuration management on top: packages, users, service configs. Both are version-controlled in Git and applied through a CI pipeline with a plan/review/apply flow.

Implementation

Terraform modules were built for reusable environment templates so staging and production stay in parity, and Ansible playbooks were made idempotent and tested against staging before ever touching production.

Technologies Used

Challenges

Retrofitting existing, hand-configured servers into Terraform/Ansible-managed state without triggering destructive changes on first apply.

Results

New environments now stand up in a fraction of the previous time with guaranteed staging/production parity, and configuration drift is eliminated since servers are reconciled from source-controlled definitions instead of hand edits.

Lessons Learned

The value of infrastructure-as-code isn't speed on day one — it's that six months later, nobody has to remember what they changed by hand.

Business Problem

"Works on my machine" issues were routine, new-developer environment setup took days, and scaling meant manually replicating server configuration by hand.

Architecture

Multi-stage Dockerfiles per service, a shared base image for common dependencies, Docker Compose for local development parity with production, and a container registry wired into the CI pipeline.

Implementation

Image size and attack surface were minimized via multi-stage builds, dependency versions pinned for reproducibility, and Trivy scanning added to the build step before any image is pushed to the registry.

Technologies Used

Challenges

Legacy services with hard-coded file paths and undocumented runtime dependencies didn't containerize cleanly on the first pass.

Results

Environments are now identical from a developer's laptop through to production, new-developer onboarding dropped from days to minutes, and deployments became portable across EC2 and Kubernetes nodes alike.

Lessons Learned

Containerizing legacy services surfaces every undocumented assumption they were built on — budget time for that discovery, not just for writing the Dockerfile.

Business Problem

The existing environment had a single point of failure per component, no clear separation between environments, and no formal security baseline — broad security groups and shared credentials.

Architecture

A VPC with public/private subnet separation: an Application Load Balancer (or NGINX, depending on the environment) in the public subnet, compute in the private subnet — either EC2 or EKS depending on workload — per-service security groups, IAM roles instead of shared credentials, managed RDS/ElastiCache for stateful services, and S3 for backups and static assets.

Implementation

Networking was rebuilt around least-privilege security groups, staging and production were given clear environment isolation, backup verification was automated, and the application tier was placed behind a load balancer for horizontal scale — with stateful components migrated onto managed services to remove self-hosted database/cache maintenance from the team's plate.

Technologies Used

Challenges

Migrating live traffic onto the new network topology without downtime, and revoking legacy shared credentials without breaking existing automation that depended on them.

Results

The environment now scales horizontally under load, no single component is a hard single point of failure, and access is fully attributable per IAM role instead of shared logins.

Lessons Learned

Security and scalability are cheaper to design in from the start than to retrofit — most of the hard migration work was undoing shortcuts taken under early deadline pressure.

Business Problem

No single view existed for the health of the fleet — CI/CD build status, container health, service uptime, SSL expiry, and resource usage each lived in a different tool or required manually SSHing into hosts, so incidents were often found manually instead of automatically.

Architecture

A Node.js/Express backend runs independent collectors in parallel: Jenkins and GitHub Actions REST APIs for deployments, HTTP health pings per service, TLS handshakes for SSL expiry, and a host-side cron script over SSH (never docker.sock) that gathers container/disk/memory/CPU stats across the EC2 fleet into read-only JSON files. Results feed a browser dashboard, and an alerting engine pushes to Telegram and Discord only on state transitions.

Implementation

Built from scratch rather than adopting an existing tool, specifically to fit the exact mix of infrastructure in use — Jenkins and GitHub Actions side by side, a rootless Docker daemon, and a fleet too small to justify running and maintaining a full Prometheus/Grafana/Alertmanager stack just for this.

Technologies Used

Challenges

Rootless Docker ruled out the common docker.sock-mount approach for container stats; an early CPU% calculation briefly measured the collector script's own load instead of the host's real usage; a single slow Jenkins response was delaying unrelated panels.

Results

A single dashboard now gives an accurate, real-time view of the whole EC2 fleet's health, catches SSL expiries and service outages automatically via push alerts, and removes the need to manually SSH into hosts just to check status.

Lessons Learned

A small, purpose-built internal tool can be faster and cheaper than adopting a general-purpose one — especially when the exact mix of infrastructure (two CI providers, mixed self-managed and managed services) doesn't map cleanly onto an off-the-shelf dashboard's assumptions.