API-Hosting als Basis einer Microservice-Architektur

Der Weg in die Wolke mit Web-APIs

| Autor / Redakteur: Dr. Veikko Krypczyk & Elena Bochkor / Stephan Augsten

Vom Monolith zum Microservice, nach einer Idee von Capgemini.
Vom Monolith zum Microservice, nach einer Idee von Capgemini. (Bild: https://www.capgemini.com/2016/06/microservices-in-cloud-based-infrastructure-paving-the-way-to-the/)

Microservices gelten heute als Basis moderner Anwendungsarchitekturen. Statt einer monolithischen und schwerfälligen Software wird die gesamte Funktionalität auf überschaubare Teilsysteme verteilt. Die entstandenen Services werden dann üblicherweise über das Internet und RESTful APIs zur Verfügung gestellt.

Die Art und Weise der Softwareentwicklung steht einmal mehr am Scheideweg. Die Zeiten komplexer und teilweise schwerfälliger Softwareapplikationen sind vorbei. Stattdessen hat man es überall mit einer hohen Vielfalt und Flexibilität zu tun.

Neben unterschiedlichsten Gerätetypen – von Desktop-PCs über Notebooks und Tablets bis hin zu Smartphones – kommen auch die verschiedensten Betriebssysteme zum Einsatz: Windows, macOS, Linux, iOS und Android. Für die Softwareentwicklung haben diese Entwicklungen vielfältige Konsequenzen.

Insbesondere ändert sich die verwendete Architektur. Der Weg geht weg vom monolithischen Anwendungssystem, hin zu einer schlanken und flexiblen Architektur auf der Basis von Microservices. Ebenso gilt es, bestehende Applikationen durch Migration für diese Ansprüche zu transferieren.

Permanenter Netzzugriff

Man kann davon ausgehen, dass eine Anwendung nahezu einen stetigen Zugriff über das Internet auf Daten und Services hat. Insbesondere schnelle Internetverbindungen für mobile Geräte erlauben den Zugriff auf entfernte Services und größere Datenmengen.

Dabei wird die Funktionalität auf viele kleinere Einheiten aufgeteilt, die lose miteinander gekoppelt werden. Einmal programmierte Services können in mehreren Anwendungen auf einfachste Art und Weise wiederverwendet werden.

Der Weg zur modernen Softwarearchitektur

Als monolithische IT-Systeme werden umfassende Softwareapplikationen bezeichnet, welche keine explizite Trennung in unterschiedliche Teilsysteme aufweisen. Die Funktionen eines solchen Anwendungssystems (Datenhaltung, Anwendungslogik, Benutzeroberfläche) sind eng gekoppelt und zu einem Gesamtsystem verschmolzen. Ein monolithisches IT-System hat folgende Nachteile:

  • Hohe Komplexität: Die Teilmodule weisen vielfältige gegenseitige Abhängigkeiten zueinander auf.
  • Schlechte Wartbarkeit: Es gelingt nicht einzelne Teile der Anwendung gegen neuere Technologien auszutauschen, ohne dass dies direkte Einflüsse auf andere Bestandteile der Software hat.
  • Eingeschränkte Wiederverwendung: Die Wiederverwendung einzelner Softwarekomponenten ist kaum möglich.
  • Geringe Flexibilität: Eine Erweiterbarkeit und eine Skalierbarkeit sind stark eingeschränkt.

Aus heutiger Sicht sind monolithische IT-Systeme veraltet. Oft sind sie durch stetige Weiterentwicklung und Anpassung entstanden. Dennoch sind noch viele solcher Systeme im Einsatz. Sie werden als Legacy-Systeme bezeichnet. Ihre Modernisierung und Anpassung (Migration) ist schwierig. Besser ist eine Aufteilung der Gesamtapplikation in Schichten, üblicherweise für die Datenhaltung, die Verarbeitung und die Präsentation.

Service-orientierte Architektur

Im industriellen Umfeld haben sich die serviceorientierten Architekturen (SOA) als eine Form der verteilte Systemarchitektur etabliert. Das SOA-Prinzip besteht darin, dass Nutzer (Service Consumer) komplexe Anwendungen nahezu aus dem Zusammenfassen bzw. der Kombination von Service-Dienstleistungen realisieren können. Die dahinterstehende Idee ist, zusammengehörige Anwendungsfunktionen zu einer Einheit zu bündeln und diese als Dienstleistungen (SOA-Services) anzubieten.

Auf diese Weise können die vorhandenen Services wiederverwendet und Entwicklungskosten gespart werden. Alle verfügbaren Dienste werden über eine Registry bekannt gemacht. Die tatsächliche Bindung zwischen den Software-Elementen Service Consumer und Service Provider erfolgt zur Ausführungszeit durch die dynamische Zuordnung. SOA zielt damit auf eine Flexibilisierung der Unternehmens-IT ab.

Bei Microservices können die Module unabhängig voneinander in Produktion gebracht werden. Die Services können dabei flexibel durch unterschiedlichste Anwendungssysteme, welche nicht nur auf das eigene Unternehmen beschränkt sind, benutzt werden. Die Integration erfolgt üblicherweise über „RESTful http“, d.h. über eine einheitliche Schnittstelle.

Die eigene Anwendung wird damit gewissermaßen zum Service, welcher sich wiederum aus der Nutzung anderer Dienste zusammensetzt. Für die Nutzung eines Service spielt dessen technische Umsetzung keine Rolle. Verschiedene Betriebssysteme und die Bereitstellung auf unterschiedlichen Technologien sind möglich.

Vom Monolith zum Microservice, nach einer Idee von Capgemini.
Vom Monolith zum Microservice, nach einer Idee von Capgemini. (Bild: https://www.capgemini.com/2016/06/microservices-in-cloud-based-infrastructure-paving-the-way-to-the/)

Nutzt eine App beispielsweise den Service, so muss diese nur die Aufrufkonventionen des API kennen. Die technische Umsetzung des Dienstes ist nicht von Interesse. Sofern sich die Schnittstelle nicht ändert, haben Anpassungen am Dienst keine Auswirkungen auf die nutzende Software. Einen Vergleich der Architekturansätze zeigt die vorangestellte Abbildung 1.

Chancen und Herausforderungen von Microservices

Microservices bieten eine Reihe von Chancen:

  • Jedes Modul kann einzeln konzipiert, implementiert, getestet und deployt werden.
  • Die Module sind hinsichtlich der Technik untereinander unabhängig.
  • Änderungen an einem Modul beeinflussen andere Module nicht, sofern die Schnittstelle unverändert bleibt.
  • Einzelne Module können sehr gut in unterschiedlichen Anwendungskontexten verwendet werden.
  • Die Module können untereinander fachlich unabhängig sein.
  • Eine gute organisatorische Zuordnung der Verantwortlichkeiten ist möglich.

Folgende Herausforderungen sind zu bewältigen:

  • Zuordnung der der Services, zu den Schichten, wie Daten-, Logik und User Interface-Ebene.
  • Einführung einer Microservice-Infrastruktur, um z.B. das Deployment zu automatisieren.
  • Begrenzung und Auswahl der verwendeten Technologien auf ein akzeptables Maß.

Gerade der letzte Punkt kann zu einer echten Herausforderung werden. Beim Aufbau einer komplexen Softwarelandschaft sind bereits Client-seitig unterschiedlichste Technogien notwendig. Sehr schnell erfordert die Umstellung auf eine Microservice-Architektur das Beherrschen weiterer Technologien.

Hierzu zählen Microservice-Frameworks, Docker, Kubernetes, serverseitiges JavaScript in zusätzlichen Frameworks wie Node.js und vieles mehr. Gefragt sind daher Ansätze, welche für einen durchgängigen Entwicklungszyklus vom Client bis hin zum RESTful Service auf Server-Seite sorgen, um den gesamten Entwicklungsprozess effizient gestalten zu können.

Geschäftslogik als API bereitstellen

Ein eigenes Application Programming Interface zu hosten kann aufwändig sein. Serverseitig sind einige Installationen und Konfigurationen notwendig. Ebenso muss man die Logik auf den Server bekommen. Ein typischer Ansatz, gewissermaßen das „manuelle“ Vorgehen, basiert auf den Einsatz von JavaScript, d.h. Node.js und Express.

Vermittelnde Zwischenschicht zwischen Client und Service aus Serverseite.
Vermittelnde Zwischenschicht zwischen Client und Service aus Serverseite. (Bild: Embarcadero)

Mit Hilfe von Tools kann man den Aufwand minimieren. Einen eigenen Server kann man zum Beispiel mit Hilfe des RAD Servers aufsetzen. Die Server-Applikation fungiert hier flexibel und wahlfrei als Backend oder Middleware und bietet folgende Funktionen:

Flexibel nutzbaren REST-Endpunkt: Die Services werden als REST/ JSON-API bereitgestellt und können damit von allen Arten von Clients genutzt werden. Eine integrierte Zugriffsteuerung erlaubt es Berechtigungen für die API-Nutzung über Benutzerauthentifizierung und -autorisierung festzulegen.

Vermittelnde Zwischenschicht: Serverseitig bieten sich vielfältige Möglichkeiten, u.a. die Integration von Unternehmensdatenbanken, die Verwaltung von IoT-Hardware und die Integration von Cloud- und Backend-as-a-Service-Diensten wie Google, Amazon, Facebook und Kinvey.

Bereitstellung von Anwendungsdiensten: Der Server bietet ein Set an Anwendungsdiensten wie Benutzerverzeichnis- und Authentifizierungsdienste, Push-Benachrichtigungen, Indoor-/ Outdoor-Positionsermittlung und JSON-Datenspeicher.

Über die integrierte Entwicklungsumgebung RAD Studio ist es auf einfachste Weise möglich Geschäftslogik als Restful API Service zu hosten. Diese automatisierte Vorgehensweise ist gerade im Umfeld der Anwendungsmigration von Vorteil.

Hier geht es darum, die ursprüngliche Gesamtapplikation in kleinere Einheiten (Services) zur zerlegen und diese als voneinander losgelöste Dienste via RESTful Services anzubieten. Um die Kosten der Migration in Grenzen zu halten ist nach Möglichkeit bestehender Programmcode wiederzuverwenden.

Fazit

Die Architektur von Anwendungssystemen wird durch den Ansatz von Microservices flexibler. Die einzelnen Services werden voneinander entkoppelt. Damit gelingt es, die steigende Komplexität und Größe der Softwaresysteme in den Griff zu bekommen. Um den Aufwand, die Kosten und die Entwicklungszeit zu reduzieren, sollten nach Möglichkeit keine großen Systembrüche zwischen der Client- und Serverseitigen Entwicklung stattfinden.

Idealerweise können die gleichen Werkzeuge und Programmiersprachen eingesetzt werden. Der Vorteil liegt auf der Hand. Das Entwicklungs-Knowhow kann direkt weiterverwendet werden und die Kosten der Umstellung bleiben begrenzt.

* Dr. Veikko Krypczyk ist begeisterter Entwickler und Fachautor. Elena Bochkor arbeitet primär am Entwurf und Design mobiler Anwendungen und Webseiten. Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter Larinet.com.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  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? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46177340 / Microservices)