Die Erfolgsgeschichte der Cloud ist beeindruckend: Die entscheidenden Meilensteine der Erfolgsgeschichte lassen sich auch schnell zusammenfassen: Mit der sogenannten Multi-Tenant-Software-Architektur wurde Ende der 1990er die Grundlage gelegt; Damit wurde es möglich, dass eine Software gleichzeitig von mehreren Unternehmen über den Browser genutzt werden konnte, ohne das ein Unternehmen jeweils die Daten eines anderen Unternehmens ausspähen konnte. Ein Pionier bei der Anwendung dieses Prinzips war das Unternehmen SalesForce. Nur kurz darauf, Anfang der Nuller-Jahre kam bereits der Begriff Cloud Computing auf, im Jahr 2006 startete Amazon Web Services das Angebot von Cloud-Infrastruktur-Dienstleistungen, einer der vier Hyperscale-Anbieter (neben Azure, Google und IBM). Der Markt erreichte in 2019 ein Volumen von 214 Milliarden US-Dollar.

Das Marktpotential ist aber noch lange nicht ausgeschöpft. In einem Interview mit dem Handelsblatt im Juli 2019 erklärte der CEO von AWS, Andy Jassy, es werden erst 3 Prozent aller IT Aufgaben in der Cloud abgewickelt. “In zehn oder 20 Jahren werden die meisten Unternehmen keine eigenen Rechenzentren mehr haben. Nur Aufgaben, bei denen es auf die Nähe ankommt – zum Beispiel in einer Fabrik – werden künftig noch vor Ort erledigt.“. Die Marktentwicklung gibt ihm Recht: Viele Unternehmen setzen bereits auf Cloud Only, nicht nur auf Cloud First; nicht zuletzt DB Systel setzt seit einigen Jahren eine solche Strategie um. Und während etwa Daimler seine Big Data Analytics in die Azure Cloud migrierte, hält der Autokonzern gleichzeitig an den Rechenzentren in seinen Fabriken fest, um einem Ausfallszenario vorzubeugen.

Zu Grundbegrifflichkeiten Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) vergleiche das Glossar.

Cloud: Die Vorteile

Als Cloud Computing aufkam, war eines der Kernargument, die Nutzung der Cloud sei kostengünstiger als der Betrieb eines eigenen Rechenzentrums. Auf Basis der bisherigen Erfahrung gilt das aber nur in speziellen Fällen. Wer in die Cloud geht, sollte damit rechnen, dass die Kosten über den gesamten Lebenszyklus eher höher liegen. Ausnahmen hiervon sind tendenziell eher Unternehmen mit einer sehr ungleichen Lastverteilung der IT Workload, was die Vorhaltung von Überkapazitäten im eigenen Rechenzentrum erfordert. Unter nachfolgendem Link finden Sie zwei nachvollziehbare Kostenvergleiche zwischen Cloud und Rechenzentrum, und zwar zum einen für ein Forschungs-Cluster, zum anderen für einen SaaS-Anbieter: Kostenvergleich Cloud vs. Rechenzentrum

Wo für Unternehmen bei Kosten aber nichtsdestotrotz ein Vorteil entsteht: Die Kosten / Investitionen verteilen sich anders im Zeitverlauf. Aus CAPEX wird OPEX. Hohe Anfangsinvestitionen entfallen, stattdessen werden monatliche Nutzungsgebühren entrichtet, was etwa Unternehmen mit schwacher Cash Flow Situation entgegen kommt (dazu zählen bekanntermaßen u.a. StartUps).

Was heute vor allem die Marktdynamik des Cloud Computing treibt, ist der Vorteil der Agilität (oder auch: Skalierungsfähigkeit, Flexibilität). Das ist insbesondere relevant für Unternehmen, die ihre IT Infrastruktur in stark wachsenden Märkten hochskalieren können müssen, beispielsweise die Smartphone Bank N26, die zeitweise bis zu 10.000 neue Kunden pro Tag aktiviert haben.

Es kommt hinzu: Entfallen die sunk costs in Form von Anfangsinvestitionen für IT Hardware/Software, dann werden Investitionsanträge und längliche Entscheidungsprozesse hinfällig, das Cloud-Angebot schafft erst die Voraussetzung für eine „Fail fast, Fail cheap“-Unternehmenskultur (oder auch: StartUp Kultur), mit der Unternehmen in den Prozess eine Digitalen Transformation einsteigen können. Denn die Idee für ein Digitales Geschäftsmodell von heute kann sich bereits morgen als erfolglos erweisen und eine andere Idee geht an den Start.

Wer heute außerdem Software-as-a-Service nutzt, reduziert damit erheblich die Bindung an einen Anbieter. Wer nach einem Jahr feststellt, dass etwa ein Anbieter von CRM-Software seine Versprechungen nicht einhält, hat deutlich niedrigere Hürden für einen Wechsel. Ganz trivial ist ein solcher Wechsel natürlich nicht, denn Neu-Investitionen in Einführung, Konfiguration, Datenmigration und Lernkurve bleiben natürlich.

Als weitere Effekt aus Cloud-Migrationsprojekten wird oft genannt, dass damit auch die Nutzung von Automatisierungstechnologien und Infrastrukturangeboten forciert werden. Wenn etwa in Rechenzentren bislang nur wenig Skripting beim Aufbau und Wartung von Rechenzentrumsinfrastruktur genutzt wurde, dann ändert sich das beim Rebuild in der Cloud unmittelbar. Die Migration in die Cloud ist insofern eine effiziente Maßnahme, um verkrustete Strukturen und Prozess in IT Abteilungen aufzubrechen – und es ist anzunehmen, dass eben dieses Momentum auch in dieser Weise genutzt wird.

Cloud: Kosten und Nachteile

Auf den Kostenaspekt für den Betrieb bin ich im vorangegangenen Kapitel bereits eingegangen. Ergänzend sei darauf hingewiesen, dass Unternehmen, die nur eine schmale Bandbreite haben, bei der Umstellung auf Cloud-basierte Services in eine verbesserte Bandbreite investieren müssen.

Wer eine IT Infrastruktur in die Cloud migriert, der braucht natürlich eine ausreichende Anzahl von Infrastrukturspezialisten. Darüber hinaus werden aber auch Anpassungen an den Core-Anwendungen, am Programmiercode erforderlich. Das beginnt mit der Entfernung von hart-kodierten Pfaden, Änderungen der Konnektivität zu externen Systemen und erfordert eine Anpassung des Prozesses zum Upgrade von Bibliotheken. Wird eine Software weitestgehend ohne Änderung in die Cloud migriert, spricht man häufig von Lift and Shift (oder auch: Rehosting). Bereits mit höherem Aufwand verbunden ist das sogenannte Replatforming, auch genannt: Lift, tinker and shift. Hier werden immerhin einige Cloudoptimierungen an der Software vorgenommen, ohne allerdings die Kernarchitektur der Anwendung zu verändern.

Wird eine bestehende Software für die Cloud optimiert – oder sogar neu geschrieben – , dann spricht man vom Re-Architecting. Ergebnis ist dann eine Native Cloud Application (auch: NCA), die eine optimale Skalierung und einfachere Upgrades ermöglicht. Voraussetzung dafür ist eine Software-Architektur, die auf Microservices basiert, eine Software wird stark modularisiert, es handelt sich je um kleine Dienste, die als eigene Prozesse laufen (mit eigener Datenbank und eigenem Storage) und die miteinander über APIs miteinander kommunizieren. Da diese Microservices unabhängig voneinander sind, können Sie in verteilten Umgebungen laufen, zudem kann jeder Microservice in einer eigenen Programmiersprache geschrieben sein. Microservices können in einer Container-Infrastruktur einfach skaliert werden. Wenn etwas ausfällt, betrifft das in der Regel nur das Modul, nicht das Gesamtsystem.

Das Re-Architecting einer ehemals monolithischen Anwendung mit dem Ziel einer Microservice-basierten Architektur ist mit erheblichem Aufwand verbunden. Zwar hat auch eine monolitische Architektur Vorteile (z.B. Performance), aber ist mit klaren Nachteilen auch hinsichtlich Continuous Integration und Delivery verbunden. Wer auf Microservices-basierte Software-Architekturen umstellt, muss in der Regel weitere zusätzliche Herausforderungen bewältigen: Ein angepasster Entwicklungsprozess, einhergehend mit einer neuen Kommunikationskultur. Auch das Testing wird aufwändiger.

Last but not least sei das Entstehen einer Schatten IT genannt, die mit Cloud-basierten Dienstleistungen möglich wird. Denn war VOR der Ära des Cloud-Computing bei IT Anforderungen durch eine Fachabteilung der Gang zur unternehmensinternen IT Abteilung unumgänglich, so kann heute etwa eine Marketing-Abteilung bei Nutzung einer SaaS-Software wie SalesForce oder Sugar CRM diese IT Dienstleistung in Anspruch nehmen, ohne auf die IT Abteilung angewiesen zu sein. Sogenannte Low-Code-Plattformen ermöglichen (bis zu einem bestimmten Grad) auch die Entwicklung von fachbereichsspezifischen Applikationen in Regie durch die Fachabteilung.

Unternehmen müssen hierauf eine praktikable Antwort finden, um einerseits die erforderliche Flexibilität zu ermöglichen und andererseits die Einhaltung bestimmter (Konzern)Richtlinien zu gewährleisten und eine „Verinselung“ der IT Landschaft zu verhindern. Eine Möglichkeit sind beispielsweise „Rapid Reaction Teams“ von Spezialisten aus der IT Abteilung, die mit einer Fachabteilung zusammenarbeiten.

Cloud: Sicherheit

Last but not least ein paar Überlegungen zum Thema Sicherheit. Aus einer rein technologischen Perspektive dürfte die Migration von Daten in einer Public Cloud eines Hyperscale-Anbieters die Sicherheit erhöhen. Warum?

Erstens, ein solcher Hyperscale-Anbieter dürfte als Spezialist für diese Dienstleistung in der Regel mehr Sicherheitsexperten auf seiner Payroll haben als dessen Kunden. Nicht zuletzt deshalb, weil ein erfolgreicher Hacker-Angriff / Sicherheitsvorfall das Geschäftsmodell ganz unmittelbar bedroht. Das bedeutet in der Praxis eine sehr hohe Motivation für hohe Sicherheitsstandards.

Zweitens, tatsächlich erschwert die Multi-Tenant-Architektur das Auffinden von Daten: Während Daten on-premise gespeichert werden, dient die IP Adresse als einfache Orientierung für Hacker zum Lokalisieren der Daten. In der Public Cloud hingegen ist eine solche Orientierung nicht gegeben.

Drittens, etwa 60 Prozent aller Datenleakages werden von Insidern begangen. Die Public Cloud hat hierbei den Vorteil, dass Datenabgriffe immer Spuren hinterlassen: Das dient zur Abschreckung bzw. erlaubt ein einfaches Tracking.

Dieser Vergleich gilt selbstverständlich nur für den Vergleich einer Private Cloud (also: Hosting einer webbasierten Anwendung im eigenen Rechenzentrum) mit einer Public Cloud. Es gibt natürlich auch noch eine (allerdings zurückgehende) Anzahl von on-premise Anwendungen, die nicht remote per Internet zugänglich sind; diese weisen natürlich ein deutlich geringere Risikoprofil auf, ein Cloud-Migration (sei es in die Private Cloud, sei es in die Public Cloud) erhöht hier offenbar das Sicherheitsrisiko deutlich.

Vergleiche auch: Der Technology Stack für Softwareentwicklungsprojekte im Zeitalter von Cloud-Native Companies

Sebastian Zang
Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.