Zum Hauptinhalt springen
FromNine
Menü

Engineering

Cloud- und Plattform-Engineering, das Releases zur Routine macht

Wir bauen Cloud-Fundamente und interne Entwicklerplattformen, in denen Umgebungen als Code vorliegen, Releases signiert und wiederholbar sind und jeder Euro an Ausgaben eine verantwortliche Stelle hat.

Für belgische Unternehmen und Verwaltungen, die unter das NIS2-Gesetz fallen und ihre Cloud nachweisbar sicher betreiben müssen.

Ihr Projekt besprechenUnser Vorgehen kennenlernen
Cloud- & Plattform-Engineering: LeistungsschichtenVier hintereinander gestaffelte Schichten. Von oben nach unten: die Workloads der Produktteams, die interne Entwicklerplattform, die signierten Delivery-Pipelines und an der Basis die Landing Zone mit Identität, Netzwerk und Richtlinien.01Workloads der Produktteams02Interne Entwicklerplattform03Signierte Delivery-Pipelines04Landing Zone und Richtlinien
  1. 01Landing Zones mit Policy as Code und Datenresidenz je Workload
  2. 02Golden Paths, die einen neuen Service wiederholbar in Produktion bringen
  3. 03SLOs, getestete Wiederherstellung und Kosten je Produkt, sichtbar für die Entscheidenden

01 Herausforderungen

Woran Sie merken, dass das Fundament bremst

  1. 01

    Jede Umgebung ist ein Einzelstück

    Test und Produktion unterscheiden sich auf eine Weise, die niemand dokumentiert hat, und manuelle Korrekturen in der Konsole gehen beim nächsten Neuaufbau verloren.

  2. 02

    Ein Release braucht ein Meeting

    Deployments sind selten, manuell und auf den Abend gelegt. Teams bündeln Änderungen, und genau das macht jedes Release riskanter.

  3. 03

    Die Cloud-Rechnung überrascht alle

    Kosten sind je Subscription sichtbar, nicht je Produkt. GPU-Kapazität für KI-Workloads reserviert, wer zuerst gefragt hat.

  4. 04

    Niemand weiß, ob die Wiederherstellung funktioniert

    Backups gibt es. Wiederherstellungen wurden nie getestet, und Ziele für Wiederanlaufzeit und Datenverlust wurden nie mit dem Fachbereich vereinbart.

02 Leistungsumfang

