t3n News Infrastruktur

Die Wucht der kleinen Teile: Wie Microservices deine Projekte besser machen

Die Wucht der kleinen Teile: Wie Microservices deine Projekte besser machen

Ein kurzer Blick auf Google-Trends zeigt, dass das Interesse an „Microservices“ stetig steigt. Was bringen Microservices für Entwickler, das Deployment, den Betrieb und das Management von IT-Projekten? Dennis Winter und Timo Sellin vom Berliner IT-Dienstleister Neofonie berichten von ihren Erfahrungen beim Einsatz von Microservices.

Die Wucht der kleinen Teile: Wie Microservices deine Projekte besser machen

(Grafik: Shutterstock)

Der Einstieg in die Welt der „Microservices“ ist komplex: Die technische Infrastruktur muss geschaffen werden, eine gewisse Lernphase durchlaufen und die Projektplanung, Kundenkommunikation und Teamzusammenstellung reorganisiert werden. Dennoch lohnt sich die Transformation von einem „monolithischen System“ hin zu einer flexiblen „Landschaft der kleinen Dienste“, denn die meisten monolithischen Anwendungen leiden früher oder später an den gleichen Krankheitssymptomen.

So ist es bei stark gewachsenen Projekten oft schwer, veraltete Komponenten wie Libraries, Binaries oder gar Datenbanken zu aktualisieren. Alte Frameworks oder Build-Tools werden oft erst angefasst, wenn es keine andere Option mehr gibt. Hinzu kommt, dass mit höherer Komplexität des Projekts die Fehleranfälligkeit steigt oder Ausfälle teils dominoartige oder unvorhersehbare Züge annehmen. Das hat auch Einfluss auf die Rollouts, die auf Grund ihres Umfangs eher selten durchgeführt werden, oft lange dauern und häufig von allen Beteiligten mit einer gewissen Sorge betrachtet werden. Das kann so weit führen, dass einzelne Projektmitarbeiter nur zögerlich Änderungen umsetzen weil sie befürchten, die Folgen nicht gänzlich überschauen zu können und Fehler im System zu verursachen. Notwendiges Refactoring findet aus den gleichen Gründen in der Regel nicht mehr statt. Die Software droht zu erodieren. Im Worst Case kann das zur Unwartbarkeit führen, das heißt die Pflege und Weiterentwicklung verursacht so hohe Kosten, dass der Aufwand in keiner Relation mehr zum Nutzen steht.

Microservices helfen, viele dieser Probleme zu vermeiden und sie bieten einen Weg, Monolithen sukzessive abzubauen. Zentrale Voraussetzungen für die von Microservices sind der Ausbau der Kommunikation zwischen Software- und System-Entwicklern, die umfangreiche Automatisierung und eine klare Vision der zu erstellenden Dienste.

Impact I – Entwicklungsteam & Deployment

Die Cycle-Time – die Zeit von Beauftragung bis Lieferung eines Features – ist eines der Kernargumente für den Einsatz von Microservices. Auf dem Grundsatz, dass ein Service nur eine Aufgabe erfüllen sollte, werden Komponenten einer Plattform gekapselt und somit deren Funktionsumfang klar definiert. Entwicklern fällt es dadurch viel leichter, den Umfang einer Änderungen zu überschauen. In der Folge reduziert sich nicht nur der Aufwand für die jeweilige Implementierung, sondern auch die Zeit, die für nachgelagerte Tests benötigt wird.

Bei Microservices mit Docker rutscht zudem ein großer Teil der Infrastruktur in den Code. Als klassische Server-Infrastruktur existieren am Ende nur noch dedizierte oder virtuelle Hosts, die Rechenpower, RAM, Storage und einen Docker-Daemon zur Verfügung stellen. Beim Rollout wird das Starten oder Ersetzen der gewünschten Container automatisiert.

Docker-Logo. (Grafik: Docker)
Bei Docker rutscht ein Großteil der Infrastruktur in den Code. (Grafik: Docker)

Auf dieser Basis macht es am Ende keinen Unterschied, ob Anpassungen an einer Datenbank-Konfiguration oder an einer Web-Applikation vorgenommen werden. Alle Änderungen müssen den gleichen Weg durch Versionsverwaltung, Review-Prozess und die Continuous-Delivery-Pipeline gehen. Nur so lässt sich sicherstellen, dass bei der Implementierung neuer Features Fehler vermieden und alle Qualitätstandards eingehalten werden. Neofonie realisiert Reviews unter anderem mit Hilfe von Pull-Requests, die das Versionierungs-System Stash (Git) zur Verfügung stellt. Als Build-System kommt Go CD zum Einsatz.

