devops24x7

Cloud-Architektur / Infrastructure as Code

Cloud-Infrastruktur als Code, die selbstständig läuft.

Aleksey DmitrievFreiberufler · München · über 20 Jahre

Freiberuflicher Softwareentwickler und IT-Berater · Infrastructure as Code, Cloud-Architektur, CI/CD

Ich entwickle Infrastruktur, die rund um die Uhr selbstständig läuft.

Kontakt LinkedIn ↗
Aleksey Dmitriev

Leistungen

Infrastructure as Code & Cloud-Architektur

Ich plane und implementiere Cloud-Infrastruktur als Code mit Terraform, Kubernetes und Helm auf AWS und GCP. Dazu gehören Migrationen zwischen Clouds und Plattformen, CI/CD-Pipelines und Observability, die von Anfang an Teil des Plattform-Designs ist.

Softwareentwicklung

Ich entwickle Backend-Anwendungen, Schnittstellen zwischen Systemen und Automatisierungswerkzeuge in Python und Go. Ergebnis ist getesteter Code in Ihrem Repository, mit einer Dokumentation, mit der Ihre Entwickler ihn erweitern können.

Technische Beratung & Architektur-Review

Ich analysiere bestehende Architektur und Infrastruktur-Code, zeige Risiken und Engpässe auf und erstelle einen Modernisierungsplan. Während Ihr Team den Plan umsetzt, berate ich es.

Einführung einer Technologie in Ihrem Team: Workshop, How-to-Dokumentation und Pilot in Ihrer Umgebung (Kubernetes, Istio, Argo CD, Terraform).

Arbeitsweise

Vom ersten Gespräch bis zur dokumentierten Übergabe.

  1. 01

    Kennenlernen

    Wir besprechen Ziele, Kontext und Rahmenbedingungen.

  2. 02

    Einschätzung

    Wir vereinbaren Umfang, Prioritäten und Ergebnisse.

  3. 03

    Umsetzung

    Ich entwerfe, programmiere und prüfe die vereinbarte Lösung.

  4. 04

    Übergabe

    Code und Dokumentation gehen an Ihr Team.

Konditionen

  • Aufgaben und Prioritäten werden im Projektverlauf mit Ihnen abgestimmt; wie und wann ich die Arbeit erledige, entscheide ich selbst.
  • Remote aus München (MEZ); Termine vor Ort nach Vereinbarung.
  • Abrechnung nach Stunden oder pro vereinbartem Meilenstein.
  • Eine Rechnung pro Monat mit Aufschlüsselung nach Aufgaben.
  • Vertrag nach deutschem Recht.
  • Keine deutsche Umsatzsteuer für Geschäftskunden außerhalb Deutschlands (innerhalb der EU: Reverse-Charge-Verfahren).

Arbeitsbeispiele

Ausgewählte Arbeiten aus den Jahren 2019 bis 2026, anonymisiert: keine Kundennamen, keine Branchen, keine absoluten Zahlen des Kunden.

Arbeitsbeispiel 1

Kubernetes auf AWS: halb so viele Nodes, Neustarts nur im vereinbarten Zeitfenster

Ausgangslage

Mehrere EKS-Cluster in mehreren AWS-Konten waren organisch gewachsen: feste Node-Gruppen für die Spitzenlast, überall On-Demand-Instanzen, Batch-Jobs und langlaufende Dienste auf denselben Nodes. Ein Cluster forderte rund 60 % seiner CPU an und nutzte rund 10 %. Jede automatische Konsolidierung der Nodes startete Dienste zu beliebigen Zeiten neu.

Vorgehen

Umstellung der Cluster auf Karpenter mit Konsolidierung unterausgelasteter Nodes, eigene Node-Pools für Batch-Jobs mit Schutz vor Verdrängung per Policy, Spot-Pools, denen Dienstverantwortliche per Toleration beitreten. Der erste Konsolidierungslauf erzeugte eine Schleife aus Node-Neuerstellungen; nach der Ursachenanalyse wurden Konsolidierung und Node-Rotation auf ein vereinbartes Zeitfenster pro Tag begrenzt, mit Alarmregeln auf das Node-Alter. Jede Änderung über Terraform/Terragrunt und geprüfte Merge Requests, Cluster für Cluster ausgerollt und nach jedem Schritt verifiziert.

Ergebnis

Mehr als die Hälfte weniger Nodes, Node-Kosten entsprechend gesenkt. Dienste starten nur noch im Zeitfenster neu; Vorfälle durch Konsolidierung sind verschwunden.

Arbeitsbeispiel 2

CI auf selbst gehostetem GitLab: von handkonfigurierten Bare-Metal-Runnern zu autoskalierenden Flotten

Ausgangslage

Native Builds liefen auf einer Handvoll von Hand konfigurierter Bare-Metal-Runner. Derselbe Build dauerte je nach Auslastung der Hosts 7 Minuten bis über eine Stunde, die ARM-Warteschlange hungerte, Platten füllten sich mit alten Images, der Artefaktspeicher lief zweimal über und ließ Jobs scheitern. Rund 40 % der Hintergrundjobs des GitLab-Servers gingen an tote Webhooks.

Vorgehen

Entwurf autoskalierender Runner-Flotten auf AWS (x86 und ARM, Spot), als Code beschrieben und per GitOps ausgerollt. Eine Testwoche mit echten Jobs, dann Migration des schwersten Projekts, danach Abschaltung der statischen Runner und Neuinstallation ihrer Hosts für einen Rechencluster. Tote Webhooks entfernt, Aufbewahrungsfristen für die CI-Historie und Limits für den Build-Cache eingeführt, eine Upgrade-Prozedur für den Server mit Prüfung der Hintergrundmigrationen geschrieben und an das Team übergeben.

Ergebnis

Keine statischen Runner mehr. 58 % weniger gespeicherte Pipelines, Latenz der Hintergrundjobs von Minuten auf Sekunden. Ein geplantes Server-Upgrade passt in ein Zeitfenster von rund einer halben Stunde.

Arbeitsbeispiel 3

Bare-Metal-Cluster für datenintensive Berechnungen, verwaltet als Code

Ausgangslage

Ein Datenteam brauchte Rechenleistung mit schnellen lokalen Platten und großen Datenmengen, die in der Cloud unverhältnismäßig teuer war. Gefordert war ein Cluster auf gemieteten Servern mit der Disziplin der Cloud: reproduzierbare Installation, verschlüsselte Daten, gemeinsamer Speicherzugriff ohne Schlüssel auf den Hosts.

Vorgehen

Start mit einem Pilot aus drei Nodes, Ausbau auf mehr als fünfzehn: Installation und Bootstrap mit Ansible, RAID0 für Arbeitsdaten, LUKS auf der Datenpartition, ein gemeinsamer Objektspeicher-Bucket, auf allen Nodes schreibgeschützt eingebunden über eine Netzwerkrichtlinie statt über Schlüssel auf den Hosts. Prozedur für Aufnahme, Entfernung und Neuinstallation von Nodes sowie eine Anleitung für die Nutzer des Clusters geschrieben.

Ergebnis

Eine Charge von zehn Nodes war innerhalb weniger Tage nach der Prozedur einsatzbereit, nicht nach dem Gedächtnis einer einzelnen Person. Direktes Lesen aus dem Bucket ist rund siebenmal schneller als der bisherige Weg.

Arbeitsbeispiel 4

Mehr als zehn EKS-Cluster um drei Hauptversionen angehoben

Die Cluster lagen mehrere Kubernetes-Versionen zurück und zahlten den Aufschlag für veraltete Versionen. Alle Cluster durch die Versionskette zusammen mit dem CNI angehoben, auf einem Testcluster geprobt, Zeitfenster vor der Spitzenlast gelegt und die Prozedur als Playbook für das Team dokumentiert. Aufschlag entfallen; keine Vorfälle auf den Hauptclustern.

Arbeitsbeispiel 5

AWS-Plattform: von Bastion-Hosts und statischen Schlüsseln zu OIDC und Managed Services

Ein Unternehmen mit mehreren Webprodukten auf ECS und ohne Infrastrukturdokumentation. EKS-Umgebung von Grund auf als Code entworfen (Argo CD, IRSA, CSI-Treiber für Secrets und EFS, Logs in OpenSearch, ExternalDNS), Bastion durch ECS Exec ersetzt, Datenbank auf Aurora Serverless migriert, Repositories auf GitHub Actions mit OIDC statt statischer Schlüssel umgestellt, mehrere Site-to-Site-VPNs mit BGP aufgebaut und den Message-Broker ohne Vorfälle vom externen Hosting nach AWS verlegt.

Arbeitsbeispiel 6

Ein Deploy-Flow für acht Repositories

Die Deploy-Pipelines von acht Diensten öffneten Merge Requests im GitOps-Repository auf unterschiedliche Weise und blieben bei parallelen Deploys hängen. Umstellung auf eine gemeinsame CI-Komponente mit Rebase-and-Retry, Prüfung mit vier gleichzeitigen Deploys, mehr als hundert hängende Merge Requests geschlossen. Deploys kommen ohne manuelles Eingreifen aus.

