Cloud-native Applikationen entwickeln

Geringere Time-to-Market, bessere Skalierbarkeit, effizientere Ressourcennutzung, geringere Investitionskosten: Es gibt viele Gründe, Cloud-Angebote zu nutzen. Herausforderungen zeigen sich hingegen, wenn Unternehmen selbst Cloud-Software bereitstellen wollen.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Cloud-native Applikationen entwickeln
Lesezeit: 18 Min.
Von
  • Peter Putz
Inhaltsverzeichnis

Um in der digitalen Welt erfolgreich zu sein, müssen Unternehmen vor allem schnell sein. Kunden erwarten exzellente, intuitiv benutzbare Software, mit der sie ihre Anliegen selbstständig und zuverlässig zu jeder beliebigen Zeit abwickeln können. Die entsprechenden Produkte sind nicht statisch, sondern kontinuierlich zu erweitern, zu verändern und zu verbessern. Wurden früher neue Softwareversionen bestenfalls im Jahresrhythmus ausgeliefert, sind die heutigen Release-Zyklen auf Tage oder Stunden reduziert.

Dafür sind tiefgreifende organisationskulturelle und technische Veränderungen nötig. Die funktionsspezifischen Silos der Vergangenheit sind durch agile, bereichsübergreifende Entwicklungsteams abzulösen, die die volle Verantwortung vom Design bis zum Betrieb ihrer Komponenten übernehmen. Technisch gesehen führt nichts am Cloud Computing vorbei – unabhängig davon, ob die Cloud firmenintern läuft oder bei externen Anbietern.

Einer von O'Reilly Media und Dynatrace durchgeführten Studie (Cloud Platform Survey 2016) zufolge haben 94 Prozent der befragten IT-Experten aus Nordamerika und Europa vor, auf Cloud-Technologien zu migrieren. 42 Prozent setzen dabei vorwiegend auf die Public Cloud, jeweils unter 30 Prozent auf die hybride oder private Variante.

In Deutschland nutzen laut dem Cloud Monitor 2016 von BITKOM und KPMG 54 Prozent der Unternehmen Cloud-Techniken, weitere 18 Prozent planen oder diskutieren den Einsatz. Dabei holen vor allem kleine und mittelständische Unternehmen auf. Gemäß IDC nutzen sogar 63 Prozent der deutschen Firmen eine Public oder Private Cloud für Unternehmensprozesse. Das entspricht einem Zuwachs von 70 Prozent im Vergleich zum Vorjahr.

Statt großer monolithischer Anwendungen mit Millionen von Programmzeilen sind moderne Applikationen aus kleinen, vernetzten Services zusammengesetzt. Diese Microservices beschränken sich auf spezifische Funktionen wie Authentifizierung, Warenkorb oder Kreditkartenverrechnung. Die einzelnen Komponenten lassen sich völlig unabhängig voneinander entwickeln (auch in verschiedenen Programmiersprachen), solange sie sich nach außen hin in einer klar definierten Weise verhalten. Diese Art der Softwarearchitektur ermöglicht es, neue Funktionen rasch zu entwickeln und bereitzustellen, weil Veränderungen in einem kleinen Modul technisch relativ einfach sind und leicht getestet werden können.

Design und Zusammenspiel aller Microservices in einer Applikation sind aber durchaus herausfordernd. So kann es im praktischen Betrieb zu vielfältigen Anomalien durch das unerwartete Zusammenspiel der Module kommen, die sich dann negativ auf die Performance auswirken. Intelligente Monitoring-Ansätze können solche Probleme identifizieren und Gegenmaßnahmen anbieten.

Microservices lassen sich in kleinen, selbstgesteuerten Teams entwickeln. Sie sind oft heterogen zusammengesetzt, sodass neben den Softwareentwicklern auch themenbezogene Fachexperten, Kundenrepräsentanten und weitere Fachkräfte vertreten sind. Der agilen Methode entsprechend, sind die Entwicklungszyklen kurz und iterativ.

In den letzten Jahren ist der Trend aufgekommen, den Entwicklungsteams die volle Verantwortung für den Betrieb ihrer Komponente zu übertragen. So hat Amazons CTO Werner Vogels die Direktive "You build it, you run it" ausgegeben und zum Standard im gesamten Unternehmen erhoben. Ziel ist es, höchste Qualität trotz schneller Entwicklungszeiten sicherzustellen. Dazu sollen die funktionalen Gräben zwischen Entwicklung, Qualitätssicherung und Betrieb verschwinden und von der sogenannten DevOps-Kultur abgelöst werden.

Entwickler müssen dadurch schon zu Projektbeginn überlegen, wie sie einen reibungslosen Betrieb ihrer Komponente in der Produktionsumgebung sicherstellen und die entsprechenden Daten zur Früherkennung von Störungen erhalten. DevOps hat aber auch weitreichende Konsequenzen für die gesamte Organisationsstruktur: Herkömmliche Funktionsgrenzen und vertikale Hierarchien sind zu überwinden und durch dynamische, eigenverantwortliche und funktionsübergreifende Teamstrukturen zu ersetzen.

Durch weitgehende Automatisierung von Tests und Softwarebereitstellung, verschieben sich auch die Aufgaben des Ops-Teams. Während die Gewährleistung und Überwachung des Betriebs zunehmend weniger Ressourcen in Anspruch nehmen, übernimmt das Ops-Team immer häufiger die Überwachung und Optimierung des automatisierten Softwarebereitstellungsprozesses.

Höchste Qualität und Software-Releases im Stundentakt sind mit manuellen Test- und Softwareintegrationsprozessen unvereinbar. Eine weitestgehende, im Idealfall sogar vollständige Automatisierung des Bereitstellungsprozesses ist unabdingbar. Hier kommen Techniken und Methoden der kontinuierlichen Integration (CI), Testautomatisierung und Continuous Delivery (CD) zum Tragen. Überdies sind entsprechende Werkzeuge nötig, weil es in vielen Cloud-Umgebungen nicht mehr möglich ist, Apps manuell bereitzustellen.

Entwickler verpacken Apps oder Microservices zunehmend in sogenannte Container, um den Bereitstellungsprozess unterschiedlicher Komponenten zu standardisieren. Ein Container enthält alles, was eine Applikation zum Laufen benötigt: den Programmcode, die Laufzeitumgebung, Systemkomponenten und -verzeichnisse, etc.