Architektur

Middleware-Architekturen im Wandel

Der Markt im Bereich Middleware und Applikationdevelopment in Bezug auf Backendarchitekturen ist im Wandel. Durch Cloudanbieter wie Amazon oder Google haben Techniken wie Virtualisierung und Linux-Container deutliche Marktanteile gewonnen. Themen wie Microservices bringen neue Ansätze, um die Verwaltung von Middleware Applikation zu vereinfachen. Im Folgenden werden drei mögliche Middleware-Architekturen vorgestellt und verglichen.

Bei den beschriebenen Architekturen für Infrastruktur steht die Middleware im Vordergrund. Die Middleware soll hier als Schicht zwischen den Anwendungen verstanden werden. Die Anwendungen können stark variieren. Von IoT-Systemen über Mobileanwendungen bis zu Desktopanwendungen ist alles möglich. Auch Frontendapplikationen für Verwaltung und Administration sind Teil der Middleware.

Folgende Gruppen lassen sich unterscheiden:

  • Offen – open source und proprietäre Software
  • One Vendor –  proprietäre ein Herstellers, hier am Beispiel Oracle
  • Cloud-Native-Stacks – Plattformen für Microservices wie DCOS, Mesos oder Spring Cloud.

Offene Architekturen

Unter offenen Architekturen fassen wir Installation zusammen, die auf verschiedene Hersteller und auf Open Source setzen. Die Notwendigkeit eines Integrationslayers ergibt sich aus der Anforderung, dass die einzelnen Applikation Daten austauschen müssen. Um dies sicher und einfach durchführen zu können, kommt ein Service Bus zum Einsatz. Die Kommunikation zwischen den verschiedenen Applikationen findet fast auschließlich über diesen Service Bus statt.

 

Der Integrationslayer steht im Mittelpunkt und stellt die Verbindung zwischen der Applikation her. Der Service Bus stellt sicher, dass alle Verbindungen zwischen den Applikationen über einen zentralen Knoten geleitet werden. Dort werden Zugriffsrechte verwaltet, eine Überwachung und Monitoring der Services findet statt und die Versionierung von Services ist möglich. Ebenso wird von den meisten Service Bus Produkten eine Vielzahl von Adaptern zu Fremdsystemen wie z.B. SAP mitgeliefert. Daraus ergibt sich die Möglichkeit beliebige Produkte, sei es Open Source oder kommerzielle Tools, in Kombination zu verwenden. Produkte für den ESB Einsatz sind z.B. Mule, Talend oder Apache Service Mix. Eine Integration in Prozess Engines wie Cammunda oder Rules Engines wie Drool ist problemlos möglich.

One Vendor am Beispiel Oracle

Im Vergleich zu einem offenen, herstellerunabhängigen System, bietet ein spezielles, nur auf einem Hersteller aufbauendes System, weitere Features. Oracle zeigt zum Beispiel mit dem Enterprise Service Bus (OSB) die Möglichkeit auf, eine direkte Kopplung von OSB Kompenenten mit SOA Prozessen Suite (SOA Suite) und Business Process Management (BPM) durchzuführen. Das Konfigurieren von Strecken auf dem Service Bus wird erleichtert. Der Securitylayer ist transparent über alle Phasen des Prozesses. Eine gleichmäßige Auditierung in allen Phasen des Prozesses ist gewährleistet.

Zusätzlich zu den Funktionen eines ESBs sind Workflowkomponenten direkt implementiert. Diese müssen in offenen Architekturen integriert werden, was eventuell erhöhten Aufwand bedeutet. Somit ist nicht nur ein Basis Routing oder eine Mediator Funktion vorhanden, sondern es können ohne zusätzliche Produktintegration spezielle Prozessabläufe am Servicebus modelliert werden. Eine sperate Implementation einer Workflowengine entfällt. Ebenso gibt es Adapter für viele weitere Systeme, nicht nur für Oracle Produkte. (siehe Oracle Dokumentation)

Cloud-Native-Stacks

Der Begriff Cloud-Native-Stack kam im Zusammenhang mit Microservices-Installationen, meist mit Docker auf. Er steht für die Infrastrukturansätze wie Kubernetes, Mesos oder Spring Cloud. Microservcies spielen hier eine zentrale Rolle. Der Stack unterscheidet sich deutlich von den anderen beiden Möglichkeiten. Es wird kein zentraler Service Bus installiert. Die Verbindung zu den Backend Services wird jeweils in einem Microservice entwickelt. Die Services werden in der Service Registry bekannt gegeben und können von anderen Microservices innerhalb der Plattform genutzt werden. Information, wo welche Services verfügbar sind, stellt die Service Registry zur Verfügung. Über ein API Gateway oder Loadbalancer können die Services von außen, z.B. Internet, erreicht werden. Hier können notwendige Sicherheitskonfigurationen eingestellt werden. Die Informationen, wo und wie viele Services laufen, können in der Serviceregistry abgerufen werden. Die Serviceregistry wird beim Deployment der einzelnen Komponenten, meist automatisch, aktualisiert.

 

Die Vorteile bei Verwendung eines Cloud Stacks, basierend auf Microservices, liegt in den kleinen, einfachen Service-Bausteinen. Für jeden externen Dienst kann ein Service mit der passenden Softwarebasis (Libraries, Wahl der Programmiersprache etc) entwickelt werden. Alle erstellten Services registrieren sich gegen die Registry. Eine fachliche Logik wird in getrennten Services entwickelt. Von den einzelnen Services kann eine beliebige Anzahl gestartet werden. Diese Skalierung wird in der Serviceregistry hinterlegt und kann sofort von aufrufenden Services verwendet werden. Eine Festlegung auf eine Programmiersprache oder Modell ist nicht notwendig. Querschnittliche Aspekte, wie Logging, Security oder Transaktionsmanagement sind einheitlich zu Implementieren. Meist werden als Basis Docker Container verwendet, es können aber auch direkte Prozesse, z.B. Java Programme, gestartet werden. Die meisten Module innerhalb von Microservice Infrastrukturen wie Kubernetes oder Mesos sind Open Source und frei verfügbar. Microservice bieten eine ideale Plattform für ein agiles Projektmanagement.

Zusammenfassung

Je nach Anwendungsfall entstehen unterschiedliche Vorteile jedes Systems. Ebenso sind hybride Systeme möglich, die mehrer Konzepte vereinheitlichen. Microservices werden meist in Cloud Installationen verwendet. Diese Cloud kann sowohl bei einem Provider betrieben werden (Amazon, Google etc), aber auch on premise, im eigenen Rechenzentrum installiert sein. Ein Cloud Native Stacks bieten viele Bestandteile, wie eine Service Registry oder ein Loadbalancer, die die Entwicklung von Microservices erleichtern und beschleunigen. Querschnittskomponenten wie ein gemeinsames Logging sind in einem Cloud-Native-Stack als Komponente vorbereitet oder der Stack ist leicht zu erweitern. Microservice können in jeder Architektur entwickelt und deployed werden, allerdings bietet der Cloud-Native-Stack viele Vorteile, die die Durchführung deutlich erleichtert.