Zum Hauptinhalt springen
FromNine
Menü

Entwicklung

Ein Cloud-Fundament, auf dem Releases zur Routine werden.

Wir bauen Cloud-Fundamente und interne Entwicklerplattformen, auf denen Umgebungen als Code beschrieben sind, Releases signiert und wiederholbar ablaufen und jeder Euro an Ausgaben einen Verantwortlichen hat.

Für Banken, Fonds, Versicherer und andere Organisationen in Luxemburg, die ein Cloud-Fundament für Gesellschaften unter mehreren Aufsichten betreiben.

Projekt anfragenReferenzarchitektur ansehen
Cloud- & Plattform-Engineering: die BausteineVier gestaffelte Ebenen: obenauf laufen die Anwendungen der Produktteams, darunter liegt die Plattform für die Entwicklung, dann folgen die Pipelines, die jede Version signieren, und zuunterst die Landing Zone mit Identitäten, Netzwerk und Regeln.01Anwendungen der Produktteams02Interne Entwickler­plattform03Signierte Pipelines04Landing Zone und Regeln
  1. 01Landing Zones mit Policy as Code und einem Datenstandort, der je Anwendung festgelegt ist
  2. 02Golden Paths, die einen neuen Dienst wiederholbar in den Produktivbetrieb bringen
  3. 03Servicelevel, erprobte Wiederherstellung und Produktkosten, offen für alle, die darüber entscheiden

01 Probleme

Woran Sie merken, dass das Fundament bremst

  1. 01

    Jede Umgebung ist ein Einzelstück

    Zwischen Test- und Produktionsumgebung gibt es Unterschiede, die nirgends dokumentiert sind. Wer etwas direkt in der Konsole repariert, verliert die Korrektur beim nächsten Neuaufbau.

  2. 02

    Für ein Release braucht es eine Besprechung

    Ausgeliefert wird selten, von Hand und nach Feierabend. Also bündeln die Teams ihre Änderungen, und genau das erhöht das Risiko jeder Auslieferung.

  3. 03

    Die Cloud-Rechnung überrascht alle

    Kosten sind je Abonnement sichtbar, nicht je Produkt. GPU-Kapazität für KI-Arbeit bekommt, wer zuerst gefragt hat.

  4. 04

    Ob die Wiederherstellung klappt, weiß niemand

    Gesichert wird zwar, zurückgespielt aber nie zur Probe. Wie lange ein Ausfall dauern und wie viele Daten er kosten darf, wurde mit der Fachseite nie vereinbart.

02 Leistungsumfang

Was wir liefern

  1. 01 Landing Zones und Optionen für Souveränität

    Wir legen Konten- und Abonnementstruktur, Identitäten, Netz und Leitplanken an, bei Azure, AWS oder Google Cloud ebenso wie bei souveränen europäischen Angeboten. Regeln stehen als Code fest, der Datenstandort wird pro Anwendung bestimmt.

    Was wir tun

    • Entwurf von Organisation, Management-Gruppen und Konten
    • Hub-Netzwerk, Kontrolle des ausgehenden Verkehrs und private Verbindungen
    • Policy as Code für Datenstandort, Verschlüsselung und Kennzeichnung
    • Abgleich mit den Nachweisen, die Ihre Kunden und Ihre Aufsicht verlangen

    Was Sie erhalten

    • Landing Zone vollständig als Code
    • Regelbibliothek mit Verfahren für Ausnahmen
    • Papier zu Souveränitätsoptionen je Anwendungsklasse

  2. 02 Infrastructure as Code und interne Entwickler­plattformen

    Die Infrastruktur beschreiben wir mit Terraform, OpenTofu oder Bicep, Deployments laufen über GitOps, betrieben wird auf Kubernetes oder einer verwalteten Laufzeit, je nachdem, was passt. Über Golden Paths startet ein Team einen regelkonformen Dienst selbst, ohne auf ein Ticket zu warten.

    Was wir tun

    • Modulbibliothek für Infrastructure as Code
    • GitOps mit Übergang von Umgebung zu Umgebung
    • Kubernetes-Plattform oder verwaltete Alternativen
    • Dienstvorlagen und ein Entwicklerportal

    Was Sie erhalten

    • Interne Entwicklerplattform mit Golden Paths
    • Umgebungen in Selbstbedienung
    • Plattform-Roadmap in der Hand eines Plattformteams

  3. 03 Auslieferungs­pipelines und Sicherheit der Lieferkette

    Jedes Artefakt wird genau einmal gebaut und signiert, seine Herkunft nach SLSA dokumentiert. Geheimnisse liegen in einem Tresor, nicht in der Pipeline, und vom Test bis in die Produktion wandert stets dasselbe Artefakt.

    Was wir tun

    • Pipeline-Vorlagen mit Qualitäts- und Sicherheitsschwellen
    • Signatur von Artefakten und Herkunftsnachweise
    • Verwaltung von Geheimnissen und Schlüsselrotation
    • Regeln für die Weitergabe und Änderungsprotokolle

    Was Sie erhalten

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

  4. 04 Beobachtbarkeit und SRE

    Service Level Objectives, mit der Fachseite vereinbart, Fehlerbudgets, die das Release-Tempo lenken, OpenTelemetry über alle Schichten und ein Vorfallprozess, der auch die Meldepflichten nach dem luxemburgischen NIS2-Gesetz oder nach DORA bedient, wo sie greifen.

    Was wir tun

    • Festlegung der SLOs mit den Dienstverantwortlichen
    • Instrumentierung mit OpenTelemetry und Dashboards
    • Alarme auf Symptome statt auf Ursachen
    • Vorfallmanagement und Nachbesprechungen

    Was Sie erhalten

    • SLO-Katalog
    • Beobachtbarkeits-Stack und Dashboards
    • Betriebshandbücher für Vorfälle und Meldungen

  5. 05 FinOps und KI-Kapazität

    Kostenzuordnung nach Produkt und Team, Stückkosten wie die Kosten pro Transaktion sowie Planung und Kostenkontrolle der GPU-Kapazität für KI-Anwendungen.

    Was wir tun

    • Kennzeichnungsregeln und Zuordnungsmodell
    • Kennzahlen zu Stückkosten je Produkt
    • Planung von Zusagen und Reservierungen
    • GPU-Planung, Kontingente und passende Dimensionierung

    Was Sie erhalten

    • Kosten-Dashboards je Produktverantwortlichem
    • Einsparliste mit Verantwortlichen
    • Kapazitätsplan für KI

  6. 06 Wiederherstellung und Ausstieg

    Sicherung und Notfallwiederherstellung mit festgelegten Werten für RTO und RPO, die nach Plan geprobt werden, dazu eine Ausstiegsstrategie auf Grundlage der Wechselrechte aus dem Data Act.

    Was wir tun

    • RTO und RPO je Dienst vereinbaren
    • Tests für Rücksicherung und Umschaltung
    • Abhängigkeiten der kritischen Dienste erfassen
    • Exit-Plan und Prüfung der Datenübertragbarkeit

    Was Sie erhalten

    • Getestete Wiederherstellungsverfahren
    • Berichte zu den Wiederherstellungstests
    • Dokumentierte Exit-Strategie

03 Architektur

Eine Referenz­architektur zur Veranschaulichung

Links kommt Code hinein, rechts laufen die Anwendungen. Dazwischen signiert die Pipeline, was sie baut, die Registry nimmt nur signierte Artefakte auf, und ein GitOps-Controller reicht sie unter Regelkontrolle von Umgebung zu Umgebung weiter.

Das Fundament bildet die Landing Zone. Organisation, Identitäten, Netz, Schlüssel, Wiederherstellung und Kostensteuerung werden dort ein einziges Mal als Code festgelegt und stehen jedem Produktteam zur Verfügung.

Schichten in der Zeichnung

