Das Versprechen dynamischer Anwendungen Cloud-native Entwicklung – nicht ganz ohne Tücken

Leicht veränderbare, skalierbare und ohne großen Aufwand erweiterbare Applikationen – Cloud-basiert und damit kostengünstig in Entwicklung und Betrieb. Wer würde das nicht wollen? Das Versprechen von Cloud Native Development ist verführerisch, aber der Hype hat auch seine Tücken.

Wer Cloud-native Development im Unternehmen etablieren möchte, sollte beachten, dass alle traditionellen IT-Strukturen und -Prozesse neu gedacht werden müssen (was aufwändig, aber durchaus erfrischend ist). Diese Prozesse, die ja auch den Kern eines Unternehmens bilden, werden schneller als bisher verändert – ein Kulturwandel, der nicht jedermanns Sache ist.

Cloud-native Development kurz betrachtet

Aber noch einmal einen Schritt zurück – wovon sprechen wir eigentlich? Cloud-native Development und DevOps ist ein Ansatz zur geplanten und automatisierten Entwicklung von Applikationen, der konsequent auf Public Cloud ausgerichtet ist. Das heißt, es wird in der Cloud entwickelt, mit Tools, die in der Cloud bereitgestellt und genutzt werden.

Die großen Vorteile der Entwicklung und Bereitstellung in der Cloud sind Geschwindigkeit und Agilität, schnelleres Feedback an die Entwickler und schnelleres Debugging. Der Schlüssel zu einer schnelleren und zuverlässigeren Softwareentwicklung ist ein DevOps-Prozess in einer Cloud-Umgebung, der sicherstellt, dass Tests und Sicherheit kontinuierlich überwacht werden.

Kurz: die Cloud hat Entwickler effektiver und effizienter gemacht – zumindest in der Theorie. In der Praxis gibt es noch einige Fallen, die auf Kosten von Qualität und Geschwindigkeit gehen können.

Legacy – die ewige Herausforderung

Cloud-native ist vor allem für Unternehmen mit langer Legacy-Historie nicht immer einfach umzusetzen. Die Kluft zwischen den Cloud-nativen Abläufen eines Unternehmens und seinen bestehenden, physisch gehosteten Anwendungen wird mit der zunehmenden Verbreitung von Cloud-Features und -Funktionalität nur noch größer.

Schnelle Releases lassen sich nicht mit veralteter Technologie umsetzen. Dies gilt insbesondere dann, wenn die Anwendungen noch nicht in Container umgewandelt und noch keine Cloud-nativen Äquivalente für Legacy-Komponenten eingesetzt werden. Aber Native Cloud-Development heißt nicht, dass alle monolithischen Systeme sofort verschwinden müssen.

Man kann durchaus einige Applikationen mit einer Microservices-Orientierung entwickeln und allmählich Funktionen, Neuentwicklungen und Legacy-Upgrades in die Cloud verlagern. Als erste Kandidaten bieten sich Funktionen an, die von mehreren Anwendungen gemeinsam genutzt werden oder aber CPU-intensive Funktionen, die eine ganze Anwendung verlangsamen könnten.

Doch Cloud Native kann auch an Mustern scheitern, die noch aus Legacy-Zeiten kommen. Manche Unternehmen konfigurieren und verwalten ihre Cloud-Ressourcen beispielsweise manuell über ein Admin-Panel. Dies macht es schwierig, Änderungen im Auge zu behalten.

Infrastructure-as-Code löst dieses Problem, indem Cloud-Ressourcen in Codeform definiert und unter Versionskontrolle gestellt werden. Änderungen werden dann direkt im Code der Infrastrukturkonfiguration vorgenommen und durch den Bereitstellungsprozess des Unternehmens geleitet, der Peer-Reviews, CI und CD umfassen kann.

Zuweilen werden auch in Cloud-nativen Umgebungen – wie bei Legacy-Systemen – Log-Dateien einzeln gespeichert. Das ist mühsam und die Vielfalt der Logs macht es schwer, zu verstehen, was wirklich im System geschieht. Cloud-native Tools verwenden zu diesem Zweck Zeitreihen-Metriken, die die Monitoring-Daten aggregieren und optimalerweise mit Alerts kombiniert werden.

Die richtigen Tools

Eine Herausforderung ist auch die Bandbreite an Tools: Die Cloud Native-Landschaft ist riesig. Die Auswahl zwischen immer mehr konkurrierenden und sich überschneidenden Plattformen und Technologien ist problematisch.

