Microservices ist wie die Microbiologie

Microservices – was Sie über den Betrieb wissen sollten

Microservices sind noch immer Trendthema. Viele Unternehmen planen, ihre monolithischen Anwendungen dadurch zu ersetzen. Die Gründe liegen auf der Hand: Einfache Erweiter- und Skalierbarkeit oder Cloud-Readiness sind nur wenige Stichworte. Doch der flexible Architekturstil bringt auch Herausforderungen mit sich, besonders im Betrieb. Aber dafür gibt es Lösungen.

Wenn es um moderne Software-Architektur geht, liegen Microservices bei den Entwicklern noch immer hoch im Kurs, das zeigen aktuelle Trendanalysen (Link zu einer externen Seite). Denn die Vorteile sind verlockend.

Die Vorteile

Microservices ermöglichen die Modularisierung von Anwendungen. Hochkomplexe Software wird in kleine, gut handhabbare Dienste zerlegt. Die Gesamtfunktion bleibt erhalten, kann aber jederzeit schnell und nahtlos durch neue Funktionen erweitert werden. So wächst eine Anwendung über kleine wöchentliche oder sogar tägliche Updates einfach weiter. In monolithischen Architekturen dagegen ist jede Software-Aktualisierung ein Großereignis. Wichtige Innovationen lassen sich so erst umsetzen, wenn die Konkurrenz es wahrscheinlich schon längst getan hat.

Die am häufigsten genannten Vorteile von Microservices:

 

  • Durch kürzere Release-Zyklen und einfache Ersetzbarkeit lässt sich mit ihnen schneller auf Marktveränderungen reagieren.
  • Ihre starke Modularisierung erlaubt eine bessere Skalierbarkeit von Anwendungen. Damit wird auch das Deployment in der Cloud erleichtert.
  • Microservices unterstützen den Aufbau einer Continuous-Delivery-Pipeline
  • Ihr Code muss nicht in das bestehende System integriert werden. Erweiterungen werden dadurch stark vereinfacht.

Tatsächlich lohnt sich der Einsatz von Microservices vor allem, wenn

 

  • Systeme unterschiedlicher Technologien integriert werden sollen,
  • Teile eines Systems (temporär) hoher Last ausgesetzt sind und schnell dynamisch skalieren müssen,
  • eine Anwendung Cloud-ready sein soll,
  • Teile der Anwendung einer hohen Änderungsfrequenz unterliegen,
  • schnell auf veränderte Marktgegebenheiten reagiert werden muss oder
  • ein Legacy-System erweitert werden soll.
     

Allerdings bringt der flexible Architekturstil auch einige Punkte mit sich, die beachtet werden sollten. Entwicklungsseitig kann es schwierig sein, gleich zu Anfang einen sinnvollen Schnitt für die Anwendung zu finden. Schließlich entwickeln sich die Anforderungen und das fachliche Know-how erst im Laufe des Entwicklungsprozesses. Außerdem muss die Datenhaltung der verschiedenen aufeinander zugreifenden Microservices vollständig disjunkt sein, damit eine bedingungslose Deploybarkeit gewährleistet ist. Darüber hinaus wird die Infrastruktur komplexer, denn jeder Microservice benötigt eine eigene Umgebung. Und schließlich ist es wahrscheinlich, dass für die Entwicklung neue Technologien erlernt und beherrscht werden müssen.

Neben den technischen Implementierungshürden gibt es eine Reihe organisatorischer Überlegungen, die beim Betrieb von Microservices zu beachten sind. Dennoch holt man sich mit ihnen nicht unweigerlich mehr Komplexität ins Haus. Schließlich müssen viele der genannten Punkte auch bei monolithischen Systemen beachtet werden. Und auch wenn diese bei Microservices durchaus vielfältiger sind: Wenn man weiß, worauf man sich einlässt, ist ihr Einsatz beherrschbar – und kann sich sehr lohnen."

Fazit von Christoph Wellner, Senior Software Engineer

Herausforderungen im Betrieb – und wie Sie sie meistern können

Der Betrieb von Microservices wiederum stellt ganz eigene Anforderungen. Die wichtigsten Themen: Wartung, Wiederverwendung, Release-Zyklen, Sicherheit und Ressourcenmanagement.

Wartung

Jeder Microservice wird von einem einzigen Team entwickelt. Dieses Team ist vollkommen verantwortlich – für den Service, für die Umsetzung vom UI bis zum Backend, für die Entwicklung bis zum Deployment in die Produktion und auch für die Wartung.