Auslieferung
Repositories, Pipelines, signierte Artefakte und Weitergabe per GitOps.
Plattform
Die Entwicklerplattform, Policy as Code und die Laufzeitumgebung, in die Produktteams ausliefern.
Landing Zone
Organisation, Identität, Netzwerk, Schlüssel, Wiederherstellung und FinOps-Kontrollen.
Betrieb
Telemetrie, SLOs, Fehlerbudgets und Vorfallbearbeitung über alles hinweg.
Beispiel zur Veranschaulichung

  1. Auslieferung

    • Repositories für Code und IaC
    • Bauen, signieren, bezeugen
    • Registry für signierte Artefakte
    • Weitergabe per GitOps

  2. Plattform

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

  3. Landing Zone

    • Verwaltungsstruktur
    • Identität und Zugriff
    • Netzwerk-Hub und Ausgang
    • Schlüssel und Geheimnisse
    • Backup und Wiederherstellung
    • Kostenzuordnung

  4. Betrieb

    • OpenTelemetry, SLOs und Fehlerbudgets, Vorfallbearbeitung
Signierte Auslieferung auf einer geregelten Landing Zone

Veranschaulichende Architektur, kein Kundensystem.

Diagramm als Text lesen

Code und Infrastrukturbeschreibung kommen aus den Repositories in die Pipelines. Dort wird gebaut, signiert und die Herkunft bescheinigt; die Artefakte landen in der Registry, ein GitOps-Controller reicht sie weiter, und am Ende laufen sie in den Bereichen der Produktteams.

Die Entwicklerplattform führt über Golden Paths in die Pipelines. Was der GitOps-Controller tun darf, begrenzen Regeln als Code; diese stützen sich auf Schlüssel, die der Kunde selbst verwaltet. Die Anwendungen laufen auf Kubernetes und verwalteten Diensten.

Zur Landing Zone gehören Verwaltungsstruktur, Identitäts- und Zugriffsverwaltung, ein zentraler Netzknoten, Schlüssel, Sicherung und Wiederherstellung sowie die FinOps-Steuerung. Über allem liegt die Beobachtung mit SLOs und Vorfallbearbeitung.

04 Abwägungen und Grenzen

Technische Abwägungen und Grenzen

  • Souveränität hat Abstufungen

    Unser Umgang damit

    Jede Anwendung erhält eine Schutzklasse, und jede Klasse eine Betriebsform: Hyperscaler mit Rechenzentren in der EU, souveräne Cloud oder eigene Server. Welche Einbußen bei Funktionsumfang, Kosten und Betrieb damit verbunden sind, steht schwarz auf weiß im Entscheidungspapier.

    Grenzen und Abhängigkeiten

    Bei verwalteten Diensten, KI eingeschlossen, sind souveräne Angebote häufig im Rückstand. Für einzelne Anwendungen heißt das höhere Kosten oder weniger Funktionen; diese Abwägung trifft die Fachseite.

  • Eine Plattform braucht einen Product Owner

    Unser Umgang damit

    Wir behandeln die interne Plattform als Produkt mit Nutzern, Roadmap und Rückmeldeschleifen und helfen Ihnen, das Team aufzustellen, das sie betreibt.

    Grenzen und Abhängigkeiten

    Eine Plattform ohne eigenes Team bremst alle anderen aus. Fehlt Ihnen das Personal dafür, raten wir zu verwalteten Diensten und einer schlankeren Plattform.

  • Regulierung prägt den Betrieb

    Unser Umgang damit

    Wo das NIS2-Gesetz vom 5. Mai 2026 oder DORA für Sie gelten, bauen wir Einstufung von Vorfällen, Meldefristen und Beweissicherung in den Vorfallprozess ein, etwa die 24-Stunden-Meldung an die zuständige Behörde nach dem NIS2-Gesetz.

    Grenzen und Abhängigkeiten

    Ob Sie in den Anwendungsbereich fallen und wie das luxemburgische Gesetz im Einzelnen auf Sie anzuwenden ist, klären Ihre Compliance- und Rechtsabteilung.

  • Kostenkontrolle ist eine gemeinsame Aufgabe

    Unser Umgang damit

    Pro Produkt werden die Ausgaben transparent, dazu kommen Budgets, Kontingente und Zeitpläne, nach denen ungenutzte Umgebungen nachts und am Wochenende ruhen.

    Grenzen und Abhängigkeiten

    Die größten Einsparungen kommen meist aus Entscheidungen zu Architektur und Nutzung, die die Produktverantwortlichen treffen, nicht aus der Plattform allein.

