This post is sponsored by VMware. Learn about VMware virtualization and cloud solutions for small & mid-size business visit info.vmware.com



This article is available in other languages:

This article is available in other languages:

Germany Vorteile eines Hybrid Cloud /VirtualisierungssystemsFrance Vorteile eines Hybrid Cloud /VirtualisierungssystemsChina Vorteile eines Hybrid Cloud /VirtualisierungssystemsNetherlands Vorteile eines Hybrid Cloud /VirtualisierungssystemsEngland Vorteile eines Hybrid Cloud /VirtualisierungssystemsPortugal Vorteile eines Hybrid Cloud /Virtualisierungssystems

In unserem letzten Eintrag habe ich über ein paar Unterschiede geschrieben, die sich ergeben, wenn Sie die App auf einer öffentlichen Commodity Cloud laufen lassen versus des Hosting und Aufbaus Ihrer eigenen Cloud, um sie dort laufen zu lassen, und darüber, wie Sie zwischen diesen beiden Optionen wählen sollten.

Diesmal möchte ich Ihnen mitteilen, dass Sie sich nicht zwingend entscheiden müssen. Als ich erklärt habe, wie eine Hosting-Umgebung zu wählen ist, habe ich die wesentliche Annahme ausgelassen, die dies zu einer ,entweder-oder’-Prämisse gemacht hat, nämlich dass Ihre Applikation in ihrer Gesamtheit ein heterogenes Set von Leistung, Verfügbarkeit und Budgetrestriktionen beinhaltet.

Es ist leicht, eine solche Annahme zu treffen, da generell die meisten Applikationen in einer monolithischen Art und Weise entwickelt werden, mit einer einzigen Code-Basis, einer Standard-Entwicklungsumgebung, und letztlich mit nur einem Serieneinsatz. Durch Zerteilung Ihrer monolithischen App in kleinere Komponenten steht es Ihnen nun frei, jede der Komponenten in einer Umgebung zu hosten, die idealerweise mit ihren eigenen Bedingungen übereinstimmt.

Service- oder ressourcenorientierte Architektur

Dieser Prozess des Aufsplittens Ihrer Applikation wird generell als Service- bzw. ressourcenorientierte Architektur bezeichnet. Die korrekte Bezeichnung hängt davon ab, wie Sie Ihre Applikation unterteilen, und ist für uns gerade nicht relevant.

In diesem Artikel erörtere ich die Vor- und Nachteile einer SOA insofern, als sie speziell das Hosting betreffen. Die SOA zu ändern ist ein weitaus größeres Themengebiet, und ich empfehle Ihnen dringend, noch mehr zum Thema zu lesen, bevor Sie sich darauf einlassen.

Ein spezifisches Beispiel

Im letzten Artikel habe ich das Beispiel des Marktplatzes mit digitalen Inhalten benutzt und beschrieben, wie wir diesen von der Cloud auf eine private, virtuelle Umgebung verschoben haben, hauptsächlich aufgrund des Wunsches nach schnellerer Leistung und mehr Kontrolle.

Im Laufe der Zeit, und zusammen mit unserer Erschließung neuer Marktplätze, hat sich das Lastprofil der Applikation dramatisch verändert. Wir hatten zwar noch immer den gleichen, stetigen Zustrom an E-Commerce Kunden, die zügigen Service forderten, aber mit jedem neuen Marktplatz gab es neue Arten von Dateien, die hochgeladen wurden, mit stark unterschiedlichen Anforderungen hinsichtlich der Nachbearbeitung, und diese traten sehr sporadisch auf.

Zu diesem Zeitpunkt war unser Produktionsumfeld zu sehr darum bemüht, es “jedem recht zu machen”. Wenn wir die App als etwas betrachten, das primär zu dem Zweck gestaltet wurde, den Einkauf von Dingen so einfach wie möglich zu machen, war die Entscheidung, auf unserer privaten Cloud zu hosten, stimmig. Wenn wir diese hingegen primär als eine Plattform für Leute betrachten, die Inhalte in größeren Mengen beisteuern möchten (die dann zum Verkauf stehen), allerdings mit einem sehr unvorhersehbaren Lastverlauf, dann machen die elastischen Eigenschaften der öffentlichen Cloud für diese Applikation mehr Sinn.

Die Applikation zweiteilen