Arbeitsbeispiel 7

Cloud-Plattform-Team für ein B2B-Produkt

Leitung eines siebenköpfigen Plattform-Teams beim Aufbau der Kubernetes-Plattform. Migration der Produktionscluster von Docker auf containerd, Spot-Flotte für Entwicklungsumgebungen zu rund einem Drittel des On-Demand-Preises pro Node, dedizierte Node-Gruppen für kritische Anwendungen, teamübergreifende Regeln für Requests/Limits und Kapazität, automatische Zertifikatserneuerung mit cert-manager, der erste Kubernetes-Operator des Unternehmens in Go, Managed Kafka mit eigenen Dashboards, GitOps mit Argo CD und Infrastructure as Code mit Terraform.

Softwareprojekte

Eigene Projekte, die zeigen, wie ich Software baue, nicht nur Infrastruktur.

Analyseplattform: von über 40 Rohquellen zur Entscheidung

Eine durchgehende Pipeline, die Daten aus mehr als vierzig heterogenen Quellen aufnimmt, normalisiert und als Zeitreihen speichert, sie mit einer Regel-Engine und LLM-Analyse mit strukturierter Ausgabe bewertet und das Ergebnis dorthin liefert, wo Menschen handeln: Dashboards in einer Webanwendung, geplante Zusammenfassungen und ereignisgesteuerte Benachrichtigungen in Telegram, weitere Kanäle anschließbar. Engineering: Sammler mit Konsistenzprüfungen und Wiederanlauf nach Fehlern, Schemaänderungen nur über Migrationen, Architecture Decision Records, End-to-End- und Unit-Tests, Deployments mit Rollback. Python, PostgreSQL, TypeScript.

Pipeline für Spracherkennung und Zusammenfassung auf eigener GPU-Hardware

Beobachtet Video- und Audiokanäle, nutzt vorhandene Untertitel und transkribiert sonst auf einer GPU mit Sprachaktivitätserkennung und Unterdrückung halluzinierter Texte, fasst anschließend mit einem selbst gehosteten LLM zusammen und stellt die Ergebnisse in einer Webanwendung hinter OAuth bereit. Datenschutz als Grundeinstellung: nichts verlässt den Perimeter des Eigentümers, keine externen APIs. Die Erkennungsqualität ist je Sprache und Audiobedingung abgestimmt und dokumentiert. Python.

Secrets-Werkzeug für macOS mit hardwaregestützter Entsperrung

Ein Kommandozeilenwerkzeug in Swift, das das Master-Geheimnis des Passwortmanagers im Data Protection Keychain hält, es per Touch ID entsperrt und einen Post-Quanten-age-Schlüssel an SOPS zum Verschlüsseln von Repository-Secrets übergibt. Kein Netzwerkzugriff, keine Telemetrie, ein dokumentiertes Bedrohungsmodell.

Benchmark-Rahmen für LLM-Coding-Agenten

Dieselbe Aufgabe geht an mehrere Agenten; der Rahmen misst Tokens, Laufzeit und Kontingentverbrauch, ein separater Prüf-Agent bewertet die Ergebnisse nach einem Raster und schreibt den Bericht. Werkzeugentscheidungen fallen danach anhand von Zahlen statt Eindrücken.

Über mich

Planung und Entwicklung von Individualsoftware und Infrastruktur-Code, Cloud-Architektur und die damit verbundene fachliche Beratung für Unternehmen in Deutschland, Österreich, der Schweiz, den Niederlanden, Großbritannien und den USA. Sitz in München, Arbeit remote. Keine Lieferung von Hardware oder Lizenzen, kein laufender Betrieb.

Seit 2016 in Deutschland, seit 2019 in München, freiberuflich tätig. Hochschulabschluss in Rechenmaschinen, Komplexe, Systeme und Netze (GUAP St. Petersburg, 2002); mehr als 20 Jahre in Infrastruktur und Softwareentwicklung auf der Grundlage von Linux, Netzwerktechnik und Systemprogrammierung. Programmiersprachen: Python, Go, Swift, TypeScript. Sprachen: Deutsch, Englisch, Russisch.

  • Kubernetes
  • Terraform
  • Terragrunt
  • Helm
  • Argo CD
  • GitOps
  • AWS
  • GCP
  • Bare metal
  • Linux
  • Karpenter
  • Istio
  • Kafka
  • PostgreSQL
  • GitLab CI
  • GitHub Actions
  • Prometheus
  • Grafana
  • Python
  • Go
  • LLM integration

Kontakt