05 Arbeitsweise

Wie wir arbeiten

Erst das Fundament, dann ein Pilotteam, danach der Rest der Organisation.

  1. 01

    Bewerten und einstufen

    Anwendungen, Schutzbedarf der Daten, heutige Kosten und die Kontrollen, die Ihre Prüfer erwarten.

    ErgebnisEinstufung der Anwendungen und Zieloptionen

  2. 02

    Landing Zone aufbauen

    Alles als Code, mit der Informationssicherheit durchgesehen, mit einem Verfahren für Ausnahmen.

    ErgebnisLanding Zone im Produktivbetrieb

  3. 03

    Ein Pilotteam aufnehmen

    Ein Produktteam wechselt auf den Golden Path; was es dabei bremst, formt die Plattform.

    ErgebnisErster Dienst auf der Plattform

  4. 04

    Ausweiten und übergeben

    Schrittweise ziehen die übrigen Teams nach, Ihr Plattformteam übernimmt den Betrieb, und Wiederherstellungstests stehen fest im Kalender.

    ErgebnisPlattform-Roadmap und Berichte zu Wiederherstellungstests

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

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

  • Änderungen an der Produktion sind nachvollziehbar

    In die Produktion gelangt nur, was als geprüfter Commit vorliegt. Urheber und Freigabe jeder Änderung lassen sich so jederzeit belegen.

  • Notfallzugriff ist selten und protokolliert

    Ein Notfallzugriff ist zeitlich begrenzt, muss begründet werden und wird im Nachhinein überprüft.

  • Ausnahmen von Regeln haben einen Verantwortlichen

    Ausnahmen von einer Leitplanke genehmigt eine namentlich benannte Person mit Risikoverantwortung, und jede Ausnahme läuft zu einem festen Datum aus.

  • Dienstverantwortliche setzen die Ziele

    Wiederanlaufziele und Service Levels vereinbaren wir mit den fachlich Verantwortlichen jedes Dienstes; das Plattformteam legt sie nicht allein fest.

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-Knotenpools für KI-Anwendungen
Betrieb
  • OpenTelemetry
  • Prometheus und Grafana
  • Cloud-native Überwachung
  • Regel-Engines wie OPA

Eine hier genannte Technologie beschreibt unsere Erfahrung in der Entwicklung. Sie bedeutet weder eine Partnerschaft mit dem Hersteller noch dessen Empfehlung.

08 Beispiel

Ein veranschaulichendes Beispiel

Beispiel zur Veranschaulichung

Landing Zone und Exit-Plan für eine Bank unter DORA

01Ausgangslage
Eine Bank in Luxemburg betreibt mehrere Cloud-Umgebungen mit unterschiedlichen Kontrollen. Schwerwiegende IKT-Vorfälle muss sie über das eDesk der CSSF melden, die Daten dafür sucht das Team jedes Mal aus mehreren Konsolen zusammen, und für den wichtigsten Cloud-Dienst gibt es keinen getesteten Ausstieg.
02Was wir bauen würden
Eine Landing Zone als Code mit Regelsätzen je Geschäftsbereich, zentraler Protokollierung und einem Vorfallprozess, der nach DORA einstuft und die Angaben für die Meldung vorbereitet, dazu ein Exit-Plan, der einmal im Jahr geprobt wird.
03Wo Menschen entscheiden
Die Informationssicherheit genehmigt Ausnahmen von den Regeln; die Geschäftsleitung bestätigt Exit-Plan und Wiederanlaufziele. Die Meldung selbst gibt immer ein Mensch ab.
04Was wir messen würden
Zeit von der Erkennung eines Vorfalls bis zur Einstufung, Anteil der Anwendungen unter Regelkontrolle sowie bestandene Wiederherstellungs- und Exit-Tests pro Quartal.

09 Branchen

In Ihrer Branche

  • Staat & Gemeinden

    Souveränitätsoptionen je Datenklasse, die Nachweise, die ein Lastenheft verlangt, und Exit-Pläne, die auch die nächste Ausschreibung auf marches.public.lu überstehen.

  • Finanzsektor

    Operative Resilienz nach DORA für Banken, Fonds und Versicherer unter Aufsicht von CSSF oder CAA: getestete Wiederherstellung, Steuerung der IKT-Drittanbieter und Vorfallmeldung als Teil des Betriebs.

Luxemburg

Nachweise einmal erzeugen, für jede Aufsicht

In Luxemburg gilt seit dem 10. Mai 2026 das Gesetz vom 5. Mai 2026 zur Umsetzung von NIS2. Für die meisten Sektoren ist das Institut Luxembourgeois de Régulation (ILR) zuständig, das auch das Registrierungsportal betreibt, und wesentliche und wichtige Einrichtungen melden Vorfälle innerhalb von 24 Stunden. Für Banken, Fonds und Versicherer kommt DORA hinzu: Zuständig sind die CSSF und das Commissariat aux Assurances (CAA), und Vorfälle von Unternehmen unter Aufsicht der CSSF werden nach dem Rundschreiben CSSF 25/893 über das eDesk der CSSF gemeldet.

Eine Gruppe mit Gesellschaften in Luxemburg und den Nachbarländern braucht deshalb eine Plattform, die jeder Behörde die verlangten Nachweise liefert. Wir entwerfen Landing Zones, in denen Datenstandort, Protokollierung und Einstufung von Vorfällen Regeln sind und keine Projekte, sodass eine neue Gesellschaft per Konfiguration hinzukommt. Exit-Pläne stützen sich auf die Wechselrechte aus dem Data Act und werden getestet, nicht nur geschrieben.

Fragen zu Cloud- und Plattform-Engineering

Welchen Cloud-Anbieter empfehlen Sie?

Das richtet sich nach Ihren Anwendungen, nach laufenden Verträgen und danach, wie viel Souveränität Sie brauchen. Wir sind auf den großen Hyperscalern ebenso zu Hause wie bei europäischen souveränen Anbietern und halten die Abwägung schriftlich fest. So können Sie die Entscheidung im Vergabeverfahren oder vor der Aufsicht vertreten und später neu bewerten.

Brauchen wir Kubernetes?

Nicht zwingend. Der Aufwand rechnet sich erst bei vielen Diensten und einem Team, das die Plattform betreut. Für wenige Dienste genügen meist Container- oder Serverless-Angebote des Cloud-Anbieters, die weniger Betrieb verlangen.

Wie gehen Sie Sicherheit an?

Sie ist in Landing Zone und Pipelines eingebaut: Identitäten erhalten nur die nötigen Rechte, Regeln stehen als Code fest, Artefakte sind signiert, und Passwörter oder Schlüssel haben im Quellcode nichts zu suchen. FromNine ist zudem nach ISO/IEC 27001 zertifiziert.

Können Sie unsere Cloud-Kosten senken?

In der Regel schon. Eine Prozentzahl nennen wir aber erst nach einem Blick in Ihre Daten. Am Anfang steht die Transparenz pro Produkt; danach gehen wir die Sparmöglichkeiten gemeinsam mit den Verantwortlichen durch, die sie umsetzen können.

Wie vermeiden wir Abhängigkeit von einem Anbieter?

Indem Sie bewusst wählen, wo Sie anbieterspezifische Dienste nutzen, die Infrastruktur als Code halten und einen dokumentierten, getesteten Exit-Plan pflegen. Der Data Act stärkt Ihre Wechselrechte; DORA verlangt von Finanzunternehmen Ausstiegsstrategien für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen. Erst ein getesteter Plan macht beides belastbar.

Zeigen Sie uns Ihre nächsten drei Releases

Sie erfahren, was nötig wäre, damit diese Releases Routine werden, und was ein solches Fundament im Aufbau und im laufenden Betrieb kostet.

Projekt anfragenArchitektur & Beratung ansehen