Ich baue Cloud-Umgebungen, die sich versionieren, nachbauen und automatisiert ausliefern lassen: Terraform statt Klickpfade, Container statt handgepflegter Server, CI/CD statt Deployment am Freitagabend – als Freelancer, remote in der DACH-Region und vor Ort in NRW.
Die meisten Cloud-Umgebungen entstehen nicht am Reißbrett, sondern nebenbei: eine Ressource im Portal geklickt, eine Firewall-Regel von Hand nachgezogen, ein Server, den nur noch eine Person versteht. Das funktioniert, bis etwas ausfällt, jemand kündigt oder eine zweite Umgebung für Tests gebraucht wird. Genau an diesem Punkt setze ich an: Ich überführe gewachsene Infrastruktur in beschriebenen, versionierten Code und mache Deployments zu einem Vorgang, der jederzeit wiederholbar ist.
Als freiberuflicher Senior Software Engineer komme ich aus der Anwendungsentwicklung und nicht aus der reinen Administration. Das ist beim Thema DevOps ein Vorteil: Ich kenne die Anwendung, die betrieben werden soll – ihre Abhängigkeiten, ihre Datenbankmigrationen, ihre Startzeiten, ihre Logs. Pipelines und Cluster entstehen deshalb entlang dessen, was die Software tatsächlich braucht, statt entlang eines generischen Referenzdiagramms.
Welche Plattform es wird, entscheiden Ihre Rahmenbedingungen: vorhandene Lizenzen und Verträge, Anforderungen an Datenstandorte, das Wissen im Team, die Betriebskosten. Ich arbeite in Microsoft Azure, Amazon AWS und Google Cloud und bin für Azure und AWS zertifiziert (Azure Fundamentals, AWS Cloud Practitioner). Ebenso offen bespreche ich, wenn ein Teil der Last auf klassischen Linux-Servern oder im eigenen Rechenzentrum günstiger und einfacher aufgehoben ist.
Vier Bausteine, die einzeln oder gemeinsam greifen – vom ersten Container bis zur Plattform, die mehrere Teams nutzen.
Netzwerke, Cluster, Datenbanken, Speicher und Berechtigungen werden als Terraform-Code beschrieben: mit wiederverwendbaren Modulen, Remote State, getrennten Umgebungen für Entwicklung, Test und Produktion und einem Plan-Schritt im Pull Request, der vor jeder Änderung zeigt, was sie anfasst. Konfigurationen auf den Maschinen selbst übernimmt bei Bedarf Ansible.
Anwendungen werden in schlanke Docker-Images verpackt und über Helm oder Kustomize nach Kubernetes ausgerollt – inklusive Health Checks, Ressourcenlimits, Autoscaling, Secrets-Handling und Ingress. Wo ein Cluster zu viel wäre, gehe ich den kleineren Weg über verwaltete Container-Dienste der jeweiligen Cloud.
Pipelines mit GitHub Actions, GitLab CI oder Azure DevOps: Build, Tests, Sicherheitsprüfungen, Image-Registry, automatisches Deployment in die Testumgebung und ein kontrollierter Schritt in die Produktion. Dazu Datenbankmigrationen, Rollback-Pfade und Deployments ohne Ausfallfenster.
Metriken und Logs mit Prometheus, Grafana und dem ELK-Stack, Alarme, die auf echte Störungen zeigen statt auf Rauschen, und ein Blick auf die Rechnung: richtige Instanzgrößen, Autoscaling, Speicherklassen, abgeschaltete Testumgebungen außerhalb der Arbeitszeit. ITIL 4 Foundation als Hintergrund für Incident- und Change-Abläufe.
Situationen, in denen ich in der Praxis am häufigsten dazukomme.
Eine Anwendung läuft auf eigenen Servern und soll nach Azure oder AWS. Wir klären zuerst, was wirklich migriert wird, was containerisiert wird und was durch einen verwalteten Dienst ersetzt werden kann. Danach entsteht die Zielumgebung als Code, die Anwendung zieht in kleinen Schritten um, und der Rückweg bleibt offen, bis der Betrieb stabil ist.
Die Umgebung existiert bereits, ist aber im Portal zusammengeklickt und nirgends dokumentiert. Ich nehme den Bestand auf, überführe ihn schrittweise nach Terraform und importiere vorhandene Ressourcen, statt alles neu anzulegen. Am Ende ist jede Änderung nachvollziehbar und eine zweite Umgebung eine Frage von Minuten.
Mehrere Anwendungen oder Microservices sollen sich einen Cluster teilen. Dazu gehören getrennte Namespaces, Rechte, Ressourcenkontingente, ein gemeinsamer Ingress, zentrale Logs und ein Standardweg, wie ein neues Team seinen Dienst ausliefert – ohne dass jedes Team eine eigene Pipeline erfindet.
Die Rechnung steigt, ohne dass klar ist, warum. Ich ordne die Kosten nach Projekt und Umgebung zu, suche überdimensionierte Instanzen, vergessene Ressourcen, teure Speicherklassen und unnötigen Datentransfer und baue Automatismen ein, die Testumgebungen nachts und am Wochenende herunterfahren.
Infrastruktur lässt sich nicht in einem großen Schritt umbauen, ohne den laufenden Betrieb zu gefährden. Deshalb dieser Ablauf.
Was läuft heute wo, wer greift darauf zu, welche Abhängigkeiten gibt es und was tut weh? Am Ende steht eine ehrliche Übersicht inklusive der Stellen, an denen ein Ausfall heute teuer wäre.
Wir legen Plattform, Umgebungen, Namenskonventionen und Rechte fest und ich baue eine erste Umgebung vollständig als Code – klein genug, um schnell fertig zu sein, und vollständig genug, um als Vorlage für alle weiteren zu dienen.
Pipelines, Images und Deployments entstehen entlang der Anwendungen, die tatsächlich umziehen. Migriert wird in Schritten mit klarem Rückweg, begleitet von Monitoring, damit Abweichungen auffallen, bevor Nutzer sie melden.
Dokumentierte Architektur, Runbooks für die häufigsten Störfälle, Alarme mit klarer Zuständigkeit und eine Einarbeitung Ihres Teams. Danach kann Ihr Team die Umgebung selbst betreiben – auf Wunsch bleibe ich als Ansprechpartner dabei.
Was konkret zum Einsatz kommt, hängt von Plattform, Teamgröße und dem Betriebsmodell ab, das Sie tragen wollen.
Beschreiben Sie kurz, wo Ihre Umgebung heute Handarbeit verlangt oder unnötig Geld kostet. Ich melde mich mit einer ehrlichen Einschätzung, was sich mit vertretbarem Aufwand ändern lässt.