Cloud-Computing im Großkonzern

Cloud-Computing hat die einfache Bereitstellung von IT-Ressourcen für ein sehr breites Publikum ermöglicht. Cloud-Anwender reservieren IT-Ressourcen wie virtuelle Server oder Container-Laufzeitumgebungen innerhalb von Minuten und bezahlen nur für die benötigten Ressourcen. Das National Institute of Standards and Technology [NIST] des Handelsministeriums der USA hat die wichtigen technischen Eigenschaften von Clouds wie folgt zusammengefasst (links in Abbildung 1):

Selfservice-Schnittstelle (Self-Service Interface): Cloud-Kunden können Ressourcen reservieren, konfigurieren, nutzen und freigeben, ohne dass sie mit einem Mitarbeiter des Cloud-Anbieters persönlich interagieren müssen. Vollautomatisierte Prozesse ermöglichen eine agile Nutzung der Cloud und sind die Basis für wettbewerbsfähige Preise.

Schnelle Elastizität (Rapid Elasticity): Die Größen der einer Cloud zugrunde liegenden IT-Ressourcen (Netzwerk, Server, Speicher usw.) emulieren das Gefühl, dass Ressourcen ohne Verzögerung und in beliebiger Anzahl verfügbar sind. Diese Eigenschaft trägt auch wesentlich zur agilen Nutzbarkeit von Cloud-Umgebungen bei.

Ressourcenzusammenfassung (Resource Pooling): Cloud-Anbieter bündeln alle Hardware-Ressourcen, die die Cloud-Umgebung umfasst, und teilen sie zwischen allen Cloud-Kunden. Es gibt somit keine oder kaum dedizierte Ressourcen für einzelne Kunden. Daher kann der Cloud-Anbieter wettbewerbsfähige Preise anbieten, indem er Skaleneffekte nutzt. Der Cloud-Kunde profitiert von dieser Kostensenkung.

Gemessene Servicenutzung (Measured Service): Der Cloud-Provider misst den Ressourcenverbrauch jedes Kunden und rechnet entsprechend ab. Dadurch kann der Kunde große Vorabinvestitionen (Capital Expenditures – CAPEX) vermeiden und nur die laufenden Kosten von Projekten (Operational Expenditures – OPEX) planen. Die OPEX eines Projekts steigen also mit zunehmender Nutzung der erstellten Cloud-Anwendungen. Das Kapitalrisiko bei der Umsetzung neuer Business-Cases in der Cloud wird reduziert: Cloud-Kunden können hohe Vorabinvestitionen in die IT-Infrastruktur vermeiden, da die Betriebskosten erst mit zunehmender Nutzerzahl steigen. In der Regel bedeutet dieser Anstieg der Nut­zerzahlen, dass die Anwendung auch mehr Einkommen erwirtschaftet.

Im Folgenden bewerten wir die Auswirkungen einer solchen Cloud-Umge­bung auf Beschaffungsprozesse, IT-Anwendungs­architektur und Teamorgani­sation.

Beschaffung von Cloud-Ressourcen

In der fertigenden Industrie sind vor allem Automobilunternehmen weitgehend auf Lieferanten angewiesen. In Werkverträgen ist detailliert festgelegt, welche Anwendungsfunktionen ein IT-Lieferant zu einem Festpreis umsetzen und betreiben muss. Alle Änderungen an diesem Gewerk erfordern vertragliche Änderungsanfragen, die zu höheren Kosten führen.

In einer derartigen Geschäftsbeziehung ist es nur natürlich, dass in Verträgen oft festgelegt ist, dass der Auftraggeber Cloud-Computing nicht direkt nutzt. Stattdessen verlagern Auftraggeber Entwicklung und Betrieb von IT-Anwendungen sowie die damit verbundene Nutzung von Clouds an Lieferanten. Daher ist der Cloud-Kunde nicht direkt der Auftraggeber, sondern der Lieferant, wie in Abbildung 2 dargestellt. Leider kann diese Geschäftsbeziehung die Vorteile von Cloud-Eigenschaften drastisch reduzieren, wie in Abbildung 3 dargestellt:

Die flexible Nutzung von Cloud-Ressourcen, die durch die Self-Service Interface- und die Rapid Elasticity-Eigenschaft gewährleistet ist, wird verhindert, wenn der Vertrag einen Festpreis enthält und somit die Anzahl der Cloud-Ressourcen auf eine bestimmte Anzahl festlegt. Erhöhungen der Cloud-Ressourcen können zu vertraglichen Änderungsanfragen führen. Der organisatorische Aufwand für solche Änderungsanfragen einschließlich Genehmigung, Budgetierung und Abrechnung zwischen Lieferant und Auftraggeber verhindert die flexible Verfügbarkeit von IT-Ressourcen, die die Cloud technisch ermöglicht.

Auch die durch die Resource Pooling-Eigenschaft ermöglichte Kostenreduzierung kann je nach vertraglicher Gestal­tung begrenzt sein. Da der Lieferant die Cloud für den Auftraggeber nutzt, müssen zu den eigentlichen Preisen für Cloud-Ressourcen auch die Aufwände des Lieferanten für die Verwendung der Cloud-Selfservice-Schnittstelle zur Implementierung der Ressourcenspezifikation des Auftraggebers hinzukommen. Daher kann es erforderlich sein, dass der Lieferant die Kosten für die Cloud-Ressourcen in Abhängigkeit vom vertraglichen Interaktionsmodell zwischen Auftraggeber und Lieferant erhöht.

Schließlich können Verträge OPEX in CAPEX umwandeln. Der in Werkverträgen ausgehandelte Festpreis zielt darauf ab, das Kostenrisiko auf den Lieferanten zu verlagern. Der Lieferant profitiert jedoch von der Measured Service-Eigenschaft der Cloud und muss daher nur für die tatsächlich verbrauchten Cloud-Ressourcen bezahlen. Der Lieferant bietet dem Auftraggeber jedoch einen festen Ressourcenpreis an.

Während dies für den Auftraggeber einfacher in seiner internen Budgetplanung zu berücksichtigen ist, maximiert dieser Beschaffungsansatz aber seine Cloud-Kosten. Oft liegt der Fokus bei unternehmensinternen Budgetplanungen auf Vorhersehbarkeit. Für eine effiziente Nutzung von Clouds muss sich dieser Fokus verschieben und das Kostenri­siko verstärkt vom Auftraggeber getragen werden. Der Cloud-Kunde sollte somit der Auftraggeber bleiben (siehe Kasten 1), auch wenn dies bedeutet, ein erhöhtes Kostenrisiko zu tragen.

Ein weiterer kritischer Aspekt der Beschaffung von Cloud-Ressourcen ist das Lizenzmodell des Cloud-Anbieters. Die Standardisierung von Cloud-Ressourcen wurde bis heute nur langsam eingeführt. Dies macht Cloud-Angebote technisch schwer zu vergleichen und dies gilt noch mehr in Bezug auf ihr Lizenzmodell. Cloud-Anbieter beschreiben mit eigenen Begriffen ihre Cloud-Services für Datenverarbeitung, Datenspeicherung und Anwendungskommunikation. Die lizenzierte Einheit und daher auch die Einheit, auf der die verbrauchsbasierte Abrechnung (Measured Service) basiert, können sich erheblich unterscheiden.

So kann beispielsweise eine Laufzeitumgebung für Cloud-Anwendungen nach verbrauchten Ressourcen wie RAM oder CPU-Zyklen abrechnen. Alternativ kann das Angebot auch nach der Anzahl der gehosteten Anwendungen, Container, Zugriffe auf Anwendungen usw. abgerechnet werden. Lizenzierungsmodelle können dabei einen erheblichen Einfluss auf die Anwendungsarchitektur haben, weshalb Cloud-Kunden die Lizenzbedingungen sorgfältig prüfen müssen.

Im Folgenden wird beschrieben, dass Cloud-Anwendungen skaliert werden müssen, um die Performanz zu erhöhen, indem sie zur Laufzeit weitere Ressourceninstanzen hinzufügen. Eine weitere architektonische Eigenschaft, die in Cloud-Anwendungen angestrebt wird, ist die der Verteilung von Anwendungsfunktionalität über mehrere Cloud-Ressourcen, sodass die Anwendungsfunktionalität nicht nur von einer einzigen Anwendungsinstanz bereitgestellt wird. Stattdessen ist die Funktionalität auf mehrere Anwendungskomponenten verteilt, die oft als Microservices bezeichnet werden.

