Überdenken von Support-Modellen für eine Cloud-native Welt

Josh Prewitt

abstract futuristic image

Die meisten IT-Teams liegen irgendwo zwischen​ dem traditionellen IT-Betrieb und modernen, Cloud-nativen Arbeitsweisen. Zu den definierenden Merkmalen des traditionellen IT-Betriebs gehören: klare Übergaben zwischen Entwicklung und Betrieb​, Betonung von Infrastruktur und Betrieb sowie ein Entwicklungs- und Release-Ansatz nach dem Wasserfallprinzip. Um sich zu einem Cloud-nativen Betriebsmodell zu entwickeln, darf es keine Grenzen zwischen Entwicklung und Betrieb geben. An dieser Stelle kommt DevOps ins Spiel.

Ein DevOps-Ansatz verwischt die Grenze zwischen Entwicklung und Betrieb und ermöglicht es Ihnen, echte Ergebnisse zu erzielen. Als Teil der Verlagerung in Richtung Cloud Native sollte der Fokus weiter nach oben auf die Anwendungen verlagert werden, damit diese die Infrastrukturentscheidungen diktieren und nicht umgekehrt. Bildlich gesprochen: die Anwendungen sitzen auf dem Fahrersitz, während die Infrastruktur der Beifahrer ist.

 

Gefangen in alten Mustern

Viele Unternehmen arbeiten in der Cloud immer noch so, als wäre sie ein Rechenzentrum. Wir bekommen oft Fragen zu Patching und Backups. Das sind Konzepte, die in einer Cloud-nativen Anwendung ganz anders gehandhabt werden sollten als in einer, die in Ihrem Rechenzentrum läuft. Um den puren Zustand eines „Cloud-Native-Nirvana“ zu erreichen, müssen sich Kunden bewusster von einem traditionellen VM-zentrierten Ansatz wegbewegen.

Ein Teil des Problems ist, dass Sie wahrscheinlich von Ihren MSP-Partnern zurückgehalten werden. Traditionelle MSPs wurden für die alte Welt konzipiert. Es gibt keinen Anreiz für sie, Ihre Entwicklung zu fördern. Vielmehr sind sie darauf ausgelegt, die Lücken in isolierten Entwicklungs- und Betriebsbereichen zu füllen, wobei sie sich gleichzeitig durch eng definierte und SLA-basierte Verantwortungsbereiche auszeichnen. Die Wahrheit ist, dass das klassische IT-Supportmodell zwangsmäßig auf die Grenzen der Vergangenheit beschränkt ist.

 

Wie MSPs die Evolution fördern können

Wenn Unternehmen zu einem Cloud-nativen Modell übergehen, bauen sie oft kleine Teams mit hoher Verantwortlichkeit auf, die für den gesamten Lebenszyklus der Anwendung zuständig sind. Die Support-Modelle müssen sich ändern, um Services bereitzustellen, die diese Teams angemessen unterstützen. Diese Services sollten mehr wie technische Dienstleistungen und weniger wie ein reines Betriebsmodell gestaltet sein. Dabei sollten sich diese technischen Dienstleistungen an den Initiativen des Kunden orientieren und nicht an willkürlichen SLAs.

Es liegt in der Natur der Cloud-Engineering-Arbeit, dass sie ein fortlaufendes Engagement sein sollte. Es gibt immer etwas, das automatisiert oder behoben werden kann. Support-Modelle müssen flexibel sein und sollten sich nahtlos in die Kundenteams integrieren lassen. Nur dann kann ein MSP vollständig auf die Ziele des Kunden ausgerichtet sein und Erweiterungen auf die richtige Weise bereitstellen.

 

Langsames Loslassen der Vergangenheit

Sich entwickelnde IT-Organisationen benötigen ein ​modernes Cloud-Support-Modell, das sich von den abgeschotteten Grenzen der Vergangenheit löst​, Anwendungen gegenüber der Infrastruktur in den Vordergrund stellt und ihre Teams zu einem agilen, DevOps-getriebenen Ansatz für den IT-Betrieb führt.

Zudem sollte es die Aufgabe von MSPs sein, Kunden dabei zu helfen, das VM-Management aus jeder Anwendung zu entfernen, die mehr und mehr Cloud-nativ wird. Die älteren VM-Management-Aufgaben werden ein hohes Maß an Unterstützung benötigen, um sicherzustellen, dass sie korrekt gehandhabt werden. Mit integrierten und hochspezialisierten Teams, die an derselben Mission arbeiten, wird der Weg in Richtung Cloud Native allerdings viel klarer werden.

 

Wie kann Rackspace Technology diese neue Welt unterstützen?​

Die Weiterentwicklung zu einem cloud-nativen​ Ansatz erfordert eine neue Denkweise. Wir führen eine neue Support-Herangehensweise ein. Weiteres folgt am 15. April.

 

Revolutionieren Sie Ihr Support-Modell