Nach einer gewissen Reifephase, die alle derartigen Prozesse durchlaufen, ist der Weg frei zum Continuous Deployment - dem automatischen Ausrollen auf den Live-Systemen. Das erfordert die Automatisierung aller Schritte in der Delivery-Kette und ein hohes Maß an Testabdeckung, damit keine defekte Software ausgerollt wird. Neofonie verwendet für den Test von REST-APIs beispielsweise das Test-Framework Aiko - eine Open-Source-Eigenentwicklung die auch auf GitHub veröffentlicht wurde.

Für die Entwickler und Systems-Engineers ändert sich die Art der Zusammenarbeit. Wo sich zuvor die Spezialisten unterschiedlicher Abteilungen gegenseitig den Ball über den Zaun geworfen haben, trifft jetzt ein cross-funktionales Team selbstständig Entscheidungen. So kann es anstehende Aufgaben bestmöglich lösen. Diese Form von Empowerment wirkt sich motivierend auf alle aus, da es nicht nur langwierige und teils mühselige Kommunikation über den Umfang von Auftragsteilen eliminiert, sondern auch Ausdruck von Vertrauen aller Stakeholder ist. Trotzdem – oder gerade darum – ist eine enge Abstimmung innerhalb des Teams notwendig, denn es gilt der Grundsatz: „You build it, you run it“. Auch in der Neofonie waren die Entwicklungs- und Betriebs-Abteilungen strikt getrennt. Diese Trennung löst sich jedoch zunehmend auf, ganz im Sinne des DevOps-Gedanken und der Kunden.

Neofonie testet seine REST-APIs mit dem eigens entwickelten Open-Source-Framework Aiko. (Screenshot: GitHub)
Neofonie testet seine REST-APIs mit dem eigens entwickelten Open-Source-Framework Aiko. (Screenshot: GitHub)

Mitglieder eines solchen Teams bauen automatisch über die Zeit hinweg neben ihren Kernkompetenzen Fähigkeiten außerhalb ihrer bisherigen Tätigkeiten auf. Erfahrenere Kollegen validieren die Entscheidungen von weniger erfahrenen Kollegen. Das minimiert das Risiko, dass Wissensinseln entstehen und dass durch den manchmal unvermeidlichen Weggang einzelner Kollegen kostbare Informationen zum Projektaufbau verloren gehen.

Eine weitere, über die gesamte Projektlaufzeit hinweg integrale Rolle im Team ist die des Product-Owners, der die Produktvision der umzusetzenden Dienste aufrecht erhält und bei Rückfragen zur Verfügung steht. Denn wo sich schnell Arbeitspakete aus der laufenden ergeben, braucht es jemanden, der das finale Ziel stets vor Augen hat.

Er ist das kommunikative Bindeglied im Team und ermöglicht durch schnelle Informationsbeschaffung und klare Kommunikation die eigentliche Performance bei der Umsetzung der Komponenten.

Impact II - Betrieb

Die Sicherstellung des störungsfreien Betriebs für Services, deren Komponenten potenziell in jedem Moment im Rahmen eines automatischen Rollouts durch andere ersetzt werden können, stellt nochmal andere Anforderungen, als das bei konventionellen Architekturen der Fall ist.

Das offensichtlichste ist das Monitoring. Statische Konfigurationen sind nur bedingt einsetzbar. Die Systemüberwachung selbst muss Teil der Microservice-Infrastruktur werden. Nur so können valide Informationen zum Soll-Zustand der Dienste ermittelt werden. Eine höhere, erstrebenswerte Ausbaustufe dessen ist ein proaktives System. Dort werden die eingesetzten Kontrollen selbst in die Lage versetzt, korrektive Maßnahmen zu ergreifen und einzelne Ausfälle zu verhindern, wenn nicht gar zu beheben.

