Cloud, DevOps & IaC
Infrastructure ends up described as code and deployment automated, so shipping to production is routine and anyone on the team can do it.
The signal is easy to spot: nobody dares deploy on a Friday, staging looks nothing like production, and there are steps only one person knows how to do.
The goal is not the most modern infrastructure, but that anyone on the team can deploy, roll back and understand what is running.
Where the work goes
Infrastructure in the repository
Everything that exists in the cloud is described in code and reviewed like any other change. That removes the fear of touching it: you see the diff before applying it and you can recreate the environment from scratch.
The pipeline as a safety net
The checks somebody does by hand today end up in the pipeline: tests, linters, migrations, dependency scanning. If it passes, it deploys itself; if not, it does not reach production.
Being able to go back
A deploy with no way back is a bet. Hence immutable versions, migrations compatible with the previous release, and a rollback path that has been tested rather than assumed.
How it fits together
From a commit to production
Every stage has a condition for letting the next one through. If it is not met, the change stays where it is.
- 01
Commit
Lint and unit tests in under five minutes, otherwise nobody waits for them.
- 02
Image
Reproducible build, vulnerability scan and a tag with the commit sha.
- 03
Staging
Migrations first, then smoke tests against data that resembles the real thing.
- 04
Approval
A human looks at what changes and what can be undone. Only where it is needed.
- 05
Production
Progressive rollout: 10% of traffic first, with the metrics right next to it.
If the canary makes latency or errors worse, one command goes back to the previous version. Rehearsed, not improvised.
What lives inside the account
All of this is described in code. Anything clicked by hand in the console is lost on the next apply.
Cloud account or project
Network
VPC · Private subnets · Controlled egress
Cluster
Namespace per environment · CPU and memory limits · Autoscaling
Data
Managed PostgreSQL · Read replica · Backups with a tested restore
Terraform state
Workspace per environment · Remote locking · Plan on every pull request
What it includes
- Infrastructure as code with Terraform or Pulumi, reviewable in a pull request.
- CI/CD pipelines (GitHub Actions, Jenkins, Bitbucket) that build, test and deploy with no manual steps.
- Containers and orchestration on Kubernetes, with resource limits, health checks and autoscaling.
- Separate environments created from the same definition, so staging actually resembles production.
- Zero-downtime deploys, fast rollback and backward-compatible database migrations.
- Secret and per-environment variable management, kept out of the repository.
- Metrics, logs and alerts that point at something actionable instead of paging about everything.
- Cost control: what is being paid for and what can be switched off.
How the project runs
- 01It starts by reproducing the current environment as code, without changing how anything behaves.
- 02One service gets its deployment automated, and that becomes the template for every other one.
- 03The checks somebody runs by hand today move into the pipeline.
- 04Operations end up in your team hands: infrastructure only its author understands is a liability, not a service.
What you get
- The infrastructure repository and working pipelines.
- Environments reproducible from scratch.
- Metric dashboards and alerts with an owner.
- An operations and recovery document.
Usual stack
- IaC
- TerraformPulumiHelm
- Containers
- DockerKubernetesCompose
- CI/CD
- GitHub ActionsJenkinsBitbucket Pipelines
- Cloud
- AWSGoogle CloudCoolifyCloudflare
- Observability
- PrometheusGrafanaSentryUptime Kuma
Where this has been done
Frequently asked questions
Is this possible without an infrastructure team?
Yes, and that is part of the goal: deploying and rolling back should not depend on a specialist. Infrastructure ends up described as code and reviewable in a pull request, and operations are handed to the product team with documentation.
What about what is already set up by hand?
It gets reproduced as code exactly as it is, without changing behaviour, and only then does anything change. Starting with a redesign is the fastest way to break something that worked and not know why.
AWS or Google Cloud?
Whichever is already being paid for, unless there is a concrete reason to move. Both cover the same ground for most products, and a cloud migration eats the budget the product needed.
Always Kubernetes?
No. Kubernetes pays off with several services, several environments and a need to scale parts independently. For a product with two services, a simpler platform costs less to run and ships just as fast.