,

Softwareentwicklung in der Cloud. Was ändert sich?

Softwareentwicklung in der Cloud. Was ändert sich?

Vielen Unternehmen ist der Start in die Cloud bereits geglückt – oder es wird intensiv daran gearbeitet. Spätestens jetzt wird klar: Die Cloud ändert so einiges. Ein guter Zeitpunkt also, um darüber nachzudenken, wie wir mit Cloud-Technologien eigentlich umgehen wollen.

Cloud ist anders. Ja, stimmt. Definitiv führt die Nutzung der Technologien zu einer veränderten Herangehensweise bei der Softwareentwicklung. Neben diversen technischen Raffinessen spielen bei Cloud-Native-Design-Ansätzen auch die Arbeits- und Herangehensweise eine entscheidende Rolle. Stichwörter wie „DevOps“, „Design for failure“ oder „Fail Fast, Learn Fast“ kommen nicht von ungefähr.

Was die Applikationsentwicklung nach Cloud Native-Prinzipien ausmacht, habe ich hier schon umrissen. Zum Thema DevOps existieren auch schon einige Artikel in diesem Blog. Den Zusammenhang zwischen diesen beiden Pfeilern der Cloud will ich anhand ausgewählter Punkte des Cloud Application Maturity Levels in diesem Beitrag erläutern.

Cloud Native Applikationsentwicklung

Design for Failure

Der Cloud native Design-Ansatz kommt einem Paradigmenwechsel gleich: Bisher konnte bei einer On Premises Entwicklung meist davon ausgegangen werden, dass Schnittstellen verfügbar sind – eine Nichtverfügbarkeit war eher die Ausnahme. Dies liegt an der Nähe im Netzwerk und der Auslegung der Schnittstellen: Instabiler Mobilfunk, Begrenzungen aufgrund von Quotas oder Updates während des Betriebs waren nicht weit verbreitet bzw. nicht genutzt.

Architekturen für Cloud Services oder Mobilgeräte hingegen setzen Pattern ein, die das genaue Gegenteil annehmen. Ein entferntes System – wie es beim Einsatz von Microservices eigentlich immer der Fall sein kann – hat eine höhere Latenz bei der Antwort. Oder es antwortet auch einmal gar nicht. Dadurch müssen Anwendungen sehr robust konzipiert werden und gegen den Ausfall einzelner Komponenten gewappnet sein.

Dahinter steckt das Prinzip der Resilienz: Die Komponenten reagieren selbstständig auf Verbindungsabbrüche und prüfen z.B. regelmäßig auf eine erneute Verfügbarkeit externer Schnittstellen.

Retry Pattern

„Jetzt? Jetzt? Vielleicht jetzt?“ – Die Wahlwiederholung am Telefon kennen und nutzen wir schon seit langem. Auch bei der Nutzung von (Micro-)Services kann es vorkommen, dass der Dienst besetzt ist – bspw. durch eine Bandbreitenbeschränkung oder Verlängerung der Antwortzeit aufgrund von Überlastung – oder schlicht gerade nicht verfügbar. In diesem Fall kann das Retry Pattern genutzt werden, um die Applikation robust zu gestalten. Jeder ITler kennt den Spruch „Have you tried turning it off and on again?" – So funktioniert auch das genannte Pattern: Der Dienst, und damit die Anwendung, reparieren sich quasi selbst, indem Anfragen wiederholt werden und (im übertragenen Sinne) nicht direkt ein Supportcall eröffnet wird.

Circuit Breaker

Im Gegensatz zur On Premises-Welt, in der wir immer davon ausgehen, dass eine Operation erfolgreich sein wird, nimmt ein Circuit Breaker einfach an, dass eben dies nicht der Fall ist. Wenn nun z.B. eine Verbindung über einen längeren Zeitraum hinweg nicht zustande kommt, wird eine „Sicherung“ wird gezogen. Im Normalzustand ist der Circuit Breaker geschlossen. Erst im Fehlerfall wird er geöffnet und kann in den halb offenen Zustand übergehen, um Anfragen wieder vom Aufrufer zur Ressource durchzulassen. Zum Schutz der entfernten Ressource dient ein Proxy, damit nicht alle Konsumenten losstürmen und das System überlasten, wenn es nach einem Ausfall wieder verfügbar wird. Natürlich kann der Ausfall auch hier wieder eine Offline-Szenario sein.

Simian Army

Netflix dient häufig als Referenz, wenn von erfolgreichen Cloud-Lösungen gesprochen wird. Auf einer Vielzahl von Servern werden über 500 Microservices betrieben. Ein Resiliency Tool – der sogenannte Chaos-Monkey – sorgt dafür, dass zufällig gewählte einzelne Dienste oder auch eine ganze Gruppe von Diensten ohne Vorwarnung außer Betrieb genommen werden. Das Tool ist Teil der Simian Army, die mittels dieses andauernden Stresstests die Cloud-Applikationen robust halten. In der Cloud Native-Welt wird also schon während der Entwicklung auf eine Nichtverfügbarkeit geachtet. Die gesamte Plattform wird so robuster – und kein Entwickler sollte je wieder nachts aus dem Bett geklingelt werden, weil ein System versagt.

Stateless

Von einer Stateless Architektur sprechen wir dann, wenn für die Verarbeitung nur übergebene Parameter genutzt werden. Nehmen wir bspw. die Webseite eines Onlineshops: Sie besteht aus vielen Komponenten wie Warenkorb, Suche oder der Anzeige von Produkten. Um die Webseite richtig anzuzeigen, werden einzelne Services angesprochen, die Inhalte in einem Teil der Webseite darstellen. Der Warenkorb zeigt bspw. die hinterlegten Artikel für den aktuellen Benutzer. Kann der Dienst diese Daten nur ermitteln, wenn er die Vorgeschichte des Benutzer kennt (z.B. ausgelesen aus der Session, die nicht über Server hinweg repliziert wird), so ist er stateful – benötigt also einen vorherigen Zustand und arbeitet mit Abhängigkeiten (in diesem Fall zwischen Browser und Webserver). Wird die UserID hingegen beim Aufruf direkt an den Dienst übergeben, ist er nicht mehr von vorangegangenen Aktionen abhängig und kann autark arbeiten. Hierbei dürfen natürlich weitere Daten aus einer Persistenz Schicht (Cache, Datenbank) nachgeladen werden. Damit wird er zustandslos (stateless). Ist das CMS der Webseite gemäß den Cloud Native Prinzipien skalierbar, tauschen sich die einzelnen Serviceinstanzen nicht mehr darüber aus, welche Artikel im Warenkorb des Benutzers liegen, sie bekommen diese Information von einem weiteren Dienst/ Datenbank/ Cache. Andernfalls verpuffen die gewünschten Skalierungseffekte und die Webseite reagiert langsamer auf Anfragen.

DevOps / Fail Fast, Learn Fast

Neben den genannten Design Prinzipien, die sich aus dem Einsatz von Microservices, Containern oder Serverless ergeben, spielt in der Cloud Native-Welt der DevOps-Ansatz eine ebenso entscheidende Rolle. Konsequent umgesetzt verschafft das Prinzip den Teams einen enormen Vorteil bei der Applikationsentwicklung und -betreuung. Dass DevOps sich nicht "mal eben" einführen lässt, haben bereits andere Beiträge in diesem Block veranschaulicht. Eine schnelle Entwicklung kann allerdings nur dann stattfinden, wenn ein hoher Automatisierungsgrad erreicht wurde und Zeit, Plattform sowie Einstellung stimmen. Und genau deswegen empfiehlt es sich so früh wie möglich z.B. eine Fail Fast, Learn Fast-Philosophie zu etablieren. Durch den Einsatz von Microservices ist es problemlos möglich kleine Änderungen schnell zu entwickeln, bereitzustellen (Stichwort Blue-Green Deployment) und den Erfolg zu messen.

Der eigene Start in Cloud native Entwicklung und die sich durch DevOps erforderliche Änderung der Zusammenarbeit erfordert eine gründliche Vorbereitung. Ein Mindchange über alle Projektebenen hinweg ist nötig, um wirklich moderne Softwareentwicklung zu betreiben. Ansonsten macht sich schnell Frustration breit und die gut gemeinten Vorstöße verlaufen im Sand.


Eine Übersicht zur Entwicklung von Cloud Native Applikationen finden Sie in unserem Download Bereich.

Über den Autor des Beitrags:

René Hézser

 

 

 

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.