Artem

Im Tagesgeschäft verantworte ich die Anwendungs- und Plattformarchitektur auf AWS und GCP: alles im Einklang mit Cloud-Best-Practices halten, es aber gleichzeitig in einen einheitlichen internen Standard mit Kubernetes als Kern überführen, damit nicht jeder Service ein Sonderfall ist. Parallel dazu baue ich die Plattform selbst — interne Services in Go, davor APIs mit OAuth2/OIDC — damit interne Teams und Kunden Self-Service-Automatisierung bekommen statt einer Ticket-Warteschlange. Auf diesen APIs sitzen agentische Workflows: Wer kein Terraform schreibt, beschreibt die Anwendung oder Umgebung, die er braucht, und bekommt sie innerhalb der Guardrails provisioniert, ohne auf einen Platform Engineer zu warten.

Ein großer Teil meiner Woche geht in Pipelines und Tooling, die SRE und Support repetitive Arbeit abnehmen: Automatisierung für Aufgaben, die früher von Hand liefen, und interne Bots, die während eines Incidents Logs und Metriken zusammenziehen und korrelieren — die erste brauchbare Erkenntnis kommt damit in Minuten statt nach einer Stunde Klicken durch Dashboards.

Observability verantworte ich end to end — Metriken, Logs, Traces, Alerting, SLIs/SLOs und die SLAs darauf. In der Praxis heißt das Datadog plus einen parallelen Stack aus VictoriaMetrics / VictoriaLogs / VictoriaTraces, denn alles in einem kommerziellen SaaS zu halten wird schnell teuer — und die günstigere Ebene sollte die Frage aus der Rufbereitschaft trotzdem beantworten können.

Security und Compliance ist die andere Hälfte dieser Aufgabe. Ich betreibe PKI und Vault integriert mit Kubernetes, sodass Zertifikate, Secrets und Workload-Identitäten automatisch und kurzlebig ausgegeben werden — Ende-zu-Ende-Verschlüsselung und Zero Trust zwischen Anwendungen und zwischen Anwendungen und ihren Endnutzern, als Teil der Plattform statt als nachträglicher Aufsatz. Außerdem beobachte ich Cloud-Health, Security-Posture und Kosten kontinuierlich: Lambdas und eigene Checks, die die von unseren Zertifizierungen geforderten Controls durchsetzen und ungenutzte Ressourcen aufspüren, bevor sie auf der Rechnung auftauchen. Ein guter Teil dieser Arbeit ist Beratung — den Teams sagen, was ein Auditor tatsächlich sehen will, und die Controls dann gemeinsam mit ihnen umsetzen.

Am nützlichsten bin ich für Kunden im frühen, unsicheren Teil: Oft ist es deutlich günstiger, eine Person zu holen, die beweist, dass eine Idee funktioniert — den PoC bauen, die Sackgassen finden, den echten Aufwand abschätzen — als ein ganzes Team auf Verdacht auf eine Roadmap zu setzen. Ich bin gern diese Person und bleibe danach als Begleiter dabei, während Ihr Team die Umsetzung zu Ende bringt.

Angefangen habe ich in Telekommunikations-Rechenzentren, auf der Seite des Stacks, wo die Dinge physisch sind: eine gemischte Solaris- und Linux-Flotte, SAN-Fabrics und Storage-Arrays, Tape-Backup und die Oracle-Datenbanken auf all dem — darunter ein Data Warehouse im zweistelligen Terabyte-Bereich. Das ist eine gute Schule. Wenn um drei Uhr nachts die Replikation bricht und der DR-Standort auf einem Cluster mit Storage-Replikation hochkommen muss, interessiert niemanden, zu welcher Schicht der Fehler technisch gehört. Dort hatte ich auch genug von Handarbeit und schrieb mein eigenes Configuration-Management-Tool mit eigener DSL — ein paar Jahre bevor Ansible das zu einer schlechten Idee machte. Außerdem habe ich das Unternehmen von seiner kommerziellen Monitoring-Suite auf Open-Source-Zabbix umgestellt und die Automatisierung geschrieben, mit der es über den gesamten Bestand skalierte.

Zweimal habe ich die Infrastrukturseite einer kompletten Migration der Billing-Plattform eines Carriers auf einen neuen Anbieter verantwortet. Beide Male hatte die Aufgabe die gleiche Form: Unix, Storage und die Datenbankschicht für ein System vorbereiten, das noch niemand betrieben hatte, Disaster Recovery über den Cutover hinweg intakt halten und dafür sorgen, dass alles überwacht ist, bevor die erste Rechnung davon abhängt.

Dann änderte sich der Maßstab. Ein paar Jahre lang habe ich Unix- und Load-Balancing-Betrieb über 19 Rechenzentren vereinheitlicht — rund 2.000 physische Server und 5.000 VMs — während eine zentralisierte Billing-Plattform überall identisch landen musste, Oracle, Kafka, Cassandra, Redis und RabbitMQ inklusive. Gelöst haben wir das mit PXE-Boot, Puppet und Foreman, sodass aus „gib mir einen Cassandra-Knoten“ eine Provisionierungsentscheidung statt eines Runbooks wurde; unter die Services, die wirklich nicht ausfallen durften, kam Pacemaker; und wir betrieben einen verteilten GlusterFS-Bestand, der groß genug war, dass Red Hat ihn als Referenz nutzte. Viel meiner Zeit ging darin auf, im Bridge-Call die Person zu sein, die entscheidet, ob wir auf das Netzwerk, die Datenbank, den Hypervisor oder den Kernel schauen.

Danach hat mich interessiert, teure Dinge durch Software zu ersetzen. Wir haben die interne Virtualisierungsplattform von VMware vCloud auf OpenStack migriert und die IT-Control-Plane auf Kubernetes gebracht — und, mein Lieblingsprojekt dieser Zeit, eine Storage-Plattform auf OmniOS/ZFS mit einer Python-REST-API und einem eigenen OpenStack-Cinder-Treiber gebaut. Sie hat sechs kommerzielle Arrays abgelöst und Entwicklern Thin-Clone-Kopien produktionsgroßer Datensätze in Sekunden statt Stunden gegeben.

Die Cloud-Jahre sahen wieder anders aus: Data Lakes auf AWS und GCP für Kunden aus Medizintechnik und Pharma, Python-ETL orchestriert mit Step Functions, alles über Terraform provisioniert, und Security- und Audit-Anforderungen als Design-Input statt als Hektik vor dem Release. Von dort war es ein kurzer Schritt zum Betrieb einer Managed-Database-Plattform über drei Clouds — modulares Terraform, GitOps mit Argo CD und Argo Workflows, Cilium-Networking, SOC 2 und PCI DSS obendrauf — und damit ungefähr dorthin, wo meine heutige Arbeit ansetzt.

• Tiefe über den gesamten Stack: von Linux-Internals, Storage und verteilten Datenbanken bis hinauf zu Kubernetes, Multi-Cloud-Networking und Infrastructure as Code — damit Probleme nicht zwischen Schichten oder zwischen Teams verloren gehen.
• Observability, die tatsächlich genutzt wird: hochverfügbare Plattformen für Metriken, Logging und Tracing (Prometheus, VictoriaMetrics/VictoriaLogs, Grafana, OpenTelemetry, Datadog), mit Alerting und SLOs, die an echten Incidents justiert sind statt an Dashboards, die niemand öffnet.
• Data Lakes & Datenplattformen: Data Lakes auf AWS und GCP für regulierte Unternehmen entworfen und gebaut — Ingestion- und ETL-Pipelines, Streaming mit Kafka sowie die Governance und Zugriffskontrollen, die bei Pharma- und Medizintechnikdaten dazugehören.
• Identitäten, Zugriff & Secrets: OIDC/OAuth2-Single-Sign-on für Menschen und Workloads, kurzlebige Credentials statt statischer Keys (Vault, SPIRE, Workload Identity Federation), Least-Privilege-IAM und Netzsegmentierung — meist der Teil, der entscheidet, ob ein Audit glatt läuft.
• Ich schreibe weiterhin selbst Code: Go und Python für Automatisierung, interne Services und APIs, eigene Treiber und Operatoren sowie MCP-Server, über die KI-Assistenten echte Infrastruktur abfragen können — Architektur, die von funktionierender Software gedeckt ist, nicht nur von Diagrammen.
• Im Maßstab bewährt: Tausende physische Server und virtuelle Maschinen über 19 Rechenzentren, dazu produktive Multi-Cloud-Datenbankplattformen, die Kunden bei drei Providern bedienen.
• Führung mit Hands-on-Anteil: Engineering-Teams von bis zu 22 Personen über mehrere Länder geführt und dabei weiterhin Incident Response als letzte Eskalationsstufe übernommen — und gewohnt, Stakeholder-Anforderungen in Architektur, Aufwands- und Kostenschätzungen sowie auditfähige Dokumentation zu übersetzen.

• ✓AWS Certified Solutions Architect – Professional
• ✓Google Cloud Architect – Professional
• ✓Red Hat Certified Engineer (RHCE)