Zum Hauptinhalt springen
FromNine
Menü

Engineering

Eine Cloud-Grundlage, auf der Releases zur Routine werden.

Wir bauen Cloud-Fundamente und interne Entwicklerplattformen, bei denen Umgebungen als Code vorliegen, jedes Release signiert und wiederholbar ist und für jeden ausgegebenen Euro jemand geradesteht.

Für Organisationen in Österreich, die eine Cloud-Grundlage für Gesellschaften in mehreren Mitgliedstaaten betreiben, jede mit ihrer eigenen Aufsicht.

Erstgespräch anfragenZur Referenzarchitektur
Cloud & Platform Engineering: der AufbauVier gestapelte Schichten. Ganz oben laufen die Anwendungen der Produktteams, darunter liegt die interne Entwicklerplattform, dann folgen die signierten Auslieferungs-Pipelines, und als Basis dient die Landing Zone mit Identität, Netzwerk und Richtlinien.01Anwendungen der Produktteams02Interne Entwicklerplattform03Signierte Pipelines04Landing Zone und Richtlinien
  1. 01Landing Zones mit Policy as Code, der Speicherort der Daten je Anwendung festgelegt
  2. 02Golden Paths, über die neue Services immer auf demselben Weg in Produktion kommen
  3. 03SLOs, erprobte Wiederherstellung und Kosten je Produkt, sichtbar für alle, die entscheiden

01 Probleme

Woran Sie merken, dass das Fundament bremst

  1. 01

    Jede Umgebung ist ein Einzelstück

    Zwischen Test und Produktion gibt es Unterschiede, die keiner aufgeschrieben hat. Handgriffe in der Konsole gehen beim nächsten Neuaufbau verloren.

  2. 02

    Für ein Release braucht es eine Besprechung

    Deployments sind selten, laufen von Hand und werden auf den Abend gelegt. Also sammeln die Teams Änderungen, und jedes Release wird dadurch riskanter.

  3. 03

    Die Cloud-Rechnung überrascht jeden Monat

    Kosten sieht man je Subscription, nicht je Produkt. GPU-Kapazität für KI-Vorhaben bekommt, wer zuerst gefragt hat.

  4. 04

    Ob die Wiederherstellung klappt, weiß niemand

    Backups gibt es. Eine Rücksicherung wurde nie geprobt, und Wiederanlaufzeit und tolerierbarer Datenverlust sind mit der Fachseite nie vereinbart worden.

02 Leistungs­umfang

Was wir liefern

  1. 01 Landing Zones und Souveränitäts­optionen

    Konto- und Subscription-Struktur, Identität, Netzwerk und Leitplanken bei den großen Cloud-Anbietern und bei souveränen EU-Angeboten, mit Policy as Code und einem für jede Anwendung festgelegten Datenstandort.

    Was wir tun

    • Entwurf von Organisation, Management Groups und Konten
    • Hub-Netzwerk, Kontrolle des ausgehenden Verkehrs und private Anbindung
    • Policy as Code für Datenstandort, Verschlüsselung und Tagging
    • Abgleich mit den Nachweisen, die Ihre Auftraggeber verlangen, etwa ISO/IEC 27001 oder Prüfberichte der Cloud-Anbieter

    Was Sie erhalten

    • Landing Zone, vollständig als Code beschrieben
    • Richtlinienbibliothek mit geregeltem Ausnahmeprozess
    • Entscheidungspapier zu Souveränitätsoptionen je Anwendungsklasse

  2. 02 Infrastructure as Code und interne Entwickler­plattformen

    Infrastruktur beschreiben wir mit Terraform, OpenTofu oder Bicep, ausgeliefert wird per GitOps. Je nach Bedarf läuft das auf Kubernetes oder einer verwalteten Laufzeit. Golden Paths sorgen dafür, dass ein Team einen Service, der allen Vorgaben entspricht, ohne Ticket-Pingpong in Gang bringt.

    Was wir tun

    • Modulbibliothek für Infrastructure as Code
    • GitOps mit Stufen von Umgebung zu Umgebung
    • Kubernetes-Plattform oder verwaltete Alternativen
    • Service-Vorlagen und ein Entwicklerportal

    Was Sie erhalten

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

  3. 03 Auslieferungs-Pipelines und Sicherheit der Lieferkette

    Gebaut wird genau einmal. Danach trägt jedes Artefakt eine Signatur und einen Herkunftsnachweis gemäß SLSA, Zugangsdaten liegen in einem Tresor, und vom Test bis zur Produktion wandert stets dasselbe Artefakt.

    Was wir tun

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

    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 der Fachseite vereinbart sind, Fehlerbudgets, die das Release-Tempo steuern, OpenTelemetry über alle Schichten und ein Incident-Prozess, der zugleich die Meldepflichten nach NISG 2026 und DORA abdeckt, wo diese für Sie gelten.

    Was wir tun

    • Festlegung der SLOs mit den Verantwortlichen der Services
    • Instrumentierung mit OpenTelemetry und Dashboards
    • Alarme auf Symptome statt auf Ursachen
    • Incident-Management und Nachbesprechungen

    Was Sie erhalten

    • SLO-Katalog
    • Observability-Stack und Dashboards
    • Runbooks für Vorfälle und Meldungen

  5. 05 FinOps und KI-Kapazität

    Kosten, die Produkten und Teams zugeordnet sind, Stückkosten wie die Kosten je Transaktion sowie Planung und Kostenkontrolle für GPU-Kapazität bei KI-Anwendungen.

    Was wir tun

    • Tagging-Regeln und Zuordnungsmodell
    • Stückkosten-Kennzahlen je Produkt
    • Planung von Zusagen und Reservierungen
    • GPU-Zuteilung, Kontingente und passende Dimensionierung

    Was Sie erhalten

    • Kosten-Dashboards für jede Produktverantwortung
    • Einsparungs-Backlog mit Zuständigen
    • Kapazitätsplan für KI

  6. 06 Wiederanlauf und Ausstieg

    Backup und Notfallwiederherstellung mit ausdrücklich festgelegter Wiederanlaufzeit und maximalem Datenverlust, regelmäßig getestet, dazu eine Ausstiegsstrategie, die die Wechselrechte aus dem EU Data Act nutzt.

    Was wir tun

    • RTO und RPO je Service vereinbart
    • Tests für Rücksicherung und Failover
    • Abhängigkeiten der kritischen Services erfasst
    • Exit-Plan und Prüfung der Datenportabilität

    Was Sie erhalten

    • Erprobte Wiederherstellungsverfahren
    • Berichte über Wiederherstellungstests
    • Dokumentierte Ausstiegsstrategie

