</TECH NEWS>
NEUESTES VON UNSEREN ENTWICKLERN:

07.11.2018 – von Linus|

Schrittweise Migration – Vom Monolithen zu Microservices

Viele Unternehmen, die sich dazu entscheiden Microservices einzusetzen, stehen anfangs vor den gleichen Fragen und Herausforderungen, mit denen auch wir uns bei der SH Telekommunikation schon konfrontiert sahen. Denn tatsächlich ergeben sich eine Menge Unsicherheiten, wenn man damit beginnt Microservices zu schreiben und zudem alte Funktionalitäten von monolithischen Anwendungen abzulösen. Um im Folgenden einige zu nennen:

  • Müssen wir auf Microservices wechseln?
  • Was gewinnen wir dadurch, wenn wir auf Microservices wechseln?
  • Was für Seiteneffekte bringen Microservices mit sich?
  • Was bedeutet es für die Entwicklung, wenn sie zusätzlich neben den monolithischen Anwendungen anfangen Microservices umzusetzen?

Auch wir bei SH Telekommunikation haben die Entscheidung für uns getroffen Microservices zu entwickeln. Folgende Punkte sind Gründe dafür:

  • Follow the trend – Wir wollen natürlich neue Technologien einsetzen und uns auch für andere Entwickler attraktiv auf dem Markt positionieren.
  • Reuse of services – Bei SH Telekommunikation betreiben wir unterschiedliche Plattformen, die Überschneidungen in den Businessprozessen besitzen. Hierfür können Services geschaffen werden, die von den Plattformen gemeinsam genutzt werden können.
  • Decoupling of processes – Das bedeutet eine striktere Trennung zwischen Geschäftslogik und Frontend. Die Services stellen APIs bereit, die von einer bestehenden Applikation oder einer neu entwickelten Applikation/Frontend angesprochen werden können.
  • Build fast – Kleinere Teams übernehmen einen Teil der Geschäftslogik. Durch das Bereitstellen kleinerer Applikationen muss nicht mehr das große Ganze gebaut werden. Unittests und deployments können so ebenfalls beschleunigt werden.
  • Scaling – Bestimmte Domains werden häufiger angefragt als andere oder müssen explizit mehr Last verarbeiten. Wenn Geschäftslogik in Services geschnitten ist, lassen sich die Prozesse der Domains besser skalieren, sodass andere Services davon unbetroffen bleiben.

Microservices haben allerdings auch ihre Schattenseiten. Wenn man einen Monolithen aufbricht und durch Microservices ablöst, muss man ebenfalls einiges beachten:

  • Transaktionales Verhalten über die Services hinweg nimmt eine hohe Komplexität an. Das, was vorher in einer Applikation in einer Transaktion ausgeführt werden konnte, wird gegebenenfalls Eventually Consistent.
  • Auch durch die Vielzahl der Services wird ein Monitoring Logging wesentlich aufwändiger, denn unterschiedliche Services und Instanzen müssen überwacht und ausfallsicher bereitgestellt werden.
  • Eine Anfrage ist in einem Monolithen wesentlich einfacher nachzuvollziehen als in einer Service orientierten Landschaft. Anfragen über mehrere Services hinweg, beispielsweise Message Queueing oder HTTP Schnittstellen, müssen anders interpretiert werden.
  • Services wollen – wie auch andere Applikation – durch Berechtigungen abgesichert werden. Gerade in verteilten Systemen will man sich nicht an jedem Service neu authentifizieren. Diese Funktionalitäten müssen bereitgestellt werden, wenn sie noch nicht gegeben sind.

Im Folgenden geht es jedoch nicht darum, wie mit diesen Thematiken genau umzugehen ist, da dies zu umfangreich werden würde. Vielmehr erklärt der nächste Abschnitt wie eine monolithische Anwendung aufgebrochen werden kann ohne einen tiefen Einblick in technischen Implementierungen und die damit zusammenhängenden Herausforderungen zu geben.

