Canary-Release mit der Very Awesome Microservices Platform (Vamp)

Keine Kommentare

Im letzten Artikel der Serie “Microservice-Deployment ganz einfach” erkläre ich, dass Docker nicht zwingend notwendig ist, um Microservice-Anwendungen auszuliefern. Wie der Artikel zeigt, kann man die Linux-Paketverwaltung benutzen, um Microservice-Anwendungen schnell und komfortabel auszuliefern. Leider muss man sich bei diesem Ansatz um die Auslastung seiner Rechner und die Verteilung der einzelnen Microservices auf die unterschiedlichen Rechner selbst kümmern. Es ist aus meiner Sicht aber wünschenswert, dass man einem Rechner-Cluster einfach Arbeit in Form eines Microservice gibt und sich das Cluster eigenständig darum kümmert, die Microservices entsprechend zu verteilen und auszuführen. In der Praxis interessiert mich eigentlich nicht wo ein Microservice läuft, sondern nur das ein bestimmter Microservice läuft. Mit Kubernetes stelle ich im Artikel “Microservice-Deployment ganz einfach mit Kubernetes” ein Werkzeug vor, dass mich bei der Verteilung der Container in einem Rechner-Cluster unterstützt und mir zusätzlich auch noch dabei hilft, dass sich die Container auf unterschiedlichen Rechnern gegenseitig finden. Mein Kollege Christian Zunker beschreibt die Service-Discovery-Thematik, die durch die Verteilung von Docker-Containern auf unterschiedlichen Rechnern entsteht, ausführlich in seinem Artikel “Variation des Ambassador Pattern von CoreOS”.

Microservice-Deployments mit Kubernetes

Kubernetes benutzt Pods, Replication Controller und Services, um Docker-Container in einem Rechner-Cluster zu verteilen und auszuführen. Weiterhin verfügt Kubernetes über ein sehr nützliches Feature, das so genannte Rolling-Update. Mit ihm kann man beliebige Docker-Container über mehre Knoten hinweg zeitverzögert ausliefern. Damit hat man die Möglichkeit einen Microservice auszurollen und mit realem Traffic entsprechende Daten über den Erfolg eines Deployments zu sammeln, bevor ein Microservice im kompletten Cluster ausgeliefert ist. Geht etwas schief, hat man immer noch die Möglichkeit das Deployment abzubrechen. Damit minimiert man die Gefahr, dass grobe Softwarefehler im kompletten Cluster in Produktion landen. Allerdings gilt das nur für Softwarefehler, wenn unsere Fachabteilungen bei der Produktentwicklung Änderungen machen, die die Benutzer nicht gut finden, dann stellt man das erst am geringeren Umsatz nach dem Deployment fest. Es ist aber aus meiner Sicht wünschenswert, dass man im Produkt-Entwicklungsprozess Kundenfeedback nach Fertigstellung einer neuen Funktionalität einholen kann, um eine Produktidee zu verbessern.

Dazu wäre es gut, wenn man einen Router hätte, der die Verteilung der Benutzer entsprechend bestimmter Regeln auf unterschiedliche Docker-Container organisiert, um das Benutzerverhalten mit einem Teil seiner Kunden messen und analysieren zu können. Einen solchen Router besitzt Kubernetes allerdings nicht. Die Verteilung der Benutzer ist abhängig von der Anzahl der Knoten im Kubernetes-Cluster, auf die die neue Version der Software ausgeliefert ist. Daher bietet Kubernetes out-of-the-box keine Möglichkeit, ein so genanntes Canary-Release abzubilden.

Canary-Release

Ein Canary-Release verwendet man, um das Risiko bei der Einführung einer neuen Software-Version zu vermindern. Man stellt Änderungen erst mal nur einem Teil seiner Benutzer zu Verfügung und misst wie dieser Teil auf die Änderungen reagiert, bevor man die neue Software auf der kompletten Infrastruktur ausrollt. Durch dieses Vorgehen hat man die Möglichkeit die Software schrittweise zu verbessern.

Ein Canary-Release ähnelt in der Ausführung einem Blue-Green-Deployment, das aber das Ziel verfolgt, die Downtime einer Applikation zu minimieren. Dazu hält man zwei Infrastruktur-Stränge für zwei unterschiedliche Softwareversionen vor und leitet die Benutzer über einen Router auf die entsprechende Version um. Bei einem Blue-Green-Deployment macht man einen harten Wechsel auf die neue Version der Software. Beim Canary-Release leitet man dagegen z.B. nur 5 Prozent des Traffic auf die neue Version um. Mit einem Canary-Release möchte man also vielmehr herrausfinden, ob eine neue Funktionalität wirklich eine signifikante Veränderungen im Verhalten der Benutzer auslöst. Diese Releases können auch benutzt werden, um A/B-Testing zu implementieren.

Canary Release

Microservice-Deployments mit Vamp

Vamp oder Very Awesome Microservices Platform vereinfacht das Durchführen von Canary-Releases. Vamp unterstützt im Moment Mesos und Marathon, später soll aber auch Kubernetes als Container-Manager hinzukommen. Die Plattform wird von der niederländischen Firma magnetic.io entwickelt. Ähnlich wie Kubernetes ist Mesos ein Dienst zum Starten von Docker-Containern in einem verteilten Rechner-Cluster. Mesos ist zuständig für Ressourcenverwaltung im Cluster und kann mit Marathon das Deployment von Microservice-Anwendungen durchführen. Marathon übernimmt dabei die Aufgabe eines Schedulers, der die Verteilung und Ausführung von Docker-Containern steuert. Viele große Firmen setzen ähnliche Technologie-Stacks schon erfolgreich in Produktion ein, darunter sind z.B, Apple, Holidaycheck und Otto.

Bernd Zuther

Kampferprobter Projektveteran, der immer fokussiert auf die Lieferung von funktionierender Software in der vorgegebenen Zeit ist. Zu seinen stärksten Waffen gehören ein sicherer Umgang mit agilen Methoden wie Scrum und sein breit gestreutes IT-Wissen, das er gezielt dazu einsetzt, auch die schwierigsten Problemstellungen pragmatisch und einfach zu lösen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.