COMLINE Cloud ServicesCloud Computing Domain Principles

Christian GüntherHannover, 11.10.2015

Die COMLINE AG präsentiert

COMLINE Cloud Services Platform

Domain Principles

1. Business Value durch maßvolle, kontinuierliche Verbesserung

2. Erwartung nach unendlicher Kapazität3. 100%ige Service-Verfügbarkeit4. Agieren wie ein Public Cloud-Service

Provider5. Optimierte Ressourcen-Nutzung6. Verfügbarkeit als ganzheitlicher Ansatz 7. Minimieren personeller Unterstützung8. Vorhersagbarkeit 9. Gewünschtes Verhalten belohnen10. Einheitliche User-Experience

Prinzipien für die Anwendungs-domäne Cloud-Services

Domain Principles

Statement:  Der produktive Einsatz von Technologie muss sich immer am Business Value messen

Grundprinzip:  Alle Investitionen in IT-Services müssen einen Business Value liefern. Durch kontinuierliche Messung des Geschäftsbeitrages eines Services, können Verbesserungen an und für

diesen Service, direkt mit seinem Ertrag in Beziehung gesetzt werden. Dies ermöglicht Kunden und Anbieter, den maximalen Ertrag aus diesem zu ziehen. Folgt man diesem Prinzip, so wird sich die Servicelandschaft kontinuierlich verbessern und qualitativ, wie

quantitativ (Wertbeitrag) hochwertige Services anbieten. Unnötige, qualitativ eingeschränkte oder veraltete Services verschwinden sukzessive aus dem Portfolio.

Schlussendlich kann die Cloud-Service-Abteilung konkurrenzfähig am Markt agieren und einen Wertbeitrag zum Gesamtunternehmen bieten.

Implikation:  Die Hauptimplikation ist die Notwendigkeit, zur kontinuierlichen TCO und ROI Rechnung angebotener Services. Die zu beantwortende Fragen ist: Liefert der Service in seiner jetzigen Form noch einen Wertbeitrag? Wird die Frage verneint, muss überprüft werden, ob der Service in sich ausreichend ist, oder durch andere

(externe Anbieter, wie interne Dienste) erfolgreicher angeboten wird. Im größeren Rahmen muss regelmäßig geprüft werden, ob die genutzte Service-Architektur noch ein adäquates

Kosten/Nutzen-Verhältnis bietet.

Business Value durch maßvolle, kontinuierliche Verbesserung

Statement:  Aus Kundensicht muss ein Cloud-Service mit praktisch grenzenloser Kapazität angeboten werden. Kapazität (wie

Performance, Verfügbarkeit oder Volumen) wird also nur durch den Preis, den der Kunde zu zahlen bereit ist, reglementiert.

Grundprinzip:  Historisch wurden IT Dienste nach den Maximalanforderungen von Auslastungspeaks gesized. Im Cloud-Services Umfeld ist dies erstens schwer vorhersehbar und zweitens potentiell extrem teuer, da

Ressourcen vorgehalten werden müssen, obwohl diese im Normalbetrieb gar nicht genutzt werden. Kunden sind nicht bereit Ressourcen zu zahlen, die sie nicht nutzen. Sie wollen Dienste, deren Skalierung sie

nach eigenen Anforderungen und Budget selbst hoch- runter-Sizen können.

Implikation: Cloud-Service Anbieter benötigen ein ausgereiftes Kapazitäts-Management, um Leistung OnDemand zu- und

abschalten zu können. Je mehr Services angeboten werden, umso wichtiger wird hierbei das Balancing der tatsächlich verfügbaren

Kapazitäten (im Sinne von verfügbarer Hardware und Netzbandbreite), gewichtet nach einer Quality-of-Service Strategy.

Um sowohl die QoS, als auch das Kapazitäts-Management sauber aufzusetzen, ist eine enge Zusammenarbeit des Anbieters mit seinen Kunden notwendig.

Erwartung nach unendlicher Kapazität

Statement:  Aus Kundensicht muss ein Cloud-Service immer verfügbar sein. Noch weiter geführt, erwarten Kunden

