Transformation · Hosting
Die Plattform, auf der digitale Lösungen verlässlich weiterlaufen.
Somos-Co entwirft, übernimmt und betreibt technische Plattformen als Teil einer vollständigen Lösung. Hosting verbindet Runtime, Auslieferung, Beobachtbarkeit, Wiederherstellung und Infrastrukturverantwortung – passend zum tatsächlichen Betriebsmodell.
Plattformfluss
Vier verbundene Plattformebenen: Delivery-Pipeline, Runtime, Beobachtbarkeit und Wiederherstellung.
Delivery-Pipeline
Runtime-Plattform
Beobachtbarkeit
Wiederherstellung
Technisches Fundament
Hosting ist Plattformverantwortung, nicht nur bereitgestellte Infrastruktur.
Eine betriebsfähige Lösung braucht mehr als Rechenleistung. Sie braucht einen kontrollierten Auslieferungsweg, sichtbaren Zustand, definierte Sicherheitspraktiken und eine vorbereitete Wiederherstellung.
Passende Plattform
Cloud-, Container- und Infrastrukturentscheidungen folgen den Anforderungen der Lösung und des Betriebsmodells.
Kontrollierte Auslieferung
CI/CD und Deployment-Prozesse machen Änderungen nachvollziehbar, wiederholbar und steuerbar.
Vorbereiteter Betrieb
Monitoring, Backup, Restore und dokumentierte Verantwortungen werden als Bestandteil der Plattform ausgelegt.
Hosting- & Plattformfähigkeiten
Die technische Umgebung als zusammenhängendes System betreiben.
Die Bausteine werden nach Architektur, Risiko und Verantwortungsmodell ausgewählt. Nicht jede Lösung benötigt dieselbe Plattform.
Cloud Hosting
Anwendungs- und Datenkomponenten in einer passend ausgelegten Cloud-Umgebung bereitstellen.
- Cloud-Ressourcen
- Umgebungsdesign
- Betriebsübergabe
Managed Kubernetes
Containerisierte Workloads auf Kubernetes oder K3s mit dokumentierten Betriebsabläufen führen.
- Kubernetes & K3s
- Container-Plattform
- Workload-Betrieb
Platform Engineering
Wiederverwendbare Plattformbausteine und klare Wege von der Entwicklung in den Betrieb schaffen.
- Plattformbausteine
- Developer Workflows
- Konfigurationsmanagement
CI/CD & Deployment
Build-, Prüf- und Auslieferungsschritte nachvollziehbar automatisieren und kontrollieren.
- CI/CD
- Deployment-Prozesse
- Release-Steuerung
Monitoring & Observability
Plattform- und Anwendungssignale für Betrieb, Fehleranalyse und Kapazitätsentscheidungen nutzbar machen.
- Monitoring
- Alerting
- Logging
Backup & Recovery
Datensicherung und Wiederherstellung als überprüfbare Betriebsabläufe vorbereiten.
- Backup
- Restore
- Wiederherstellungsabläufe
Security Baseline
Zugriff, Secrets, Netzwerkpfade und technische Härtung nach einer dokumentierten Basis ausrichten.
- RBAC
- Secrets Management
- Network Policies
Infrastructure Management
Infrastrukturzustand, Konfiguration und technische Änderungen über den Lebenszyklus steuern.
- Konfiguration
- Infrastruktur-Updates
- Technische Dokumentation
Plattform-Topologie
Wie eine Änderung in den Betrieb kommt – und wie eine Anfrage die Anwendung erreicht.
Bewusst abstrakt: Das Diagramm zeigt die Form des kontrollierten Delivery- und Anfragepfads, nicht die reale Topologie, keine Hosts, Versionen oder Konfigurationen. Jeder Knoten lässt sich auswählen und erklärt sich darunter.
Ablauf
- Delivery
- Anwendung online
- Anfrage
- Betrieb
Entwicklungsumgebung · Delivery 1/3Ausgangspunkt einer Änderung: Entwicklung und lokale Prüfung, bevor sie in den definierten Delivery-Prozess übergeht.
CI/CD · Delivery 2/3Änderungen laufen über die definierte Pipeline — bauen, testen und versionieren — bevor sie in die Zielumgebung gelangen.
Deployment · Delivery 3/3Der kontrollierte Schritt in die Umgebung: definierte Deployment-Prozesse statt manueller Eingriffe.
Internet · Anfrage 1/3Der öffentliche Einstieg. Alles dahinter läuft über einen kontrollierten Traffic-Pfad.
Edge / Origin Shield · Anfrage 2/3Edge- und Origin-Shield-Layer vor dem Cluster — der Anfragepfad beginnt nicht direkt an der Anwendung.
Ingress · TLS · Anfrage 3/3Ingress mit TLS-Terminierung und Routing bildet den kontrollierten Pfad zur Anwendung.
K3s-Cluster · SystemgrenzeDie Kubernetes- bzw. K3s-Umgebung, abgegrenzt über RBAC und Network Policies.
Namespace · SystemgrenzeDer abgegrenzte Bereich im Cluster, in dem die Anwendung läuft. Network Policies, RBAC und Network Segmentation wirken auf dieser Grenze.
Anwendung · Ziel beider WegeDie betriebene Anwendung, containerisiert im eigenen Namespace. Beide Wege — Anfrage und Delivery — enden hier.
Monitoring · BetriebskanalMonitoring und Alerting machen den Systemzustand sichtbar; Incident-Workflows sind dokumentiert.
Backup / Restore · BetriebskanalBackup und Restore als dokumentierter Teil des Betriebsmodells.
Der Ablauf beginnt in der Entwicklungsumgebung. Eine Änderung läuft von dort über CI/CD und einen kontrollierten Deployment-Schritt in die Anwendung, die danach online ist. Anschließend verläuft der Anfragepfad vom Internet über einen Edge- und Origin-Shield-Layer zum Ingress mit TLS-Terminierung und von dort zur Anwendung. Im Betrieb machen Monitoring und Alerting den Systemzustand sichtbar; Backup und Restore sind Teil des Betriebsmodells. Der Cluster ist über RBAC und Network Policies abgegrenzt.
Einordnung
Kubernetes ist kein eigenständiges Produkt.
Kubernetes ist eine mögliche technische Grundlage innerhalb von Platform Services und Hosting. Wir setzen es dort ein, wo Architektur, Skalierung und Betriebsmodell davon profitieren – nicht als Selbstzweck.
OT/IT-Betriebsgrenze
Den geeigneten Betriebsort je Komponente wählen
Zeitkritische Steuerung bleibt dort, wo Prozess und Sicherheitsanforderungen sie benötigen. Daten-, Integrations-, Monitoring- und Managementkomponenten werden im jeweils geeigneten Edge-, On-Premises- oder Cloud-Modell betrieben.
- 01
- 02
- 03
Im Transformationssystem
Betrieb, Hosting und kontinuierliche Verbesserung bleiben verbunden.
Operations verantwortet die Lösung im Alltag. Hosting stellt die technische Umgebung und den Auslieferungsweg bereit. Erkenntnisse aus beiden Stufen fließen in die kontinuierliche Verbesserung zurück.
Vorher
Betrieb
Aktuelle Stufe
Hosting
Nächste Stufe
Kontinuierliche Verbesserung
Problem Check
Welche geschäftliche Entscheidung braucht eine belastbare Grundlage?
Beschreiben Sie Herausforderung, betroffenen Prozess und Zeithorizont. In einem ersten Problem Check klären wir, welche Fragen ein Dynamic Model beantworten sollte.
Für Anwendungen, Plattformen, IoT- und Digital-Twin-Vorhaben sowie Managed Operations.