vege - Fotolia

SOA und Webservices zur Verbesserung des Microservice-Managements zusammenführen

Die Zusammenführung einer serviceorientierten Architektur (SOA) und Webservices bietet neuen Raum für Microservices. Lösungen hierfür gibt es bereits.

In der modernen Softwarearchitektur nehmen Microservices eine herausragende Stellung ein. Microservices sind, einfach gesagt, ein leichtgewichtiger Ansatz, mit dem sich monolithische Anwendungen in lose gekoppelte Services zerlegen lassen. Die kleinen Anwendungsfunktionen sind für die breite Wiederverwendung designt und stellen damit einen Gegenpol zu den über die Jahre gewachsenen monolithischen Unternehmensanwendungen dar.

In der Praxis sind Microservices bislang allerdings kaum angekommen. Das ist zum Teil deshalb so, weil es sich meist um Cloud-spezifische Funktionen handelt, die immer noch darauf warten, dass Cloud-Services vermehrt genutzt werden. Und zum Teil, weil Microservices zwischen zwei Welten gefangen sind: der Welt der serviceorientierten Architektur (SOA) und der Welt des Internets. Doch diese Probleme sind praktisch gelöst und das Management von Microservices ist schon bald so ausgereift, dass sie ihren Platz in den Entwicklungs-Toolboxes einnehmen werden.

Zu Microservices gibt es im Prinzip zwei Sichtweisen: Die Befürworter des SOA-Modells für Anwendungen sehen Microservices in der Regel als Weiterentwicklung und Evolution von SOA, so dass SOA an Cloud Computing angepasst werden kann. Microservices, korrekt implementiert, haben die meisten Eigenschaften von RESTful, webähnlichen, funktionalen Komponenten. Diese Gruppe erwartet von Microservices SOA-Governance, Verzeichnisstrukturen, Sicherheit und verbindliche Prinzipien, die auf eine Cloud-freundliche Art in Microservices implementiert werden. Für diese Gruppe lebt SOA im Management von Microservices weiter.

Cloud- und webversierte Architekten sehen Microservices hingegen als eine Formalisierung von Webservices: Damit ist die Entwicklung von Funktionskomponenten gemeint, die auf Webprinzipien basieren und die durch ultra-einfache und erprobte Web/HTTP/HTML- oder JSON-Prinzipien an die Anwendungen gebunden sind. Vereinfachung und Effizienz sind hier die Ziele, und mit diesen Veränderungen wird SOA über Web- und Cloud-Prinzipien integriert und absorbiert.

Microservice-Management und die Cloud

Ein oberflächliches Lesen von Microservice Best Practice scheint zu belegen, dass die SOA-Seite gewonnen hat. Microservices werden in der Regel so beschrieben, dass auf sie über eine API-Manager-Funktion zugegriffen wird, die Sicherheits- und Compliance-Richtlinien sowie eine verbrauchsgerechte Abrechnung erzwingt.

Kong ist ein Beispiel für eine Open-Source-Version eines API-Managers. Die Werkzeuge werden zwischen dem Microservice-Benutzer und dem Microservice eingeführt und bieten Metering-, Sicherheits- und Compliance-Überwachung. API-Manager können Microservices sehr SOA-ähnlich machen, aber sie können wegen ihrer Einfügung auch zu einer signifikanten zusätzlichen Prozessverzögerung führen. Microservices, die oft aufgerufen werden, sind durch diese Einfügung besonders beeinträchtigt, und ab einem gewissen Punkt kann die akkumulierte Verzögerung tatsächlich eine weitere Microservice-Nutzung verhindern.

Sowohl Amazon als auch Microsoft bieten einen Cloud-basierten API-Gateway-Service, der über ähnliche Fähigkeiten verfügt. In diesen Cloud-Tools wird die Funktionalität eines traditionellen API-Managers bereitgestellt. Wenn die Microservices in der Cloud gehostet sind, verursacht das Gateway eine geringere Verzögerung als bei Verwendung eines lokal eingesetzten API-Managers. Latenz ist jedoch auch dann immer noch ein Thema für häufig genutzte Microservices.

Es ist immer möglich gewesen, Microservices als einfache RESTful APIs ohne API-Manager oder Gateway zu nutzen. Dies kann aber ein Problem darstellen, wenn Instanzen von Microservices unter Last skaliert werden. Die Skalierung erfordert eine Lastverteilung zwischen den Instanzen, und ein API-Manager oder Gateway kann dies leisten, wenn eines davon vorhanden ist. Eine Alternative, die im Jahr 2017 weiterentwickelt wird, ist die Verwendung von Domain Name Servern (DNS), die URLs zu IP-Adressen aufzulösen. Es stehen Load Balancing DNS-Dienste (zum Beispiel Cedexis und Dyn Traffic Director) und kommerzielle wie auch Open-Source-Produkte zur Verfügung. NGINX Plus ist zum Beispiel bei Spitzenunternehmen weit verbreitet.

Sowohl Amazon als auch Microsoft stellen DNS- und Load-Balancing-Tools als Bestandteil ihrer Webservices zur Verfügung. Diese bieten zwar keine perfekte Lastverteilung oder Sicherheit, sind aber gut genug für das Microservice-Management ohne das Risiko von explodierenden Latenzen. Beide Unternehmen sollen an mikrosservicespezifischen oder microservicegestützten Werkzeugen arbeiten, die noch 2017 bereitgestellt werden sollen.

Entwerfen des Microservice-Managements

Ein weiterer Lösungsweg, der sich auf das Microservice-Design im Jahr 2017 auswirken wird, ist eine Serviceless-Version. In einer Microservice-Anwendung stellen API-Manager und Gateways ein Mittel zur Registrierung und Lokalisierung der Services bereit. Dies kann wichtig werden, wenn Microservices in die Cloud gelegt oder skaliert werden, um in der Cloud arbeiten zu können.

Ein großer Microservice-Nutzer hat nun Apigee API Gateway mit der funktionalen Programmierung (auch Lambda genannt) von Amazon kombiniert. Amazon Lambda kann Microservices bauen, die eigentlich nicht gehostet werden. Sie werden nach Bedarf instanziiert und dann entfernt. Da es keine dauerhafte Serviceinstanz zur Wiederverwendung gibt, brauchen Sie nicht zu verfolgen, wo ein Microservice gerade ist. Interessanterweise wird Amazon Web Services (AWS) Lambda oft mit den Cloud-Workflow-Tools von Amazon verbunden, und Workflows können auch die Zukunft der Cloud sein.

Mehr zum Thema Microservices:

Microservices verändern die Organisation und fördern Innovationen in Unternehmen.

Wie sich die Leistung von Microservices und Cloud-Anwendungen optimieren lässt.

Microservices testen: Auf diese Punkte sollten Sie achten.

Per Amazon API Gateway auf eine Microservice-Architektur zugreifen.

Was ist der Unterschied zwischen SOA und einer Microservice-Architektur?

Um die Cloud von den Limitierungen der traditionellen Programmier- und Rechenzentren zu befreien, sollte man die Ressourcen und das Hosting vergessen und stattdessen über Anwendungen als Komponenten nachdenken, die über Workflows miteinander verknüpft sind.

Wenn Microservices als traditionelle Anwendungskomponenten betrachtet werden, wird das Verteilen einer größeren Menge von ihnen sicher große Leistungsprobleme verursachen. Einfach aufgrund der Multiplikation der Netzwerkverzögerung, die mit der größeren Anzahl von Komponenten verbunden ist.

Wenn jedoch Anwendungen als für Workflows gedachte Komponenten betrachtet werden, dann könnten die Lambda-basierten Microservices entlang der Workflows instanziiert werden, was nur minimale inkrementelle Verzögerungen zur Folge hätte.

Um dieses Ziel zu erreichen ist ein Denken erforderlich, das Microservices weniger als eine Call/Return-Funktion ansieht, sondern als eine Pipeline-Funktion, was gut zu den Lambda-Service von AWS passt. Amazon führt in diesem Jahr zudem Greengrass ein, eine Softwarekomponente, die AWS Lambda außerhalb der Amazon-Cloud laufen lässt.

Da es Lambda bereits ermöglicht, Funktionen über einen Pfad zu verteilen (es verbindet tatsächlich nicht einmal eine Funktion mit einem bestimmten Hosting-Ort oder -Service) und da sämtliche Lambda-Programmierung Pipeline-orientiert ist, ist es ideal für eine Workflow-Support-Mission geeignet, und ein Vermittler der Transformation zu den Workflows.

Die Nutzung von Lambda oder funktionaler Programmierung für die Entwicklung von Microservices kann der bedeutendste Trend für das Microservice-Management im kommenden Jahr sein. Lambdas sind von Natur aus zustandslos, einfach zu bauen und zu debuggen, und können entweder im traditionellen Call/Return- oder Pipeline-Modell verwendet werden. Damit hat Amazon auch bewiesen, dass die gleichen Lambdas in ihrer Cloud oder lokal vor Ort laufen können.

Microsoft unterstützt ebenfalls Lambda-Programmierung als Teil von .NET und Azure. Da einige spezielle Entwicklungsverfahren wichtig für den Aufbau eines effektiven Microservices sind und da die Lambda-Entwicklung nur diese Verfahren benötigt, wird die Akzeptanz der Lambdas die Microservices insgesamt fördern.

Die meisten wirklich bedeutenden Fortschritte in der Softwarearchitektur und in den Design-Praktiken erfordern grundlegende Änderungen in den Anwendungen. Wir sind am Beginn großer, Cloud-zentrierter Veränderungen in der Art, wie wir Anwendungen bauen. Das Microservice-Management wird im kommenden Jahr erheblich von diesen Veränderungen profitieren.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im April 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über SOA

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close