Wenn der Cloud-Anbieter nun aber Instanzen von Anwendungskomponenten lizenziert und verbrauchsbasiert abgerechnet, besteht ein erheblicher Anreiz für Anwendungsentwickler, monolithische Anwendungen zu erstellen, um Kosten zu vermeiden (siehe Kasten 2). Eine solche Anwendungsarchitektur würde aber die technischen Vorteile einer Cloud drastisch reduzieren.

Eigenschaften von Cloud-Anwendungen

Um eine Cloud-Umgebung effizient zu nutzen, müssen Cloud-Anwendungen fünf Eigenschaften implementieren. Wir nennen solche Anwendungen IDEAL Cloud Applications ([Feh14], siehe Kasten 3) entsprechend den implementierten Eigenschaften:

Isolierter Zustand (Isolated State): Eine einzelne Cloud-Ressource, wie beispielsweise ein virtueller Server, gewährleistet oft nur eine geringe Verfügbarkeit. Daher sollte die Cloud-Anwendung keine Zustandsinformationen in ihren Anwendungskomponenten speichern, die auf einzelnen Cloud-Ressourcen gehostet werden. Stattdessen wird der Anwendungszustand (Application State), also die von der Anwendung verwalteten Daten, in Cloud-Speicherangeboten gespeichert. Der Sitzungszustand (Session State), also Daten über die Interaktion der Benutzer mit der Cloud-Anwendung, wird bei jeder Anfrage an die Anwendung durch den Client (z. B. Browser) bereitgestellt.

Verteilung (Distribution): Da die Cloud selbst ein großes verteiltes System ist, ist auch die Anwendungsfunktionalität selbst auf viele Anwendungskomponenten verteilt.

Elastizität (Elasticity): Die Cloud-Anwendung muss in der Lage sein, ihre Leistung zu steigern, indem sie die Anzahl der Anwendungskomponenteninstanzen erhöht. Dieser Prozess wird als „Scaling Out“ bezeichnet. Im Gegensatz dazu würde ein sogenanntes „Scaling Up“ die Leistung erhöhen, indem die Fähigkeiten einer einzelnen Anwendungsinstanz erhöht werden, zum Beispiel durch Hinzufügen von RAM zu einem Server. Elastizität bedeutet nun nicht nur, dass die Leistung erhöht werden kann, sondern auch, dass die Leistung verringert werden kann, wenn sich die Auslastung von Anwendungsinstanzen verringert.

Automatisiertes Management (Automated Management): Die Anwendung muss während ihrer Laufzeit automatisch auf bestimmte Ereignisse reagieren. Wenn beispielsweise eine Cloud-Ressource ausfällt, müssen betroffene Anwendungsinstanzen automatisch ersetzt werden. Wenn mehr Leistung benötigt wird, muss die Anwendung weitere Instanzen ihrer Komponenten hinzufügen.

Lose Kopplung (Loose Coupling): Da Anwendungsinstanzen auf viele Cloud-Ressourcen verteilt sind und sie kontinuierlich hinzugefügt und entfernt werden, sollten sie sich hinsichtlich Verfügbarkeit, Datenaustauschrate und Datenformat nicht gegenseitig beeinflussen.

Unternehmenshierarchien und die Cloud

Cloud-Computing ist nicht nur eine technologische Revolution, sondern beeinflusst auch Teams und Organisationen, die Cloud-Technologien einsetzen. Die Mitte von Abbildung 3 zeigt einen exemplarischen Application-Stack, der die Anwendungskomponenten und ihre Laufzeitumgebung beschreibt: Die Benutzeroberfläche (User-Interface) läuft auf einem Webserver. Diese Komponente integriert verschiedene funktionale Komponenten, die Benutzerkonten (User-
Accounts), Veranstaltungen (Events) und Abrechnungen (Billing) verwalten.

Jede der integrierten Funktionskomponenten greift auf eine Datenbasis zu, die jeweils auf einer anderen Datenbanktechnologie betrieben wird. Eine Broker- und Integrationskomponente stellt sicher, dass Datenänderungen in einer der funktionalen Komponenten korrekt in anderen Komponenten abgebildet werden.