heutzutage die Möglichkeit, einen Service von überall und mit jedem Gerät nutzen zu können.

Grundprinzip:  Die 100% Verfügbarkeit eines Cloud-Service wird von Kunden vorausgesetzt. Sie lässt sich nicht, wie traditionell in der „internen IT“, mit einem entsprechenden Preisschild versehen. Kunden erwarten einfach, dass ein angebotener Service immer verfügbar ist, kommt es zu Ausfällen, wenden sie

sich über kurz oder lang anderen Angeboten zu.

Implikation: Traditionelle Hochverfügbarkeits-Konzepte setzen typischerweise auf hochpreisige Spezialsysteme auf und

gehen von der Prämisse aus, dass der Ausfall einer Komponente ein katastrophaler Sonderfall ist. Bei Cloud-Services sollte der Ausfall einer Komponente als alltäglicher „Normalzustand“ angesehen werden, der

den angebotenen Dienst (nach außen hin) nicht beeinträchtigt. Hierzu bedarf es einer verteilten Architektur ohne Single Point of Failure bei der sich einzelne Komponenten ohne

administrativen Aufwand zwischen Hardware-Umgebungen (wie einzelnen Servern oder ganzen Rechenzentren) und Laufzeitumgebungen automatisch verteilen lassen.

Direkte Methodenaufrufe müssen in verteilten Umgebungen durch Service-Aufrufe (über offene Protokolle und APIs) ersetzt und zentrale Dienste von vielen, oder gar allen Teilnehmern bereitgestellt werden.

Mit einer solchen Architektur kann, anstelle teurer Spezialsystemen, Commodity- Hard- und Software zum Einsatz kommen, wodurch einerseits die Kosten reduziert und andererseits auch gleich das Prinzip 2 (Erwartung nach unendlicher Kapazität) erfüllt wird.

100%ige Service-Verfügbarkeit

Statement:  Egal, ob es um interne oder nach außen gerichtete Cloud-Services geht. Die Cloud-Service Abteilung eines

Unternehmens sollte das gleiche Selbstverständnis wie ein öffentlicher Cloud-Service Provider haben.

Grundprinzip:  Die von einem Cloud-Service Provider angebotenen Dienste unterscheiden sich in ihrer Definition häufig von rein

intern genutzten IT-Ressourcen. Leistungen und Services werden mit den folgenden klar definierten Eigenschaften angeboten:

– Computer, Netzwerk und Storage Ressourcen werden von mehreren Anwendern gemeinsam genutzt. – Eindeutige, klar verständliche Beschreibung des angebotenen Dienstes– Eine nachvollziehbare Service Level Metrik zur Messung der Qualität des Dienstes (etwa Verfügbarkeit,

Performance etc.)– Nutzungsbasierte Abrechnung der Kosten durch die Nutzung des Service– Klar geregelte Verantwortlichkeiten, sowohl seitens des Anbieters als auch des Kunden (Nutzers)

Implikation:  Dienste mit der gleichen Professionalität wie einer der großen Cloud-Service Provider anzubieten, stellt vielfältige

Herausforderungen an die IT. So muss die IT ein klares Verständnis der von ihnen erreichbaren Service Level und verursachten Kosten haben. Kern dabei ist die Messung, Überwachung und Veröffentlichung von System- oder Dienst-Immanenten KPIs.

Agieren wie ein Public Cloud-Service Provider

Statement:  Die Cloud-Plattform sollte die vorhandene Infrastruktur möglichst effizient nutzen und sich automatisch an

geänderte Anforderungen anpassen.

Grundprinzip:  Optimierte Ressourcen-Nutzung ermöglicht Effizienz und reduziert die Kosten. Erreicht wird dies hauptsächlich durch Virtualisierung und die gemeinsame Nutzung der Ressourcen. Wenn vorhandene Ressourcen von mehreren Kunden gemeinsam genutzt werden, so erhöht dies die

Ressourcen-Auslastung und die vorhandene Infrastruktur wird effizient genutzt. Optimierung durch Virtualisierung ermöglicht viele der nachfolgenden Prinzipien und ermöglicht schlussendlich

