Platform-as-a-Service – Definitionsansätze (Teil 2) Sourcing von PaaS-Frameworks

Was man unter „Platform as a Service“ versteht, welche Rolle ein PaaS-Framework spielt und wer für dessen Aufbau, Wartung und Betrieb verantwortlich ist, hat der erste Teil dieses Beitrags beleuchtet. Ergänzende Plattformen, Tools und Services sowie die Auswirkungen auf das Sourcing diskutiert der Autor im zweiten Teil.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Information Services Group (ISG)

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.

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

Die große PaaS-Konfusion

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.

Bildergalerie

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.

Bildergalerie

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.

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

Die große PaaS-Konfusion

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

(ID:44641819)