Managing Infrastructure At Scale: So betreibt Denovo GmbH 250+ Cloud-Instanzen mit Docker, Terraform und inner-sourceten Pipelines

Kontext: Warum diese Session für Engineering-Teams relevant ist

In „Managing Infrastructure At Scale“ führte uns Speaker Lukas Korl (Director of Operations, Denovo GmbH) durch die Operations-Realität eines Softwarehauses, das in wenigen Jahren von 4–5 auf 25 Mitarbeitende gewachsen ist und heute parallel über 35 Projekte im Jahr stemmt. Das Besondere: Denovo entwickelt nicht nur, sondern betreibt die ausgelieferten Produkte – vom ersten Ideensprint bis zur laufenden Cloud-Operations.

Diese Betriebsverantwortung trifft auf handfeste Skalierungsfakten:

• über 250 Cloud-Instanzen (virtuell und bare metal) über mehrere Provider
• 5.000+ umgesetzte User Stories (Features), die automatisiertes Testen notwendig machen
• 25 Mitarbeitende vs. 35 Projekte pro Jahr – keine einzelne Person kann die komplette Übersicht behalten

Die Konsequenz: Ein standardisiertes, reproduzierbares Setup ist Pflicht. Lukas bringt es auf den Punkt:

Gleichzeitig vermeidet Denovo Silos. Statt klassischem „Dev vs. Ops“ fordert Korl:

Und mit Blick auf laufende Pflege erinnert er an die Verantwortung, die nach dem Launch beginnt:

In diesem Artikel fassen wir als DevJobs.at-Redaktion zusammen, wie Denovo diese Prinzipien technisch umsetzt – mit Containerisierung, Infrastructure as Code, GitLab CI/CD, modularen Pipelines und regelmäßigen Cloud-Audits.

Das Problemfeld: Viele Projekte, heterogene Clouds, geteilte Verantwortung

Denovo baut Individualsoftware – von Mobile- und Web-Apps bis hin zu Desktop-Anwendungen – häufig im Kontext der Kreislaufwirtschaft (Abfall- und Recyclingindustrie), aber nicht ausschließlich. Die Teams sitzen in Graz und Athen, arbeiten projektübergreifend und folgen einem agilen Prozess, der sich an Scrum orientiert. Abgerechnet wird teilweise im Modell „Agiles Fixpreisangebot“. Entscheidend ist: Entwicklung und Betrieb gehören zusammen; Denovo liefert und betreibt.

Mit dem Wachstum entstanden konkrete Operations-Ziele:

• Kein Single-Point-of-Knowledge: Wissen muss modularisiert, dokumentiert, reproduzierbar sein.
• DRY-Konfiguration: 35+ Setups pro Jahr dürfen nicht zu Copy-Paste-Ritualen verkommen.
• Verlässliche Deployments: Jede Entwicklerin, jeder Entwickler soll ausrollen und verifizieren können.
• Kostenhygiene: „We learned the hard way“ – ungenutzte Instanzen dürfen nicht weiterlaufen.

Daraus formte Denovo drei durchgängige Prinzipien:

1) Reproduzierbarkeit in Setup und Betrieb

2) Support und Kollaboration ohne Silos

3) Sicherheit als laufende Aufgabe

Im Folgenden die technische Umsetzung dieser Leitlinien.

Prinzip 1: Reproduzierbarkeit – Containerisieren, beschreiben, trennen

Containerisierung als Default

Denovo verpackt jedes Projekt in einen Container (z. B. Docker). Das zentrale Motiv: alle Laufzeitabhängigkeiten wandern in ein standardisiertes Artefakt, das in Entwicklung, Test und Produktion identisch ist. Damit verschwinden typische Drift-Probleme der Art „works on my machine“.

• Gleiches Image in CI, Staging und Production
• Definierte, versionierte Abhängigkeiten pro Service
• Reproduzierbare Builds, deterministisches Deployment

Korl hat die Motivation prägnant umrissen: Transparenz, Vergleichbarkeit und Fehlerminimierung über Umgebungsgrenzen hinweg.

Infrastructure as Code mit Terraform

