
Cloud Services
- Ibrahim Fiqhan
- Cloud services
- March 28, 2025
Table of Contents
Infrastructure design, migration, and automation — for teams who need production environments that can be rebuilt from code rather than remembered.
I’m an AWS Certified Solutions Architect – Associate with 7+ years in software engineering, currently running multi-environment AWS infrastructure for a microservices platform and previously responsible for 900+ hosting accounts across three servers in government.
What you get
- Infrastructure as code in Terraform. Your environment is reproducible, reviewable in pull requests, and not locked in anyone’s head.
- Configuration as code in Ansible, with roles and inventory committed to your repository.
- An architecture document covering network layout, security boundaries, data flow, and the trade-offs behind each decision.
- A CI/CD pipeline with quality gates, security scanning, and controlled promotion to production.
- Monitoring and alerting that reaches a human — dashboards for logs, metrics, and traces, with alerts routed to Telegram, email, or Slack.
- Backup and disaster recovery policy, with a restore actually performed and verified rather than documented and trusted.
- A cost breakdown of what you’re running and why, plus where it can be reduced.
- Runbooks for deployment, rollback, scaling, incident response, and restores.
- Handover and training for your team, so this doesn’t become a dependency on me.
What I can do
The five areas on the poster.
Design & Architecture
Infrastructure planned around what the application actually needs: how much traffic, how much downtime is survivable, how much budget exists.
Multi-environment setups with real network segmentation — public load balancers for production, private for staging, stateful services in private subnets. Auto-scaling, availability across zones, and security by design: secrets in a managed store, least-privilege IAM, VPN access to anything private.
I hold the AWS Certified Solutions Architect – Associate certification, which is largely the reasoning behind those trade-offs rather than the button-clicking.
My bias, stated up front: fewer moving parts. Kubernetes is a good answer to a problem most projects don’t have yet.
Migration
Getting systems out of somewhere they have outgrown. Legacy to containers, on-premise to cloud, or one provider to another.
Inventory and dependency mapping first, then a staged cutover with a rollback available at each step. Reference case: 50+ legacy PHP applications moved from shared cPanel hosting onto a containerised VPS, plus 150+ web applications migrated off WHM hosting in my government role.
That project also taught me how much of a migration is inventory work. You cannot containerise what nobody wrote down.
Management
Running it once it exists: monitoring, patching, cost review, capacity planning, and incident response.
Observability belongs here rather than as an upsell — a self-hosted LGTP stack (Loki for logs, Grafana for dashboards, Tempo for traces, Prometheus for metrics) with agents across your servers, or CloudWatch if you would rather stay managed.
Alerts route somewhere a human will see them: Telegram, email, or Slack. A dashboard nobody opens is not monitoring.
Backup & Recovery
Backup schedules, retention rules, and a written recovery procedure with agreed targets for how much data and how much time you can afford to lose.
The part that matters is that the restore gets performed and verified, not merely configured. I have found backup jobs reporting success every night for weeks while producing nothing usable. An untested backup is a rumour.
Automation & Orchestration
Infrastructure that provisions itself and deploys on merge.
Terraform with Atlantis for plan-and-apply on pull requests. Ansible roles with dynamic inventory and Molecule tests. Packer for golden machine images. Bash for the gaps that deserve a script rather than a framework.
CI/CD with gates that mean something: pre-commit hooks, linting, unit tests, vulnerability and infrastructure security scanning, then semantic-versioned builds auto-deployed to dev and staging with manual promotion to production.
On one migration this took deployments from 15 minutes to under 2, roughly 90% faster, by replacing manual steps with push-to-deploy.
Stack
| Area | Tools |
|---|---|
| Cloud | AWS (EC2, VPC, ALB/ASG, RDS, S3, SQS, SES, Secrets Manager, CloudWatch), GCP |
| IaC | Terraform, Atlantis, Packer |
| Config management | Ansible (roles, dynamic inventory, Molecule) |
| Containers | Docker, Docker Compose, Kubernetes, Podman |
| CI/CD | GitLab CI, GitHub Actions, Jenkins, Bitbucket Pipelines, Xcode Cloud |
| Code quality & security | SonarQube, Checkov, pre-commit |
| Observability | Grafana, Prometheus, Loki, Tempo, Grafana Alloy, CloudWatch |
| Data & messaging | PostgreSQL, MariaDB/MySQL, Redis, RabbitMQ, NATS |
| Servers | Linux (Ubuntu/Alpine), Caddy, Nginx, WHM/cPanel, VPS |
Engagement options
Project — a defined piece of work with a fixed scope: a migration, a Terraform build-out, a pipeline.
Consulting — architecture review, cost audit, or a second opinion before you commit to a direction. Usually a few days.
Retainer — ongoing operations, monitoring, and improvement work at an agreed monthly allocation.
Get in touch
Describe your current setup and what’s going wrong with it. Send a message on WhatsApp and I’ll give you a straight assessment, including if the answer is that you don’t need what you think you need.