03 Architektur

Eine Referenz­architektur zur Orientierung

Am einen Ende steht der Quellcode, am anderen die laufende Anwendung. Unterwegs versieht die Pipeline jedes Build-Ergebnis mit einer Signatur, die Registry akzeptiert ausschließlich Signiertes, und ein GitOps-Controller hebt es regelkonform von einer Umgebung in die nächste.

Das Fundament bildet die Landing Zone mit Organisationsstruktur, Identität, Netzwerk, Schlüsseln, Wiederherstellung und Kostenkontrolle. Sie ist einmal als Code beschrieben, und alle Produktteams nutzen sie gemeinsam.

Schichten in der Zeichnung

Auslieferung
Vom Repository über die Pipeline und das signierte Artefakt bis zum GitOps-Rollout.
Plattform
Die Plattform für Entwicklerinnen und Entwickler, Regeln als Code und die Zielumgebung der Produktteams.
Landing Zone
Struktur, Identitäten, Netz, Schlüsselverwaltung, Wiederanlauf, Kostensteuerung.
Betrieb
Telemetrie, SLOs, Fehlerbudgets und Incident Response über alle Ebenen.
Beispiel zur Veranschaulichung

  1. Auslieferung

    • Code- und IaC-Repositories
    • Bauen, signieren, bestätigen
    • 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

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

  4. Betrieb

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

Architektur zur Veranschaulichung, kein System eines Kunden.

Diagramm als Text lesen

Aus den Repositories für Code und Infrastruktur führt der Hauptweg durch Pipelines, die bauen, signieren und Herkunft bestätigen, in eine Artefakt-Registry, von dort zu einem GitOps-Controller und schließlich zu den Anwendungsbereichen der Produktteams.

Golden Paths zu den Pipelines kommen aus der internen Entwicklerplattform. Was der GitOps-Controller ausrollen darf, regeln Richtlinien im Code. Die Anwendungen laufen auf Kubernetes und verwalteten Diensten; selbst verwaltete Schlüssel speisen die Richtlinienebene.

Unten liegt die Landing Zone: Verwaltungsstruktur, Identitäten und Zugriffe, zentrales Netzwerk, Schlüssel, Sicherung und Wiederanlauf, Kostensteuerung. Über allem spannt sich die Observability mit SLOs und Störungsbehandlung.

04 Überlegungen und Grenzen

