Aus dem Dunkel in die Cloud: Wie durchblicker.at seine Infrastruktur auf Google Cloud Run erneuerte

Kontext: Ein Migrationsbericht aus erster Hand

In der Session „Out of the Dark, Into the Light“ schildert Michael Karner (Speaker: Michael Karner, Company: durchblicker.at) die Reise von durchblicker.at – von einer historisch gewachsenen Multi-Cloud- und VM-Landschaft hin zu überwiegend Cloud-Run-basierten Services auf der Google Cloud Platform (GCP). Wir bei DevJobs.at haben zugehört und die technischen Eckpunkte, Entscheidungswege und Lessons Learned dieser Migration für Engineering-Teams zusammengefasst.

durchblicker.at ist Österreichs unabhängige, marktführende Online-Vergleichsplattform. Gegründet 2010, wuchs das Unternehmen auf über 80 Mitarbeiter:innen und bietet 28 Preisvergleiche. 2023/2024 erfolgte der Verkauf an die NetRisk-Gruppe, die führende Vergleichsportale in CEE betreibt. Karner selbst ist seit Ende der 1990er Softwareentwickler, seit 2019 bei durchblicker.at und inzwischen stark auf Infrastruktur, Operations und On-Call fokussiert.

Sein Ziel in diesem Talk: eine rückblickende, nüchterne Aufarbeitung – ohne Schuldzuweisungen – darüber, warum und wie ein VM-lastiges, verteiltes Setup in GCP modernisiert wurde. Der Weg führte vom „Graveyard“ historischer Artefakte zu einer Cloud-Architektur, in der Cloud Run eine zentrale Rolle spielt.

Ausgangslage: Ein Jahrzehnt Tech-Wandel trifft auf gewachsene Systeme

Die Frühphase (ab 2010) spiegelt typische Muster wider: Bare-Metal-Server, virtuelle Maschinen, jQuery – und viele Experimente im Startup-Modus. Parallel veränderte sich das Ökosystem:

• 2005: Erste Git-Version
• 2013: Docker
• 2014: Kubernetes
• Mitte der 2010er: AWS Lambda, Google Cloud Functions
• 2019: AWS Fargate, Google Cloud Run
• 2021: Google Kubernetes Autopilot

2020 zeigte sich der Preis der Historie: „Auch wir haben einen Friedhof von Ideen – in Code und Infrastruktur.“ Konkret (Stand Anfang 2021):

• Rund 120 Git-Repositories auf selbstgehostetem GitLab, davon etwa 40 ungenutzt
• Etwa 60 virtuelle Maschinen und Bare-Metal-Server, verteilt über Google Compute Engine, DigitalOcean und Hetzner
• DNS bei AWS; einige S3-Buckets mit mehreren Terabytes
• MySQL teils in GCP, teils lokal auf VMs
• Ca. 20 Core-Microservices
• Releases bereiteten manchen Entwickler:innen Angst

Die grafische Commit-Historie (2010–2021) erzählte denselben Befund: viel Historie, viel Fragmentierung, wenig Vertrauen in die Gesamtsicht.

Schmerzpunkte: Wenn DIY, Lärm und manuelle Eingriffe bremsen

Karner benennt zentrale Pain Points – eine Liste, die „nicht vollständig“ ist, aber erschreckend vertraut klingt:

• Zu viel Selbstbau statt konsequenter Nutzung von Platform-/Software-as-a-Service
• Unzureichendes Secret-Management
• Nicht-optimale Build-Prozesse auf Jenkins
• Logging und Alerting „nicht gut“; Graylog, Elastic, Grafana wurden von durchblicker.at selbst betrieben
• Viel Rauschen durch zahlreiche „Non-Errors“ – echte Fehler gingen unter
• Ständiger personeller Aufwand für Security-Patches und OS-Updates
• Langsame Bereitstellung neuer Testsysteme
• Vertrauensverlust in das Ansible-Repo als „Single Source of Truth“; manuelle Änderungen direkt auf VMs wurden nicht zuverlässig ins Repo zurückgeführt
• Zertifikatsmanagement suboptimal
• Multi-Cloud-Probleme durch Netzwerk-Traffic
• „Keine gelebte DevOps-Kultur“ und Sicherheitsprobleme

Kurz: Die Organisation trug die Last von Technikschulden, Tool-Fragmentierung, manuellem Betrieb und inkonsistenter Automatisierung.