Die Aufrechterhaltung ausreichender Slack-Kapazität zum Umgang mit dem großen Zustrom an neuen Inhalten führte zu einem Anstieg sowohl der Kosten als auch der Komplexität im Bereitstellen von Datenspeicherplatz, um alles erhalten zu können. Daher haben wir die Applikation aufgeteilt und 100% des Asset-Speichers und der Bearbeitung auf die Cloud verschoben.

Das Haupt-Produktionsumfeld behielt jeden hochgeladenen Inhalt lange genug, um ihn in den Cloud-Speicher zu verschieben, und informierte den neuen Asset-Bearbeitungsservice über die Verfügbarkeit von neuen Inhalten. Der Asset-Service wiederum vollzog alle notwendigen Validierungen der Dateien, Transformationen, das CDN-Publishing usw., und informierte dann die Haupt-Webseite darüber, dass der Inhalt zur Nutzung bereitstand.

Nutzen

Der erste größere Nutzen lag im Endergebnis. Durch Reduktion der Slack-Kapazität in unserer privaten Cloud, und das Verschieben von Arbeit auf die öffentliche Cloud, wo wir Kapazitäten je nach Bedarf hinzufügen oder entfernen konnten, gaben wir weniger aus, um mehr “Arbeit” erledigen zu können.

Der nächste Nutzen lag in einer reduzierten Komplexität des primären Umfelds. Das primäre Umfeld war nun zu 100% darauf fokussiert, der Webseite zu dienen und hatte nun weniger damit zu tun, die sich bewegenden Teile beizubehalten. Da Leistung von vornherein einer der Hauptgründe für die Wahl der privaten Cloud gewesen war, führte die Vereinfachung des Umfelds dazu, dass wir weniger potentielle Engpässe hatten, wodurch das Finden und Beheben von entstehenden Störungen wesentlich leichter wurde.

Zu guter Letzt wurde es einfacher, unseren Kunden gegenüber eine hohe Verfügbarkeit sicherzustellen. Durch die strikte Trennung von Webseite und Asset-Verarbeitung konnten sich Probleme in unserem Asset-System kaum noch in unserer Webseite bemerkbar machen.

Nachteile

Leider haben all diese Vorteile auch ihren Preis.

Der erste Nachteil besteht darin, dass durch die unterschiedlichen Komponenten in verschiedenen Rechenzentren – oder sogar im selben Rechenzentrum, da manche Provider das physische und das Cloud-Hosting anbieten – Ihr System insgesamt unter einer Wartezeit zu leiden hat, und diese wird höchst unterschiedlich ausfallen.

Sie werden einen erheblichen technischen Aufwand betreiben müssen, was wiederum alle Interaktionen zwischen den beiden Systemen asynchron und fehlertolerant macht. Es gibt nun jede Menge Netzwerk-Hardware zwischen Ihren beiden Systemen, über die Sie keine Kontrolle haben. Datenpakete werden verspätet oder gar nicht ankommen. Falls Ihre Webseite nur unter der Bedingung funktioniert, dass der andere Service Daten unmittelbar zurücksendet, wird Ihre Webseite aufhören zu funktionieren.

Sicherheit ist auch ein Thema, da Ihre zuvor “interne” Systemkommunikation nun über das große, böse Internet laufen wird. Es ist eine gute Idee, ein VPN einzurichten, oder aber, falls Sie Ihre interne Service-Kommunikation über HTTP laufen lassen, sicherzustellen, dass alle Ihre Services eine zuverlässige Authentifizierung haben und über SSL laufen.

Letztlich erhöht sich die Komplexität von Entwicklung und Personaleinsatz, wenn Sie den Übergang von einer monolithischen App zu multiplen Services machen, die unabhängig voneinander gehostet werden. Die Einführung neuer Funktionalitäten erfordert einen erheblichen Koordinationsaufwand, um sicherzustellen, dass alle Services weiterhin zusammenarbeiten.

Schlussfolgerung

Falls es Ihnen schwerfällt, herauszufinden, ob eine öffentliche oder private Cloud die richtige für Ihre App ist, könnte die Antwort lauten: beide.

Schauen Sie sich Ihre Applikation genau an. Es könnte sein, dass es zwei (oder mehr) kleinere apps gibt, die versuchen, sich durchzusetzen, und wenn sie es tun, sollte es viel einfacher sein, die richtige Hosting-Umgebung für jede von ihnen zu finden.