Bei einer cloud-basierten Entwicklung würde man diesen Application-Stack in Microservices aufteilen, die von cross-funktionalen Teams erstellt werden [New15]. Diese Organisationsstruktur wird daher auch im Verlauf dieses Artikels empfohlen. Bestehende Teams und Organisationsstrukturen, die einen solchen Application-Stack erstellen und betreiben, sind aber oft so organisiert, wie rechts in Abbildung 3 zu sehen ist: Jedes Team behandelt eine Anwendungskomponente und ihre Laufzeitumgebung. Daraus ergibt sich

• ein UI-Team für die Benutzeroberfläche,
• ein Application-Team für die funktionalen Komponenten,
• ein Integration-Team für die Integrationslogik und
• ein Database-Team für die Verwaltung und den Betrieb der Datenbanken.

Diese Teams kommunizieren meist asynchron über ein Ticketing-System. Ein Ticket beschreibt dabei zum Beispiel eine benötigte Änderung in einer Anwendungskomponente, die eine aufrufende Anwendungskomponente benötigt.

Werden Teams an externe Lieferanten ausgelagert, sind diese Ticketing-Systeme auch die Schnittstelle zu den Mitarbeitern des Lieferanten. Somit kann Outsourcing das Routing von Tickets in den Teamhierarchien verkomplizieren: Ein Lieferantenvertreter auf Auftraggeberseite schreibt das Ticket und ordnet es dem jeweiligen Vertreter auf Lieferantenseite zu. Je nach Komplexität der Umgebung, in der die Anwendungskomponente gehostet wird, muss der Lieferantenvertreter dieses Ticket möglicherweise in weitere Tickets für verschiedene Abteilungen auf der Lieferantenseite aufteilen.

So kann beispielsweise eine Erweiterung der Benutzeroberfläche eine Neukonfiguration auf dem von einem Lieferantenteam verwalteten Webserver erfordern. Diese Änderung betrifft auch die von einem anderen Lieferantenteam verwaltete Netzwerkumgebung sowie den von einem weiteren Lieferantenteam verwalteten virtuellen Server. Lieferanten können wiederum einen Teil ihrer eigenen IT-Infrastruktur auslagern, sodass sich die Teams, denen der Vertreter des Lieferanten Tickets zuweist, möglicherweise wieder in einem anderen Unternehmen befinden.

Eine solche Organisation von IT-Teams, die sich aus der Aufteilung des Application-Stacks und dem Outsourcing wesentlicher Teile dieses Stacks ergibt, behindert den effizienten Einsatz von Cloud-Technologien erheblich. Cloud-Computing lebt von der durchgängigen Automatisierung aller Teile des Application-Stacks und der relevanten Verwaltungsaufgaben.

Auf der linken Seite von Abbildung 3 ist ein exemplarisches Tooling von Amazon Web Services [AWS] für dieses Konzept namens Infrastructure as Code (IaC) abgebildet. Mithilfe von Automatisierungstechnologien kann ein Anwendungsentwickler die gesamte Anwendung und ihre Laufzeitumgebung so beschreiben, wie er die Anwendungsfunktionalität beschreibt: als Code. Basierend auf diesem Code können Cloud-Automatisierungsfunktionen Aufgaben wie die Bereitstellung der Laufzeitumgebung, die Konfiguration von Firewalls und Netzwerken, das Bereitstellen von Speicherplatz usw. übernehmen. Änderungen, die bisher manuelle Aufgaben und menschliche Interaktion erfordern, werden durch diese Automatisierung der Cloud-Infrastruktur ersetzt.

Ein Unternehmen, das Teams entlang des Application-Stacks aufgebaut und Teile dieser Teams ausgelagert hat, wird erhebliche Schwierigkeiten bei der Einführung neuer Cloud-Technologien haben, da die Ansätze für das IT-Management nicht kompatibel sind: Die Cloud-Automatisierung ist nur dann erfolgreich, wenn der Entwickler das Modell zur Beschreibung der Anwendungskonfiguration parallel zum funktionalen Anwendungscode erstellen kann. Ein zentrales Automatisierungssystem interpretiert diesen Code, um die Cloud-Umgebung für eine Anwendung zu konfigurieren und zur Laufzeit zu verwalten.