Leitplanken für die Erneuerung

Vor diesem Hintergrund wurden Grundannahmen definiert – konservativ, pragmatisch, migrationsfreundlich:

• Vollständige Migration aller Kernservices in eine Cloud
• Entscheidungen nach Best Practices – mit externer Unterstützung durch Consultants
• Containerisierung aller Services
• Kein Big Bang: Migration Service für Service
• Konservativer Ansatz: Services „as is“ migrieren, um neue Bugs leichter von alten zu unterscheiden
• Zentrales Secret-Management ist Pflicht
• Infrastructure as Code ist Pflicht; keine „Mausklicks im GUI“
• Drei Umgebungen: Development, Staging, Production
• „Wirklich gutes“ Logging und Error Reporting
• Jenkins durch GitLab ersetzen

Diese Leitplanken gaben die Richtung vor: weg von manuellen, verteilten Setups – hin zu einer wiederholbaren, deklarativen, observablen Delivery-Pipeline auf einer Plattform.

Entscheidungsfindung: POC in AWS und GCP, dann „Bauchgefühl“

Das Team startete zweigleisig: Proof-of-Concept-Migration eines Services sowohl in AWS (mit externem Consultant) als auch in GCP (mit Unterstützung von Google). Ergebnis:

• AWS CDK passte „nicht optimal“ – Terraform war die bevorzugte Wahl
• Keinen klaren Cloud-Gewinner zu diesem Zeitpunkt

Im Juni 2021 fiel die Entscheidung dennoch „mehr oder weniger aus dem Bauch heraus“ für GCP. Begründungen:

• Imperatives vs. deklaratives Infrastruktur-Definitionsthema (die Richtung zeigte auf das deklarative Arbeiten mit Terraform)
• GCP hatte bei durchblicker.at bereits verlässlich funktioniert (Load Balancer, Datenbanken liefen dort stabil)
• Falls Kubernetes nötig würde, sah man GCP im Vorteil

Kurz darauf kam der Implementierungsturbo: durchblicker.at fand mit Haptic (Wien) einen passenden Implementierungspartner. Im Juli 2021 erfolgte ein gemeinsamer Kickoff-Workshop mit Haptic und Google – der Startschuss.

Planung vs. Realität: Die unterschätzte Roadmap

Die ursprüngliche Roadmap unterschätzte den Aufwand deutlich. Der Plan: etwa ein Monat Lernphase, dann ein bis zwei Services pro Woche nach Cloud Run migrieren – „fertig bis Oktober 2021“. Die Realität: Es wurde komplexer. Diese Diskrepanz ist ein wiederkehrendes Muster bei tiefgreifenden Migrationsprogrammen – besonders, wenn man konservativ migriert, die Service-Landschaft heterogen ist und Altlasten konsequent abgebaut werden müssen.

Der erste Pilot: „tariffs“ als Hochlast-Kandidaten

Der erste migrierte Service war „tariffs“, die Tarife-Berechnungsengine. Gründe für die Wahl:

• Rund 11 Jahre alt – also historisch gewachsen, aber technisch überschaubar
• Wenige Abhängigkeiten
• Viel Traffic – Fehler würden schnell auffallen

Im August 2021 waren Containerisierung und Terraform-Infrastruktur fertig, der Cloud-Run-Service lief „ein paar Stunden“ stabil. Dann der erste große Stolperstein:

• Fast alle Services sind an RabbitMQ angebunden, um asynchrone Jobs zu verarbeiten.
• Cloud Run drosselt standardmäßig die CPU („CPU throttling“), sobald ein Request beendet ist. Wird aber gleichzeitig aus RabbitMQ konsumiert, bleiben diese Jobs liegen – bei gedrosselter CPU läuft kein Worker weiter.

Dieser Konflikt traf durchblicker.at ins Mark: asynchrone Verarbeitung war essenziell. Zwei Optionen lagen auf dem Tisch:

• RabbitMQ durch Pub/Sub ersetzen und per HTTP pushen – hätte aber ein Umschreiben sämtlicher Services erfordert
• Statt Cloud Run auf GKE setzen und bei RabbitMQ bleiben

Man probierte GKE Autopilot. In Lasttests zeigte sich jedoch: Scale-up war „ziemlich zu langsam“. Gleichzeitig wollte das Team keinen Kubernetes-Cluster „von Hand“ betreiben – Managed Services hatten Priorität.

Dann der Glücksfall: Im September 2021 kündigte Google „CPU always on“ für Cloud Run an. Ein Flag, mit dem die CPU auch ohne eingehende Requests aktiv bleibt – genau das fehlende Puzzleteil für RabbitMQ-Consumer. Durchblicker.at migrierte drei Services von Autopilot zurück auf Cloud Run; ein Service lief bereits auf Cloud Run. Die Migration gewann spürbar an Tempo.

Ende 2021: Fundamente, Observability und Tempo

Bis Jahresende 2021 stand ein erstaunliches Fundament – sauber per Terraform orchestriert:

• Organisation und Projekte für die Umgebungen in GCP
• IAM, Org-Policies
• Billing Alerts
• Alerting und Atlassian Opsgenie
• Migration von über der Hälfte der Produktionsservices
• Migration einiger MySQL-Datenbanken
• Einführung einiger Cloud Functions
• Nutzung von Cloud Storage und Cloud Scheduler
• Nutzung des Secret Managers
• Einsatz von Cloud Armor zur Zugriffsbeschränkung
• Cloud Debug und Cloud Profiler

Bemerkenswert: „Wir hatten noch Spaß am Projekt.“ Ein gutes Zeichen in einer Phase, die bei Migrationsprogrammen oft zermürbend ist.

2022: Das Frontend-Monster zähmen

Im Januar 2022 startete die große Frontend-Migration. Die Ausgangslage:

• 11 Git-Repositories
• „Old style“ Legacy-Website
• Neue Next.js/React-basierte Website
• Konfigurationsdaten
• Ein Service für Publikation/Entfernung von PDF-Dokumenten zum Download
• Über 100.000 JSONs und Binärdateien
• Builds und Deployments liefen auf Jenkins, das Repos zusammenklebte, Artefakte baute und per rsync auf vier Server schob

Oder, wie ein Kollege sagte: „Es ist ein Monster.“

Die Migration verlangte viel Arbeit. „Es hat ein halbes Jahr gedauert.“ Seit dem 1. Juni 2022 läuft die Website in Produktion – „und wir sind noch am Leben.“

Status „heute“: Managed, konsistent, Cloud Run-zentriert

Der Blick „auf den Screenshot von morgen“ fällt optimistisch aus: Alle Services werden von Google gemanagt und laufen in Cloud Run. „Alles funktioniert gut.“ Viele Ziele sind erreicht – auch wenn „noch viel zu tun bleibt“.

Fazit des Teams: Pros und Cons nach der Reise

Klartext zu den Erfahrungen mit GCP und der neuen Plattform:

Cons:

• „Der Google Support ist abenteuerlich.“
• „AWS scheint modernere Features zu haben“ – GCP hinke „ein wenig hinterher“.
• „Einige Einschränkungen in GCP sind nicht nachvollziehbar.“
• „Die Google-Cloud-Console-App auf Smartphones ist komisch“ – „kaum zu glauben, dass sie von Google ist.“

Pros:

• „Terraform ist ziemlich cool.“
• „Mit Haptic zu arbeiten ist großartig.“
• „GCP ist stabil.“
• „Cloud Run ist ein wirklich cooles Produkt.“

Das Team bestand aus einer „Gang of Four“ – zeitweise plus zwei. Und: „Wir stellen ein.“

Technische Learnings für Engineering-Teams

Aus der Session lassen sich für ähnliche Vorhaben handfeste Learnings ableiten – konkret aus dem, was Karner und durchblicker.at explizit adressiert haben:

1) Konservative Migration senkt Risiko

• Services „as is“ zu migrieren, erhöht die Chancen, neue von alten Fehlern zu unterscheiden.
• Kein Big Bang: inkrementelle Migration Service-für-Service erhält Handlungsfähigkeit.

2) Eine Cloud, klare Umgebungen

• Die Entscheidung für eine Zielplattform beendet Multi-Cloud-Friktionen (z. B. Traffic-Kosten, Netzwerkpfade).
• Drei Umgebungen (Dev, Staging, Prod) sind gesetzt – inklusive konsistenter Policies und Zugriffsmodelle.

3) Infrastructure as Code – ohne Ausnahmen

• Terraform organisiert Org, Projekte, IAM, Policies, Billing Alerts – die Plattform wird reproduzierbar.
• Manuelle Änderungen direkt auf Maschinen untergraben Vertrauen (Ansible-Vertrauensverlust war ein Warnsignal). IaC muss „Single Source of Truth“ sein.

4) Secret-Management als Pflicht

• Secret Manager gehört zum Grundgerüst. Weg von „irgendwo im System“ hin zur zentralen, verwalteten Lösung.

5) Observability frühzeitig produktionsreif machen

• Logging, Alerting, Fehlerberichte: In der Ausgangslage „nicht gut“, teils mit zu viel Rauschen.
• Der Umstieg auf Managed-Stacks (Alerting, Opsgenie, Cloud Debug/Profiler) entlastet und macht echte Fehler sichtbarer.

6) Build-/Deploy-Pfade entkoppeln und vereinfachen

• Jenkins-Skripte, die Repos „zusammenkleben“ und per rsync verteilen, sind fragile Pfade.
• Das Ziel war, Jenkins durch GitLab zu ersetzen und die Pipelines zu straffen.

7) Architekturentscheidungen an realen Lastfällen prüfen

• RabbitMQ + Cloud Run trafen auf CPU-Throttling – der Pilot „tariffs“ machte das sichtbar.
• GKE Autopilot brachte (hier) zu langsames Scale-up. Diese Erkenntnis verhinderte einen Umweg.
• Das Feature „CPU always on“ war der Gamechanger – Timing ist Teil jeder Cloud-Reise.

8) Managed-first – aber ohne Dogma

• „Wir wollten keinen Kubernetes-Cluster von Hand betreiben.“ Der Fokus blieb auf Managed Services.
• Als Autopilot nicht performte, hielt man an dem Managed-Prinzip fest und nutzte die Chance mit Cloud Run.

9) Partnerwahl und Kickoff sind Beschleuniger

• Haptic (Wien) plus Google-Kickoff im Juli 2021: Klarer Startpunkt, Alignment und Tempoaufbau.

10) Realistische Roadmaps – mit Puffer

• Die ursprüngliche Roadmap war „komplett unterschätzt“. Diese Einsicht ist wertvoll – und normal.

Checkliste: Fragen, die wir uns nach der Session stellen

• Haben wir unsere Pain Points schriftlich und ehrlich erfasst – inklusive Lärmquellen im Monitoring?
• Nutzen wir konsequent Managed-Angebote statt „wir bauen alles selbst“?
• Ist unser Secret-Management zentralisiert und auditiert?
• Ist unsere IaC-Quelle wirklich die einzige Wahrheit – oder passieren noch manuelle Änderungen an Systemen?
• Haben wir drei durchgängige Umgebungen mit konsistenten Policies?
• Existiert ein klarer Weg, Jenkins-Altlasten auf eine einfachere CI/CD zu überführen?
• Haben wir einen realistischen Pilot-Service mit viel Traffic und wenigen Abhängigkeiten gewählt?
• Kennen wir die Grenzen der gewählten Cloud-Features (z. B. CPU-Modi in Cloud Run)?
• Haben wir die Time-to-Scale geprüft – unter Last, nicht nur im Leerlauf?
• Ist unsere Roadmap mit Lernzeit und Gegenwind geplant – nicht nur mit Idealgeschwindigkeit?

Stimmen und Momente, die hängen bleiben

Schlussgedanke

„Out of the Dark, Into the Light“ von Michael Karner (durchblicker.at) zeigt eine realistische Modernisierungsreise: erst ehrlich Bilanz ziehen, dann Leitplanken setzen, mit einem Pilotservice starten, konsequent Managed-Services und IaC nutzen – und mit Geduld, Partnern und einem Quäntchen Cloud-Feature-Timing ans Ziel kommen. Viele Details sind spezifisch für durchblicker.at – die Muster sind universell. Wer ähnliche Altlasten schultern muss, findet in diesem Erfahrungsbericht klare Anhaltspunkte, worauf es in der Praxis wirklich ankommt.

• 

  

  Raising Infrastructure Configuration to the next Level

  Johannes Brottrager von Durchblicker teilt in seinem devjobs.at TechTalk ein paar Tricks und Learnings, welche das Devteam gemacht hat, wie sie ihre IT Infrastruktur mit Terraform erstellt haben.

  Jetzt ansehen

• 

  

  Andreas Deuschl, CTO von Durchblicker

  Der CTO von Durchblicker Andreas Deuschl gibt im Interview Einblicke in die Organisation des Devteams, wie das Recruiting und Onboarding abläuft und welche Technologien eingesetzt werden.

  Jetzt ansehen