Platform-as-a-Service - Definitionsansätze

Die große PaaS-Konfusion (Teil 2)

| Autor / Redakteur: Matthias Popiolek * / Florian Karlstetter

Ein PaaS-Framework bietet Entwicklern einen zentralen Zugang zu Infrastruktur- und Middleware-Services. Im Bild: Ausschnitt verschiedener Services und Servicetypen.
Ein PaaS-Framework bietet Entwicklern einen zentralen Zugang zu Infrastruktur- und Middleware-Services. Im Bild: Ausschnitt verschiedener Services und Servicetypen. (Bild: ISG Information Services Group)

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.

Ohne klare Definition von PaaS und entsprechender Verteilung der Verantwortlichkeit sind Unternehmen nicht in der Lage, zum Beispiel eindeutige Vereinbarungen mit PaaS-Anbietern zu treffen. Teil 1 des Artikels ging vor allem der Frage nach, was unter PaaS zu verstehen ist, welche Rolle ein PaaS-Framework spielt und wer für dessen Aufbau, Wartung und Betrieb verantwortlich ist. In diesem zweiten Teil diskutiert der Autor, 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

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

Die große PaaS-Konfusion

11.04.17 - 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? lesen

Integrations- und unterstützende Frameworks

Das PaaS-Framework alleine schafft noch keine Anwendungen und stellt nicht sicher, dass diese auch funktionieren. Eine der kritischsten Komponenten in der digitalen Welt ist die Integration von Datenquellen, Datenbanken und Rechenfunktionen. In einer klassischen Umgebung geschah dies entweder mithilfe von ETL-Werkzeugen (ETL=Extraktion, Transformation, Laden) oder bei einem serviceorientierten Ansatz durch den Aufbau eines Enterprise Service Bus (ESB). Mittlerweile gibt es eine weitere Option: iPaaS (integration Platform as a Service) entspricht auf Cloud-Ebene einem ESB. Am Markt existieren viele Lösungen für vielfältige Zwecke und mit unterschiedlichen Levels der Enterprise Readiness – also ob eine Lösung die für Großunternehmen notwendige Reife und Skalierung aufweist. Aus welchem Blickwinkel man es auch immer betrachtet: Integration ist eine Aufgabe der Middleware und fällt deshalb unter PaaS, sobald sie in Form von „aaS“ bereitgestellt wird. Aus der Perspektive des PaaS-Frameworks muss Integration unabhängig von ETL, ESB oder iPaaS betrachtet werden.

In gleicher Weise könnten auch andere Plattform-Services als PaaS bezeichnet werden. Dies reicht von Mobile Enterprise Application Platforms (MEAP) über Data Warehouse-Lösungen bis hin in den Bereich von Big Data und der Analytik. Selbst wenn diese Plattform-Services unter das PaaS-Label fielen, wenn sie „as a Service“ bereitgestellt werden, betrachtet man sie üblicherweise dennoch separat. Der Grund: Ihre Bedeutung liegt mehr darin, was diese Lösungen und Services direkt an Funktionen bieten. Zwar sind sie in der Lage, auch Applikationen und damit Entwicklern Funktionalität bereitzustellen. Doch werden sie nicht in der gleichen Weise wie PaaS-Frameworks wahrgenommen und fallen deshalb üblicherweise auch unter die Hoheit von Spezialteams außerhalb der Infrastruktur-Abteilung.

Instanzenbasierte Services

Bestandteil von instanzenbasierten Services ist immer auch Infrastruktur. Es handelt sich hier um fertige und standardisierte Services beispielsweise für Datenbanken. Deren Umfang und Qualität ist auf der Ebene des Services definiert und nicht auf der Ebene seiner Komponenten. Während ein Entwickler zum Beispiel einen neuen Service kreiert, indem er IaaS, gehostete Middleware und Anwendungen miteinander verbindet, handelt es sich bei instanzenbasierten PaaS-Services eher um Produkte als Komponenten. Solche Services sind auch der Blueprint für Mikroservices, bei denen die Zielsetzung des jeweiligen Services kleiner und kleiner wird. Mikroservices können miteinander verbunden werden, sodass sie die gleiche Funktionalität bieten wie größer dimensionierte Serviceschnitte.

Da vielen nicht klar ist, um was es sich bei einem Mikroservice handeln könnte, folgt hier ein Beispiel, wie ein einfacher DBaaS (Date Base as a Service) durch Mikroservices erstellt werden kann. Die Hauptfunktionen dieser Beispieldatenbank sind „Datensatz hinzufügen“, „Datensatz lesen“, „Suche“, „Datensatz löschen“ sowie der Speicher, das Netzwerk und die Rechnerleistung, die für das Ausführen dieser Aktionen nötig sind. Jeder dieser Vorgänge benötigt ein bestimmtes Maß an Rechnerleistung und verfügt über Input und Output. Wenn man sich nun vorstellt, dass jede dieser Aktionen an sich einen Service darstellt, wären zum Beispiel bei der Suchfunktion unterschiedliche Mikroservices aktiv, die jeweils andere Suchalgorithmen verwenden. Von Fall zu Fall lässt sich so entscheiden, welcher dieser Algorithmen jeweils am besten geeignet ist. Letztlich brechen Mikroservices eine Applikation auf detailliertere Ebenen herunter. Mit anderen Worten: Sie schaffen Komponenten und machen diese Komponenten als Service verfügbar. Dementsprechend wird es zukünftig ganze Bibliotheken an Mikroservices geben, welche die Auswahlmöglichkeiten beträchtlich erhöhen – gerade auch im Hinblick auf die verfügbaren Services im Rahmen eines PaaS-Frameworks.

Der Markt hält instanzenbasierte Services bereit und die Angebotsvielfalt wird immer größer. Die Herausforderung besteht dabei wiederum darin, welche Services in einem Unternehmen angeboten werden sollen und wer sie im Rahmen des Sourcings zur Verfügung stellt. Genauso wie die Infrastruktur-Abteilung solche Entscheidungen für die Infrastruktur fällt, ist sie auch dafür vorbestimmt, dasselbe für instanzenbasierte Services zu tun. Manche mögen einwenden, dass die bestehenden Teams dafür nicht geeignet sind. Doch müssen genau solche Silos aufgebrochen werden, wenn ein Unternehmen zukunftsfähig bleiben will. Genauso, wie Entwicklungsteams Kompetenzen in Sachen Infrastruktur erwerben müssen, benötigen die Infrastrukturteams Know-how bezüglich Middleware und Applikationen. Interdisziplinäre Teams sind dabei das einfachste Mittel, solche Fähigkeiten miteinander zu kombinieren. So fließt Middleware-Know-how ins Infrastruktur-Team, und die Middleware-Experten profitieren vom Service-Know-how ihrer Infrastrukturkollegen.

Auswirkungen auf das Sourcing

Wie lassen sich die unterschiedlichen PaaS-Services am besten sourcen? Die Antwort lautet: Schritt für Schritt. Das PaaS-Framework ist in erster Linie eine Entscheidung über eine Technologie. Die daran anschließende Frage, ob das Framework selbst oder über die Cloud betrieben werden soll, ist zuallererst eine Frage der jeweiligen Kundenpräferenzen. Grundsätzlich kann das Framework einfach outgesourct werden, da es selbst nur Metadaten vorhält. Auch der Serviceumfang ist im Vergleich mit anderen Services sehr klein. Unternehmen müssen jedoch sicherstellen, dass das Framework alle Technologien und Arten der Bereitstellung unterstützt, die aktuell oder in Zukunft benötigt werden.

Die innerhalb des Frameworks verwendeten Services (klassische Rechnerleistung, IaaS, instanzenbasiertes PaaS) können auf herkömmliche Weise outgesourct werden. Dementsprechend ist davon auszugehen, dass Public Cloud-Services keinen klassischen Ausschreibungen durchlaufen, sondern einfach mit dem jeweiligen Provider vereinbart werden. Zumal bei der Private Cloud aktuell ein Markttrend zu erkennen ist, der weg von maßgefertigten und hin zu standardisierten Services führt. Die Integration der Services ist schon lange vor den Sourcing-Entscheidungen eine Herausforderung für die Unternehmensarchitektur. Diese Weichenstellungen in Sachen Sourcing hängen auch vom jeweiligen Standort ab sowie von Datenfluss und -klassifizierung.

Für die anderen Plattform-Services gilt Ähnliches wie für das Framework: In erster Linie handelt sich um eine Technologieentscheidung und erst danach geht es um die Frage, wer welche Aufgaben übernimmt. Die instanzenbasierten PaaS-Services können auf herkömmliche Weise gesourct werden. Manche Services treten auf und hängen davon ab, wie sich ein PaaS-Framework zusammensetzt. Dementsprechend stellen sie interne Services von bereits gesourcten Komponenten dar.

* 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: 44598342 / Technologien)