Integration in der Cloud – Ein Serverless Ansatz

Integration hat in Zeiten der Digitalisierung nicht an Bedeutung verloren – vielmehr wird diese Disziplin immer wichtiger, um Menschen, Dinge und Maschinen mit den Informationen zu versorgen, die sie benötigen.

Integration muss dabei nicht on-Premise und mit großen, zentralen Integrationsplattformen erfolgen. Cloud und Container haben die Disziplin Integration ebenfalls nachhaltig beeinflusst. Hier sind einige „Platform as a Service“-Produkte entstanden, die eine gute Alternative zu klassischen Integrationsplattformen darstellen.

Beispielsweise sind so genannte „Serverless Functions“ entstanden, die unter anderem „AWS Lambda“ und „Azure Functions“ genannt werden. Die Laufzeitumgebung wird dabei von der Cloud zur Verfügung gestellt, sodass keine direkte Server-Infrastruktur benötigt wird. Mittels dieser Funktionen würde in Integrationsumgebungen die Transformations- und Geschäftslogik abgebildet.

In Kombination mit weiteren Services wie Messaging, Cloud-Speicher, API Gateways und weiteren Diensten lassen sich somit schnell Integrationsprozesse erstellen.

Quelle – Logik – Senke

Komplexere Prozesse lassen sich mit bekannten Konzepten aus dem Integrationsumfeld realisieren. Nutzt man Beispielsweise eine Orchestrierungs-Engine in der Cloud oder extern, lassen sich die Funktionsaufrufe miteinander kombinieren. Über einen Messaging Layer lassen sich Konzepte einer Message-Oriented Middleware oder Enterprise Integration Patterns umsetzen.

Orchestrierung von Funktionen über Dritt-Tool

Message-orientierter Ansatz über Queues und Topics

Ein entsprechender Ansatz bietet einige Vorteile:

  • Es fallen nur Kosten für die Integration an, wenn diese wirklich benötigt wird. Typischerweise kommen Pay-by-Use-Modelle zum Einsatz.
  • Kosten für Wartung und Betrieb der Infrastruktur existieren nicht beziehungsweise werden diese vom Cloud Provider übernommen.
  • Verantwortung für die Infrastruktur wird an den Cloud Provider abgegeben, sodass ein Fokus auf Fachlichkeit und Entwicklung gesetzt werden kann.
  • Man erreicht eine schnellere Time-to-Market.
  • Die Strukturen der Cloud Provider enthalten bereits einen komponentenorientierten Ansatz, sodass ein Service-Schnitt und anteiliges Deployment vereinfacht wird. Gleichzeitig verbessert dieser Ansatz die Code-Strukturen für das automatisierte Testen.

Die Nachteile sind:

  • Kosten für “Pay by Use”-Modelle sind schwer abzuschätzen. Wenn Ausführung und Nutzung nicht im Detail bekannt sind, können Kosten rasant steigen.
  • Man hat keine Hoheit über die Infrastruktur und Laufzeitumgebung. Sind Probleme mit Konnektivität oder Performanz vorhanden, sind der eigenen Analyse Grenzen gesetzt.
  • Es fallen zusätzliche Kosten in der Cloud für weitere Stages neben der Produktions-Stage an.
  • Cloud-Dienste unterliegen einem stetigen Wandel, sodass Unsicherheiten vorhanden sind und spätere Anpassungen notwendig werden können.
  • Erfahrungen und Wissen auf dem Markt sind rar.

Werden neue Integrationsstrecken geplant, könnte eine Serverless Architecture interessant sein. Insbesondere in Unternehmen mit einer kleinen IT-Abteilung, bei einer gut kalkulierbaren Nutzung der Integrationsplattform oder, falls ein Betrieb in der Cloud bereits angedacht ist, sollte eine Serverless-Architektur für die Integration in Betracht gezogen werden.

Dieser Beitrag wurde unter BPM & System Integration, Cloud & Infrastructure, IoT & Industry 4.0 veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.