Unsere Leistungen

  1. 01 Landing Zones und Souveränitätsoptionen

    Konto- und Subscription-Struktur, Identität, Netzwerk und Leitplanken auf den großen Hyperscalern und auf souveränen Cloud-Angeboten in der EU, mit Policy as Code und Datenresidenz je Workload.

    Was wir tun

    • Design von Organisation, Management Groups und Konten
    • Hub-Netzwerk, Egress-Kontrolle und private Konnektivität
    • Policy as Code für Residenz, Verschlüsselung und Tagging
    • Abgleich mit den Cloud-Sicherheitsnachweisen, die Ihre Auftraggeber oder Aufsichtsbehörden verlangen

    Was Sie erhalten

    • Landing Zone vollständig als Code
    • Richtlinienbibliothek mit Ausnahmeprozess
    • Optionspapier zur Souveränität je Workload-Klasse

  2. 02 Infrastructure as Code und interne Entwicklerplattformen

    Terraform oder OpenTofu und Bicep für die Infrastruktur, GitOps für Deployments, Kubernetes oder verwaltete Laufzeitumgebungen, wo sie passen, und Golden Paths, mit denen ein Team einen regelkonformen Service ohne Ticket startet.

    Was wir tun

    • Modulbibliothek für Infrastructure as Code
    • GitOps mit Stufen-Promotion über die Umgebungen
    • Kubernetes-Plattform oder verwaltete Alternativen
    • Service-Vorlagen und ein Entwicklerportal

    Was Sie erhalten

    • Interne Entwicklerplattform mit Golden Paths
    • Umgebungen im Self-Service
    • Plattform-Roadmap in der Verantwortung eines Plattformteams

  3. 03 Delivery-Pipelines und Lieferkettensicherheit

    Pipelines, die einmal bauen, Artefakte signieren, die Herkunft nach SLSA dokumentieren, Secrets sauber verwalten und dasselbe Artefakt vom Test bis in die Produktion befördern.

    Was wir tun

    • Pipeline-Vorlagen mit Qualitäts- und Sicherheits-Gates
    • Signierung von Artefakten und Herkunftsnachweise
    • Secrets-Management und Schlüsselrotation
    • Promotion-Regeln und Änderungsnachweise

    Was Sie erhalten

    • Wiederverwendbare Pipeline-Vorlagen
    • Signierte Artefakte mit überprüfbarer Herkunft
    • Release-Nachweise für das Change Management

  4. 04 Observability und SRE

    Service Level Objectives, die mit dem Fachbereich vereinbart sind, Error Budgets, die das Release-Tempo steuern, OpenTelemetry über den gesamten Stack und ein Incident-Prozess, der auch die Meldepflichten aus NIS2 und DORA bedient, wo sie gelten.

    Was wir tun

    • Definition der SLOs mit den Service-Verantwortlichen
    • Instrumentierung mit OpenTelemetry und Dashboards
    • Alarmierung auf Symptome statt auf Ursachen
    • Incident Management und Post-Incident-Reviews

    Was Sie erhalten

    • SLO-Katalog
    • Observability-Stack und Dashboards
    • Runbooks für Incidents und Meldungen

  5. 05 FinOps und KI-Kapazität

    Kostenzuordnung nach Produkt und Team, Stückkosten wie die Kosten je Transaktion sowie Kapazitätsplanung und Kostensteuerung für GPU-Ressourcen bei KI-Workloads.

    Was wir tun

    • Tagging-Richtlinie und Zuordnungsmodell
    • Stückkostenkennzahlen je Produkt
    • Planung von Commitments und Reservierungen
    • GPU-Scheduling, Kontingente und Right-Sizing

    Was Sie erhalten

    • Kosten-Dashboards je Produktverantwortung
    • Einsparungs-Backlog mit Verantwortlichen
    • KI-Kapazitätsplan

  6. 06 Wiederherstellung und Exit

    Backup und Disaster Recovery mit ausdrücklichen Zielen für Wiederanlaufzeit (RTO) und Datenverlust (RPO), regelmäßig getestet, und eine Exit-Strategie, die die Wechselrechte aus dem EU Data Act nutzt.

    Was wir tun

    • RTO und RPO je Service vereinbart
    • Wiederherstellungs- und Failover-Tests
    • Abhängigkeitsanalyse für kritische Services
    • Exit-Plan und Prüfung der Datenportabilität

    Was Sie erhalten

    • Getestete Wiederherstellungsverfahren
    • Berichte über Wiederherstellungstests
    • Dokumentierte Exit-Strategie

03 Architektur

Eine beispielhafte Referenzarchitektur

Links geht Code hinein, rechts kommen laufende Workloads heraus. Dazwischen signiert die Pipeline, was sie baut, die Registry speichert nur signierte Artefakte, und ein GitOps-Controller befördert sie unter Richtlinienkontrolle durch die Umgebungen.

Darunter liegt die Landing Zone: Organisationsstruktur, Identität, Netzwerk, Schlüssel, Wiederherstellung und Kostenkontrollen, einmal als Code definiert und von allen Produktteams gemeinsam genutzt.

Ebenen der Darstellung