Technische Überlegungen und Grenzen

  • Souveränität hat Abstufungen

    Wie wir damit umgehen

    Anwendungen ordnen wir nach Schutzbedarf in Klassen und wählen für jede Klasse eine Option: EU-Regionen eines großen Cloud-Anbieters, ein souveränes Cloud-Angebot oder eigene Infrastruktur. Was das an Funktionsumfang, Kosten und Betriebsaufwand bedeutet, halten wir schriftlich fest.

    Grenzen und Abhängigkeiten

    Beim Angebot verwalteter Dienste, KI eingeschlossen, liegen souveräne Clouds oft zurück. Wer dorthin geht, zahlt manchmal mehr oder verzichtet auf Funktionen. Diese Abwägung trifft das Management.

  • Eine Plattform braucht einen Product Owner

    Wie wir damit umgehen

    Die interne Plattform behandeln wir als Produkt mit Nutzerinnen und Nutzern, Roadmap und Rückkopplung, und wir helfen Ihnen beim Aufbau des Teams, das sie betreibt.

    Grenzen und Abhängigkeiten

    Fehlt das Team, wird die Plattform zum Flaschenhals. Lässt sich keines aufstellen, empfehlen wir verwaltete Dienste und so wenig Abstraktion wie möglich.

  • Regulierung prägt den Betrieb

    Wie wir damit umgehen

    Wo das NISG 2026 oder DORA für Sie gelten, sind Einstufung von Vorfällen, Meldefristen und Beweissicherung fester Teil des Incident-Prozesses.

    Grenzen und Abhängigkeiten

    Ob Ihre Organisation erfasst ist und wie die österreichische Umsetzung im Einzelnen greift, klären Ihre Compliance- und Rechtsabteilung.

  • Kostenkontrolle ist Gemeinschaftsarbeit

    Wie wir damit umgehen

    Kosten werden pro Produkt ausgewiesen. Budgets, Kontingente und nächtlich abgeschaltete Testumgebungen setzen zusätzliche Grenzen.

    Grenzen und Abhängigkeiten

    Am meisten spart, wer als Produktverantwortliche oder Produktverantwortlicher an Architektur und Nutzung dreht. Die Plattform allein schafft das nicht.

05 Vorgehen

So arbeiten wir

Fundament legen, ein erstes Team auf den Golden Path bringen, dann die übrigen nachholen.

  1. 01

    Erheben und einstufen

    Wir erfassen Anwendungen, Schutzbedarf, laufende Kosten und die Kontrollen, auf die Ihre Wirtschaftsprüfung oder Revision achtet.

    ErgebnisEinstufung der Anwendungen und Zieloptionen

  2. 02

    Die Landing Zone aufbauen

    Alles als Code, gemeinsam mit der IT-Sicherheit geprüft, mit einem Verfahren für Ausnahmen.

    ErgebnisLanding Zone im Produktivbetrieb

  3. 03

    Ein Pilotteam an Bord holen

    Ein Produktteam wechselt auf den Golden Path; wo es hakt, lernt die Plattform dazu.

    ErgebnisErster Service auf der Plattform

  4. 04

    Ausrollen und übergeben

    Nach und nach steigen weitere Teams um. Das Plattformteam übernimmt, und Wiederanlauftests finden nach festem Kalender statt.

    ErgebnisPlattform-Roadmap und Berichte zu Wiederherstellungstests

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Automatisierung betreibt die Plattform. Entscheidungen, die Risiko oder Kosten tragen, verantworten Menschen.

  • Änderungen an der Produktion sind nachvollziehbar

    In die Produktion gelangt nur, was als geprüfter Commit vorliegt. Damit ist jederzeit belegbar, wer welche Änderung vorgenommen und wer sie abgesegnet hat.

  • Notfallzugriff ist selten und protokolliert

    Ein Notfallzugang gilt nur befristet, braucht eine Begründung und wird im Nachhinein überprüft.

  • Ausnahmen von Richtlinien haben eine Zuständigkeit

    Ausnahmen von einer Leitplanke gibt es nur befristet und nur mit Unterschrift einer namentlich benannten risikoverantwortlichen Person.

  • Die Service-Verantwortlichen setzen die Ziele

    Wiederanlaufziele und Service Levels werden mit der fachlich verantwortlichen Stelle jedes Services 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 rechnet
  • GPU-Knotenpools für KI-Anwendungen
Betrieb
  • OpenTelemetry
  • Prometheus und Grafana
  • Cloud-natives Monitoring
  • Policy-Engines wie OPA

Was hier steht, beschreibt unsere Praxis in der Entwicklung. Eine Partnerschaft mit dem Hersteller oder eine Empfehlung durch ihn folgt daraus nicht.

08 Beispiel

Ein Beispiel zur Veranschaulichung

Beispiel zur Veranschaulichung

Eine gemeinsame Landing Zone für eine Gruppe mit Gesellschaften in drei Ländern