Neben den Applikationscontainern beschreibt Denovo die Cloud-Infrastruktur deklarativ. Terraform liest die gewünschte Zielstruktur aus Konfigurationsdateien und erzeugt, ändert oder entfernt Ressourcen, bis der reale Zustand mit der Beschreibung übereinstimmt.

• Einheitliche, versionierte Infrastruktur-Beschreibungen
• Reviewbare Änderungen (Plan/Apply) im Versionskontrollfluss
• Provider-agnostisches Vorgehen: AWS heute, Heroku morgen – per Modulwechsel

Lukas schildert ein konkretes Muster: Ob eine API auf Heroku oder auf AWS läuft, entscheidet sich über Module. Die Konfiguration bleibt im Kern identisch. Zusätzliche Komponenten – etwa eine Datenbank – werden als weiteres Modul ergänzt. Diese Modularisierung unterstützt DRY auf Infrastruktur-Ebene und hilft, Projekte konsistent und zügig aufzusetzen.

Build und Deployment strikt trennen

Ein Kernstück ist die Trennung der Lebenszyklen von Code und Infrastruktur. Denovo arbeitet mit zwei Repositories:

• Repo A: Infrastruktur-Beschreibung (Terraform)
• Repo B: Applikationscode (der Service selbst)

Beide Repos durchlaufen GitLab CI/CD. Für Infrastruktur bedeutet das: Terraform-Plan/Apply richtet etwa AWS- oder Heroku-Ressourcen ein. Für die Anwendung heißt es: Tests laufen, ein Container wird gebaut und in ein Registry gepusht. Ein anschließender Job deployt das Image auf die passende Zielumgebung (z. B. EC2).

Diese Separation bringt mehrere Vorteile:

• Reproduzierbarkeit: Infrastruktur-Änderungen sind versioniert und rückrollbar.
• Diagnostik: Build-Fehler und Infrastruktur-Themen lassen sich isoliert analysieren.
• Flexibilität: Eine frühere App-Version kann gezielt in eine frische Umgebung gerollt werden.

Kostenhygiene und Aufräumen als Teil der Definition of Done

„We learned the hard way“ – ungenutzte Instanzen kosten Geld. Mit IaC und Pipeline-Disziplin wird das Aufräumen Teil des Standardprozesses: Ephemere Ressourcen werden automatisiert beendet, Staging-Umgebungen kommen und gehen, Aging-Ressourcen fallen bei Bedarf kontrolliert aus dem Bestand. Reproduzierbarkeit umfasst damit auch die Fähigkeit, verlässlich zu de-provisionieren.

Prinzip 2: Support und Kollaboration – Silos auflösen, Infrastruktur inner-sourcen

Lukas vermeidet Buzzword-Debatten, die Grundhaltung ist jedoch klar:

Operations frühzeitig einbinden, Verantwortung teilen

Operations arbeiten nicht erst am Ende eines Releases, sondern begleiten Projekte frühzeitig. Umgekehrt sollen Entwicklerinnen und Entwickler Deployments anstoßen und verifizieren können. Dieses gemeinsame Ownership-Modell reduziert Wartezeiten und senkt Fehlerrisiken, weil Kontextwissen dort bleibt, wo es entsteht.

Inner-sourced Infrastructure: Open-Source-Prozess innerhalb des Unternehmens

Denovo behandelt Infrastruktur wie ein internes Open-Source-Projekt. Änderungen laufen über Merge Requests, werden reviewed und mit Terraform geprüft, bevor sie produktiv werden. Dieser Prozess hat mehrere Effekte:

• Transparenz: Jede Änderung ist nachvollziehbar.
• Qualitätskontrolle: Terraform-Plan zeigt, was sich ändert, bevor etwas ausgerollt wird.
• Lernkurve: Entwickler gewinnen Infrastruktur-Kompetenz durch Review und Contribution.

Modulare CI/CD-Pipelines über Includes

Ein konkretes Artefakt dieser inner-sourceten Infrastruktur sind modulare Pipeline-Konfigurationen. Korl beschreibt eine Pipeline-Datei, die über Include-Bausteine orchestriert wird. Je nach Projektbedarf wählt das Team die passenden Bausteine aus:

• Development-, Test- oder Staging-System per Include zuschalten
• Heroku- oder AWS-Deployment per Include austauschen