Das reduziert jedoch nicht die Notwendigkeit eines Incident-Response-Teams, das in der Nacht auf einen Zwischenfall im System reagieren kann, denn eine einhundertprozentige Automatisierung gibt es auch in komplexen Microservice-Infrastrukturen nicht. Dessen Aktivitäten allerdings beschränken sich normalerweise nur noch auf den bewusst entschiedenen oder unterlassenen Neustart oder das Hochskalieren von Instanzen. Für alles andere ist das Projektteam verantwortlich, das den Service gebaut hat.

(Grafik: Shutterstock)
Stockt ein Microservice, sollten die anderen auf dem Server ohne Probleme weiterlaufen. (Grafik: Shutterstock)

Zum Anderen ist Resilience ein wichtiger Punkt. Gemäß des Prinzips „Everything fails, all the time!“ darf der Ausfall eines Servers im Rechenzentrum oder der Absturz einer Anwendung zu keiner Beeinträchtigung der verbleibenden Services führen. Wenn ein Service ausfallen sollte, müssen dessen Konsumenten graceful damit umgehen. Sie dürfen auch bei Timeouts und invaliden Antworten keine Fehler werfen und müssen größtenteils weiter funktionieren. Das Wegbrechen einer einzelner Funktionalitäten hat in diesem Moment keine Folgen mehr für die Verfügbarkeit der Webseite. Es arbeitet dann lediglich der betroffene Teil der Seite nicht mehr, beispielsweise eine Suche. So können unschöne Fehlermeldungen vermieden und im Fall der Fälle eine konsumierende Komponente - wie ein Suchfeld oder eine Ergebnisliste - ausgegraut oder deaktiviert werden.

Impact III - Management & Sales

Wo zuvor Key-Account- und Projektmanager in regelmäßigen Abstimmungsrunden mit den Kunden Change-Requests und Milestones produzierten, um daraus formulierte Tickets am Ende in die Entwicklungsteams zu kippen, entsteht jetzt ein fließender Prozess. Große Change-Requests machen vielleicht noch Sinn, wenn es darum geht, einen großen Monolithen um- oder weiterzustricken. Änderungen an Microservices hingegen sind inhärent überschaubar und in der Regel deutlich schneller umsetzbar. Das Rollout setzt keine Downtime für andere Komponenten der Infrastruktur voraus. Das bedeutet für den Auftraggeber einen kürzeren Time to Market, Ausfallsicherheit, Stabilität, Resilience, Skalierbarkeit, sowie einen reduzierten Abstimmungs- und Planungs-Overhead.

Anfragen zum Status von Beauftragungen können schneller beantwortet werden und Zwischenzustände sind einfacher zu präsentieren. Die größste Herausforderung ist es, agile Konzepte firmenweit zu etablieren. Die Unterstüzung der Geschäftsführung und von externen Coaches ist dazu so gut wie unerlässlich.

Fazit

Die Vorteile, die Microservices gegenüber konventionellen Strukturen bieten, liegen klar auf der Hand.

  • Kürzere Time To Market und Cycle-Time
  • Bessere Wartbarkeit durch austauschbare Teile
  • Reduzierte Downtimes durch Incidents
  • Keine Downtime bei Rollouts
  • Resilientes Verhalten - ein einzelner Ausfall produziert keinen Domino-Effekt
  • Jeder Dienst läuft im Cluster und kann im Bedarfsfall problemlos skaliert werden
  • Technologie-Agnostisch - durch die Kommunikation via REST-Calls kann letztlich für jede Komponente die optimale Technologie verwendet werden, zum Beispeil Java oder Go, was mit einem Monolithen nicht möglich ist
  • Zukunftssicherer Betrieb - alte Technologien ersetzt man ohne großen Aufwand Stück für Stück durch Neue
  • Bugs und Fehlentscheidungen sind vom Umfang begrenzt und können mit vertretbaren Kosten korrigiert werden
  • Schnelle Reaktion auf (Business-)Anforderungen - ein neuer Service ist innerhalb von Minuten erstellt und auf der Produktions-Umgebung ausgerollt (wir brauchen zur Zeit etwa 30 Minuten dafür)

Über die Autoren:

dennis-winter-neofonie Dennis Winter ist Systems-Engineer und Teil des ersten Microservice-Teams in der Neofonie. (Foto: Malte Cornils / Neofonie)
timo-sellin-neofonie Timo Sellin ist Senior Software-Entwickler und beschäftigt sich unter anderem mit DevOps und Docker. (Foto: Malte Cornils / Neofonie)
Newsletter