Auslieferung
Repositories, Pipelines, signierte Artefakte und GitOps-Promotion.
Plattform
Die Entwicklerplattform, Policy as Code und die Laufzeitumgebung, auf die Produktteams deployen.
Landing Zone
Organisation, Identität, Netzwerk, Schlüssel, Wiederherstellung und FinOps-Kontrollen.
Betrieb
Telemetrie, SLOs, Error Budgets und Incident Response über alles hinweg.
Beispiel zur Veranschaulichung

  1. Auslieferung

    • Code- und IaC-Repositories
    • Bauen, signieren, attestieren
    • Registry für signierte Artefakte
    • GitOps-Promotion

  2. Plattform

    • Entwicklerplattform und Golden Paths
    • Policy as Code
    • Kubernetes und verwaltete Dienste
    • Workloads der Produktteams

  3. Landing Zone

    • Managementstruktur
    • Identität und Zugriff
    • Netzwerk-Hub und Egress
    • Schlüssel und Secrets
    • Backup und Wiederherstellung
    • Kostenzuordnung

  4. Betrieb

    • OpenTelemetry, SLOs und Error Budgets, Incident Response
Signierte Auslieferung auf eine richtliniengesteuerte Landing Zone

Beispielhafte Architektur, kein Kundensystem.

Diagramm als Text lesen

Der Hauptpfad führt von Code- und Infrastruktur-Repositories über Pipelines, die bauen, signieren und attestieren, in eine Artefakt-Registry, dann zu einem GitOps-Controller und schließlich zu den Workload-Spokes der Produktteams.

Eine interne Entwicklerplattform stellt Golden Paths zu den Pipelines bereit. Policy as Code begrenzt den GitOps-Controller. Eine Laufzeitplattform mit Kubernetes und verwalteten Diensten hostet die Workloads. Kundenseitig verwaltete Schlüssel speisen die Richtlinienschicht.

Die Landing Zone darunter umfasst Managementstruktur, Identitäts- und Zugriffsverwaltung, einen Netzwerk-Hub, Schlüssel, Backup und Wiederherstellung sowie FinOps-Kontrollen. Observability mit SLOs und Incident Response umspannt die gesamte Plattform.

04 Abwägungen und Grenzen

Technische Abwägungen und Grenzen

  • Souveränität ist ein Spektrum

    Wie wir vorgehen

    Wir stufen Workloads nach Schutzbedarf ein und ordnen jeder Klasse eine Option zu: EU-Regionen eines Hyperscalers, ein souveränes Cloud-Angebot oder eigene Infrastruktur. Die Abwägungen bei Funktionsumfang, Kosten und Betrieb werden dokumentiert.

    Grenzen und Abhängigkeiten

    Souveräne Angebote hinken bei verwalteten Diensten, auch bei KI-Diensten, oft hinterher. Manche Workloads kosten dort mehr oder können weniger, und das ist eine geschäftliche Entscheidung.

  • Eine Plattform braucht einen Product Owner

    Wie wir vorgehen

    Wir behandeln die interne Plattform als Produkt mit Nutzenden, Roadmap und Feedbackschleifen und helfen Ihnen, das Team aufzubauen, das sie betreibt.

    Grenzen und Abhängigkeiten

    Eine Plattform ohne Team wird zum Engpass. Können Sie es nicht besetzen, empfehlen wir verwaltete Dienste und weniger Abstraktionen.

  • Regulierung prägt den Betrieb

    Wie wir vorgehen

    Klassifizierung von Vorfällen, Meldefristen und Beweissicherung sind in den Incident-Prozess eingebaut, wo NIS2 oder DORA für Sie gelten.

    Grenzen und Abhängigkeiten

    Ob Sie in den Anwendungsbereich fallen und wie die nationale Umsetzung greift, beurteilen Ihre Compliance- und Rechtsabteilung.

  • Kostensteuerung ist Teamarbeit

    Wie wir vorgehen

    Wir machen Kosten je Produkt sichtbar und ergänzen Leitplanken wie Budgets, Kontingente und das zeitgesteuerte Abschalten ungenutzter Umgebungen.

    Grenzen und Abhängigkeiten

    Die größten Einsparungen entstehen meist aus Architektur- und Nutzungsentscheidungen der Produktverantwortlichen, nicht aus der Plattform allein.

