Compute: Scale-Up vs. Scale-Out
Um kosteneffizient arbeiten zu können, sollte der Compute Tier bei einem SaaS-Angebot dynamisch mit der Anzahl der User wachsen, aber auch wieder schrumpfen können. Häufig wird bei einem Anstieg der User-Zahlen ein Scale-Up durchgeführt. Das heißt, der Server wird mit mehr Hauptspeicher, einer größeren Anzahl an Prozessoren, mehr Festplattenkapazität und mehr aufgerüstet. Dieses Szenario sollte vermieden werden, da bei weiterem Wachstum des Service zu einem bestimmten Zeitpunkt eine Aufrüstung des Servers nicht mehr möglich beziehungsweise wirtschaftlich darstellbar ist. Auch kann der Compute Tier bei sinkender User-Zahl nicht dynamisch wieder verkleinert werden.
Eine Alternative stellt hierbei das Scale-Out dar. Hier wird nicht die Kapazität eines einzelnen Servers erhöht, vielmehr wird die Last auf eine (theoretisch unbegrenzte) Anzahl von zusätzlichen, gleichberechtigten Servern verteilt. Sollten die jeweiligen Server statusbehaftete Informationen (beispielsweise Inhalt eines Warenkorbes) benötigen, so kann dieser Status auf zentrale Dienste wie Cache Services oder Datenbanken ausgelagert werden. Durch dieses Verfahren wird das Scale-Out des Service ermöglicht.
- 9 Basisanforderungen an einen Cloud-Vertrag
Die Entscheidung Cloud-Services zu nutzen, bedingt aus Sicht von IDC daher grundsätzlich, dass die Nutzung des jeweiligen Cloud-Service dem Unternehmen einen höheren Level in Bezug auf IT Sicherheit und Ausfallsicherheit bietet als vorher. Die folgenden Punkte zählt IDC zu Basisanforderungen in Vertragsverhandlungen. - 1. Zugangsrechte
Cloud-Services-Anbieter müssen in der Lage sein zu demonstrieren, dass die Kontrolle über Einstellungen, Aufsicht, Zugang des internen Personals jederzeit ausgeübt wird, damit Zuverlässigkeit und Integrität der internen Mitarbeiter sichergestellt ist. Ein Cloud-Anbieter sollte deshalb immer Identifikation und Zugriff mit geeigneten organisatorischen, personellen und technischen Maßnahmen absichern. - 2. Gesetzliche Compliance
Es bestehen nach wie vor große Unsicherheiten, welche Daten extern in welche Cloud-Variante verschoben werden dürfen. Deshalb sind "Datenspeicherung in Deutschland" (50 Prozent) sowie "Verträge nach deutschem Recht" (48 Prozent) aktuell die beiden wichtigsten Sicherheitsanforderungen der befragten IT-Entscheider an Hosted und Public Cloud-Anbieter. Obwohl schlussendlich immer der Kunde für die Einhaltung der gesetzlichen Compliance verantwortlich ist, sollte aber die Verantwortung für die Einhaltung der konsistenten Qualität der Arbeitsvorgänge seitens der Anbieter eingehalten werden. Die Verteilung der Haftung zwischen Cloud-Provider und Kunde muss eindeutig geklärt sein und in rechtlich-bindenden Verträgen festgehalten werden. Unabhängige Audits müssen beschrieben werden und die Lösung von widersprüchlichen Anforderungen muss definiert werden. Nur so erreicht man Transparenz. - 3. Anwendungszertifikate
Rechtsgültige Zertifikate sind ebenso eine Grundvoraussetzung für Cloud-Services, da diese bestätigen, dass das Unternehmen, welches für die Domain oder den Server verantwortlich ist, auch tatsächlich existiert. Nach Beobachtung von IDC steigt der Stellenwert von Standards und Zertifizierungen weiter stark an, denn sie schaffen Vertrauen und die Einhaltung von gesetzlichen Regularien lässt sich nachweisen. - 4. Datenursprung
Insbesondere in Deutschland sind die Datenschutzrechte stark ausgeprägt. Zudem werden die Cyberattacken nicht nur hartnäckiger sondern sie sind auch wesentlich raffinierter. Die Verträge müssen somit auch die Einhaltung der vielfältigen lokalen Datenschutzanforderungen sicherstellen, welchen außerdem einem konstanten Wandel unterliegen. - 5. Datentrennung
Da Public-Cloud-Services mandantenfähig sind und auf demselben Server oder Software-System mehrere Kunden bedienen, ist es essenziell, dass der Cloud-Hosting-Anbieter die Sicherheit zu jeder Zeit garantiert. Der Anbieter muss daher akzeptable Maßnahmen für das kontinuierliche Monitoring der Datenverarbeitung aufzeigen. - 6. Datenwiederherstellung (Recovery)
Für den Fall einer Störung oder Katastrophe muss der Anbieter in der Lage sein, die Daten wiederherstellen zu können. Auch dies sollte immer Vertragsbestandteil sein und sogar die maximale Ausfallzeit für verschiedene Vorfälle regeln. - 7. Transfer der Applikationen
Um Cloud-Services in die bestehende IT Landschaft zu integrieren und durchgängige Prozesse zu ermöglichen, sind in der Regel einige lokale Modifikationen notwendig. Dadurch können in der Regel Kosteneinsparungen erreicht werden. Gleichzeitig kann dies aber auch ein Hindernis für einen eventuellen Rücktransfer der Applikation darstellen. Es ist wichtig, vor allem auf die Interoperabilität der Lösungen auch vertraglich wert zu legen. Dies ist technisch gesehen ein anspruchsvoller Aspekt bei der Migration von Public-Cloud-Lösungen. Für die Befragten ist eine einfache Rückholung der Daten (35 Prozent) sowie die gesetzeskonforme und nachgewiesene Löschung aller Daten nach Anbieterwechsel (32 Prozent) besonders wichtig. - 8. Business Continuity
Unternehmen reorganisieren sich, schließen sich mit anderen zusammen und Rechenzentren werden konsolidiert. Cloud-Services Verträge sollten daher den Transfer der Daten zwischen verschiedenen Rechenzentren klar regeln, um den Betrieb auch bei großen Veränderungen jederzeit sicherzustellen. - 9. Monitoring und Reporting
ieser Aspekt kann insbesondere bei der Nutzung von Public-Cloud-Services komplex werden. Vor allem dann, wenn verschiedene Ansprechpartner die legale Verantwortung und die Kosten im Unternehmen dafür tragen. Die IT Abteilung sollte das Monitoring und Reporting idealerweise zentral übernehmen, um Synergien zu heben und Kosten zu senken.
Compute: Segregation of Concern
Nicht minder wichtig ist die Aufteilung des Service in Komponenten, welche eine eng eingegrenzte Problemstellung bearbeiten. Eine triviale Aufteilung in beispielsweise Frontend- und multiple Backend-Komponenten, welche unabhängig voneinander operieren können, kann als erster Schritt betrachtet werden. Diese Segregation of Concern ermöglicht es, rechenintensive Arbeiten sowohl asynchron als auch getrennt skalierbar von anderen Komponenten zu implementieren. Die notwendige Kommunikation der Komponenten untereinander kann durch bekannte Enterprise-Service-Bus-Technologien oder beispielsweise durch den Einsatz von internen Load-Balancern erreicht werden.
Durch Berücksichtigung von transienten Fehlern im Compute Tier wird eine weitere Stabilität erreicht. Hierbei handelt es sich um Fehler, die kurzfristig auftreten und durch einfache Wiederholung der Aktion gelöst werden. So kann zum Beispiel ein fehlerhafter Zugriff auf eine relationale Datenbank durch einfache Wiederholung gelöst werden, falls diese in einem Fail-Over-Cluster vom primären auf den sekundären Node gewechselt wurde.