reduzierte Kosten und Agilität. 

Implikation:  Die Anforderungen der anzubietenden Services an die Cloud-Plattform müssen bekannt und als Grundlage

sowohl der Architektur vor allem aber auch des Sizings genutzt werden. Das Effizienzlevel und die Effektivität der Cloud-Plattform ist direkt Abhängig von den Kriterien Zeit, Qualität und

Kosten. Wenn eine Infrastruktur auf minimierte Kosten getrimmt ist, muss die Effizienz durch maximales Ressourcen-Sharing erreicht werden. Das andere Extrem wäre eine Infrastruktur die auf maximale Agilität abzielt. In diesem Fall wird sich das Design auf die Reaktionszeit (Zu- und Abschalten weiterer Ressourcen) konzentrieren

Optimierte Ressourcen-Nutzung

Statement:  Die Sicherstellung der Verfügbarkeit einer Cloud-Service Infrastruktur und der darauf laufenden Cloud-Dienste

muss einen ganzheitlichen Ansatz verfolgen. Angebotene Dienste müssen den Ausfall von Netzwerk-, Hard- oder Software-Komponenten ohne eine Serviceminderung überstehen.

Grundprinzip:  Traditionell wurde dem Ausfall wichtiger IT-Ressourcen durch das redundantes Vorhalten der darunterliegenden

Hardware begegnet. Server waren mit redundanten Netzwerkkarten, Plattensubsystemen und Netzteilen ausgestattet. Sehr wichtige Dienste wurden über doppelt vorgehaltene Server mit Failover-Möglichkeiten abgesichert.

Dieser Ansatz erzeugt hohe Kosten (durch das doppelte Vorhalten von Hardware-Ressourcen) und ist darüber hinaus unflexibel, da die Ressourcen nur zu 50% für Anfragen der Clients genutzt werden können.

Ein elastischer Architekturansatz, der es Diensten erlaubt frei auf der darunterliegenden Plattform verschoben zu werden, ist häufig das kosteneffizientere Design. Bei diesem Ansatz wird vom Ausfall einzelner Komponenten ausgegangen. Die Cloud-Umgebung und die Cloud-Dienste werden so konzipiert, dass sie, ohne Service-Unterbrechung weiterarbeiten, auch wenn einzelne Knoten ausfallen.

Implikation:  Um elastisch auf Ausfälle reagieren zu können, müssen sowohl die Cloud-Infrastruktur, als auch die einzelnen

Dienste ganzheitlich auf alle denkbaren Ausfallsituationen hin konzipiert sein. Neben der obligatorischen Virtualisierung der Betriebsplattform sind vor allem die verteilte Architektur ohne Single

Point of Failure wichtige Elemente einer ganzheitlichen Konzeption.

Verfügbarkeit als ganzheitlicher Ansatz

Statement:  Der tagtägliche Betrieb einer Cloud-Plattform sollte mit minimalen Personalressourcen erfolgen.  

Grundprinzip:  Der Betrieb einer Cloud-Plattform unterscheidet sich teilweise erheblich vom Betrieb rein interner IT-Ressourcen. Die Nutzung (also wann oder woher Kunden angebotene Dienste in Anspruch nehmen) und damit einhergehend

die Servicezeiten, sind nicht mehr auf die eigenen Bürozeiten beschränkt. Zur Automatisierung einer Cloud-Plattform gehören entsprechend die Bereiche:

– User Self-Services – z.B. Benutzer suchen sich Dienste aus einem Store selbst aus und stoßen damit automatisch Prozesse, zur Abrechnung der genutzten Leistungen an

– Automatische Lastanpassung – z.B. automatisches starten und stoppen weiterer Instanzen Automation ist eines der charakteristischen Merkmale eines OnDemand Angebotes.

Implikation:  Die Cloud-Dienste Plattform muss Self-Service Funktionen zur Benutzerverwaltung (wie z.B. Benutzererzeugung,

Profil- und Rechteverwaltung) zur Verfügung stellen. Die Überwachung von Leistungsgrenzen der Plattform und der einzelnen Dienste muss mit administrativen

