Die Cloud als Backend nutzen

Public Cloud Plattformen, wie Microsoft Azure oder Amazon Web Services, bestehen aus vielen verschiedenen Diensten, die einzeln oder zusammen in einer Applikation verwendet werden können. Diese Präsentation zeigt am Beispiel des fiktiven Unternehmens „MeteoR“, wie solche Dienste eingesetzt werden können und welchen Zweck sie erfüllen.

Die Vorteile, die man dank des Einsatzes dieser Cloud-Dienste erhält, sind unter anderem Skalierbarkeit, Kostenflexibilität, Sicherheit, Plattform- und Technologieunabhängigkeit auf der Client-Seite. Diese werden erreicht dank offener Schnittstellen, Hoch-Verfügbarkeit, globale Verteilung und einfache Wiederverwendbarkeit.

Die MeteoR ist ein fiktives Unternehmen, aber mit sehr realen Herausforderungen.

Die MeteoR produziert Wetterstationen. Diese Wetterstationen werden einerseits für Heimanwender entwickelt, welche die aktuellen Temperatur-, Wind- und Druckverhältnisse ablesen wollen.

Das grosse Geschäft sind die Wettersensoren für Unternehmen, etwa für Windparks, Transportunternehmen oder Tourismusgebiete. Die Präzision der Swiss-Made-Wetterstationen ist sehr beliebt und die MeteoR-Wetterstationen werden über verschiedene Distributionskanäle in die ganze Welt geliefert.

Das Geschäft der MeteoR blüht, aber man muss auch in dieser Branche innovativ bleiben und die Konkurrenz beobachten. Und hier zeichnet sich in der Branche einen klaren Trend ab: Das Internet der Dinge. Als das Internet der Dinge bezeichnet man die Verknüpfungen von bisher eigenständigen Endgeräten mit dem Internet. Es soll also ein Konzept entworfen werden, wie diese grosse Menge an Wetter-Daten, die von den Wetterstationen bisher nur lokal verarbeitet wurden, via Internet zentral gesammelt und ausgewertet werden können. Die Vision ist, bald zu einem der führenden Anbieter von aktuellen und historischen Wetterdaten weltweit zu werden.

Das Produktmanagement hat diese Vision konkretisiert und der Entwicklungsabteilung präsentiert mit dem Auftrag, ein entsprechendes technisches Konzept auszuarbeiten. Wir steigen ein in den Workshop der Entwicklungsabteilung, in welchem die technischen Hürden besprochen und Lösungsvorschläge für das zu erstellende System gefunden werden sollen.

Der Architekt der MeteoR beginnt mit der ersten Anforderung aus dem Product Backlog: Es soll möglich sein, mit dem Smartphone oder im Internet die Wetterdaten einer beliebigen Wetterstation abrufen zu können, um das aktuelle Wetter (Temperatur, Luftdruck, Windverhältnisse, Regen, etc.) zum Beispiel in Sidney oder Rio de Janeiro anzuzeigen. Gemäss der agilen Vorgehensweise beginnt er mit dem einfachsten System, welches potentiell funktionieren könnte, und zeichnet obenstehendes Diagramm. Zentral ist dabei eine Webapplikation mit einer relationalen Datenbank, welche im Datencenter der MeteoR gehostet ist. Die Wetterstationen liefern ihre Daten via Internet an die Webschnittstelle. Die mobilen und Web-Clients fragen diese Daten ab.

Den Workshop-Teilnehmern ist jedoch klar, dass diese Architektur nicht lange hält. Will man Marktführer werden im Bereich der Wetterdaten, dann werden sehr viele Wetterstationen und sehr viele Kunden benötigt und damit steigt auch das Datenvolumen. So wird es nicht möglich sein, die Applikation mit nur einem Webserver zu betreiben, sondern es wird eine Webserver-Farm benötigt. Die relationale Datenbank wird irgendwann nicht mehr in der Lage sein, mit so grossen Datenmengen umzugehen (Terrabyte oder Petabyte). Die Bandbreite der Internetverbindung müsste massiv ausgebaut werden. Und letztlich führt eine zentrale Applikation im MeteoR-Datencenter in Europa zu längeren Latenzzeiten für die Requests der Kunden und Wetterstationen in Asien oder Amerika.

Um diese Probleme zu lösen, beginnt man zunächst mit dem Speicher. Wenn die MeteoR keinen relationalen Speicher verwenden kann, was ist die Alternative? Es sollte ein Speicher sein, der sehr grosse Datenmengen effizient und günstig verwalten kann. Weiter sollte er über eine HTTP-REST-Schnittstelle verfügen, damit die Wetterstationen ihre Daten direkt in den Speicher laden können und die Clients (Smartphones und Browser) die Daten direkt via HTTP holen und darstellen können. Und idealerweise ist dieser Speicher noch global verteilt.