Herausforderung:
Fehler in Microservices fallen meist erst nach Inbetriebnahme auf. Die Teammitglieder sind dann schon in anderen Projekten eingesetzt oder haben sogar die Abteilung oder das Unternehmen verlassen. Deshalb kann das Team unter Umständen nicht sofort auf das Problem reagieren. Besonders schwierig wird es dann, wenn bei der Entwicklung eine seltene Technologie eingesetzt wurde und das Wissen darüber mit den alten Kollegen verschwunden ist.

Tipp:
Um dies zu vermeiden, sollten möglichst wenige unterschiedliche Technologien eingesetzt werden. Diese sollten außerdem von mehreren Mitarbeitern beherrscht werden.

Herausforderung:
Auch die Problemanalyse kann durch die modulare Microservice-Architektur erschwert werden. Ein Fehler in einem Microservice muss schließlich nicht zwangsläufig in diesem selbst seinen Ursprung haben. Er kann ein Folgefehler aus einem anderen Microservice sein.

Tipp:
Um die Fehlerquelle zu ermitteln, ist ein zentrales Logging und Monitoring unabdingbar. Andernfalls müssen mehrere Teams koordiniert und Informationen mühsam gesammelt werden. Ein zentrales Logging ist zum Beispiel mit ELK-Stack (Link zu einer externen Seite) realisierbar. Damit können Log-Nachrichten aus allen Microservices zentral durchsucht und analysiert werden.

ELK-Stack

Problemanalyse bei einer modularen-Architektur in den Griff bekommen - ein zentrales Logging mit ELK-Stack aufsetzen.

Wiederverwendung

Eine einfache Methode, den Wartungsaufwand in einem System zu verringern, ist die Verwendung bestehender Microservices aus anderen Systemen. Schließlich sind diese bereits getestet und in Produktion. Hier ist allerdings Vorsicht geboten. Und das aus mehreren Gründen.

Herausforderung:
Die Erfahrung zeigt, dass die Funktionalität des Moduls nur selten zu 100 % für die neue Aufgabe passt. Es stellt sich nun die Frage: Muss der verwendete Microservice angepasst oder erweitert werden? Wenn ja, hat die Änderung Auswirkungen auf andere Funktionalitäten der Anwendung oder Systeme?

Tipp:
Um dies zu erkennen, ist eine gute Testabdeckung notwendig, die bei Änderungen verwendeter Ressourcen Alarm schlägt. Dazu muss nicht nur der eigene Microservice getestet werden, sondern auch in Verbindung mit den anderen verwendeten Microservices. Auch müssen die Ergebnisse geprüft werden und nicht nur, ob der Service prinzipiell funktioniert. All diese Tests sollten automatisiert ausgeführt werden.

Herausforderung:
Verwenden Sie einen Microservice, um zum Beispiel eine zentrale Berechnung für mehrere andere Funktionen durchzuführen, laufen Sie Gefahr, den Überblick zu verlieren. Möglicherweise vergessen Sie dann bei der Einführung eines neuen Service für diese Berechnung davon abhängige Funktionen. In der Folge arbeitet das System an dieser Stelle mit falschen oder veralteten Werten.

Tipp:
Auch hier hilft ein zentrales Monitoring, um den Überblick zu behalten.

Release-Zyklen

Herausforderung:
Wenn jedes Team seine Services eigenverantwortlich bereitstellt, existieren auch keine einheitlichen Zeitpunkte für die Bereitstellung von Patches und Erweiterungen. Insbesondere bei nicht-abwärtskompatiblen API-Änderungen oder Änderungen, die aufeinander aufbauen, kann das problematisch werden.

Tipp:
Release-Termine sollten daher unter den Teams abgestimmt werden. Zudem brauchen Sie Strategien für den Fall, dass unterschiedlichen Release-Termine dennoch zu Problemen führen.

Sicherheit

Herausforderung:
Microservices bieten durch ihre Webschnittstellen eine breitere Angriffsfläche als Monolithen.

Tipp:
Neben der Absicherung der Kommunikationskanäle, zum Beispiel durch HTTPS, muss der Zugriff geregelt werden. Wie? User und Berechtigungen zur Authentifizierung und Autorisierung werden am besten zentral verwaltet. Die Anmeldung an einem Microservice erfolgt via Token, der von zentraler Stelle erzeugt wird. Die Authentizität des Tokens wird mittels digitaler Signatur geprüft. Zudem enthält der Token Informationen über Berechtigungen des Users, die vom Login-Mechanismus des Microservice überprüft werden müssen. Eine Implementierung ist beispielsweise per JSON Web Token (Link zu einer externen Seite) möglich.

Herausforderung:
Auch die grundsätzliche Technologiefreiheit bei der Entwicklung vergrößert die Angriffsfläche.

Tipp:
Alle eingesetzten Technologien müssen deshalb auf dem aktuellen Stand gehalten und gehärtet werden, um Einfallstore zu schließen. Dies gilt sowohl für eingesetzte Libraries, Frameworks oder Datenbanken als auch für die Infrastruktur, auf der Microservices bereitgestellt werden.