Automatismen zur Leistungsanpassung gekoppelt sein.

Minimieren personeller Unterstützung

Statement:  Eine Cloud-Plattform muss vorhersagbar auf Anfragen reagieren. Dies beinhaltet sowohl zugesagte

Leistungsparameter und deren verursachte Kosten, als auch Ausfall- und Fehlersituationen.

Grundprinzip:  Inkonsistente Quality-of-Service Level reduzieren das Vertrauen von Benutzern in die genutzten Ressourcen

genauso, wie überraschend hohe Kosten – etwa verursacht durch nicht eindeutig deklarierte Nutzungsgebühren. Konsistente und transparenter Service-Levels zeigen Kunden und Anwendern genau auf, welche Leistung sie zu

welchem Preis erhalten. Betriebsorganisationen können sich auf diese Erwartungshaltung einstellen und entsprechend agieren. Der Cloud-Service Anbieter muss zu jeder Zeit über Leistungsgrenzen und –möglichkeiten bescheid wissen. Nur hierdurch lässt sich die Erwartungshaltung der Kunden nach einem hohen Qualitätsstandard einerseits und

ein effizienter Betrieb andererseits garantieren.

Implikation:  Die Infrastruktur muss an darauf ablaufende Dienste eine konstante Leistung bereitstellen, um die

Vorhersagbarkeit auf Leistungsebene zu ermöglichen. Hierzu bedarf es einer, bis zu einem gewissen Grad homogenisierten Betriebsumgebung.

Zusätzlich dazu, sind geeignete Tools mit einem hohen Automatisierungsgrad einzusetzen.

ACHTUNG: Aus Sicht des Anwenders bedeutet Vorhersagbarkeit auch ein konsistentes Preisgefüge, mit berechenbaren Nutzungspreisen inklusive aller abhängigen Dienste und Komponenten.

Vorhersagbarkeit

Statement:  Stellen sie sicher, dass ihre Kunden, die mit einem Service einhergehende Kosten für Bereitstellung und Nutzung

stets im Blick haben und bieten sie Anreize, zur kosteneffizienten Nutzung der Dienste. Nur so können sie auch interne Kosten steuern und ein optimales Preis- Leistungsgefüge anbieten.

Grundprinzip: Im Gegensatz zu einer internen IT Abteilung, welche häufig als reines Cost-Center geführt wird, erwirtschaftet ein

Cloud-Service-Anbieter direkt einen Wertbeitrag für das Unternehmen. Kunden müssen vornehmlich Dienste angeboten werden, die einen direkten oder zumindest indirekten positiven

Wertbeitrag zum Unternehmen, oder zur Verbreitung der Plattform liefern. Der Cloud-Service Provider sollte klar definierte Kosten/Nutzen Vorgaben haben, nach denen Dienste ausgewählt

und Betrieben werden. Die verursachten Kosten und Erträge sollten kontinuierlich, zumindest aber monatsgenau abfragbar sein und

sowohl direkte als auch indirekte Kosten beinhalten.

Implikation:  Alle verursachten Kosten, welche nicht direkt einem oder mehreren Kunden zuzuordnen sind, müssen auf ihre

Notwendigkeit hin untersucht und bewertet werden. Hierzu bedarf es einer noch stärker optimierten Kosten/Nutzen-Rechnung, mit dem Ziel, nicht lukrative Dienste zu

identifizieren und möglichst aus dem Portfolio zu entfernen. Auf der anderen Seite sollten Dienste mit einem positiven Preis/Leistungsindex verstärkt zur Nutzung der Kunden

Gewünschtes Verhalten belohnen

Statement:  Auf der Cloud-Plattform angebotenen Dienste, müssen dem Anwender in einheitlicher Form, also mit einem

hohen Wiedererkennungsfaktor, angeboten werden. Diese „Corporate Cloud Identity“ ist nicht auf rein visuelle Aspekte beschränkt, sondern erstreckt sich auf alle

Phasen des Lebenszyklus eines Dienstes: Bereitstellung, Nutzung und Out-Phasing. Zusätzlich zur eigenen Corporate Cloud Identity müssen dem Anwender angebotene Dienste in zumindest

ähnlicher Form, wie die Dienste anderer Cloud-Anbieter, zur Verfügung gestellt werden.

Grundprinzip:  Kunden erwarten eine bestimmte Art der Nutzungsmöglichkeit von Cloud-Diensten. Hierzu zählen

– Service-Auswahl – etwa über einen Katalog oder Store.– Buchungsvorgang mit integriertem Bezahlprozess– Endgeräteunabhängige Nutzungsmöglichkeit – dies schließt in einigen Fällen auch die Nutzung über mobile

Endgeräte ein– Kündigung oder zeitweiliges „suspenden“ des Dienstes mit reduzierten Kosten

Implikation:  Die Cloud-Plattform muss Dienste in einfacher Form auffindbar machen, etwa über einen integrierten

Suchservice. Neukunden müssen sich einfach registrieren und Zahlungsmodalitäten festlegen, beziehungsweise auswählen

können. Alle angebotenen Dienste müssen ein gemeinsames Look-and-Feel mit einer einheitlichen User-Experience

aufweisen.

Einheitliche User-Experience

Kostenmodell

Das Kostenmodell für Cloud Services basiert auf folgenden Konzepten:

1. Kostentransparenz2. Nutzungsbasierter Preis

Kostenmodell Cloud Services

Kostentransparenz (sowohl nach Außen zum Kunden, als auch nach Innen, zu den eigenen Teams) ist als Cloud-Anbieter unabdingbar. Es ist ein fundamentales Konzept, wenn man als Geschäftsbereich Services und Dienste, wie ein Cloud Service Provider am Markt entwickeln und vertreiben will.

Durch exakte Definition der Kosten der Infrastruktur, Abbildung auf Ressource-Pools (mittels Service-Klassifizierung) und nutzungsbasierte Preismodelle können die Kosten eines Service ermittelt und damit ein präzises Preisgefüge abgebildet werden.

Serviceklassifizierung und Kostentransparenz zusammen ermöglicht dem Team aus Business Development, Produkt Management und Architekt fundierte Entscheidungen zur Entwicklung neuer Services zu treffen.

Anwendungen mit einer elastischen, verteilten Architektur können typischerweise zu einem geringeren Kostensatz betrieben werden, als monolithische Anwendungen, deren Verfügbarkeit etwa nur durch Redundanz erzielt wird.

Kostentransparenz hilft also auch bei der Entscheidung, ob ein bestehender Service neu entwickelt werden sollte, in der alten Form weiter betrieben und vertrieben wird oder evtl. ganz abzuschalten ist.

Kostentransparenz

Nutzungsbasierter Preis, Pay-as-you-Go oder OnDemand Pricing. Hinter diesen Namen steckt das Konzept, welches sich im Cloud-Service Bereich fast vollständig durchgesetzt hat: für einen Service nur dann etwas zu zahlen, wenn man ihn auch wirklich nutzt.

Im klassischen RZ- wird dagegen ein fixer Preis, zumeist direkt abgeleitet aus Anschaffungs-kosten (etwa Hardware o.ä.) plus SW-Lizenzen plus Betriebspauschale, angesetzt.

Dies führt dazu, dass Services häufig zu billig oder zu teuer angeboten werden.

Durch die bereits benannten Konzepte zur Serviceklassifizierung und Kostentransparenz lässt sich ein Service eher auf den Punkt kalkulieren und mit einem entsprechenden Preis versehen.

Pay As You Go – Ich zahle nur, was ich auch wirklich nutze

Nutzungsbasierter Preis

Christian GüntherPrincipal Solution Architect

Mobile: +49 1511 22 40 942E-Mail: christian.guenther@comlineag.de

COMLINE Computer und Softwarelösungen AG

Leverkusenstr. 54

DE - 22761 Hamburg

www.comlineag.de

Vielen Dank für Ihre Aufmerksamkeit.