Cloud Computing: 3 Brillen

Fast jedes Unternehmen will heutzutage »in die Cloud«. Doch was bedeutet das eigentlich? Ich verstehe Cloud für Unternehmen als ein abstraktes Konzept, das aus verschiedenen Brillen, der IT und der Plattform, betrachtet werden kann — nur wie?

Prinzipiell umfasst IT verschiedene Ebenen: den Betrieb, den Entwickler und den Architekten. Der Betrieb ist dabei dafür zuständig Hardware zu beschaffen und die Software im Betrieb zu halten. Während Entwickler dem Betrieb zuarbeiten. Sie entwickeln entsprechend die Software. Das Plattform-Team und die Architekten, geben dabei den Rahmen und die Prozesse an, die für das Zusammenspiel zwischen den Teams erforderlich ist. Jede dieser Rolle kann durch »Cloud« beeinflusst werden und hat entsprechend eine eigene Brille auf das Thema Cloud. Wichtig zu verstehen: Die Rollen können sich durchaus vermischen.

Sicht des Betriebes

Im Betrieb ist es notwendig Hardware für Software bereitzustellen und diese zu beobachten, um einen reibungslosen Ablauf zu garantieren.

Klassischerweise betreiben Unternehmen ihre IT in eigenen Datenzentren. Sie sind deshalb für den Betrieb und der Bereitstellung der Hardware selbst verantwortlich: Die Hardware wird selbst bestellt, Systeme installiert und Computer selbst gepflegt. Was auf der einen Seite maximale Flexibilität gibt, bringt auf der anderen Seite auch eine große Herausforderung mit. Läuft etwas nicht nach Plan, z. B. weil ein Server nicht erreichbar ist, liegt es in der eigenen Hand ein Betrieb wiederherzustellen. Das bedeutet: Eigene Ressourcen stellen den eigenen Betrieb sicher.

Das sich nicht jedes Unternehmen das Investment eines eigenen Datenzentrums (der Hardware) und eine dazugehörige IT-Abteilung leisten kann, sollte klar sein — die monetären Ressourcen werden ganz woanders benötigt. Glücklicherweise gibt es auch in der IT deshalb Mietmodelle, die sich diesen Markt zunutze machen: Hosting. Beim Hosting wird Hardware bei einem Anbieter angemietet. Betrieben wird deshalb nur die Software selbst, nicht aber die Hardware. Dadurch verlieren Unternehmen auf der einen Seite Kontrolle über ihre IT, erspart aber ein Warten und Kaufen von Computern und Netzwerktechnik.

Gerade Hosting von virtuellen Maschinen ist ein essenzieller Aspekt vom Cloud-Computing, wenn es um das Betreiben von Software geht. Er ist so gut wie in allen Kern-Diensten der verschiedenen Cloud-Anbieter enthalten.

Damit die VMs und dessen auftretenden Probleme regelmäßig beobachtet werden, ist ein entsprechender Monitoring-Softwarestack essenziell. Hosting schützt nicht davor, dass die Software — das impliziert den Monitoring Stack — selbst gewartet werden muss. Datenbanken, Message Queues, Monitoring-Software etc., die betrieben werden, werden in der Regel extern weiterentwickelt. Weiterentwicklung impliziert dabei, dass zwischen Versionen Änderungen dabei sein können, die im schlimmsten Fall nicht abwärtskompatibel sind. Und das kann verheerend sein. Die Betreiber der Software (in dem Falle die eigene IT-Abteilung) müssen deshalb bei Aktualisierungen ständig auf Änderungen achten, die bestehende Software tangieren können. Auch ein Skalieren der einzelnen Software-Komponenten erfordert häufig ein konkretes Wissen der Applikationen selbst und ist nicht ganz trivial. Als Beispiel: Allein die Software Loki unterstützt 3 verschiedene Deployment-Modi, die unterschiedliche Vor- und Nachteile haben.

Aus betrieblicher Sicht ist also klar: Hosting/Mieten verhindert eine große Investition in eine IT-Infrastruktur, Software muss allerdings selbst installiert, gewartet und skaliert werden. Eine Expertise über die betriebene Software ist in den meisten Fällen unabdinglich.

Und hier kommt die dritte Stufe beim Betreiben von Software ins Spiel: Managed Services.

Managed Services sind das, was das größte Potenzial, aber auch Gefahren mitbringt. Bei Managed Services werden keine virtuellen Maschinen, sondern eben die (High-Level) Software an sich gemietet. Das inkludiert zum Beispiel AWS RDS, AWS CloudWatch oder verwaltetes Kubernetes. Dabei wird Expertise der Software selbst mit vermietet. Das bedeutet, dass Wissen zu Themen wie:

• Security Updates
• Backup Strategien
• Speicher Upgrades
• Skalierungen & High Availability-Setups

