Foto: SevenMaps - shutterstock.com
Die Auguren von Gartner prognostizieren in einer Studie, dass bis zum Jahr 2025 mehr als 95 Prozent der Anwendungs-Workloads auf Cloud-nativen Plattformen laufen werden. Gegenüber dem Jahr 2021 wäre das eine Steigerung um 65 Prozent. Ich glaube persönlich nicht an diese Prophezeihung, da die Akzeptanz neuer Technologien nicht linear verläuft.
Wenn Sie immer noch verwirrt darüber nachsinnen, was "Cloud Native" eigentlich bedeutet, sind Sie damit nicht allein. Meine Definition: Cloud-native Entwicklung ist der Prozess, Anwendungen in einer Cloud-Umgebung zu entwerfen, zu erstellen und auszuführen. Dabei werden die Vorteile, Architekturmuster und Fähigkeiten der Cloud genutzt, um Performance, Skalierbarkeit und Kosteneffizienz zu optimieren. Anders ausgedrückt: Alles wird so bereitgestellt, dass Cloud-ähnliche Funktionen zur Verfügung steht - ob es nun in der Cloud läuft oder nicht.
"Verkauft" wird der Cloud-Native-Ansatz vor allem über seine offensichtlichen Benefits:
schnellere Markteinführung,
höhere Agilität und Flexibilität sowie
verbesserte Skalierbarkeit und Zuverlässigkeit.
Cloud-Native markiert einen grundlegenden Wandel der Art und Weise, wie Software entwickelt, bereitgestellt und gemanagt wird. Dabei sollen Unternehmen die Möglichkeiten der Cloud voll ausschöpfen und so Innovation und Wachstum vorantreiben können.
3 Cloud-Native-Nachteile
Ohne Zweifel bietet die Entwicklung Cloud-nativer Applikationen zahlreiche Vorteile. Sie hat aber auch ihre Schattenseiten - die allzu oft und gerne übersehen werden. Je mehr Workloads unter einem Cloud-Native-Ansatz bereitgestellt werden, desto offensichtlicher treten die Nachteile zutage. Beachten Sie dabei bitte, dass ich hier nicht gegen die Cloud-Native-Technologie an sich argumentiere. Ich möchte lediglich unterstreichen, dass bei der Entscheidung über den Move zu einem Cloud-Native-Ansatz auch dessen potenzielle Nachteile Berücksichtigung finden müssen.
Die folgenden drei Punkte sollten Sie sich deshalb in diesem Zusammenhang bewusst machen:
Vendor Lock-in ist eines der Hauptprobleme bei einer Cloud-nativen Entwicklung und Bereitstellung. Wenn eine Anwendung für einen bestimmten Cloud-Anbieter entwickelt und bereitgestellt wird, verwenden Sie in der Regel die nativen Funktionen dieses Cloud-Anbieters. Zu einem anderen Anbieter oder einer lokalen Plattform zu wechseln, kann schwierig und kostspielig sein. Das schränkt wiederum die Flexibilität des Unternehmens in Bezug auf den Ort, an dem es seine Anwendungen ausführt, ein - und steht im Widerspruch zur Portabilität als Kern-Feature der Cloud-Native-Entwicklung. Das Gros der Cloud-Native-Verfechter gibt sich dennoch der Illusion hin, dass Vendor Lock-in kein Thema ist.
Zudem kann Cloud-Native einen Skills Gap hervorrufen: Auf diese Art und Weise zu entwickeln, kann komplex sein und erfordert unter Umständen andere Skills und Tools als traditionelle On-Premises- oder Public-Cloud-Entwicklungsprojekte. Insbesondere für Unternehmen, die mit Cloud-nativen Verfahren noch keine oder nur unzureichend Erfahrung gesammelt haben, entstehen an dieser Stelle Herausforderungen, die zum Beispiel zusätzliche Schulungsmaßnahmen oder weitere Ressourcen erfordern. Im Ergebnis stehen schlecht konzipierte und übermäßig komplexe Anwendungen.
Darüber hinaus können Unternehmen durch Cloud-Native-Projekte explodierende Kosten drohen: Die nutzungsabhängige Preisgestaltung der Cloud kann zu unerwarteten Mehrkosten führen, wenn eine Anwendung einen sprunghaften Traffic-Anstieg verzeichnet. Unternehmen sind deshalb gut beraten, ihre Cloud-Nutzung sorgfältig zu überwachen und entsprechend zu planen, um Budgetüberschreitungen zu verhindern. Ich kann an dieser Stelle nur dringend empfehlen, keine Cloud-nativen Applikationen ohne ein solides Finops-Programm bereitzustellen.
Nur wenn sich Unternehmen dieser potenziellen Nachteile bewusst sind, können sie entsprechend planen, um vollumfänglich von den Cloud-Native-Vorteilen zu profitieren. Ist das nicht der Fall, sind die Risiken unberechenbar. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.