Hilfestellung bei der Service-Entwicklung leisten spezifische Frameworks und Technologie-Stacks mit gebrauchsfertigen, getesteten Funktionalitäten. Plattformen in der Cloud wie Eficode Roots decken den gesamten Software-Development Lifecycle vom Anforderungsmanagement bis hin zu Continuous Delivery und Analytik ab und bieten bewährte Tools in der jeweils gewünschten Version.

Je höher der Automatisierungsgrad, desto höher die Effizienz. Es reicht nicht, in der Cloud zu arbeiten und nicht durchgängig zu automatisieren. Eine ordnungsgemäße Governance trägt zur Risikominderung bei, aber automatisierte Tests sind die einzige Möglichkeit, dies zu gewährleisten. Unter dem Druck, Services immer schneller zu releasen, vernachlässigen manche Entwickler die Test- und Release-Automatisierung.

Ohne Testing geht es aber eigentlich nicht, wenn die Veröffentlichungszyklen der Microservices kurz sein sollten und die Kompatibilität zwischen den Services nicht garantiert ist. Kurz, alle Checks in Bezug auf Qualität, Konformität und Sicherheit müssen automatisiert und in den Deployment-Prozess integriert werden. Die richtigen Tools auf einer leistungsstarken Plattform erleichtern diese Aufgabe wesentlich.

Gedanken zur Architektur

Bei Cloud-nativen Anwendungen oder Architekturen steigt die Gefahr der Abhängigkeit von einem bestimmten Cloud-Anbieter oder -Service. Allzu einfach lassen sich die Workloads so gestalten, dass sie nicht mehr ohne einen bestimmten Service einer bestimmten Cloud auskommen. Doch gute Planung verringert das Risiko des Cloud-Lock-Ins. Nutzt man aber Community Standards (wie OCCI), können die Workloads dynamisch zwischen den Clouds wandern. Zusätzlich sollte man den Einsatz von sehr speziellen Services meiden.

Doch ein kleines Risiko wird immer bleiben: wer eine Cloud-native Anwendung für eine bestimmte Public Cloud Plattform schreibt, nutzt die nativen APIs dieser Cloud, so dass ein Wechsel ziemlich Arbeit macht. Auch unterstützen die Public Clouds nicht immer dieselben Sprachen und Frameworks– auch hier lohnt ein Blick vorab (Java ist immer eine sichere Wahl).

Auch die Integration von Services kann bei Cloud Native Development zum Problem werden. Selbst wenn ein Service immer – optimalerweise – nur eine einzige Funktion erfüllt und damit die Komplexität möglichst niedrig gehalten wird, kann eine falsche Methode der Bereitstellung auf Kosten der Effizienz gehen. Die Containerisierung der Services ist zwar meist das Mittel der Wahl, doch kann zuweilen eine Verbindung der Services über SPIs oder Serverlose Funktionen die bessere Methode sein.

Datenspeicherung muss man ebenfalls neu denken. Container, serverlose Funktionen und Anwendungen, die mit einem unveränderlichen Infrastrukturmodell bereitgestellt werden, können meist selbst keine Daten speichern. Man muss also Funktion und Datenspeicherung trennen und die Daten extern lagern, mit dem Vorteil einer langfristigen Speicherung und einer Nutzbarkeit durch mehrere Anwendungen.

Viele Anwendungsbereitstellungspipelines laufen immer noch auf traditionellen On-Premises-Umgebungen. Das verzögert die Bereitstellung von Code und macht es schwer, das Verhalten der Applikation unter Live-Bedingungen korrekt vorherzusagen. Verlagert man die CI/CD-Pipeline in eine Cloud-Umgebung wird der Code schneller bereitgestellt und die Testumgebungen entsprechen eher den Produktionsumgebungen.

Die vernachlässigte Security

Cloud-native Anwendungen haben größere Angriffsflächen und mehr logische Teile, die geschützt werden müssen. Microservices und Container können etliche Herausforderungen in Bezug auf Transparenz, Fehlerbehebung und Sicherheit mit sich bringen. Das beginnt damit, alle dynamisch bereitgestellten Microservices zu finden.

Microservices werden von einem Ort zum anderen migriert, zusätzliche Instanzen werden von Microservices bereitgestellt – entsprechend wird es schwieriger, den Überblick darüber zu behalten, wo alle Instanzen zu einem bestimmten Zeitpunkt bereitgestellt werden. Dies zu wissen, ist aber für die Fehlerbehebung entscheidend.

Ein Fehler in einem Service bleibt nicht notwendigerweise isoliert, er kann sich auf die gesamte Anwendung auswirken. Je mehr Dienste es gibt, desto wichtiger wird Testing und Monitoring. Zwar sinkt mit Microservices die Komplexität der Services selbst, aber das damit entstehende verteilte System erhöht die Komplexität auf der Systemebene. Statt einiger weniger Monolithen muss man etliche Microservices mit möglicherweise mehreren parallelen Instanzen überwachen.

Wenn Developer nicht darauf achten, Abhängigkeiten zwischen Microservices zu vermeiden (oder wenigstens die Kommunikation zwischen abhängigen Diensten effizient zu gestalten), wird diese Komplexität überhandnehmen. Das Monitoring darf sich deshalb auch nicht nur auf die einzelnen Services beschränken, sondern muss auch auf die Beziehung zwischen ihnen berücksichtigen.

Spezielle Tools wie Retrace können das Monitoring der Instanzen und das systemübergreifende Sammeln von Informationen übernehmen. Eine weitere Möglichkeit, das Risiko zu minimieren, ist, Fehler und deren Folgen vorherzusagen – nicht einfach in einer dynamischen Umgebung. „Dynamic Baselining“ vergleicht die tatsächlichen Antwortzeiten mit historischen Durchschnittswerten und bietet so einen aussagekräftigen Einblick in Service-Anomalien, ohne absolute Schwellenwerte für jede Transaktion festzulegen.

Aber bei Security gibt es noch mehr klassische Versäumnisse. So übernehmen die Entwicklungsteams zu Beginn eines Projekts in der Regel die Standardeinstellungen für einen Cloud-Service. Aber nicht jede Plattform räumt bei diesen Einstellungen der Sicherheit die höchste Priorität ein. Auch Secrets-Management und -Verschlüsselung (Passwörter, Keys und Anmeldeinformationen etc.) werden trotz seiner entscheidenden Bedeutung vor allem in kleineren Projekten häufig vergessen.

Ein ebenfalls häufiges Versäumnis besteht darin, die Kommunikation zwischen Diensten nicht mit Transport Layer Security (TLS) zu sichern – fatal, denn so kann ein Angreifer den gesamten Datenverkehr zwischen den Diensten lesen. Dies ist auch für Container-basierte Lösungen wichtig, denn es können verschiedene Dienste auf derselben physischen Maschine laufen.

Die optimale Organisation

Die DevOps-Mentalität ist auch auf dem Weg zu Cloud Native entscheidend. Viele Projekte scheitern nicht an der Technologie, sondern an der Kultur im Unternehmen. Ein Beispiel: Cloud Native heißt häufige Releases und damit agile Anforderungserfassung, Design, Architekturüberprüfung, Entwicklung, Tests und Bereitstellung.

Wer in jeder dieser Phasen lange auf Genehmigungen warten muss, kann keine häufigen Releases durchführen. Auch müssen alle im Team dasselbe Ziel vor Augen haben. Was, wenn die Entwicklungsteams ein anderes Verständnis haben als die Test- oder Betriebsteams? Wenn Infrastrukturteams beim Aufbau von Cloud- und Kubernetes-Plattformen die Anforderungen der Entwickler nicht berücksichtigen, wird es Probleme geben. Oft verschwenden die Teams Zeit, Ressourcen und Geld für Funktionen, die nicht benötigt werden oder nicht für die Entwickler passen.

Cloud Native Development heißt auch nicht, dass Fehler notwendigerweise schneller erkannt und behoben werden. Es mag Fehler geben, die sich durch Anwendungen kaskadieren und zu größeren Ausfällen führen. Ganze Projekte können scheitern – und es gilt, dieses Scheitern mitzudenken und daraus lernen zu wollen. Wer Angst vor Fehlschlägen hat, wird früh stecken bleiben.

Und doch – es lohnt sich!

Cloud Native ist eine dynamische Vision mit neuen Tools und Praktiken, die kontinuierlich entwickelt und erweitert werden. Mit Cloud-native Development sind sehr viele Vorteile verbunden – aus unserer Sicht mehr als Risiken. Selbst wer den Weg in die Cloud nicht so weit mitgeht, wird sehen, dass diese neuen Ideen die Art und Weise beeinflussen, wie in Zukunft Anwendungen entwickelt werden. Und man muss diesen Weg ja nicht allein gehen: es gibt Spezialisten und ganze Communities, die ihr Know-how gerne teilen.

* Petteri Ahonen ist Managing Director bei der Eficode GmbH.

(ID:47869060)