Bleibe immer up-to-date. Sichere dir deinen Wissensvorsprung!

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
3 Antworten
  1. von grep am 20.03.2016 (13:21 Uhr)

    Hallo ...,


    sehr interessant und anspruchsvoll verfasster Artikel ... auch wenn dieser derart geschrieben worden ist dass besagter ledigl. als explizite Eigenwerbung der diesbezüglichen Projekte jener Autoren zu verstehen sein mag.

    Was Google (Trends) in Bezug auf Microservices anbelangt bin ich skeptisch inwieweit Googles Tool bestimmte 'Trends' ggf. versucht zu forcieren - kann / sollte man Google (inbes. in diesem Kontext) vollends vertrauen ?!
    Software welche nicht modular konzipiert worden kann leicht zum Einfallstor für entsprechende Angriffe werden.


    Ciao, Sascha.

    Antworten Teilen
  2. von Philipp Blum am 21.03.2016 (11:23 Uhr)

    Ich bin schon lange der Meinung, dass man auf Microservices umsteigen sollte. Sowieso sollte alles per REST-Interface verfuegbar sein. Dadurch lassen sich APIs nach aussen der einfach realisieren. Ich habe schon viele Unternehmen gesehen, in denen es diese gewachsene Infrastruktur gibt. Frueher oder spaeter fliegt einem das so derart um die Ohren. Es gibt nur 2 Leute im gesamten Unternehmen, die alle Einzelheiten der Anwendung kennen. Der Rest wird es auch niemals verstehen, weil das inzwischen 10 oder 15 Jahre Entwicklungszeit sind, die dahinter stecken. So etwas darf niemals passieren. Mitarbeiter kommen und gehen. Durch derartige Anwendungen wird man, als Unternehmen, erpressbar. Wenn es nur noch einen Mitarbeiter, unter 200 oder 300 gibt, der die Anwendung wirklich versteht, wird er irgendwann ein unglaubliches Gehalt verlangen. Als Unternehmen ist man gezwungen darauf einzugehen. Aber das heisst nicht, dass ich Neofonie dafuer nehmen wuerde. Ich mag diese Eigenwerbung ueberhaupt nicht.

    Antworten Teilen
  3. von grep am 21.03.2016 (12:29 Uhr)

    Hallo Philipp Blum,


    sehe ich ähnlich, obschon die Sache mit der Eigenwerbung für mich kein Ärgernis darstellt - ist schon okay, man möchte seine Produkte / Dienstleistungen natürlich medienwirksam propagieren ... und Neofonie ist sicherlich auch eine sehr gute Wahl.

    Ich mag es lediglich nicht wenn Informationen eines Artikels (auch durch Auslassungen) in einen surreal konstruierten Kontext gebracht werden sodass beim Leser ein verzerrter Eindruck entsteht ... nur um die eigene Webseite besser bewerben zu können ... dass ist hier aber definitiv NICHT der Fall.

    Da würde ich - wie bereits erwähnt - eher Google (Trends) weniger über'n Weg trauen ...; okay, die Wenigsten sehen dies vermutlich so paranoid wie ich !


    Ciao, Sascha.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Webentwicklung
Google-Suche-Trend: 20 Prozent aller Anfragen finden schon per Sprache statt
Google-Suche-Trend: 20 Prozent aller Anfragen finden schon per Sprache statt

Es sprechen immer mehr Nutzer mit ihrem Smartphone. Das hat Google-CEO Sundar Pichai bei seiner Google-I/O-Keynote am Mittwoch anhand der ihm vorliegenden Daten festgestellt. Jede fünfte … » weiterlesen

„Okay, Drittanbieter!“ – Google öffnet neue Spracherkennungs-API für Entwickler
„Okay, Drittanbieter!“ – Google öffnet neue Spracherkennungs-API für Entwickler

Googles Cloud-Plattform bietet ab sofort eine Spracherkennungs-API an. Damit sollen eure Apps, wie schon Google-Now, an den Lippen eurer Nutzer hängen. » weiterlesen

Flat 2.0: Was hinter dem neuen Design-Trend steckt
Flat 2.0: Was hinter dem neuen Design-Trend steckt

Je mehr Designer die fehlende Usability von Flat Design wahrnehmen, desto schneller hat sich ein neuer, mehr vollendeter Trend entwickelt: Flat 2.0. Wir gucken hinter den Trend. » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?