Managed Application: Wenn Hosting allein nicht reicht
Die Plattform läuft, das SLA gilt — und trotzdem ist die Anwendung nachts um drei kaputt. Warum wir mit Ebene 09 auch den Code übernehmen, wo die Grenze zu Managed Portainer liegt und was CTO und DevOps as a Service im Alltag bedeuten.
Jede unserer Ebenen zieht eine klare Linie: bis hierhin wir, ab hier Sie. Bei Managed Portainer (Ebene 07) endet unsere Verantwortung an der Deploy-Oberfläche, bei Managed Services (Ebene 08) am Endpoint der Datenbank. Das ist ehrlich — und für viele Teams genau richtig. Aber es gibt einen Fall, in dem diese Linie zum Problem wird: wenn niemand mehr auf der anderen Seite steht.
Das Muster: die Anwendung ohne Zuhause
Die Agentur, die das System gebaut hat, gibt es nicht mehr. Der Entwickler, der es kannte, ist gegangen. Die Abhängigkeiten sind drei Major-Versionen alt, die CI-Pipeline läuft gelb, und das Deployment ist ein Ritual mit fünf manuellen Schritten. Das Hosting darunter ist tadellos — und trotzdem ruft nachts um drei jemand an, weil der Checkout hängt. Wir haben dieses Muster so oft gesehen, dass wir ihm eine eigene Ebene gegeben haben.
Ebene 09: das SLA reicht bis in den Code
Managed Application heißt: Wir übernehmen die Anwendung selbst. Repository, Deployments, Fehlerbehebung, Dependency-Updates, Monitoring auf Anwendungsebene — und wenn neue Anforderungen kommen, die Weiterentwicklung. Der Unterschied zu allen anderen Ebenen ist der Verantwortungsübergang: Ein Fehler in der Software ist auf Ebene 09 unser Incident, mit Reaktionszeiten, die für die Anwendung gelten und nicht nur für den Server darunter.
Drei Wege hinein
Nicht jedes Unternehmen braucht das ganze Paket. Deshalb gibt es Ebene 09 in drei Ausprägungen, die sich kombinieren lassen. CTO as a Service: technische Führung tageweise oder im Retainer — Architekturentscheidungen, Technologie-Auswahl, Team-Aufbau, Reviews, als Sparringspartner der Geschäftsführung. DevOps as a Service: Wir sind die DevOps-Abteilung — Pipelines, Umgebungen, Deployments, Incident Response — während Ihr Team weiter selbst Code schreibt. Und Softwareentwicklung: neue Anwendungen, Weiterentwicklung oder die Übernahme bestehender Systeme, umgesetzt in unserer Produktschmiede Ambos Development.
Wie eine Übernahme abläuft
Eine fremde Codebase übernimmt man nicht per Vertrag, sondern per Einarbeitung. Wir beginnen mit einem technischen Blick unter NDA: Repository, Build, Deployments, Infrastruktur, offene Risiken. Daraus entsteht ein Plan in drei Phasen — erst den Betrieb absichern (reproduzierbare Builds, automatisiertes Deployment, Backups, Monitoring), dann aufräumen (Abhängigkeiten, Tests, Dokumentation), dann weiterentwickeln. Erst wenn Phase eins steht, geben wir ein SLA auf die Anwendung. Alles andere wäre ein Versprechen ohne Grundlage.
Warum das nur als Consultancy-Hoster funktioniert
Ein reiner Hoster kann Ebene 09 nicht anbieten — ihm fehlt das Entwicklungsteam. Eine reine Agentur kann sie nicht garantieren — ihr fehlt die Infrastruktur darunter. HOST SMITH ist aus einer Produktschmiede gewachsen: Wir bauen seit Jahren eigene Plattformen und betreiben sie auf denselben Ebenen, die wir Kunden anbieten. Wer Code und Cluster aus einer Hand verantwortet, hat keine Schnittstelle mehr, an der sich zwei Dienstleister gegenseitig die Schuld zuschieben.
Kurz: Die Ebenen 01 bis 08 nehmen Ihnen die Infrastruktur ab. Ebene 09 nimmt Ihnen die Sorge um die Anwendung ab. Ob das für Sie passt, klären wir in einem halbstündigen Gespräch — und wenn nicht, sagen wir Ihnen auch, welche Ebene stattdessen die richtige ist.
Ça ressemble à votre setup ?
Nous construisons et exploitons exactement ce type d'environnements au quotidien. Dites-nous où vous en êtes — et nous vous dirons honnêtement ce qui est pertinent pour votre cas et ce qui ne l'est pas.