Ihre Public-Cloud-Applikationen laufen nicht erwartungsgemäß? Damit sind Sie nicht allein. Im Regelfall betrifft dieses Problem Anwendungen, die mit wenig bis gar keinem Modernisierung- oder Refactoring-Aufwand im Lift-and-Shift-Verfahren in die Cloud gehievt wurden. Das hat zur Folge, dass die Vorteile von Services wie Infrastructure as Code (IaC) oder Cloud-Native Security nicht zur Geltung kommen.

Ursächlich für das Schlamassel dürfte der Cloud-Rush der vergangenen Jahre - insbesondere während der Cororna-Pandemie - sein: Es war angebracht, schnell zu handeln - nachzudenken und zu planen fiel dabei in manchen Fällen unter den Tisch. Dazu kam mancherorts die naive Annahme, die Anwendungsprobleme würden sich unter der "Schirmherrschaft" eines Hyperscalers in Luft auflösen. Vielmehr war das Gegenteil der Fall: Die On-Premises-Probleme wurden durch den Move in die Cloud nur noch verstärkt.

Das Ende vom Lied: Anwendungen zu betreiben, kostet dreimal so viel wie erwartet. In manchen Fällen ist die Performance das Problem, in anderen Security und Governance. Eigentlich müssten diese Funktionen nun nachgerüstet werden.

Schrott-Apps in der Public Cloud: 3 Optionen

Eigentlich. Denn an dieser Stelle stehen Ihnen drei verschiedene Optionen offen. Alle bringen enorme Nachteile mit sich, die Sie für Ihren individuellen Fall mit den Vorteilen abwägen sollten. Fakt ist aber: Jeder Tag, an dem suboptimale Applikationen auf kostenpflichtigen Plattformen laufen, beziehungsweise Ressourcen verschwenden, ist einer zu viel.

Option 1: Nichts tun.

Damit würden Sie die ganze Sache auf die lange Bank schieben. Das bringt lediglich den gefühlten Vorteil mit sich, dass Sie die Sache erst einmal so gut wie möglich verdrängen dürfen.

Die "Logik" dahinter: Wenn Sie etwas gegen diesen Missstand unternehmen, entstehen zusätzliche Kosten und Risiken. Gleiches gilt jedoch auch für die Nachteile dieser Option. Verantwortungsbewusst geht anders - und am Ende werden Sie Millionen investieren müssen. Nur dass in der Zwischenzeit kein Mehrwert für Ihr Unternehmen entsteht.

Option 2: Teilweise modernisieren.

Sie könnten auch nur einzelne App-Funktionen aufrüsten, beziehungsweise vorhandene aktualisieren, um die Vorteile von Public Cloud Services besser auszunutzen. Zum Beispiel könnten Sie einige Systeme auf einen Cloud-nativen Architekturansatz umstellen.

Diese Option bringt im Gegensatz zur erstgenannten auch viele (echte) Vorteile mit sich. Sie können sich nämlich im ersten Schritt auf die drängendsten und teuersten Probleme fokussieren - beispielsweise Ressourcenverschwendung oder unzureichende E/A-Systeme.

Die Nachteile manifestieren sich in den dabei anfallenden Kosten und dem Risiko. Denn um solche Projekte richtig anzugehen, braucht man teure Profis. Und jede Applikation hat dabei ihre ganz eigenen Probleme, die unterschiedliche Lösungen erfordern. Ein Patentrezept gibt es nicht. In meinen Augen ist eine teilweise Modernisierung dennoch oft der beste Ansatz. Denn hier kommen Kosteneffektivität und maximal positiver Effekt zusammen: Der Return on Investment stimmt.

Option 3: Vollständig modernisieren.

Diese Option würde nach sich ziehen, dass Sie Remote-Büros für Entwickler einrichten, fähige Cloud-Architekten einstellen und die Applikationen für die Cloud von Grund auf neu entwickeln müssten. Anders ausgedrückt: Sie reißen alles ein und bauen es komplett neu auf - diesmal aber so, dass Sie die Vorteile der Cloud optimal für sich nutzen zu können.

Der Nachteil liegt auf der Hand: enorme Kosten. Das muss sich rechnen - was es nicht in jedem Fall tun wird. Bevor Sie diese Option wählen, sollten Sie also prüfen, ob viele Teilmodernisierungsprojekte nicht eventuell den besseren Weg zum Ziel darstellen. (fm)

There is no cloud
by u/Fusion89k in ProgrammerHumor

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.