01Ausgangslage
Eine Industriegruppe mit Sitz in Österreich und Tochtergesellschaften in Deutschland und Tschechien betreibt drei getrennte Cloud-Umgebungen mit unterschiedlichen Kontrollen. Jedes Land erwartet Meldungen zu Sicherheitsvorfällen nach eigenem Zeitplan, in Österreich nach dem NISG 2026, und niemand kann die Sicherheitslage der Gruppe auf einen Blick zeigen.
02Was wir bauen würden
Eine Landing Zone als Code mit Richtliniensätzen je Gesellschaft, gemeinsamer Protokollierung und einem Incident-Prozess, der Meldungen je Land einstuft und an die richtige Stelle leitet.
03Wo Menschen entscheiden
Die Sicherheitsverantwortlichen jeder Gesellschaft genehmigen Ausnahmen für ihre Anwendungen; die gemeinsame Grundlinie verantwortet die CISO-Funktion der Gruppe.
04Was wir messen würden
Zeit von der Erkennung eines Vorfalls bis zu seiner Einstufung, Anteil der Anwendungen unter Richtlinienkontrolle und bestandene Wiederherstellungstests je Quartal.

09 Branchenblick

In Ihrer Branche

  • Öffentliche Verwaltung

    Souveränitätsoptionen je Datenklasse, Nachweise für die Sicherheitsvorgaben öffentlicher Auftraggeber und Exit-Pläne, die auch die nächste Ausschreibung nach dem BVergG 2018 überstehen.

  • Finanz­dienst­leistungen

    Digitale operationale Resilienz nach DORA, beaufsichtigt von FMA und OeNB: erprobte Wiederherstellung, Steuerung der IKT-Drittdienstleister und Meldung schwerwiegender Vorfälle als Teil des Betriebs.

Österreich

Nachweise einmal erzeugen, für jede Aufsicht

In Österreich setzt das NISG 2026 (BGBl. I Nr. 94/2025) die NIS2-Richtlinie um. Es gilt seit 1. Oktober 2026, löst das NISG 2018 ab und benennt als zuständige Behörde das Bundesamt für Cybersicherheit (BCS), eine dem Bundesminister für Inneres unmittelbar nachgeordnete Behörde. In Deutschland, Tschechien oder Slowenien unterscheiden sich Anwendungsbereich, Registrierung und Meldedetails.

Banken, Versicherungen und andere Finanzunternehmen kommen unter DORA hinzu, mit eigenen Meldepflichten und eigener Aufsicht über IKT-Drittdienstleister; zuständig ist die FMA, die mit der OeNB zusammenarbeitet. Eine Gruppe mit Gesellschaften in mehreren Ländern braucht deshalb eine Plattform, die jeder Behörde die verlangten Nachweise liefern kann.

Unsere Landing Zones behandeln Datenstandort, Protokollierung und Einstufung von Vorfällen als Richtlinien, nicht als Einzelprojekte. Eine neue Gesellschaft oder ein neues Land kommt so per Konfiguration dazu. Exit-Pläne stützen sich auf die Wechselrechte aus dem EU Data Act und werden geprobt, nicht nur aufgeschrieben.

Fragen zu Cloud und Platform Engineering

Welchen Cloud-Anbieter empfehlen Sie?

Den, der zu Ihren Anwendungen, laufenden Verträgen und Souveränitätsvorgaben passt. Ob großer Anbieter oder souveränes EU-Angebot: Wir halten die Gründe schriftlich fest, sodass die Wahl im Vergabeverfahren hält und sich später neu bewerten lässt.

Brauchen wir Kubernetes?

Nicht unbedingt. Erst bei vielen Services und einem eigenen Plattformteam rechnet sich Kubernetes. Bei wenigen Services fahren Sie mit verwalteten Container- oder Serverless-Angeboten meist einfacher und billiger.

Wie gehen Sie an Sicherheit heran?

Wir verankern sie in Landing Zone und Pipelines, mit knapp bemessenen Rechten, Regeln als Code, signierten Artefakten und Zugangsdaten außerhalb des Quellcodes. Das Informationssicherheits-Managementsystem von FromNine ist nach ISO/IEC 27001 zertifiziert.

Können Sie unsere Cloud-Kosten senken?

In aller Regel ja, einen Prozentsatz versprechen wir aber erst, wenn wir die Daten kennen. Zuerst machen wir die Kosten je Produkt sichtbar, dann arbeiten wir mit den Verantwortlichen, die handeln können, ein Backlog an Einsparungen ab.

Wie vermeiden wir Lock-in?

Drei Dinge helfen: Abhängigkeiten von herstellerspezifischen Diensten nur bewusst eingehen, die gesamte Infrastruktur als Code führen, einen geprobten Exit-Plan aktuell halten. Der EU Data Act gibt Ihnen das Recht zu wechseln; nutzen können Sie es nur mit so einem Plan.

Zeigen Sie uns Ihre nächsten drei Releases

Sie erfahren, was es für Routine-Releases bräuchte und welche Kosten das Fundament in Aufbau und Betrieb verursacht.

Erstgespräch anfragenArchitektur & Beratung entdecken