I build cloud environments you can version, rebuild and ship automatically: Terraform instead of clicking through portals, containers instead of hand-tended servers, CI/CD instead of Friday evening deployments – as a freelancer, remote across Europe and on-site in North Rhine-Westphalia.
Most cloud environments are not designed on a drawing board, they grow on the side: a resource clicked together in the portal, a firewall rule added by hand, a server only one person still understands. That works until something fails, until someone leaves, or until a second environment is needed for testing. This is exactly where I start: I turn grown infrastructure into described, versioned code and make deployments a process that can be repeated at any time.
As a freelance senior software engineer I come from application development, not from pure administration. For DevOps work that is an advantage: I know the application that has to run – its dependencies, its database migrations, its startup times, its logs. Pipelines and clusters therefore follow what the software actually needs, rather than a generic reference diagram.
Which platform it becomes depends on your constraints: existing licences and contracts, requirements on data location, the knowledge in your team, the cost of operations. I work with Microsoft Azure, Amazon AWS and Google Cloud and hold certifications for Azure and AWS (Azure Fundamentals, AWS Cloud Practitioner). I will say just as openly when part of the load is cheaper and simpler on classic Linux servers or in your own data centre.
Four building blocks that work on their own or together – from the first container to a platform several teams share.
Networks, clusters, databases, storage and permissions are described as Terraform code: with reusable modules, remote state, separate environments for development, test and production, and a plan step in the pull request that shows what a change touches before it happens. Configuration on the machines themselves is handled by Ansible where needed.
Applications are packaged into lean Docker images and rolled out to Kubernetes through Helm or Kustomize – including health checks, resource limits, autoscaling, secrets handling and ingress. Where a cluster would be too much, I take the smaller route through the managed container services of the respective cloud.
Pipelines with GitHub Actions, GitLab CI or Azure DevOps: build, tests, security checks, image registry, automatic deployment to the test environment and one controlled step into production. Plus database migrations, rollback paths and deployments without a maintenance window.
Metrics and logs with Prometheus, Grafana and the ELK stack, alerts that point at real incidents instead of noise, and an eye on the bill: right-sized instances, autoscaling, storage classes, test environments switched off outside working hours. ITIL 4 Foundation as the background for incident and change processes.
The situations I am most often brought in for.
An application runs on your own servers and should move to Azure or AWS. We first clarify what really migrates, what gets containerised and what can be replaced by a managed service. The target environment is then built as code, the application moves in small steps, and the way back stays open until operations are stable.
The environment already exists but was clicked together in the portal and documented nowhere. I take stock, move it to Terraform step by step and import existing resources instead of recreating everything. In the end every change is traceable and a second environment is a matter of minutes.
Several applications or microservices should share one cluster. That means separate namespaces, permissions, resource quotas, a shared ingress, central logs and one standard way for a new team to ship its service – without every team inventing its own pipeline.
The bill keeps growing and nobody can say why. I attribute costs per project and environment, look for oversized instances, forgotten resources, expensive storage classes and unnecessary data transfer, and add automation that shuts test environments down at night and on weekends.
Infrastructure cannot be rebuilt in one large step without putting daily operations at risk. Hence this sequence.
What runs where today, who accesses it, which dependencies exist and what hurts? The result is an honest overview, including the places where an outage would be expensive right now.
We agree on platform, environments, naming conventions and permissions, and I build one first environment entirely as code – small enough to finish quickly, complete enough to serve as the template for all the others.
Pipelines, images and deployments follow the applications that actually move. Migration happens in steps with a clear way back, accompanied by monitoring so deviations show up before users report them.
Documented architecture, runbooks for the most common incidents, alerts with clear ownership and onboarding for your team. After that your team can run the environment itself – and I stay available as a contact if you want that.
What is used depends on the platform, the size of your team and the operating model you want to carry.
Describe briefly where your environment still demands manual work today or costs more than it should. I will come back with an honest assessment of what can be changed with reasonable effort.