Was XaaS bedeutet

Grundsätzlich ist davon auszugehen, dass XaaS als IT-übliche Abkürzung für „Anything as a Service“ oder „Everything as a Service“ steht. Automatisch erschließen sich diese Begrifflichkeit und die dahinter stehenden Themen nicht. „Was aber genau ist XaaS?“, „Welche Entwicklungen sind damit verbunden?“, „Warum befasst sich die IT überwiegend mit „As A Service“-Themen?“, und „Aus welchem Grund etabliert sich eine weitere Abstraktion von der physikalischen Serverinfrastruktur?

Wenn man ein wenig recherchiert und sich auf „As A Service“-Themen fokussiert, wird man schnell fündig. Es gibt eine Menge Leistungen:

Bezogen auf den Betrieb einer physikalischen Infrastruktur bauen die in der IT üblichen As-a-Service-Produkte aufeinander auf und/oder bilden Schnittmengen. Das macht es für den Betrachter und Nutzer schwierig und für uns als Dienstleister komplex, einen sauber abgegrenzten Service zu definieren. Da gibt es zum einen die bekannten Servicebereiche „Infrastructure as a Service (IaaS)“, „Platform as a Service (PaaS)“ und „Software as a Service (SaaS)“:

Die drei Grundpfeiler der As-a-Service-Typen

Mit den folgenden Definitionen lösen wir das Begriffswirrwarr auf.

Software as a Service (SaaS)

Bei dem Modell Software as a Service (SaaS) betreibt ein externer IT-Dienstleister sowohl Software als auch IT-Infrastruktur eines Kunden. Der Kunde nutzt die Anwendung als Internetservice und zahlt dafür eine nutzungsabhängige Gebühr. Die Anschaffungs- und Betriebskosten entfallen überwiegend. Der Serviceanbieter übernimmt die IT-Administration und den Betrieb inklusive der Wartung und des Einspielens von Updates. Typische Anwendungsbereiche sind Content-Management-Systeme (CMS), das Customer Relationship Management (CRM), Shop-Systeme oder Groupware.

Vorteile:

• geringes Investitionsrisiko
• übersichtliche Kosten
• schneller Zugriff über das Internet
• keine Installation notwendig
• Zugriff unabhängig vom Endgerät
• in der Regel hohe Skalierbarkeit und Flexibilität
• Fokus auf das Kerngeschäft

Nachteile:

• Abhängigkeit vom Serviceanbieter (Vendor-Lock-in)
• Abhängigkeit der Anwendungsgeschwindigkeit vom verfügbaren Internet
• kaum Möglichkeit für individuelle Anpassungen (beziehungsweise nur mit entsprechendem IT-Know-how)
• teilweise nur geringe Datensicherheit
• rechtliche Unsicherheiten (zum Beispiel bei den Vorschriften zur Auftragsdatenverarbeitung – ADV)

Platform as a Service (Paas)

Beim Ansatz Platform as a Service (PaaS) stellt der Anbieter eine IT-Plattform zur Softwareentwicklung in der Cloud als Dienst zur Verfügung. Dabei handelt es sich entweder um eine Laufzeitumgebung oder um eine Umgebung, die mit geringem Verwaltungsaufwand und ohne Anschaffung entsprechender Hardware und Software nutzbar ist. PaaS unterstützen den gesamten Softwarelebenszyklus inklusive Design, Entwicklung, Test, Live Going, Betrieb und Management. Der Kunde zahlt für den Service eine nutzungsabhängige Gebühr. Neben Adacor zählen SAP HANA® Cloud Platform, Google App Engine und Windows Azure zu den bekanntesten Anbietern von Platform Services.

Vorteile:

• geringes Investitionsrisiko
• übersichtliche Kosten
• hohe Skalierbarkeit und Verfügbarkeit
• kaum Aufwand durch Systemadministration
• schnelle Umsetzung von Softwareprojekten (kurze Time-to-Market-Zyklen) durch Fokus auf Entwicklung
• Möglichkeit des standortübergreifenden Arbeitens

Nachteile:

• Abhängigkeit vom Serviceanbieter (Vendor-Lock-in) (nicht so bei Open-Source-Lösungen)
• mangelnde Portierbarkeit in andere Systeme
• Eignung der Dienste zum Großteil nur für in sich abge- schlossene Applikationen ohne komplexe Datenverarbeitung und Anwendungsdesign
• Zugriff in der Regel nur über APIs (kein direkter Zugriff auf das Betriebssystem möglich)

Infrastructure as a Service

Beim Modell Infrastructure as a Service (IaaS) stellt der Dienstanbieter dem Kunden eine virtuelle Rechnerinfrastruktur (Server, Rechenleistung, Netzkapazitäten, Kommunikationsgeräte, Archivierung-/ Backup-Systeme) oder andere Teilkomponenten „on demand“ (bei Bedarf) zur Verfügung. Der Kunde zahlt für den Service eine nutzungsabhängige Gebühr. Adacor stellt unterschiedliche Dienste im Bereich IAAS bereit. Der bekannteste Anbieter auf dem Markt ist Amazon Web Service (AWS).

Vorteile:

• keine Investitionen für eigenes Equipment nötig
• bezahlbare Kosten bei einmaliger Anwendung
• hohe Skalierbarkeit
• Abfangen von Belastungsspitzen
• voller Zugriff auf die virtuelle Hardware (eigene Installationen möglich)

Nachteile:

• Abhängigkeit vom Serviceanbieter (Vendor-Lock-in)
• Intransparenz bei Datenschutz und -sicherheit