Es gibt nur eine Art von Speicher, die diese Bedingungen erfüllen, und das sind Cloud Speicher.

Der MeteoR-Software-Architekt zeichnet also Version 2 seines Architektur-Diagramms, wie oben abgebildet. Die Applikation besteht immer noch aus einer relationalen Datenbank und einer Webapplikation. Diese sind jedoch nur noch für die Auslieferung der Stammdaten zuständig (geographische Ortung der Wetterstationen, Benutzerdaten). Die Wetterdaten selbst werden via HTTP direkt in den Cloud-Speicher geschrieben und direkt vom Cloud Speicher an die Clients ausgeliefert. Eine Art Dropbox für Wetterdaten.

Der Leiter der Entwicklungsabteilung der MeteoR meldet sich zu Wort: „Ich sehe ein, dass ein Cloud-Speicher voraussichtlich die beste Lösung für dieses Problem ist. Allerdings besitzen wir keine praktischen Erfahrungen mit der Cloud. Wir kennen die Cloud-Plattformen zu wenig, um voraussehen zu können, ob diese Verschiebung unserer Applikation in die Cloud später Vorteile oder eher Nachteile mit sich bringt.“. Also wird ein Cloud-Experte der bbv hinzugezogen. Dieser Experte sieht sich das Diagramm an uns sagt: „Nehmen wir Azure als Beispiel, die Public Cloud Plattform von Microsoft. Dann wäre das hier der Azure BLOB Storage. Dieser kann genau das, was ihr erwartet: Er besitzt eine REST Schnittstelle kann sehr grosse Datenmengen verwalten, besitzt eine riesige Bandbreite und ist global verteilt.“

Die nächste Anforderung aus dem Produkt-Backlog ist eine Integration von Unternehmenskunden. Diese wollen unsere Wetterdaten in ihren Applikationen nutzen. Der Cloud Experte meint: „Der Azure BLOB Storage würde sich auch hier eignen. Noch etwas besser geeignet ist jedoch der Azure Table Storage. Er besitzt dieselben Eigenschaften wie der BLOB Storage hinsichtlich REST-Schnittstelle und Datenmengen. Er speichert die Daten jedoch strukturiert ab. Und daher können auch Abfragen gemacht werden wie „Gib mir alle Wetterstationen aus der Schweiz mit einer aktuellen Temperatur über 20 Grad.“.

Falls die Unternehmenskunden keine REST-Anbindung verwenden können, kann mittels eines weiteren Dienstes, den Azure BizTalk Services, auch Enterprise Applikation Integration (EAI) in der Cloud betrieben werden. Damit können beliebige Schnittstellen wie beispielsweise auch SAP, Oracle ESP, SQL Server oder FTP angebunden werden.“

Der Entwicklungsleiter ist noch nicht ganz überzeugt. Er meint: „Wir müssen aber auch für unsere Stammdaten ein API erstellen. Und zu einem API gehört nicht nur einfach eine Schnittstelle, sondern erstens auch ein Entwicklerportal mit Dokumentation unserer Schnittstelle, zweitens eine Möglichkeit für die Entwickler unserer Enterprise-Kunden, diese Schnittstelle zu testen, drittens eine Möglichkeit, unterschiedliche Versionen des APIs parallel laufen zu lassen, viertens eine Verwaltung der Zugriffsberechtigungen, und fünftens mengenmässige Einschränkungen (sogenannte Quotas) sowie ein Monitoring der Zugriffe.“

„Das sind genau die Funktionalitäten, die euch der Azure API Management Dienst bietet“, meint der Cloud Experte. „Dieser Dienst nimmt euch die gesamte Verwaltung des APIs und funktioniert wie ein Proxy, der dem eigentlichen API vorgelagert ist“.

Als nächste Anforderungen sollen die Wetterdaten aus dem Table-Storage auch verarbeitet und aufbereitet werden können, zum Beispiel zu Wetterkarten (hochauflösende Bilder) oder Wettersimulationen also Videos. Diese Medien-Daten können wiederum im Azure BLOB Storage gespeichert werden und von dort den Kunden zur Verfügung gestellt werden.

Um jedoch grosse Bilder vom BLOB Storage zu laden, ist es sinnvoll, das Azure Content Delivery Network einzusetzen. Dieser Dienst ermöglicht es uns, statische Daten in verschiedene Datencenter auf der ganzen Welt zu verteilen. Damit werden die Latenzzeit und die somit auch die Ladezeit der Endkunden minimiert.

Für Video-Daten gibt es einen weiteren Dienst: Die Azure Media Services. Diese erlauben unter anderem ein Video-Streaming aus der Cloud, angepasst an die Auflösung und Bandbreite des Clients. So wird beispielsweise das Video-Streaming für Smartphones automatisch optimiert.

