Mesos als Microservice Plattform

Vielen Firmen erkennen langsam das sie mit ihrer Monolytisch aufgebauten Software oder gar Plattform an ihre grenzen stossen. Wir haben uns daher schon sehr frueh mit der Moeglichkeit auseinandergesetzt, unsere Kunden beim Weg in die Microservices Tatkraeftig aber auch Beratend zur Seite zu stehen. Das Beides sinnvoll ist, erleben wir bei unserer Taeglichen Arbeit vor Ort. Microservices erfordert ein Umdenken beim Entwickler und Admin, aber vor allem auch beim Management. Starre Strukturen, dass festhalten an IP basierter Security aber auch Aengste Arbeit zu verlieren sind die haeufigsten Hindernisse bei der Einfuehrung.

Fangen wir aber einmal von vorne an. Betrachten wir als ersten einen Monolithen am Beispiel einer Hotelbuchungsseite. Wir haben einen Client (der WebBrowser), einen Server und eine Datenbank. Im Server ist die gesamte Logic wie Kunden, Hotel Infos, die Bestellungen enthalten. Gespeichert werden die Daten in einer Datenbank.

Kommt das System an ihre Grenzen, versucht man diese in die Breite zu erweitern. Anstatt einen Monolithen zu bedienen, hat man nun mehrere, dessen Zugriffe jeweils ueber einen Loadbalancer verteilt werden.

Aber auch mit diesem Model kommt man relativ schnell an die Grenzen des Sinnvoll machbaren. Kleine Aenderungen an der Software bedeuten meistens eine Aktualisierung und Downtime der gesamten Plattform. Ein Ausfall eines der Schluessel-Systeme koennte sogar das gesamte Konstrukt zum erliegen bringen. Neue Mitarbeiter benoetigen darueber hinaus viel Zeit um sich in die Komplexitaet der Software einzuarbeiten. Eine Produktive Weiterentwicklung wird mit der Zeit schwieriger. Verlassen Kernkompetenzen das Entwickler oder Betriebsteam, steht die Firma vor weiteren Problemen.

Schauen wir uns nun den Aufbau einer Microservice Plattform an. Hierbei betrachten wir die einzelnen Logicen unserer Hotelbuchungsseite als jeweils einzelnen Microservice. Wir erinnern uns, die Logicen waren Kunden, Hotel Infos, Bestellungen. Ich erweitere diese Logicen um einen weiteren Microservice welcher fuer die Grafische Darstellung der Seite (UI) zustaendig ist.

Alle hier dargestellten Services werden je nach Ressourcen Auslastung automatisch ueber einen Orchestrator Scaliert. Der Zugriff auf die UI erfolgt wieder ueber einen Loadbalancer. In der Programmierung kann ich Microservice vielleicht eher mit einer Klasse oder gar Funktion vergleichen. Ich zerlege also eine grosse Software in einzelne Funktionen die unter einander ueber eine API sprechen. Faellt eine einzelnen Funktion aus, ist somit nicht das ganze System gestoert. Als Beispiel, funktioniert der Kundenlogin oder die Bestellung nicht, wird trotzdem noch die Buchungsseite und Hotelinfos angezeigt. Habe ich als Entwickler eine Optimierung im Buchungsvorgang entwickelt, muss ich nicht die ganze Plattform aktualisieren sondern lediglich den einzelnen Microservice.

Neben diesen eher technischen Vorteil haben wir aber noch einen weiteren den man gerne einmal unterschaetzt. Den Menschlichen! Ein Monolith wird in der Regel in einer einzigen Programmiersprache entwickelt. Merkt man spaeter das die getroffenen Wahl eher suboptimal ist, kann man schlecht umschwenken. Vielleicht ist sogar aktuell kein entsprechender Entwickler auf dem Markt zu finden welcher diese Sprache beherrscht. Teilt man eine Software jedoch in Microservices auf, ist es moeglich und sogar sinnvoll, es den einzelnen Teams zu ueberlassen wie und in welcher Sprache sie die Funktion realisieren. Das einzige was definiert werden muss, ist die API. Diese stellt quasi ein Vertrag zwischen den Teams dar. Alles weitere kann das Team frei fuer sich entscheiden. Der Vorteil liegt hier klar auf der Hand. Durch die Entwicklerischen Freiheiten steigt die Motivation und das einarbeiten von neuen Personal geht schneller. Ist gerade kein Experte in z.B. Python vorhanden wird der Microservice in einer anderen Sprache entwickelt. Aengste die gesamte Plattform zu zerstoeren sind geringer wodurch Mut zu Innovationen steigt.

Schauen wir uns nun an, wie eine Microservice Plattform mit Docker und Mesos im groben ausschaut.

Das wunderbare an Mesos ist, wir sind generell frei in der Entscheidung welche Service Frameworks wir benutzen moechten. So kann Mesos direkt Marathon als Orchestrierungsservice, oder Elasticsearch und viele weitere verwenden. Mesos ist lediglich fuer das Ressourcen Management zustaendig. Hierbei sind wir flexibel in der Benutzung der Infrastruktur. Firmen koennen ihre eigene Private Cloud, Bare Metal oder, falls es einmal schnell gehen soll, AWS als Ressourcen hinzufuegen. Eine spaetere Migration in eine komplett neue Umgebung stellt ebenfalls keine grosse Huerde dar.

Sollten sie nun Interesse an einer Mesosphere Umgebung bei sich in der Firma haben, unterstützen wir sie gerne beim Aufbau und der entsprechenden Schulung und Beratung. Über unsere Kontaktseite finden sie die entsprechenden Wege um von uns ein Angebot einzuholen.