Monolithische Anwendungen

Üblicherweise beinhaltet eine monolithische Anwendung ein Data Access Layer, die Geschäftslogik und eine visuelle Bedienoberfläche (UI), um die Geschäftslogik anzusprechen. Anwendungen entstehen nicht in einem Big Bang und sind dann final fertig, sie wachsen mit der Zeit. Neue Funktionalitäten kommen hinzu, bestehende müssen mit der Zeit angepasst werden. Und ehe man sich versieht, ist eine riesige Applikation entstanden, die jede Menge Geschäftslogik abdeckt. Dabei wird oftmals pragmatisch von dem UI auf unterschiedliche Bereiche der Business Logik und wiederum durch die Business Logik auf unterschiedliche Data Access Layer zurückgegriffen.

Eine Skalierung der monolithischen Applikation ist nur möglich, wenn man sie als Ganzes erneut startet. Oftmals ist das mit unnötigem Overhead belastet, da nur bestimmte Funktionalitäten oder Teile einer Domain unter Last stehen. Funktionen anderer Domains, die nicht so oft frequentiert angefragt werden, sind dennoch mehrmals bereitgestellt worden.

Anwendungen mit Microservices

Anders als bei einem Monolithen können Anwendungen, sei es eine native Applikation oder Single Page Applications (SPAs), sich von mehreren Microservices bedienen lassen.

Jeder Service deckt dabei einen Bereich einer Domain ab. Dabei können Microservices in jeder beliebigen Sprache implementiert werden. Zusätzlich erhält man eine strikte Trennung zwischen den Domains. Ein weiterer Vorteil dabei ist die Skalierung einzelner Microservices einer Domain. Funktionalitäten einer Domain, die wesentlich öfter angefragt werden, können somit hochverfügbar gemacht werden ohne großartig an Performance zu verlieren. Im Gegensatz zu denen können Microservices, die nicht so oft angefragt werden auf wenige Instanzen herunter skaliert werden.

Verschiedene Applikationen können sich durch die strikte Trennung der Domain, an den Services bedienen, die sie letztendlich benötigen. So können Synergien zwischen den Applikationen geschaffen werden, indem sie die gleichen Microservices wiederverwenden können. Wie in dem Schaubild dargestellt benutzen das UI und weitere Applikationen Microservices zur Kommunikation. Im Schaubild wird aktuell nur die Kommunikation über API gezeigt, jedoch kann ebenfalls eine Kommunikation über Message Queueing Systeme stattfinden.

Herausschneiden einer Domain – Bereitstellung neuer Services

Wenn man monolithische Anwendungen aufbricht, werden Funktionsbereiche einer Domain in eigene Services ausgelagert. Die Größe der Services spielt dabei am Anfang keine Rolle, da ein weiteres Herunterbrechen auf weitere Services jederzeit möglich ist. Verwenden mehrere monolithische Anwendungen die gleichen Domains, kann man diese entsprechend für beide monolithische Anwendungen in einen Microservice extrahieren. Die monolithischen Anwendungen bedienen sich dabei der Funktionen des neuen Microservices. Ein Aufbrechen einer monolithischen Anwendung kann so weit getrieben werden, bis alle Domains in Services ausgelagert sind. Das alte UI kann dabei bestehen bleiben oder man löst es durch ein neues UI ab.

Erfahrungen

Mit dem Vorgehen haben wir bereits Teile der Dienstewirtschaft abgelöst und in eigene Microservices extrahiert. Dabei bedient sich das UI der Dienstewirtschaft an den neuen Microservices. Die Services lassen sich jederzeit getrennt voneinander skalieren und können von unterschiedlichen Applikationen angesprochen werden.



WEITERE SPANNENDE BEITRÄGE



Unternehmen Marken Team Presse Karriere Tech-Blog SH Händler-Shop