05 Zusammenarbeit

So arbeiten wir

Erst das Fundament, dann ein Team auf dem Golden Path, dann alle anderen.

  1. 01

    Bewerten und einstufen

    Workloads, Schutzbedarf der Daten, aktuelle Kosten und die Kontrollen, die Ihre Prüfer erwarten.

    ErgebnisWorkload-Klassifizierung und Zieloptionen

  2. 02

    Landing Zone aufbauen

    Alles als Code, mit der IT-Sicherheit abgestimmt, mit einem Prozess für Ausnahmen.

    ErgebnisLanding Zone im Produktivbetrieb

  3. 03

    Ein Leuchtturmteam an Bord holen

    Ein Produktteam wechselt auf den Golden Path, seine Reibungspunkte prägen die Plattform.

    ErgebnisErster Service auf der Plattform

  4. 04

    Skalieren und übergeben

    Weitere Teams kommen hinzu, das Plattformteam übernimmt die Verantwortung, und die Wiederherstellung wird regelmäßig getestet.

    ErgebnisPlattform-Roadmap und Berichte über Wiederherstellungstests

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Automatisierung betreibt die Plattform. Menschen verantworten die Entscheidungen, die Risiko oder Kosten mit sich bringen.

  • Änderungen in Produktion sind nachvollziehbar

    Jede Änderung an der Produktion stammt aus einem geprüften Commit. Wer was geändert und wer es freigegeben hat, ist damit immer dokumentiert.

  • Notfallzugriffe sind selten und protokolliert

    Break-Glass-Zugriffe sind zeitlich begrenzt, müssen begründet werden und werden im Nachgang geprüft.

  • Ausnahmen von Richtlinien haben eine verantwortliche Person

    Braucht ein Workload eine Ausnahme von einer Leitplanke, genehmigt sie eine benannte risikoverantwortliche Person, mit Ablaufdatum.

  • Service-Verantwortliche setzen die Ziele

    Wiederherstellungsziele und Service Levels werden mit der fachlichen Verantwortung jedes Service vereinbart, nicht vom Plattformteam allein festgelegt.

07 Technologien

Technologien, mit denen wir arbeiten

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Souveräne Cloud-Angebote in der EU
Infrastruktur und Auslieferung
  • Terraform und OpenTofu
  • Bicep
  • Argo CD und Flux
  • GitHub Actions, GitLab CI und Azure DevOps
Laufzeit
  • Kubernetes und verwaltete Varianten
  • Serverless- und Container-Plattformen
  • Service Mesh, wo es sich lohnt
  • GPU-Node-Pools für KI-Workloads
Betrieb
  • OpenTelemetry
  • Prometheus und Grafana
  • Cloud-natives Monitoring
  • Policy Engines wie OPA

Die Nennung einer Technologie beschreibt unsere Engineering-Erfahrung. Sie bedeutet keine Partnerschaft mit dem Hersteller und keine Empfehlung durch ihn.

08 Beispiel

Beispielhaftes Szenario

Beispiel zur Veranschaulichung

Eine Cloud-Grundlage für einen regionalen Versorger

01Ausgangslage
Ein Versorger mit Netzen in der Provinz Lüttich ist als wesentliche Einrichtung eingestuft. Seine Anwendungen laufen verteilt in einem eigenen Rechenzentrum und bei zwei Cloud-Anbietern, und für die CyberFundamentals-Bewertung fehlen zentrale Nachweise.
02Was wir bauen würden
Eine Landing Zone mit einheitlicher Identitätsverwaltung, zentraler Protokollierung, signierten Pipelines und einem Meldeablauf, der Vorfälle nach den belgischen Fristen einstuft und Berichte vorbereitet.
03Wo Menschen entscheiden
Das Sicherheitsteam prüft jede Meldung an das Zentrum für Cybersicherheit Belgien und reicht sie selbst ein; nichts wird automatisch übermittelt.
04Was wir messen würden
Zeit von der Erkennung bis zur Erstmeldung, Abdeckung der CyberFundamentals-Maßnahmen und Dauer eines Wiederherstellungstests.

