Cloud and DevOps
Cloud architecture and infrastructure as code
I design reproducible cloud platforms, fully described as code and sized to actual need. You gain control over costs as well as the ability to recover from incidents.
What it covers
The cloud does not remove complexity; it moves it into network design, identities and access policies. A successful platform is one a new team can understand in a day, deploy in an hour and restore after a failure without improvising.
We start with an inventory of existing environments, accounts and network flows, then define a target organisation by subscription or project account, with explicit roles and a clear separation between environments. Everything is described in Terraform, reviewed in pull requests and applied automatically.
Cost, resilience and sovereignty
Resource sizing is documented, non-production environments are shut down automatically when idle, and costs are tracked by tag. Resilience requirements are translated into continuity objectives, with scheduled restore tests rather than assumptions.
- Organisation of accounts, subscriptions and roles.
- Network, segmentation and secured entry points.
- Environments described in Terraform and applied by pipeline.
- Centralised secret management and planned rotation.
- Cost tracking by tag and by service.
Problems addressed
Environments have drifted apart and nobody knows why. The cloud bill grows faster than actual usage. Infrastructure changes are made manually, with no trace. No restore test has been run since go-live. Data residency requirements cannot be verified.
Expected benefits
Identical environments that can be recreated if lost. Genuine control of infrastructure costs, line by line. A clear separation between production and working environments. Recovery procedures tested, not merely written. Easier onboarding for new teams thanks to documentation. A viable path between providers without a full rewrite.
Method and steps
- 1
Inventory
Catalogue of resources, access, network flows and current costs, identifying weak points and undocumented dependencies.
- 2
Target design
Account and subscription organisation, network segmentation, authentication strategy and naming rules validated with operations and security teams.
- 3
Implementation
Writing Terraform modules, setting up apply pipelines and progressively migrating existing environments onto the code-defined foundation.
- 4
Operations and measurement
Cost tracking by tag, restore tests, alert review and handover of procedures to the teams running the platform.
Deliverables
Documented inventory of existing resources and flows.
Versioned Terraform modules with usage documentation.
Infrastructure apply pipelines with mandatory review.
Naming, tagging and secret management policy.
Cost dashboard by service and environment.
Tested recovery procedure and restore test report.
Technologies used
- Kubernetes
- Helm
- Terraform
- OpenTelemetry
- AWS
- Microsoft Azure
- Google Cloud
- OpenShift
Frequently asked questions
Do we have to pick a single provider?
Not necessarily. A platform described as code and built on standard services stays portable. The choice should follow your constraints on skills, costs and data residency.
Do you work on existing infrastructure?
Yes. The most common approach is to import existing resources into Terraform, then progressively close the gaps with the target, without service interruption.
How do you act on costs?
Measurement first: cost by service, environment and tag. We then identify abnormal items, shut down unused environments and adjust resource sizing.
Related case studies
Multi-environment Kubernetes platform for a software vendor
A shared foundation for twelve applications and eighty customer instances
Demonstration sample - not a real client reference.
Request a cloud inventory
We can start with a two-week inventory that quantifies current costs and technical risks before any decision.