Cloud-native versus On-Premise-Anwendungen
Cloud-native Anwendungen basieren auf einer grundlegend anderen Architektur als traditionelle Unternehmensanwendungen. Die Unterschiede lassen sich an verschiedenen Punkten festmachen:
Programmiersprachen
On-Premise-Anwendungen sind heute typischerweise in traditionellen Sprachen wie C, C++, C# oder auch Java Enterprise geschrieben. In Mainframe-Umgebungen laufen noch etliche Cobol-Programme.
Cloud-native Anwendungen basieren auf Web-orientieren Sprachen und Entwicklungsumgebungen. Dazu gehören etwa HTML, CSS, JavaScript, .Net, Go, Node.js, PHP, Python und Ruby.
Update-Fähigkeit
Cloud-native Anwendungen sind schon systembedingt stets auf dem neuesten Stand und immer verfügbar. On-Premise-Applikationen hingegen benötigen zum Teil aufwändige Updates. Während diese installiert werden, ist die Anwendung nicht nutzbar.
Elastizität
Cloud-native Applikationen profitieren von der Elastizität der Cloud, wenn sie etwa bei Lastspitzen zusätzliche Ressourcen in Anspruch nehmen. Benötigt eine E-Commerce-Anwendung beispielsweise bei erhöhter Nachfrage mehr Rechen- und Speicher-Ressourcen, werden diese automatisch bereitgestellt. Flaut die Nachfrage ab, werden sie wieder heruntergefahren. On-Premise-Apps könne diese Art der dynamischen Skalierung in der Regel nicht bieten.
Mandantenfähigkeit
Eine Cloud-native Anwendung hat keine Probleme, in einer virtuellen Umgebung IT-Ressourcen mit anderen Programmen zu teilen. Viele On-Premise-Applikationen arbeiten entweder nicht besonders gut oder überhaupt nicht in einer virtualisierten Infrastruktur.
Verbundene Ressourcen
On-Premise-Programme sind in der Regel fest mit Netzwerk-Ressourcen verbunden. Dazu gehören neben den Netzzugängen selbst auch Security-Features, Zugriffsrechte oder Storage-Systeme. Werden Teile des Programms geändert, können diese "hart codierten" Verbindungen reißen. In der Cloud-native-Welt, in der das Prinzip der losen Kopplung gilt, gibt es solche festen Verbindungen nicht. Anwendungen lassen sich deshalb relativ einfach auch auf andere Plattformen schieben oder mit anderen Infrastruktur-Ressourcen betreiben.
Ausfallzeiten
Generell gibt es in der Cloud mehr Redundanz als in On-Premise-Umgebungen. Fällt ein wichtiges IT-System eines Cloud-Providers aus, kann das Pendant in einer anderen Region dessen Aufgabe übernehmen. Zwar sind auch etliche On-Premise-Systeme durch Failover-Prozesse geschützt. Doch die Wahrscheinlichkeit, dass mit dem Server auch die Anwendung ausfällt, ist hier deutlich höher.
Automatisierung
Vieles in der Cloud läuft automatisiert ab, darunter auch das Application Management. "Die Vorteile einer Cloud-nativen Auslieferung, insbesondere Geschwindigkeit und Agilität, ergeben sich durch stabile und geprüfte Prozesse, die je nach Bedarf von Automatisierungs- und Orchestrierungs-Tools ausgeführt werden", erläutert Splunk-Spezialist Mann. Das alles funktioniere ohne manuelle Eingriffe. Dieses Niveau der automatisierten Verwaltung lasse sich mit On-Premise-Anwendungen nicht erreichen.
Modulares Design
Die meisten On-Premise-Applikationen sind als Monolithen konzipiert. Zwar lagern sie einige Anwendungen in Bibliotheken aus. Doch unterm Strich handelt es sich um eine einzige große Anwendung mit zahlreichen Subroutinen. Cloud-native-Anwendungen sind demgegenüber viel modularer aufgebaut, viele Funktionen in Microservices gekapselt. Diese lassen sich bei Bedarf abschalten oder auch updaten, ohne dafür die gesamte Anwendung herunterzufahren.
Cloud-native: Lift and shift ist nicht genug
Viele Unternehmen mit Cloud-Ambitionen hieven alte On-Premise-Anwendungen einfach unverändert auf eine Cloud-Plattform. Splunk-Experte Mann hält das für einen Fehler: "Wer versucht, bestehende Applikationen, vor allem monolithische Legacy-Systeme, in einem 'Lift-and-Shift'-Verfahren auf eine Cloud-Infrastruktur zu migrieren, wird die mit Cloud-native möglichen Effekte nicht erzielen können."
IT-Verantwortliche sollten stattdessen neue Wege gehen, rät Mann. Das könne etwa bedeuten, neue Cloud-native Anwendungen auf einer modernen Cloud-Plattform zu betreiben. In einigen Fällen lohne es sich, vorhandene Softwaremonolithen aufzubrechen und sie nach Cloud-native-Prinzipien von Grund auf neu zu entwickeln.
Wasserfallmodell hat ausgedient
Verabschieden sollten sich Unternehmen auch von hergebrachten Softwareentwicklungsmethoden. Das klassische Wasserfallmodell eignet sich kaum für Cloud-native-Szenarien. Aber auch agile Methoden dürften in der Praxis oft nicht ausreichen, geben Experten zu bedenken. Hinzukommen müssten neue Ansätze wie eine Entwicklung nach den Prinzipien des Minimum Viable Product (MVP). Eine abteilungsübergreifende Zusammenarbeit erfordert zudem weitreichende organisatorische Veränderungen, wie sie etwa DevOps-Betriebsmodelle mit sich bringen.
Mit Material von IDG News Service
Hintergrund: Cloud Native Computing Foundation
Die Non-Profit-Organisation Cloud Native Computing Foundation (CNCF) setzt auf Open-Source-Software wie Docker und Kubernetes, um Anwendungen fit für einen Einsatz in der Cloud zu machen. Zu den Mitgliedern gehören auch große IT-Player wie Google, Fujitsu und Dell EMC.
Die Initiatoren haben sich die Entwicklung quelloffener Softwarewerkzeuge für "cloud-ready" Applikationen auf die Fahne geschrieben. Microservices-Architekturen und Container-Techniken spielen dabei eine zentrale Rolle. Sie sollen Unternehmen helfen, Cloud-Anwendungen schneller und einfacher zu entwickeln und auszurollen.