09 Branchenblick

In Ihrer Branche

  • Öffentlicher Sektor & Verwaltung

    Souveränitätsoptionen je Datenklasse, nationale Sicherheitstestate und Exit-Pläne, die auch die nächste Ausschreibung überstehen.

  • Finanzdienstleistungen

    Digitale operationale Resilienz nach DORA: getestete Wiederherstellung, Überwachung von IKT-Drittdienstleistern und Meldewesen für Vorfälle als Teil des Betriebs.

Belgien

Cloud unter dem belgischen NIS2-Gesetz

Seit Oktober 2024 gilt in Belgien das NIS2-Gesetz. Wesentliche und wichtige Einrichtungen müssen sich beim Zentrum für Cybersicherheit Belgien registrieren, Vorfälle in engen Fristen melden und ihre Maßnahmen belegen, oft anhand der CyberFundamentals. Für Finanzunternehmen kommt DORA hinzu.

Wir bauen Landing Zones, in denen Protokollierung, Datenstandort und Einstufung von Vorfällen als Richtlinien festgelegt sind und nicht in jedem Projekt neu entstehen. So lassen sich die Nachweise erbringen, die das Zentrum oder eine Prüfstelle verlangt. Ausstiegspläne stützen sich auf die Wechselrechte der EU-Datenverordnung und werden getestet.

Fragen zu Cloud- und Plattform-Engineering

Welchen Cloud-Anbieter empfehlen Sie?

Den, der zu Ihren Workloads, Ihren bestehenden Verträgen und Ihren Anforderungen an Souveränität passt. Wir arbeiten mit den großen Hyperscalern und mit souveränen Angeboten in der EU und dokumentieren die Abwägungen, damit sich die Entscheidung in der Vergabe begründen und später überprüfen lässt.

Brauchen wir Kubernetes?

Nicht immer. Kubernetes lohnt sich, wenn Sie viele Services betreiben und ein Team für den Plattformbetrieb haben. Für eine Handvoll Services sind verwaltete Container- oder Serverless-Plattformen oft einfacher und günstiger im Betrieb.

Wie gehen Sie an das Thema Sicherheit heran?

Sicherheit ist in die Landing Zone und die Pipelines eingebaut: Identitäten nach dem Least-Privilege-Prinzip, Policy as Code, signierte Artefakte und Secrets, die nie im Code liegen. FromNine selbst ist für sein Informationssicherheits-Managementsystem nach ISO/IEC 27001 zertifiziert.

Können Sie unsere Cloud-Kosten senken?

In der Regel ja, aber wir versprechen keinen Prozentsatz, bevor wir die Daten gesehen haben. Zuerst machen wir die Kosten je Produkt sichtbar, dann arbeiten wir ein Einsparungs-Backlog gemeinsam mit den Verantwortlichen ab, die handeln können.

Wie vermeiden wir einen Lock-in?

Indem Sie bewusst entscheiden, wo Sie sich auf anbieterspezifische Dienste stützen, die Infrastruktur als Code vorhalten und einen dokumentierten, getesteten Exit-Plan pflegen. Der EU Data Act stärkt Ihre Wechselrechte, ein Exit-Plan macht sie nutzbar.

Zeigen Sie uns Ihre nächsten drei Releases

Wir sagen Ihnen, was sie zur Routine machen würde und was diese Grundlage in Aufbau und Betrieb kostet, abgestimmt auf Ihre Pflichten gegenüber dem Zentrum für Cybersicherheit.

Gespräch vereinbarenUnser Vorgehen ansehen