Microservices rücken zur Zeit immer mehr in den Fokus, wenn es um Softwareentwicklung geht. Warum auch wir unsere Software basierend auf Microservice-Architektur bauen, wollen wir Dir in diesem Blogartikel näherbringen. Dabei gehen wir auf die Historie von Software-Architektur, die Flexibilität von Microservices und deren Vorteil bei der Skalierbarkeit ein.
HISTORIE
Bevor wir konkret auf die Vor- und Nachteile von Microservices eingehen, werfen wir noch einen Blick darauf, wie Software alternativ entwickelt werden kann und heutzutage oft auch noch entwickelt wird. Der Anfang der Softwareentwicklung liegt nämlich in monolithischen Strukturen. Monolithische Software verbindet ihre funktionalen Elemente in einer einzigen, großen deploybaren Einheit. Problem ist, dass diese zum einen alle Abhängigkeiten in nur einer Version unterstützt, zum anderen bringt das auch die Gefahr mit, bidirektionale Abhängigkeiten zwischen Modulen aufzubauen, die man nicht mehr los wird. Das kann langfristig zu großen Problemen führen, vor allem, wenn das Projekt mit der Zeit wachsen soll: Wartung und Weiterentwicklung werden mit zunehmendem Funktionsumfang immer komplexer und unübersichtlicher.
Aus dem Wunsch, Software übersichtlicher zu entwickeln, bildete sich die modulare Softwareentwicklung. Hier werden einzelne Funktionalitäten des Produkts in einzelne Module zerlegt, bleiben allerdings trotzdem in einer Anwendung, quasi ein strukturierter Monolith. Hier besteht jedoch weiterhin das Problem, dass das Projekt von einem Server abhängig ist und somit einzelne Ausfälle zum Ausfall des kompletten Systems führen können.
Hingegen werden bei der Microservice-Architektur die einzelnen Module in separat entwickel- und implementierbare Anwendungen ausgelagert. Somit kann teilweise bei Ausfall eines kleineren, einzelnen Services die Funktionalität der restlichen Applikation gewährleistet werden. Fällt das Chat-Modul aus, so hat dies keinen Einfluss auf die Funktionalität der anderen Services. Das Gesamtsystem funktioniert weiterhin, nur der Chat funktioniert nicht.
Mittlerweile setzen schon viele große Softwaredienstleister auf Microservices. Netflix, Spotify und viele mehr profitieren hier vor allem von der Flexibilität und Skalierbarkeit.
Doch wie würde man ein typisches System in Microservices aufteilen? Die Modularisierung geschieht hierbei über die Funktionalität: Jeder Service in unserem System übernimmt eine Funktion. Schaut man sich beispielsweise unsere Plattform zum Technologiepark Münster an: Unsere Boarding Station ist für die Nutzerverwaltung verantwortlich. Für die Verwaltung von Events haben wir die PrevoCabin entwickelt. Sie deckt von der Erstellung des Events bis hin zum Ticketverkauf alles ab. Natürlich kommen bei der Technologiepark-Plattform mehr als nur diese zwei Microservices zum Einsatz. Das dient hier nur als Beispiel, wie die verschiedenen Funktionen einer Plattform in Form von Microservices umgesetzt werden kann.
FLEXIBILITÄT
In der Entwicklung bringt die Agilität einen besonderen Nutzen für den Kunden. Während große Richtungswechsel bei der monolithischen Softwareentwicklung mit zunehmendem Fortschritt immer aufwendiger und teurer werden, kann der Kunde bei Microservices auch noch während der Entwicklung verhältnismäßig einfach Wünsche äußern. Das macht sich besonders bemerkbar, wenn sich die Anforderungen an die Software ändern: Wünsche, neue Features zu implementieren , kosten bei Monolithen aufgrund der fehlenden Gliederung in Teilsysteme viel Arbeit und dadurch Geld.
Die übersichtliche Struktur der Microservices gibt Kunden und Developern einen besseren Fortschritts-Überblick bei der Entwicklung.
SKALIERBARKEIT
Der größte Vorteil der Microservice-Architektur: Die Microservices können unabhängig voneinander skalieren. Bei einem Monolithen besteht das Problem, dass alle Anwendungen in einem großen Projekt und dadurch einem Server liegen. Benötigt eine einzige Komponente mehr Serverleistung, so muss die Serverleistung des kompletten Projekts erhöht werden. Das führt letztendlich dazu, dass ebenfalls für Bereiche zusätzliche Serverkapazität gebucht wird, die überhaupt keine zusätzliche Kapazität brauchen. Der Kunde bezahlt also für teilweise ungenutzte Serverleistung.
Hier setzt der Vorteil der separaten Deploybarkeit der Microservices ein: Benötigt ein Service mehr Serverkapazität, so kann man diese für die einzelne Anwendung hochfahren, ohne die Serverkosten der anderen Services hochzufahren. Vor allem bei großen Softwareprojekten kann das viel Geld sparen.
Darüber hinaus ist der Workload einer Plattform sehr variabel und kann von Faktoren wie Uhrzeit, Tag oder Saison abhängen. Nimmt man beispielsweise einen kleineren Online-Shop: Am Black Friday ist die Last meist um ein vielfaches höher als an anderen “gewöhnlichen” Tagen. Hier ist die Aufgabenstellung relativ leicht erkennbar und man kann beispielsweise anhand der Daten aus Vorjahren den Anspruch an die Server schätzen und die Leistung dieser im Vorhinein hochskalieren.
Das große Problem stellt sich allerdings, wenn der Anspruch an die Server unerwartet steigt. Skaliere ich meine Serverleistung manuell nach oben und riskiere, zu viel für ungenutzte Leistung zu zahlen? Möglicherweise unterschätze ich auch den Load und meine Server werden überlastet. Solche “Workarounds” werden bei monolithischer Softwarearchitketur genutzt. Sie sind leider wenig flexibel und verlässlich. Veranschaulichen wir das an einem Beispiel: Eine bekannte Internetpersönlichkeit ist mit seinem Einkauf in dem Online-Shop sehr zufrieden und beschließt, dies mit seinen Followern zu teilen. Tausende mögliche Kunden kommen auf die Seite und sorgen für einen unverhältnismäßig hohen Workload. Die Workarounds bei Monolithen durch eine manuelle Anpassung sind wenig flexibel, verlässlich und effizient.
Doch wie bereitet man ein Projekt optimal auf fluktuierenden Load vor?
Hier setzt das Auto Scaling der Microservices ein. Je nach Workload werden die Server der einzelnen Komponenten angepasst. So werden die Serverlasten perfekt und kosteneffizient balanciert.
Außerdem hat man die Möglichkeit, die Microservices regional zu skalieren. Dadurch, dass man die Microservices auf mehreren Servern in verschiedenen Regionen parallelschalten kann, kann eine höhere Ausfallsicherheit gewährleistet werden. Ein Grund für Serverausfälle könnten regionale Katastrophen sein. Wenn bei einem Blackout beispielsweise der Server in Nordkalifornien ausfällt, ist der betroffene Service über einen Server in einer anderen Region verfügbar und es kommt zu keinem Gesamtausfall. Des weiteren entscheidet ein Load Balancer, welcher funktionierende Server geografisch am günstigsten gelegen ist und spricht diesen an. Das führt grundsätzlich zu schnelleren Servicezeiten.
UNSER FAZIT
Jeder kennt Horrorgeschichten aus der Software-Entwicklung und die Wahrheit ist: die Realität ist meist noch schlimmer. Mit steigendem Funktionsumfang steigt die Unübersichtlichkeit. Die Wartung von Projekten und Implementierung neuer Technologien oder Features ist extrem kompliziert und kann ganz schön teuer werden. Bei vielen Problemen monolithischer Software-Entwicklung bietet die Microservice-Architektur eine Verbesserung: Eine klare Aufteilung der verschiedenen Funktionsbereiche in Microservices macht das Projekt übersichtlicher. Zusammen mit dem Kunden können Featurewünsche schneller und einfacher in das Projekt integriert werden.
In einer heutigen Welt, in der sich die Ziele und Ansprüche an ein Projekt ständig ändern, kann man mit Microservices meist schnell eine neue Richtung einschlagen. Außerdem kann das Autoscaling überflüssige Kosten für nicht genutzte Serverleistung minimieren. Aus all diesen Gründen haben wir uns als Lean Ocean auf die Entwicklung von Microservices spezialisiert. Die Microservices werden dann in einmalige Plattformen vereint.