Als nächstes Product Backlog Item stehen Wetteralarme an. Das Produkt-Management sagt, man möchte den Kunden ermöglichen, sich für eine Region, zum Beispiel „Zentralschweiz“, zu registrieren um dann via Push-Notifications Wetteralarme wie „Sturm auf dem Vierwaldstättersee“ zu erhalten.

Dazu dürfen die Wetterdaten der Stationen nicht mehr direkt in den Table Storage geschrieben werden, sondern müssen vorgängig verarbeitet und bezüglich Wetteralarm-Parametern überprüft werden. Die Wetterstationen schreiben also ihre Daten nicht mehr in den Table-Storage, sondern senden sie via HTTP-REST an den Azure Service Bus Messaging Dienst. Das ist im Wesentlichen eine Message-Queue, die die Nachrichten an verschiedene Worker-Prozesse verteilt, welche nun die Daten interpretieren, gegebenenfalls Wetteralarme auslösen und dann die Daten in den Table-Storage schreiben. Der Azure Service Bus ist jedoch mehr als nur eine Queue: Er besitzt Funktionalitäten eines Enterprise Services Busses mit globaler Skalierung in der Cloud als Service. So können Meldungen gefiltert, priorisiert, gebündelt oder mit Metadaten versehen werden. Es können Subscriptions eingerichtet werden, welche aufgrund von Filterkriterien eine bestimmte Menge der Nachrichten in weitere Queues duplizieren. Weiter sind auch komplexe Messaging Funktionalitäten wie Duplicate Detection, Scheduled Enqueue Time oder Dead-Lettering unterstützt.

Um nun Push-Notifications zu senden, müsste sich das System die Notifications-Channels für jeden Endkunden merken, denn für IPhone-Anwender müssen Push-Notification via Apple Push Notification Service gesendet werden. Für Google via Google Push Notification Service und für Windows Phone via Microsoft Push Notification Service. Das ist mühsam, insbesondere wenn man wie im Fall der MeteoR vielen Endkunden gleichzeitig diese Nachricht senden möchte. Dazu gibt es einen weiteren Dienst, den Azure Notification Hub. Dieser verwaltet die Notification Channels aller Kunden und erlaubt uns eine einzige Nachricht an den Notification Hub zu senden, zum Beispiel „Sturm auf dem Vierwaldstättersee“ mit dem Region-Schlüsselwort „Zentralschweiz“ und der Hub vervielfacht die Nachricht für jeden Empfänger, der sich für diese Region angemeldet hat, und sendet ihm über den Notification Service seiner Smartphone-Plattform (Apple, Google, Microsoft) die Push-Nachricht im gewünschten Format zu.

Letztlich will die MeteoR ihren Enterprise Kunden authentifizieren. So soll es möglich sein, dass sich die Mitarbeiter dieser Unternehmen via Active Directory an unserer Applikation anmelden. Zu diesem Zweck gibt es ein weiterer Dienst, das Azure Active Directory. Dieses ermöglicht die Anbindung des Active Directory der MeteoR und das der Kunden und bietet so ein Single-Sign-On Verfahren an. Zudem wäre es auch möglich, öffentliche Identity Provider wie Google, Facebook oder Windows Live anzubinden.

Die gezeigten Cloud Dienste sind nur eine kleine Auswahl der Services, die über die letzten Jahre auf den gängigen Public Cloud Plattformen entstanden sind. Diese Dienste besitzen sechs wichtige Eigenschaften:

1. Sie sind flexibel. Ob man Kilobyts oder Petabytes speichern möchte oder ob man einen kleinen Server oder eine Farm mit hunderten von Prozessoren benötigt, ist egal. In der Cloud mietet man sich die Ressourcen, die man benötigt und bezahlt auch nur das, was man effektiv braucht. Zudem kann man bei Bedarf innert Minuten hoch- oder herunterskalieren.
2. Sie sind hochverfügbar, in der Regel zu 99.95 % monatlich.
3. Sie sind sicher. Der Aufwand, den Cloud-Betreiber machen, um ihre Infrastruktur und Services zu sichern, können sich einzelne Unternehmen oder sogar Regierungen in der Regel nicht leisten.
4. Sie sind offen. Cloud Dienste besitzen offene Schnittstellen. Sie kommunizieren mittels offenen Protokollen. Sie besitzen SDKs für verschiedenste Client Technologien. Azure Services zum Beispiel besitzen offene REST-Schnittstellen und bieten SDKs für .NET, Java, Ruby, PHP, Phyton, Node.js, C, C++, iOS und Android an. Alle SDKs und einige Service-Implementationen sind open source.
5. Sie sind global. Dies führt zu geringeren Latenzzeiten und globalen Desaster Recovery Lösungen.
6. Sie sind einfach wiederverwendbar. Dadurch wir die Time-to-Market verringert und die Wartbarkeit erhöht, sowohl in Cloud Applikationen als auch in lokalen Applikationen. Sowohl im Verbund mit anderen Cloud Diensten, als auch als einzelne, unabhängige Komponenten.