Der Clou: Entwickler müssen die Tiefenlogik dahinter nicht kennen. Sie bedienen sich der standardisierten Module, können aber gezielt um Features bitten oder selbst Pull Requests schreiben, wenn der Bedarf wächst. So entsteht ein Baukasten, der flexibel ist, ohne an Qualität einzubüßen.

Prinzip 3: Sicherheit als kontinuierlicher Prozess – Tests, Audits, Expertise

Sicherheit ist kein Projektabschluss, sondern ein Wartungszyklus. Korl formuliert es pragmatisch:

Automatisierte Tests in der Cloud

Tests gehören in die Pipeline, nicht auf lokale Maschinen. Sie dienen nicht dem Fingerzeigen, sondern der Vertrauensbildung:

Kontinuierliches Testen schafft die Basis für häufige, risikoarme Deployments. Es sichert die Container-Builds ebenso ab wie Infrastrukturänderungen.

Regelmäßige Cloud-Audits mit Bericht

Nicht alles lässt sich automatisieren. Denovo führt regelmäßige Audits durch, die in einem Bericht münden – analog zum Service-Heft beim Auto. Ziel ist Klarheit über den Zustand der Architektur: „up to date“ oder „Handlungsbedarf“. Das schafft Sichtbarkeit für Priorisierung und Budget.

Menschliche Expertise für Risikobewertungen

Schwachstellen haben Kontext. Manche „kritische“ CVEs sind für ein bestimmtes Projekt irrelevant, während „minor“-Funde echte Wirkung entfalten können. Die Schlussfolgerung: Expertinnen und Experten müssen einbezogen werden – idealerweise interdisziplinär zwischen Entwicklung und Operations.

Prozessmotor: Der Deming-Zyklus (Plan–Do–Check–Act)

Denovos Prinzipien sind nicht über Nacht entstanden. Korl beschreibt die Entwicklung als Iteration entlang des PDCA-Zyklus:

1) Start mit Containerisierung: „Plan–Do–Check–Act“ – reicht das? Ergebnis: Nein.

2) Nächster Schritt Terraform: Infrastruktur deklarativ machen. Reicht das? Ergebnis: Noch nicht.

3) Ergänzung um Monitoring und Auditing: Sicherheit und Betriebsreife erhöhen.

Diese Haltung ist der Kern von Agilität: nicht das Tool (Jira), sondern das Verhalten – ausprobieren, messen, anpassen.

Praktische Takeaways für Engineering-Teams

Basierend auf der Session „Managing Infrastructure At Scale“ (Speaker: Lukas Korl, Denovo GmbH) lassen sich für Teams die folgenden Leitlinien ableiten:

• Container zuerst: Standardisieren Sie die Ausführungsumgebung, um Drift zu vermeiden.
• IaC durchgängig: Schreiben Sie die Cloud in Code. Versionieren, reviewen, planen, anwenden.
• Build/Deploy trennen: Isolieren Sie den App-Build vom Infrastruktur-Lifecycle.
• Reproduzierbarkeit auch beim Aufräumen: Ephemere Umgebungen einplanen, Ressourcen zurückbauen.
• Silos abbauen: Entwickler deployen, Ops früh einbinden. Gemeinsames Ownership lebt von geteiltem Prozess.
• Inner-sourcen: Behandeln Sie Infrastruktur wie ein Open-Source-Projekt im Unternehmen.
• Modulbaukasten: Pipelines und Infrastrukturkonfiguration als wiederverwendbare Bausteine designen.
• Tests als Vertrauensanker: In der Cloud, automatisiert, nicht zum Beschuldigen, sondern zum Absichern.
• Audits mit Bericht: Ergänzen Sie Automatisierung um regelmäßige manuelle Prüfungen.
• Expertise kombinieren: Risiken kontextsensitiv bewerten – Dev + Ops + Fachwissen.
• PDCA leben: Schrittweise verbessern, nicht „Big Bang“ planen.

Ein Blick auf die Architektur-Topologie in Worten

Die in der Session beschriebene Betriebsarchitektur fügt sich aus klaren Elementen zusammen:

• Anwendungscode wird in Containern paketiert und in ein Registry geschrieben.
• Infrastruktur wird mittels Terraform deklariert und über getrennte Pipelines angewandt.
• Deployments nehmen das geprüfte Image aus dem Registry und bringen es auf die Zielumgebung – etwa EC2 bei AWS oder eine Heroku-App.
• Die Pipeline-Definitionen sind modular. Ein Projekt aktiviert benötigte Umgebungen (Development/Test/Staging) und Zielprovider (AWS/Heroku) per Include.
• Teams arbeiten an beiden Schichten – Code und Infrastruktur – über Merge Requests, inklusive Plan/Review-Schritte.
• Sicherheit ist Teil des Flows (Tests) plus zusätzlicher Audits, die in Berichten münden und Handlungsfelder transparent machen.

Diese Struktur ist bewusst generisch gehalten und dadurch portabel. Sie erlaubt Denovo, heterogene Kundenlandschaften zu bedienen und dennoch konsistent zu bleiben.

Lessons Learned, die hängen bleiben

Einige Sätze aus der Session eignen sich als Team-Gebote für skalierende Organisationen:

• „A setup must be reproducible.“ – Ohne Reproduzierbarkeit ist Skalierung Zufall.
• „Everybody gets their hands on everything.“ – Gemeinsames Ownership schlägt Ticket-Ping-Pong.
• „We learned the hard way“ – Kostenhygiene ist kein Nice-to-have, sondern Disziplin.
• „The tests shouldn’t be there for blaming somebody … they should be there to have confidence.“ – Tests schaffen Handlungsfreiheit.
• „Software needs maintenance, exactly like a car.“ – Betrieb beginnt nach dem Launch.

Fazit: Skalierbarkeit ist Prozessdisziplin, nicht Tool-Zauber

„Managing Infrastructure At Scale“ zeigt, dass Skalierung in der Cloud weniger von exotischen Tools abhängt als von konsequenten Prinzipien: Containerisierung, IaC, Modularisierung, getrennte Lebenszyklen, geteilte Verantwortung und kontinuierliche Pflege. Denovo GmbH betreibt über 250 Instanzen und überführt 35+ Projekte pro Jahr in den Betrieb, weil diese Prinzipien durchgängig gelebt werden – in Repositories, Pipelines und Teams.

Für Engineering-Organisationen, die vor ähnlichen Herausforderungen stehen, ist der Weg klar umrissen: klein anfangen (Container), Infrastruktur in Code heben (Terraform), Build und Deploy trennen, Pipelines modularisieren, Silos abbauen, Sicherheit ritualisieren und über den Deming-Zyklus stetig nachschärfen. Genau so entstehen Systeme, die auch morgen noch zuverlässig deployen, auditierbar bleiben und kostenbewusst laufen.

• 

  

  Mattias Rauter, Managing Partner von Denovo

  Managing Partner von Denovo Mattias Rauter gibt im Interview Einblicke in die Devteams, wie das Recruiting und Onboarding abläuft und mit welchen Technologien gearbeitet wird.

  Jetzt ansehen

• 

  

  Maximilian Haider, Full Stack Developer bei Denovo

  Maximilian Haider von Denovo erzählt im Interview darüber, wie er zum Programmieren gekommen ist, was er aktuell als Full Stack Developer arbeitet und gibt Tipps für Anfänger.

  Jetzt ansehen
• 

  

  Jacqueline Rinnhofer, Full Stack Developerin bei Denovo

  Jacqueline Rinnhofer von Denovo spricht im Interview über ihre späten Anfänge in der IT bis hin zur aktuellen Arbeit im Full Stack Development und gibt Tipps für Neueinsteiger.

  Jetzt ansehen
• 

  

  Tobias Stangl, Mobile Developer bei Denovo

  Tobias Stangl von Denovo redet im Interview über seinen frühen Einstieg in die Software Entwicklung bis hin zum aktuellen Job als Mobile Developer und gibt Tipps für Anfänger

  Jetzt ansehen
• 

  

  Michael Haar, Full Stack Developer bei Denovo

  Michael Haar von Denovo teilt im Interview seine Erfahrungen als Quereinsteiger ins Full Stack Development und was seiner Meinung nach wichtig für Anfänger ist.

  Jetzt ansehen