Wenn die Verantwortlichkeiten für diese Arbeiten auf verschiedene Teams und sogar über Lieferanten hinweg verteilt sind, muss das Unternehmen zunächst einen organisatorischen Wechsel vollziehen, um die Verantwortlichkeiten auf Cloud-Entwicklungsteams zu konzentrieren. Andernfalls wird die Einführung von Cloud-Computing keinen Nutzen bringen. Die Einführung von Cloud-Technologien in eine unpassende Organisationsstruktur kann die Effektivität sogar reduzieren: Da sich alle Teams nun auf eine gemeinsame Beschreibung des Application-Stacks in Form von IaC einigen müssen, sind zusätzlicher Aufwand und Koordination zwischen diesen Teams und den Zulieferern erforderlich.

Die Selfservice-Eigenschaft einer Cloud stellt die technologische Basis für eine organisatorische Änderung von Teamorganisationen dar, wie in Abbildung 4 dargestellt. Cloud-Dienste für Datenverarbeitung, Datenspeicherung und Anwendungskommunikation können so durch das Entwicklerteam selbst konfiguriert werden. Somit kann eines dieser cross-funktionalen Teams die volle Ende-zu-Ende-Verantwortung für seine Anwendungsfunktion (User Accounts, Event Services, Billing) übernehmen.

Das UI-Portal-Team entwickelt nicht mehr das komplette User-Interface, sondern erlaubt es den anderen Teams, an bestimmten Stellen ihre eigenentwickelten Micro-Frontends [Fow19] zu integrieren. Die Broker- und Integrationskomponente wird nun nicht mehr von einem Team bereitgestellt, sondern vom Cloud-Anbieter. Die cross-funktionalen Teams integrieren dort über das erwähnte Selfservice-Interface die jeweils für ihre Anwendungsfunktion notwendigen Datenaustausche.

Im Gegensatz zur Ticket-zentrischen Teamorganisation erlaubt cross-funktionale Teamorganisation auch eine wesentlich bessere Skalierung des Arbeitsmodells (siehe Kasten 4). Mit steigender Anzahl an Anwendungsfunktionen entsteht nie eine Überlastung bestimmter zentraler Teams. Bei der Ticket-zentrischen Teamorganisation werden vor allem das User-Interface- und das Integration-Team oft mit steigender Anzahl anderer Entwicklerteams überlastet. Die konsequente Anwendung der Selfservice-Eigenschaft von Cloud-Umgebungen verhindert diesen Effekt.

Fazit

Cloud-Computing hat viele Vorteile gebracht, wie einen einfacheren und flexibleren Zugriff auf IT-Ressourcen. Davon können Unternehmen jedoch nur profitieren, wenn sie ihre Beschaffungsprozesse, IT-Anwendungsarchitekturen und Teamorganisationen für eine effiziente Nutzung von Clouds anpassen.

Um die Vorteile der Cloud vollständig zu nutzen, sollte der Einkauf sicherstellen, dass das Unternehmen der direkte Kunde eines Cloud-Providers ist und bleibt. IT-Anwendungen sollten die Eigenschaften einer IDEAL Cloud Application implementieren, um die Anwendung auf die Cloud-Laufzeitumgebung anzupassen und ihre technischen Möglichkeiten optimal zu nutzen.

Schließlich muss ein Unternehmen die Verantwortlichkeiten für Entwicklung und Betrieb von Cloud-Anwendungen in der Organisationshierarchie bündeln, indem Entwicklung und IT-Infrastrukturmanagement in cross-funktionalen Teams vereint werden, um von der Automatisierung von Cloud-Computing zu profi­tieren

Literatur & Links

[AWS] AWS CloudFormation, siehe: https://aws.amazon.com/de/cloudformation/

[CCP] Ch. Fehling, Cloud Computing Patterns, siehe: https://www.cloudcomputingpatterns.org

[Feh14] Ch. Fehling, F. Leymann, R. Retter, W. Schupeck, P. Arbitter, Cloud Computing Patterns, Springer, 2014

[Fow19] C. Jackson, Micro Frontends, martinFowler.com, 2019, siehe:
https://martinfowler.com/articles/micro-frontends.html

[New15] S. Newman, Building Microservices, O’Reilly, 2015

[NIST] P. Mell, T. Grance, The NIST Definition of Cloud Computing, National Institute of Standards and Technology, 2011, siehe:
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf