Kolumne: Stropek as a Service

Auch die Cloud setzt die Gesetze der Physik nicht außer Kraft
Kommentare

Strom kommt aus der Steckdose und Trinkwasser aus der Wasserleitung. Diese vereinfachte, fast schon kindliche Logik kommt daher, weil wir gelernt haben, uns über die komplexen Zusammenhänge, die hinter vielen alltäglichen Dingen stecken, keine Gedanken machen zu müssen. Über Jahrhunderte haben unsere Zivilisationen die Infrastruktur zur Versorgung mit Dingen wie Wasser, Strom, Gas, Fernwärme etc. perfektioniert. Selbst wenn wir die Hintergründe verstehen wollten, wäre das nicht so leicht möglich.

In unserem Alltag sind einfache Endergebnisse oft das Produkt riesiger, komplexer Systeme, an deren Aufbau und Wartung viele Menschen und Maschinen mitwirken. Gute Software-as-a-Service-Lösungen sind da ganz ähnlich.

IT kommt aus dem Netz

Bei meiner Arbeit mit Teams, die Cloud-Computing einsetzen, nehme ich immer öfter eine ähnliche Einstellung in Sachen IT wahr wie beim Strom aus der Steckdose. Warum sich darüber Gedanken machen, wie Microsoft, Google, Amazon und Co. das zusammenbringen? Wenn wir Rechenleistung oder Speicher brauchen, klicken wir auf einen Knopf in einem Managementportal und ein paar Sekunden oder Minuten später haben wir die Ressourcen, die wir brauchen. Wenn wir Software für einen gewissen Zweck brauchen, suchen wir uns ein SaaS-Projekt, schließen ein Abonnement ab und überlassen alle betrieblichen Fragen dem SaaS-Anbieter. Zum Strom aus der Steckdose hat sich die IT aus dem Internetkabel dazugesellt.

Ich halte diese Entwicklung nicht für grundsätzlich schlecht, ganz im Gegenteil. Sie zeigt, dass Cloud und SaaS erwachsen werden. Die Anbieter haben bewiesen, dass man sich auf sie so gut wie immer verlassen kann. Je länger nichts passiert, desto mehr rücken Fragen nach den technischen Details in den Hintergrund.

Cloud bedeutet Time Sharing

Das blinde Vertrauen in Betreiber hat aber auch bei Cloud-Computing und SaaS seine Schattenseiten. Was ist, wenn einmal nichts mehr geht? Ist man vorbereitet? Was, wenn die gewünschten Server einmal nicht mehr verfügbar sind, wenn man sie dringend braucht? Lassen Sie mich das an einigen Praxisbeispielen erklären.

Ein Unternehmen will Cloud-Kosten sparen und fährt am Wochenende einen Großteil der nicht gerade kleinen Infrastruktur in der Cloud herunter. Ein Script, das in der Nacht auf Montag automatisch läuft (z. B. mit Azure Automation), startet alles Notwendige oder skaliert die verkleinerten Cluster auf die für den Vollbetrieb notwendige Größe. Diese Vorgehensweise ist vorbildlich. Sie spart Kosten und Energie. Es muss aber klar sein, dass es keine Garantie gibt, dass die notwendigen Ressourcen jeden Montag zur Verfügung stehen. Cloud bedeutet Time Sharing ähnlich einem Hotel. Hotels sind manchmal ausgebucht, genauso ist es in der Cloud. Wenn in unserem Beispiel wichtige Unternehmensfunktionen wie die Produktion an der Verfügbarkeit der IT-Infrastruktur hängen, müssen begleitende Maßnahmen her. Die mindestens notwendigen Cloud-Ressourcen müssen technisch oder vertraglich garantiert sein. Nur der Anteil, auf den man im schlimmsten Fall verzichten könnte, darf variabel bleiben.