Grundsätzlich ist es daher sinnvoll, die Technologiefreiheit etwas einzuschränken und zu überwachen. Ebenso kann eine Inventarisierung der eingesetzten Technologien helfen. Diese sollte aber nicht nur die eingesetzten Technologien, sondern auch die Microservices selbst beinhalten, denn vor allem ungenutzte, ungewartete Zombie-Services können Angreifern als Zugang dienen.

Herausforderung:
Der Microservice-Ansatz erfordert, dass jedes Team, sogar jedes Team-Mitglied, einen Service bereitstellen, konfigurieren oder löschen darf. Damit gilt jedoch auch das gleiche für Angreifer, die über einen gekaperten Account Zugang zum internen Netz besitzen.

Tipp:
Zumindest die Administration von Microservices sollte deshalb einem separaten Team überlassen werden.

Herausforderung:
Dass eine kleine, unbedachte Änderung weitreichende Auswirkungen auf das gesamte System haben kann, hat
das Beispiel AWS (Link zu einer externen Seite) gezeigt. Der Grund des Problems: Je mehr Microservices verwaltet werden müssen, desto schwieriger ist es, den Überblick zu behalten – und desto anfälliger ist das System für Fehlkonfigurationen.

Tipp:
Konfigurationsänderungen sollten deshalb auf einem Testsystem erprobt werden. Eine hohe Testabdeckung hilft zudem, Auswirkungen der Änderungen im Betrieb der Microservices zu erkennen.

Ressourcen-Management

In einer Cloud-Umgebung verursachen ungenutzte aber belegte Ressourcen unnötige Kosten. Nicht mehr verwendete Microservices sollten deswegen außer Dienst gestellt werden. Damit verbessern Sie außerdem die Übersichtlichkeit und erhöhen die Sicherheit.

Herausforderung:
Dass ein Service nicht mehr verwendet wird, bedeutet nicht zwangsläufig, dass er nicht mehr aufgerufen wird. Ob dies der Fall ist, muss geprüft werden, bevor der Dienst abgeschaltet wird.

Tipp:
Auch hier hilft ein umfassendes Monitoring bei der Entscheidung.

Software Architektur

Architektur und Infrastruktur

Von der Idee bis zum fertigen System, vom Lastenheft bis zur fertigen Anwendung, vom Entwicklungsauftrag bis zur Realisierung: Wir entwickeln vollständige Softwarelösungen oder arbeiten als eng eingebundener Zulieferer von selbst entwickelten und produzierten Anwendungskomponenten. Als Entwicklungsdienstleister unterstützen wir unsere Kunden beim Design, bei der Architektur, der Softwareentwicklung, dem Test, der Produktion und dem Betrieb – gleich ob Anwendungskomponenten oder vollständige Systeme. Was können wir für Sie tun?

Anwendungsmodernisierung und Software Engineering

Digitale Transformation

Kostenersparnis, optimierter Betrieb und einfachere Wartung: Eine gelungene Anwendungsmodernisierung bringt viele Vorteile. Wir sind darauf spezialisiert! So sorgt unser Team dafür, dass Ihre fachlichen Anforderungen besser unterstützt werden und Ihre bewährten Anwendungen sicher und performant laufen – auf moderner Hardware und mit neuen Betriebssystemen. Dazu tauschen wir nicht einfach nur alte gegen neue Technik aus. Wir transformieren Ihre Anwendungen. So unterstützen wir Ihre dynamisch wachsenden Geschäftsprozesse, auch durch klassisches Software-Engineering.

Software Engineering Fachanwendungen

Digitale Transformation

Wir entwickeln moderne Fachanwendungen, die wirtschaftlich sind. Unser Ziel dabei: Ihr Erfolg. Dazu betrachten wir Fachanforderungen ganzheitlich und integrieren sie in Ihre Systemumgebungen. Selbstverständlich, dass wir Sie auch nach der Fertigstellung betreuen und professionellen Support anbieten – nicht nur in technischer, sondern auch in fachlicher Hinsicht.

Neueste Stories

Ansprechpartner

Christoph Wellner T +49 511 51 51 – 3700 F +49 511 51 51 – 3800

Kontaktformular

Leistungen

  • Skalierbarkeit
  • Cloud-Readiness
  • Microservices
  • Modularisierung von Anwendungen
  • kürzere Release-Zyklen
  • Continuous-Delivery-Pipeline
  • Legacy-System erweitern

Technologien

  • zentrales Logging und Monitoring mit ELK-Stack
  • Absicherung der Kommunikationskanäle per JSON Web Token
  • Ressourcen-Management