Keine Anbieterbindung – unser Prinzip
Wir glauben: Kunden sollten bleiben, weil sie möchten – nicht, weil sie müssen.
Lock-in ist kein Geschäftsmodell, das wir verfolgen. Gleichzeitig wissen wir, dass nicht jede technische Lösung völlig unabhängig sein kann. Deshalb dokumentieren wir hier klar, wie wir mit dem Thema umgehen – heute und in Zukunft.
Was wir unter „Anbieterbindung“ verstehen
Eine Anbieterbindung (Vendor Lock-in) liegt dann vor, wenn ein Wechsel des Dienstleisters schwer, teuer oder technisch nicht machbar ist – etwa weil:
- proprietäre Tools eingesetzt werden, die nicht zugänglich oder dokumentiert sind
- zentrale Komponenten nicht übergeben werden können
- Setups oder Prozesse stark auf einen Dienstleister zugeschnitten sind
Eine ausführliche Begriffsdefinition finden Sie im Glossar-Eintrag „Vendor Lock-in“.
Unser Ansatz: offen, nachvollziehbar, verantwortungsvoll
Infrastruktur im Auftrag, nicht als Besitzmodell
Wenn wir Infrastruktur für Kund:innen bereitstellen, geschieht das stets in einem dedizierten Kontext – technisch und organisatorisch getrennt, dokumentiert und jederzeit übertragbar.
Das bedeutet:
- Kein Mischbetrieb zwischen Kundensystemen
- Übergabe bei Projektende möglich
- Zugriff auf Konfigurationen, Daten und Betriebsparameter
Gemeinsame Plattformdienste (wenn sinnvoll)
Einzelne Services – etwa Monitoring, Metriken oder Datenbanken – können mandantenfähig betrieben werden.
Wir achten auf:
- klare Trennung auf Daten- und Zugriffsebene
- Exportmöglichkeiten für spätere Migrationen
- transparente Kommunikation, falls ein Dienst nicht dediziert betrieben wird
Die Entscheidung für gemeinsame Infrastruktur erfolgt nie ohne Absprache.
Eigene Plattform – aber keine Einbahnstraße
Unsere Infrastruktur wird über eine eigene, intern entwickelte Plattform automatisiert provisioniert – für Konsistenz, Sicherheit und Geschwindigkeit.
Dabei gilt:
- Unsere Tools sind nicht öffentlich, aber ihre Wirkung ist dokumentiert.
- Sie basieren auf offenen Standards wie Kubernetes, Helm, Git.
- Ein Wechsel ist auch ohne unsere Toolchain möglich.
Wir verwenden eigene Werkzeuge – aber wir schließen niemanden aus.
Unser IaC-Framework – gegen Cloud- und Anbieterbindung
Unsere eigene IaC-Lösung ist explizit darauf ausgelegt, technische Abhängigkeiten zu reduzieren – gegenüber einzelnen Hyperscalern oder Infrastrukturanbietern.
- Wir können Infrastruktur jederzeit zwischen Bare Metal, VMs und Cloud-Plattformen migrieren.
- Konfigurationen sind modular, portabel und automatisierbar.
- Backups (z.B. mit Velero) ermöglichen schnelle Wiederherstellung ganzer Cluster in Minuten.
- Der aktuelle Systemzustand ist dokumentiert und auf neuen Infrastrukturen reproduzierbar.
Unser Ziel: maximale Kontrolle – unabhängig vom Hosting-Modell.
Exit-Strategien & Übergaben
Wir begleiten unsere Kund:innen auch bei der Übergabe:
- übergabe von Rechten, Konfigurationen, Secrets und Betriebsdaten
- unterstützung bei Export, Snapshot-Erstellung und Replikation
- dokumentierte Prozesse – transparent und vertraglich abgesichert
Verantwortung heißt für uns: auch gut gehen können.
Unser Grundsatz
Wir betreiben Infrastruktur so, dass sie auch ohne uns funktioniert.
Und wenn sie mit uns funktioniert: umso besser.
Technische Details für Infrastrukturverantwortliche
- Provisionierung erfolgt primär über unsere eigene Toolchain.
- Deployments sind versioniert und in Git dokumentiert.
- Secrets und Konfigurationen sind verschlüsselt und übertragbar.
- Logs, Monitoring, Container Registry und CI/CD-Artefakte können dediziert oder mandantenfähig betrieben werden.
- Der Systemzustand ist jederzeit exportierbar und reproduzierbar.
Fragen zu einem konkreten Setup?
Jetzt Kontakt aufnehmen