Ein anderes Unternehmen plant, die Cloud im Fall großflächiger Katastrophen als Ausfallsrechenzentrum zu verwenden. Die Cloud ist mittlerweile populär und deshalb ist diese Idee nicht nur dieser Firma gekommen. Wenn es tatsächlich zu einer Katastrophe kommt, werden viele in kurzer Zeit Ressourcen in der Cloud anfordern. Nicht alle werden sie bekommen. Wer es mit der Absicherung ernst meint, hat durch Reservierungen (in Azure z. B. durch Stopped Allocated statt Deallocated VMs) bewusste Überdimensionierung oder Redundanzen an mehreren Rechenzentrumsstandorten vorgesorgt.

Pragmatismus bei zeitunkritischen Aufgaben

Bitte verstehen Sie meine Warnung nicht falsch. Nicht immer ist ein ausgefeiltes Konzept zur Absicherung der Verfügbarkeit von Ressourcen notwendig. Ich hatte bereits einige Male mit Unternehmen zu tun, die aufwendige Rechenaufgaben wie Monte-Carlo-Simulationen, Simulationen nach der Finite-Elemente-Methode (FEM) oder Simulationen von Versicherungsmodellen in der Cloud erledigen. Die Nutzung der Cloud ist hier besonders interessant, weil viel Rechenleistung – mehrere tausend Prozessorkerne sind keine Seltenheit – für relativ kurze Zeit benötigt wird. Ich muss zugeben, dass es beeindruckend ist, beispielsweise in Azure mit einem kleinen Azure-ARM-Template in wenigen Minuten tausende Server zu provisionieren und Aufgaben, die sonst dutzende Stunden dauern, in wenigen Minuten zu erledigen.

Solche Simulationsaufgaben sind selten zeitkritisch. Natürlich wünscht man sich eine rasche Fertigstellung. Wenn im Fall des Falles aber gerade keine Server verfügbar sind, geht die Welt nicht unter. In solchen Situationen gilt es, die variablen Kosten in der Cloud so gut wie möglich zu nutzen. Man verzichtet zugunsten niedriger Kosten auf Reservierung und greift manchmal sogar auf den Spotmarkt (z. B. Amazon EC2 Spot Instances) zurück. Bei dem legt man einen Preiskorridor fest, und der Cloud-Provider-Server startet, wenn freie Ressourcen vorhanden sind, die er für einen passenden Preis zu verkaufen gewillt ist.

Git Grundlagen für Entwickler

Thomas Claudius Huber (Trivadis Services AG)

EventStorming und Domain-Driven Design

mit Nicole Rauch, (Freiberuflerin)

Microservice-Architekturen praktisch am Beispiel Kubernetes

mit Jörg Müller & Eberhard Wolff (innoQ)

 

Performance

So wie manche Teams sich ein falsches Bild von der Cloud in Sachen Verfügbarkeit machen, ist die Cloud auch in Sachen Performance für viele trügerisch. Die gewaltigen Ressourcen, die die großen Cloud-Provider in den letzten Jahren zusammengestellt haben und den Kunden zur Miete anbieten, spiegeln eine nahezu unbegrenzte Leistungsfähigkeit vor. Performanceprobleme? Kein Problem, ab in die Cloud. Servergröße oder -anzahl mit einem Schieberegler rauf, und alles ist erledigt. So einfach ist es leider nicht. Software, die nicht auf den Betrieb in elastisch skalierbaren Clustern ausgelegt ist, profitiert oft nicht von mehr und mehr Clusterknoten. Dazu kommt, dass viele Cloud-Dienste auf Hochverfügbarkeit und nicht auf höchste Performance im Sinne von minimierter Antwortzeit getrimmt sind. Sie speichern beispielsweise ihre Daten in relativ langsamen Speicher-Clustern anstatt in schnellen, lokalen Solid State Disks (SSD).

Der Trend zu Microservices trägt das seine zu Performanceproblemen bei. Schneidet man seine Software in viele winzige Microservices, wird aus jedem lokalen Funktionsaufruf plötzlich ein Aufruf eines Web-API über das Netzwerk. Das bedeutet einen um viele Zehnerpotenzen höheren Zeitaufwand.

Man darf nicht vergessen, dass die Cloud im Hintergrund auch aus Servern und Netzwerk besteht. Die Physik wird nicht außer Kraft gesetzt, nur weil die eigene Software nicht mehr am Computer unter dem Schreibtisch, sondern in einem riesigen, zentralisierten Rechenzentrum läuft.

Fog Computing

Ein Trend, der genau in diese Kerbe schlägt, ist Fog Computing. Dabei wird radikalem Cloud-Computing mit starker Zentralisierung und ziemlich „dummen“ Clients der Rücken gekehrt. Datenspeicherung und -verarbeitung erfolgen wieder mehr auf dezentralen Computern oder IoT-Geräten, die mit entsprechenden Cloud-Services interagieren. Diese Vorgehensweise hat viele Vorteile. Hier einige Beispiele:

  • Die Antwortzeit wird nicht durch die unvermeidliche Netzwerklatenz beim Zugriff auf die Cloud begrenzt. Lokale Verarbeitung ist in vielen Situationen viel schneller.
  • Sowieso vorhandene Rechen- und Speicherkapazität auf Clientcomputern liegt nicht mehr brach.
  • Das Gesamtsystem skaliert ganz natürlich, weil neue Benutzer auch neue Geräte mit entsprechender Leistung hinzufügen.
  • Sicherheitskritische Daten müssen nicht in die Cloud oder können vorher verschlüsselt werden. Das löst eine Menge Datenschutzprobleme, mit denen zentralisierte Cloud-Diente heute kämpfen.
  • Die Datenverarbeitung erfolgt in räumlicher Nähe zum Endbenutzer. Kurze Ausfälle bei der Internetanbindung verlieren ihren Schrecken.

Ist Fog Computing das Ende der Cloud? Auf keinen Fall! Das Pendel schwingt von extremer Zentralisierung nur wieder etwas zurück in Richtung dezentraler Systeme. Die Zukunft liegt meiner Ansicht nach in einer sinnvollen Kombination der Stärken beider Ansätze.

Fog Computing steckt noch in den Kinderschuhen. Große Anbieter wie Microsoft haben gerade erst begonnen, das Konzept in die Breite zu bringen. Erste Architekturmuster, APIs, günstige zertifizierte Hardware und integrierte Cloud-Dienste erscheinen am Markt. Man darf aber noch keinen hohen Reifegrad und große Auswahl erwarten.

Kenne deine Plattform

Zusammenfassend kann man sagen, dass man als Cloud-Entwickler/in oder Cloud-Architekt/in nicht nur die entsprechenden Programmiersprachen, Frameworks, APIs und Entwicklungsumgebung kennen muss. Man sollte seine Cloud-Plattform auch vom Preis- und SLA-Modell (Service Level Agreement) her kennen. Ansonsten läuft man einerseits Gefahr, in seine Architektur teure Mechanismen einzubauen, um sich vor Risiken zu schützen, die die Cloud-Plattform von Haus aus abdeckt. Andererseits kann es aber auch leicht passieren, dass man sich durch viele 9er in den SLAs des Cloud-Provider in die Irre führen lässt und sich in falscher Sicherheit wiegt. Um performante Lösungen zu bauen, muss man verstehen, wie die genutzten Cloud-Dienste im Hintergrund arbeiten. Eine Auswahl rein auf Basis der gebotenen Funktionalität ist nicht empfehlenswert. Preismodelle, Verfügbarkeiten, Skalierbarkeit und erreichbare Antwortzeiten sind wichtige Einflussfaktoren, die betrachtet werden sollten.

Der Aufwand, eine der großen Cloud-Plattformen gut kennenzulernen, darf nicht unterschätzt werden. Alle im Detail zu kennen, ist meiner Ansicht nach unmöglich. Die Vielfalt an Diensten ist in den letzten Jahren explodiert. Es ist schwer genug, den Überblick zu behalten. Detailwissen erfordert Spezialisierung, das geht nicht nebenbei. Und nicht vergessen: Die Cloud bewirkt keine Wunder, die Grenzen der Physik gelten weiterhin.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -