Platform-as-a-Service - Definitionsansätze (Teil 1)

Die große PaaS-Konfusion

| Autor / Redakteur: Matthias Popiolek * / Florian Karlstetter

PaaS-Landkarte: Die Hauptbereiche von Platform-as-a-Service.
PaaS-Landkarte: Die Hauptbereiche von Platform-as-a-Service. (Bild: ISG Information Services Group)

Leider gibt es derzeit keine einfache und eindeutige Antwort darauf, was genau unter PaaS fällt. Und es wird sogar noch komplizierter, wenn man in einem Unternehmen danach fragt, wer als „Owner” für PaaS verantwortlich ist. Ohne klare Definition und Verteilung der Verantwortlichkeit sind Unternehmen jedoch nicht in der Lage, zum Beispiel eindeutige Vereinbarungen mit PaaS-Anbietern zu treffen. Deshalb lohnt es sich, der Frage nachzugehen: Was ist PaaS überhaupt?

Zunächst einmal steht PaaS als Abkürzung für „Platform as a Service“ und ist das Cloud-Äquivalent für Middleware. Die Definition des National Institute of Standards and Technology (NIST) zeigt Abbildung 1 (siehe Bildergalerie).

Die Schwierigkeit dieser Definition besteht darin, dass sie auf einer hohen Ebene abstrahiert und nicht in der Lage ist, die einzelnen Aspekte und Abstufungen von PaaS genau zu beschreiben. Wer mit Service-Anbietern spricht oder sich im Internet über PaaS informiert, wird vor allem eines finden: Informationen über Paas-Frameworks. Dazu gehören in einer losen Reihenfolge Technologien, Produkte sowie Anbieter und der Kunde muss sich selbst einen Reim auf das Vorgefundene machen. Doch bevor wir in Details gehen, lohnt es sich eine PaaS-Landkarte zu zeichnen (siehe Abbildung 2).

Die drei Hauptbereiche von PaaS

Auf dem Framework-Level bieten PaaS-Frameworks eine Schnittstelle und die Möglichkeit, Nutzungsszenarien von Infrastruktur und Middleware vorzudefinieren und schnell auszurollen. Container Management als solches ist nicht Teil von PaaS, aber ein integraler Bestandteil, um Anwendungen in Form von Containern zu ermöglichen.

Im Hinblick auf Integrations- und unterstützende Frameworks ist die Bandbreite theoretisch unendlich. Analytics- oder IoT-Plattformen könnten hier genauso genannt werden wie die in der Abbildung aufgeführten Beispiele iPaaS (integration Platform as a Service) oder MEAP (Mobile Enterprise Application Platform) aus der Cloud. In der Praxis werden solche Plattformen jedoch gesondert behandelt.

Instanzenbasierte Services: Man nehme eine Middleware wie zum Beispiel eine Datenbank oder einen Applikationsserver und biete ihn in Form von „aaS“ an. Der NIST-Definition zufolge würde es sich hierbei um PaaS handeln. Da sich diese Services jedoch unabhängig von einem PaaS-Framework anbieten und verwenden lassen, ist es praktikabler, sie als „instanzenbasiert“ zu beschreiben.

Um eine möglichst detaillierte Definition zu erhalten, empfiehlt es sich, dieses Spektrum verschiedener Services und Servicetypen noch weiter auszudifferenzieren (siehe Abbildung 3).

PaaS Framework

Das PaaS-Framework bietet Entwicklern einen zentralen Zugang zu Infrastruktur- und Middleware-Services. Darüber hinaus ermöglicht es, Templates zu bauen, mit denen sich Umgebungen schnell in Betrieb nehmen lassen. Das ist eine der wichtigsten Unterschiede im Vergleich zu klassischen „Self Service“-Bestellportalen, die vielerorts bereits verwirklicht sind. In den herkömmlichen Bestellportalen müssen in der Regel einzelne Komponenten bestellt und dann noch zusammengefügt werden. Der wirkliche Mehrwert eines PaaS-Frameworks hingegen kommt zum Tragen, wenn es zum einen Container-Lösungen anbietet und mit einem Container-Management-System Hand in Hand arbeitet. Zum anderen sollte es das Motto „Fail fast, fail often“ unterstützen. Denn nur so können Entwickler schneller agieren und eine DevOps-Umgebung schaffen.

Am Anfang ist es in der Regel hilfreich, sich bei einem PaaS-Framework zunächst nur auf einen Anbieter zu stützen, der sowohl das Framework als auch die dazugehörigen Services bereitstellt. Im weiteren Verlauf und im Praxiseinsatz können und sollten dann weitere Anbieter und Vorgehensmodelle hinzukommen.

Wer ist verantwortlich?

Doch wer zeichnet in einem Unternehmen für das PaaS-Framework verantwortlich und wie sind die einzelnen Zuständigkeiten verteilt? Während die Verteilung im Einzelnen individuell erfolgen kann, so gibt es doch übergreifend einen empfehlenswerten Ansatz. Seine Grundannahme geht von einer bestimmten Rolle der IT-Infrastruktur-Abteilung in der Zukunft aus. Manche behaupten, dass sie generell überflüssig wird, da sowieso alles auf Software basiert. Doch werden zum einen die bestehenden Legacy-Systeme nicht einfach so verschwinden.

Und zum anderen will und sollte sich niemand in den Entwicklerteams mit der Auswahl und dem Management von Anbietern und Lieferanten auseinandersetzen müssen. Die Aufgabe der Entwickler besteht darin, die vorhandene Infrastruktur zu nutzen, um die bestmöglichen Anwendungen und digitalen Prozesse zu erstellen. Sie benötigen Auswahlmöglichkeiten und eine leichte Bedienbarkeit. Und genau darin liegen zukünftig die Aufgaben der Infrastruktur-Abteilung.

(Vor-)Auswahl von Paas-Services

Um der Entwickler-Community Wahlmöglichkeiten bieten zu können, muss zunächst eine Vorauswahl getroffen werden. Dies mag widersprüchlich klingen, aber die auf dem Markt verfügbaren Angebote sind so zahlreich, dass sie ausgesiebt werden müssen. Entsprechend benötigen Unternehmen jemanden, der Angebote bewerten kann und entscheidet, welche es in die Serviceauswahl schaffen. Dies hat zur Folge, dass sich die Infrastruktur-Abteilung von einer operativen Einheit zu einem Anbieter von Auswahlmöglichkeiten wandelt. Oder in anderen Worten: zu einem Anbieter von Plattformen. Diese Plattformen stammen von unterschiedlichen Providern und bieten eine – wenn auch kontrollierte – Vielfalt, welche das Unternehmen benötigt, um seine Anforderungen erfüllen zu können.

Einfache Bedienbarkeit

Wer die Wahl hat, fühlt auch die Qual – sei es bei einer einfachen Schnittstelle oder einer umfassenden Integration. Die Beschaffenheit einer Schnittstelle hängt sehr davon ab, welche technische Lösung für das jeweilige PaaS-Framework gewählt wurde. Die Infrastruktur-Abteilung kann von daher im Auswahlprozess den Hut aufhaben, doch es sind die Entwickler, die Schnittstellen verwenden müssen und sollten deshalb auch die Entscheidung darüber beeinflussen. Aber etwas verwenden bedeutet nicht automatisch auch, etwas zu betreiben. Selbst wenn der Betrieb des PaaS-Frameworks ausgelagert wurde, verbleiben das Provider-Management und operative Aufgaben im Unternehmen. An dieser Stelle ist die Infrastruktur-Abteilung der Zukunft am besten angesiedelt.

Doch hat Benutzerfreundlichkeit nicht nur mit Technologie zu tun. Eine der größten Veränderungen in der Devops-Welt besteht darin, dass immer mehr Infrastruktur-Know-how in die Entwickler-Community wandert. Dies bedeutet nicht, dass Entwickler nun wissen, wie sie einen Rechner in Serverschränke schrauben, aber welcher Service sich für welchen Zweck eignet. Dieser Wandel wird zusätzlich durch Software Defined Infrastructure (SDI), Containerlösungen und Mikroservices befeuert. Nichtsdestotrotz werden die Infrastrukturteams weiterhin gebraucht. Sie müssen im Sinne der Lösungsarchitektur aus den verfügbaren Angeboten den richtigen Mix für die Entwickler-Community zusammenstellen – und zwar noch mindestens ein paar weitere Jahre. Indem sie den Entwicklern diese Vorauswahl ersparen, tragen sie entscheidend zu deren Gefühl einer leichten Bedienbarkeit bei.

Die große PaaS-Konfusion (Teil 2)

Teil 2 des Artikels diskutiert ab 11:00 Uhr am 12.04.2017, welche ergänzenden Plattformen, Tools und Services ein PaaS-Framework benötigt, und welche Auswirkungen sich auf das Sourcing ergeben.

Die große PaaS-Konfusion (Teil 2)

Platform-as-a-Service - Definitionsansätze

Die große PaaS-Konfusion (Teil 2)

12.04.17 - Die Frage, was genau alles unter den Begriff PaaS fällt, ist nicht eindeutig zu beantworten. Kompliziert wird es auch, wenn man in einem Unternehmen danach fragt, wer als „Owner” für PaaS verantwortlich ist. Im zweiten Teil des Beitrags diskutiert der Autor, welche ergänzenden Plattformen, Tools und Services ein PaaS-Framework benötigt, und welche Auswirkungen sich auf das Sourcing ergeben. lesen

* Matthias Popiolek ist Principal Consultant bei der ISG Information Services Group

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44598340 / Middleware)