Neben den drei gängigen Cloud-Schichten gibt es einige exotische Themen wie Storage as a Service, Container as a Service oder Monitoring as a Service. Die folgenden Grafiken bieten dazu einen guten Überblick.

Interessant ist, dass sich die Grundpfeiler der IT (hier als Pyramide dargestellt) aus Sicht des IT-Betriebs nicht geändert haben und sich zukünftig nicht ändern werden. Wir bauen Server auf – Infrastructure as a Service (IaaS) – schaffen Voraussetzungen zum Betrieb einer Software – Platform as a Service (PaaS) – und installieren die Software, die wir dem Anwender zur Verfügung stellen – Software as a Service (SaaS). Warum also der Abstraktionsgrad, Softwareleistungen zu extrahieren und als eigenständige Leistungen zu präsentieren?

IT betrifft alle Unternehmensaktivitäten

Darüber habe ich eine Zeit lang nachgedacht. Entgegen meinen zuerst komplex ausgedachten Erklärungen empfinde ich diese Entwicklung durchaus als logisch. IT und Digitalisierung sind aus praktisch keinem Geschäftsfeld mehr wegzudenken. Sie betreffen jeden, der in der Wertschöpfungskette eines Unternehmens direkt oder indirekt mitarbeitet. Das bedeutet, dass der Kontakt mit IT-Systemen nicht mehr ausschließlich den Fachkräften aus der IT vorbehalten ist. Entscheidungen zur Nutzung von IT-Systemen beziehungsweise IT-Services müssen auf einer Ebene getroffen werden, deren Entscheider keinerlei IT-Kenntnisse haben. Nun könnte man argumentieren, dass dies schon immer so war. Seit Nutzung von IT-Systemen in Unternehmen mussten mit IT-Themen weniger vertraute Entscheider sich auf die Empfehlungen ihrer IT-Fachkräfte verlassen. Dabei sollte man allerdings beachten, dass sich die Menge der IT-Systeme und IT-gestützten Prozesse vervielfacht hat. Häufig besteht der Bedarf an neuen Lösungen auch aus rein fachlichen Bedürfnissen verschiedener Abteilungen. Hier ist nicht mehr davon auszugehen, dass eine zentrale IT-Abteilung alle diese Entscheidungen verantworten kann. Denn dann würde der technische Leiter eines Unternehmens quasi zum zentralen Entscheider aller Prozesse werden.

Serviceanbieter stehen in der Verantwortung

Hierbei hilft es, eine Abstraktionsebene einzuführen und IT-gestützte Services, die für Nutzer und Entscheider sowie teilweise auch für versierte IT-Experten eine Blackbox darstellen, begrifflich abzukoppeln. Der Service (Nutzung, Input und Output) wird exakt definiert, sodass er für den Entscheider, der ihn als externe Dienstleistung einkauft, verständlich wird. Die Servicebeschreibung macht zwar die Blackbox ein wenig transparenter, um zum Beispiel Themen wie Datenschutz und Datensicherheit ausreichend beleuchten zu können, bis ins letzte Detail geht sie aber nicht. Technisch wird die Verantwortung für den Service komplett und flexibel an den Anbieter ausgelagert. Solange sich die vorher definierten Parameter in den gewünschten Rahmenbedingungen bewegen, ist alles in Ordnung. Um das beispielhaft darzustellen, möchte ich kurz den Betrieb einer Webanwendung am Beispiel WordPress auf zwei Wegen beschreiben.

Vor ein paar Jahren musste man, wenn man WordPress in einem Unternehmen einsetzen wollte, folgende Schritte gehen:

1. Anforderungsprüfung für die Software
2. Anmietung des passenden vServers/Servers
3. Benennung der verantwortlichen Mitarbeiter (Administratoren)
4. Installation der Software
5. Test
6. Einspielen der Inhalte
7. Test
8. Live Going

Heute kann man den gleichen Service mit weniger Schritten einkaufen:

1. Buchung des Services
2. Einspielen der Inhalte/
3. Lieferung eigener Input-Parameter
4. Inhaltlicher Test
5. Live Going

Dieses Vorgehen lässt sich in seiner Komplexität auf fast alle Services beliebig übertragen. Wichtig ist dabei, dass der Nutzer auf Basis der relevanten Parameter abstrahiert entscheiden kann und keine technische Entscheidung treffen muss. Die größte Herausforderung ergibt sich dann nur noch im Bereich des Datenschutzes und der Datensicherheit. Diese auszublenden, wie es in der Praxis bei Unternehmen hin und wieder zu beobachten ist, ist dabei nicht empfehlenswert. Vielmehr sollte die Beschreibung des Services umfassende Informationen über die Verarbeitungskette und Lagerung oder Verteilung der eingegebenen Daten liefern.

Sinnvolle Aufgabenverteilung von Vorteil

Wichtig ist, dass die Entscheidung zur Nutzung des Services von unterschiedlichen Stakeholdern, passend zum jeweiligen Kenntnisstand, getroffen werden kann. Die im Marketing operative Fachabteilung wird eher Software as a Service (SaaS)-Lösungen einkaufen, die Anwendungsentwicklung passend zum DevOps-Hype verstärkt im PaaS-Umfeld agieren und die interne IT bewegt sich in den Bereichen von Iaas oder NaaS. Solange die Beschreibung des Services ausreichend ist und den Entscheider mit allen nötigen Informationen versorgt, schafft die Abstraktion zum Service die Möglichkeit, dass auch IT-fremde Personengruppen IT-Leistungen einkaufen und ihre Geschäftsprozesse unterstützen können.