nicht, oder nicht im Detail, benötigt werden.

Durch das Anmieten von High-Level Services in der Cloud bis zum Anmieten von reiner Hardware umfasst Cloud-Computing aus der Betriebsbrille viele Facetten. Dem Betrieb ist es möglich viel Expertise über konkrete in verwaltete Services auszulagern.

Sicht des Entwicklers

In der Regel entwickelt ein Entwickler Software für eine einzelne Maschine. Wo die Software betrieben wird, kann dem Entwickler meistens egal sein. Um die Vorteile vom Cloud-Computing, Elastizität und Hochverfügbarkeit, vollends ausspielen zu können, ist Cloud-Computing aber mehr als Betreiben konkreter Software. Elastizität bedeutet, dass Software mit dem Aufkommen von Datenverkehr hoch- und runterskaliert werden kann, während Hochverfügbarkeit bedeutet, dass die Software beinahe zu immer erreichbar ist.

Doch wie man es dreht und wendet: Die Vorteile gibt es, nur weil »Cloud-Computing« dran steht nicht geschenkt. Entwickler müssen, damit die Software die Vorteile einer Cloud ausspielen kann, für ein verteiltes Betreiben entwickelt werden — mit allen dessen Konsequenzen.

Zustandslose und Zustands-volle Systeme

Software, die für die Cloud entwickelt wird, sollte aus Entwickler-Sicht deshalb zustandslos sein. Zustandslos bedeutet, dass Schnittstellen, die bei klassischen Applikationen als gegeben angesehen werden, bei verteilten Applikationen schwieriger, bzw. mit spezieller Beachtung, zu bedienen sind. Diese Schnittstellen sind meistens Zustands-volle Schnittstellen. Zustands-volle Schnittstellen sind APIs wie z. B. die native File-System-API, Serverseitiges-Session-Management oder Zustands volle Verbindungen wie Web Sockets. Alle diese Daten sind in der Regel nur lokal auf einem konkreten Knoten verfügbar.

Applikationen ohne Zustand sind allerdings kaum anzutreffen, das Problem muss also woanders gelöst werden. Glücklicherweise gibt es für die meisten Anwendungsfälle eben genau deshalb Lösungen, die bereits in der Betriebssicht aufgetaucht sind: Verwaltete Datenbanken und Datenhaltung, die Expertise im Skalieren von Daten abstrahieren. Na ja bedingt.

Skalieren und Datenhaltung ist nicht trivial. Deshalb sollte ein Cloud-Entwickler wissen, welche Trade-offs die genutzte Datenhaltung impliziert (z. B. welche Isolationslevel unterstützt werden) — und wann Daten verloren gehen können.

Nicht selten implizieren verwaltete Datenbanken aufgrund des Skalierungsmodells verschiedene Paradigmen. Das impliziert wiederum, dass bereits in der Datenmodellierung Entscheidungen getroffen werden müssen, die für ein Betreiben in der Cloud relevant sind. Konkret äußert sich dies im Aufschwung neuer Datenbank-Technologien, die eben nicht auf ein relationales Modell setzen.

Designing for Failure

Anders als klassische Software, ist bei einer Cloud-Ready Software der konkrete Rechenknoten, der die Applikation ausführt, unbekannt. Die wenigsten klassisch entwickelten Applikationen bieten für den Ernstfall Szenarien an. Fällt der Rechner aus, ist die Software schlichtweg nicht erreichbar. Software, die in der Cloud betrieben wird, wird meistens deshalb dort betrieben, damit die Software hochverfügbar ist — sogar über Kontinente hinweg.

Gerade deshalb sollte man sich schon als Entwickler Gedanken machen, was passiert, wenn beispielsweise externe Systeme nicht erreichbar sind, um ein Absturz der eigenen Software zu verhindern. Verteilte Software sollte immer mit einer Backup-Strategie entwickelt werden, die einen Ausfall externer Systeme, das können Datenbanken, Message Queues oder andere High-Level Applikationen sein, miteinbezieht. Nur so können »Cascading Failures« verhindert werden.

Sicht des Architekten

Die letzte Sicht, die vom Cloud-Computing geprägt wird, ist die Sicht des Architekten. Der Architekt ist, hat eine Brille auf das Gesamtsystem, Technologien und dessen Entwicklungs-Prozesse. Dazu ist er verantwortlich, dass die Software, die Betrieben wird reibungslos betrieben wird.

Continious Delivery

Kaum gibt es heutzutage noch Teams die ohne Continious Integration-System arbeiten. Wohl aber ohne Continious Delivery. Bei der Continious Delivery wird jedes Inkrement einer Software direkt ausgerollt und für den Endnutzer verfügbar gemacht. Gerade im Hinblick auf Kubernetes und Cloud-Computing ist es extrem einfach die bestehenden APIs zu bedienen und genau das Paradigma zu bedienen.

Im klassischen Betrieb, wo Applikationen mit neuer Version gestartet werden, ist ein Ausrollen neuer Softwareversionen sehr aufwändig. Wenn neue Software ausgerollt wird, muss die alte Software zunächst ausgeschaltet werden, und die neue heraufgefahren werden. Ist die neue Version fehlerhaft, muss ein entsprechender Rollbackmechanismus greifen um Datenbanken und Software wieder in den alten Zustand zu versetzen. Dieser Prozess ist mit reinen Linux-Systemen sehr aufwändig bzw. kompliziert — was nicht heißt, dass es nicht umgesetzt werden kann. In einer Cloud Welt, mit Werkzeugen wie Kubernetes oder Terraform ist ein kontinuierliches Aus- und Zurückrollen von Software ein leichtes Spiel und, wichtiger: vorgesehen. In der Vergangenheit habe ich dazu einen Beitrag zum Thema Deployment Strategien geschrieben, wo ich auf die einzelnen Strategien und Probleme eingehe. Das schöne dabei: Kubernetes unterstützt dabei fast jede Strategie.

Code ist die Wahrheit

Wachsen Systeme an, ist es nötig jeder einen Überblick zu behalten, damit das System wartbar bleibt. Was ist deployt? Was soll deployt sein? Welche Version welcher Software soll deployt sein? Sind diese Versionen kompatibel? — Antworten, die jederzeit dokumentiert werden sollten.

Durch das Cloud-Computing und dessen gewachsenen Tooling ist das Konzept von Immutable Infrastructre, Infrastructure as Code und ggf. GitOps aus dem Bereich Site Reliability Engineering eine wundervolle Ergänzung.

Durch Tools wie Docker, Kubernetes, und Terraform ist es heutzutage extrem einfach Systeme mittels Code abzubilden.

Mit Docker kann Software in unveränderbare Container, die die Software und dessen Betriebssystem enthalten, überführt werden. Das bedeutet: Alle Softwareversionen verhalten sich gleich. Probleme sind damit reproduzierbar — enorm wichtig beim Debuggen.

Terraform dokumentiert die Hardware, die zum Betreiben der Software genutzt wird. CPU, RAM, Speicherplatz lässt sich dabei einsehen — und zwar nicht extern, sondern genau an der Stelle die der Wahrheit entspricht. Denn: durch Infrastructure as Code ist die einzige Möglichkeit Hardware zu bestellen, dies über den entsprechenden Code zu tun — nicht über irgendeine UI.

Auch Plattformen wie Kubernetes nehmen einen Stellenwert ein. Umsetzungen der Konzepte von Kubernetes werden in der Regel über YAML-Dateien statt CLI-Commands beschrieben. Damit wird in Kubernetes jede Installation oder Update einer Software automatisch über eine Änderungshistorie der Datei dokumentiert.

Und was ist der Gewinn, wenn alles durch Code abgebildet werden kann? Wird alles durch Code abgebildet, können bekannte Prozesse aus der Entwicklung übernommen werden. Von Versionierung der Änderungen bis hin zum Verschlagen von Veränderungen im System durch Tools wie git, kann damit eine ganze IT-Abteilung ihre tägliche Arbeit dokumentieren. Vorbei sind die Zeiten wo das System dokumentiert wird — die Dokumentation lebt im System.

Natürlich ist auch ein wichtiges Thema die Developer Experience. Developer Experience beschreibt das Gefühl eines Entwicklers, dass es Spaß macht mit der Technologie zu arbeiten. Software die mehrere Minuten zum Starten braucht gehört mit Sicherheit nicht dazu. Nicht zuletzt deshalb gibt es Entwicklungen wie beispielsweise Java Quarkus oder der Aufschwung von Node.js. Es macht schlichtweg Spaß damit zu arbeiten.

Fazit

Cloud-Computing ist nicht nur ein Trend, wo Hardware gemietet wird. Es werden vielmehr alle Ebenen der Softwareentwicklung tangiert. Dabei sind die drei Brillen vom Betrieb, Entwicklung, Architektur spannend.

Cloud-Computing verändert den Betrieb dahingehend, das dessen tägliche Arbeit vielleicht eher das Heraussuchen bestimmter Produkte ist. Entwickler entwickeln vermehrt verteilte Systeme, um ein Skalieren zu ermöglichen. Und als Architekt ist es notwendig den Überblick über das ganze System zu bewahren und einen optimalen Prozess bereitzustellen. Dabei ist eine Technologie-Auswahl für einen optimalen elastischen Betrieb hilfreich. Die Kern-Idee vom Cloud-Computing ist eines: Es muss Spaß machen, Software zu entwickeln, die Werte generiert.