© abidal, 123RF

Cloudumgebungen sind in vielen Unternehmen dabei, die eigene IT abzulösen. Wer am Ende mehrere Clouds effizient verwalten muss, der braucht die richtigen Werkzeuge. Dieser Beitrag stellt sie vor.

Für Unternehmen sind private und besonders Public Clouds längst ernstzunehmende Alternativen für konventionelle IT-Setups. Auf der einen Seite haben die großen Anbieter wie Google und allen voran Amazon zu dem kommerziellen Erfolg dieses Konzepts beigetragen, andererseits waren auch Open-Source-Lösungen wie Open Stack maßgeblich daran beteiligt.

Das Ergebnis hält die IT-Abteilungen vieler Unternehmen auf Trab: Ein Wechsel hin zu einer Cloudstrategie ist keine Kleinigkeit, greift er doch erheblich in die Strukturen eines Unternehmens ein. Egal ob die Unternehmen eine eigene Cloud aufbauen oder sich bei einem Anbieter einmieten wollen: Cloudworkloads unterscheiden sich in beiden Fällen grundlegend von konventionellen Setups.

Schon das Ausrollen von Applikationen in virtuellen Maschinen gestaltet sich fundamental anders als mit physischen Rechnern, weil eine ganze zusätzliche Management-Ebene hinzukommt: Neben den virtuellen Maschinen muss auch der Virtualisierungshost verwaltet werden, auf dem sie laufen. Es wundert nicht, dass gleich mehrere Lösungen um die Gunst der Admins und Nutzer kämpfen, wenn es darum geht, die Probleme zu lindern, die solch ein Wechsel hin zur Cloud mit sich bringt.

Eine eigene Klasse von Programmen verspricht die Verwaltung von Ressourcen in Clouds zu erleichtern – und zwar auch über die Grenzen einer einzelnen Cloud hinweg. Das Linux-Magazin hat sich mehrere Vertreter dieser Gilde genauer angesehen und zeigt, wo die Stärken und Schwächen der jeweiligen Lösungen liegen. Neben Heat, das Orchestrierung in Open Stack ermöglicht, laufen im Vergleich auch Ansible, Manage IQ, Scalr, Bosh, Rundeck sowie Cloudify.

Liebling: Heat

Die Entscheidung, auf Heat [1] in diesem Artikel einzugehen, beruht auf einer simplen Einsicht: Zwar experimentieren viele Admins bereits mit Clouds und betreiben in Open Stack auch Dienste, doch Heat ist vielen bis heute unbekannt – obwohl es dem Admin viel Arbeit abnehmen kann. Heat ist die Open-Stack-eigene Orchestrierungskomponente.

Orchestrierung meint im Grunde die Fortsetzung von Automatisierung in einer Cloudumgebung. Das Prinzip beruht auf der Annahme, dass Admins es beinahe nie mit einer einzelnen virtuellen Maschine in einer Cloud zu tun bekommen. Das Beispiel eines typischen Setups macht das deutlich: Neben einer beliebigen Anzahl von VMs mit Webservern spielt hier meist auch eine Datenbank mit. Hinzu kommen vielleicht ein Load Balancer sowie Applikationsserver, die Hintergrundaufgaben für die Plattform erledigen.

All diese Komponenten wollen über ein privates Netz in der Cloud miteinander verbunden sein; viele brauchen aber auch zusätzlich öffentliche IP-Adressen. Wollte ein Admin sich ein solches Setup in Open Stack zu Fuß oder über die grafische Benutzeroberfläche Horizon konstruieren, sähe er sich einer ziemlich langen Liste von Arbeitsschritten gegenüber. Denn Netzwerke, VMs, IPs und auch Load Balancer sind in Open Stack eigene Ressourcen, die auch jeweils separat vor der Nutzung anzulegen sind.

Genau hier kommt Heat ins Spiel. Die Komponente erlaubt es dem Admin, ein Setup im gewünschten Endzustand abstrahiert zu beschreiben (Abbildung 1). Die Beschreibungen heißen Templates und können im Open-Stack-Beispiel als Json- oder Yaml-Datei vorliegen. In einem solchen Template listet der Admin alle Ressourcen auf, die seine virtuelle Umgebung benötigt. Danach übergibt er das Template an Heat, das die beschriebenen Ressourcen anlegt.

Abbildung 1: Heat-Templates sind abstrahierte Darstellungen des gewünschten Endzustands einer virtuellen Umgebung. Heat legt die nötigen Ressource an.

Am Ende erhält der Admin bereits nach wenigen Minuten ein schlüsselfertiges Setup, das er sofort benutzen kann. Im Gegensatz zur manuellen Variante fällt also nur einmal Arbeit an, um das Template für die Umgebung zu schreiben. Danach lässt sich die gleiche Umgebung beliebig oft aus demselben Template wieder starten.

Wer sich mit Cloudworkloads beschäftigt, kommt beim Open-Stack-Beispiel um Heat kaum herum. Die meisten in einer Open-Stack-Cloud nutzbaren Ressourcen lassen sich mittlerweile auch durch Heat-Templates beschreiben. Die Heat-Dokumentation listet sämtliche verfügbaren Ressourcentypen auf [2] und enthält auch praktische Beispiele, die sich gerade für Templateschreiber als sehr nützlich erweisen.

Heat-Alternative: Ansible

Konkurrenz bekommt Heat aus einer Ecke, aus der man das kaum erwartet hätte: Auch die Automatisierungslösung Ansible [3] versteht sich auf die Verwaltung von Ressourcen in einer Cloud. Eigentlich ist dies durchaus logisch: Auch ein Ansible-Playbook mitsamt den zugehörigen Rollen ist ja nichts anderes als die abstrahierte Darstellung von Arbeitsschritten, die in einer bestimmten Reihenfolge zu erledigen sind. Um ihre Lösung fit für die Cloud zu machen, liefern die Ansible-Entwickler eine ganze Reihe von Modulen, mit denen sich in Clouds Ressourcen anlegen, verwalten und löschen lassen.

Die Cloudfähigkeiten von Ansible eignen sich besonders für jene Admins, die bereits Erfahrung im Umgang mit dem Tool haben. Wer also schon Ansible spricht, kann ohne den Umweg über die Template-Sprache von Heat schnell zu Resultaten kommen, wenn er eine Open-Stack-Cloud unter den Fingern hat (Abbildung 2). Und im Gegensatz zu Heat funktioniert Ansible nicht nur mit Open Stack: Module zur Nutzung spezifischer Cloudfunktionen bietet Ansible etwa auch für die Cloud-Stack-Umgebung oder für Amazons Public Cloud.

Abbildung 2: Die Cloudmodule von Ansible ermöglichen Operationen direkt aus Ansible heraus in Cloudumgebungen, hier etwa Open Stack.

Ressourcen in Ansible konfigurieren

Das Prinzip ist dabei immer gleich: Wie gewohnt schreibt der Admin ein Ansible-Playbook, in dem er Ressourcen unterschiedlichen Typs verwendet. Die Ressourcentypen kommen aus den Cloudmodulen von Ansible, die unter [4] gut dokumentiert sind. Sobald das Playbook fertig ist, ruft der Admin Ansible auf, das auf Basis der vorhandenen Konfiguration die benötigten Ressourcen in der Ziel-Cloud anlegt.

Einschränkend sei aber angemerkt, dass Ansible kein vollständig kompatibler Ersatz für die Orchestrierungsdienste der jeweiligen Clouds ist. Zwar ist der Umfang der Cloudmodule bei Ansible beachtlich, doch decken sie nicht jede Funktion jeder Cloud ab. Keines der Module bietet zum Beispiel die Möglichkeit, in einer Open-Stack-Cloud einen Load Balancer aus Ansible heraus anzulegen – Open Stack Heat bietet diese Möglichkeit sehr wohl. Wer auf die fehlenden Ressourcen verzichten kann, sollte sich die Ansible-Integration für Cloudumgebungen definitiv genauer ansehen.

Aus einer anderen Richtung beleuchtet das Bosh-Projekt [5] das Problem. Hier steht nicht so sehr die Frage eines einfachen und kompletten Deployment im Vordergrund, sondern eher die Pflege einer Applikation, also die Abbildung eines kompletten Applikations-Lifecycle im Cloudkontext.

Bosh: Speziell für Entwickler

Das Deployment ist freilich ein Teil des besagten Lebenszyklus. Hinzu kommen dann noch solche Faktoren wie Updates beteiligter Komponenten oder das Ausrollen einer aktualisierten Version der jeweiligen Applikation.

Der Begriff Applikation bedarf im Bosh-Kontext der näheren Erläuterung: So bezeichnen die Bosh-Entwickler nicht etwa ein einzelnes Programm, das in einer VM in der Cloud läuft. Vielmehr geht es um den Applikationsbegriff, wie ihn der Cloudfoundry-Standard vorgibt. Danach ist eine Cloudapplikation die Summe aller Ressourcen, die in einer Cloud vorhanden sein müssen, damit ein spezifischer Dienst wie gewünscht funktioniert. Der Cloudfoundry-Standard gilt als Beschreibung des Idealzustands einer Platform-as-a-Service-Philosophie und Bosh war ursprünglich darauf ausgerichtet, einen Cloudfoundry-Workflow für PaaS-Projekte zu liefern.

Mittlerweile hat sich der Fokus des Projektes aber verschoben: Bosh unterstützt längst nicht mehr nur PaaS-Lösungen nach dem Cloudfoundry-Vorbild. Die Entwickler führen in ihrer Dokumentation etwa auch verteilte Systeme wie Hadoop an, die sich mit Bosh als Applikation in Clouds betreiben und pflegen lassen. Das Kernziel von Bosh ist nach eigener Aussage, die Entwickler beim Bauen, Paketieren und Ausrollen von Cloudapplikationen zu unterstützen.

Die Entwickler führen vier Prinzipien an: Zunächst lassen sich alle Teile einer Cloudapplikation direkt aus Bosh heraus verwalten, sodass Bosh zu jedem Zeitpunkt den Überblick über die komplette Applikation hat. Schritt zwei besteht darin, Reproduzierbarkeit zu erreichen: Änderungen an Apps, die in Bosh entwickelt werden, lassen sich zu jedem Zeitpunkt nachvollziehen und – wenn nötig – auch revidieren.

Das passt unmittelbar zum dritten Prinzip, der Konsistenz: Bosh bietet Entwicklern alle Werkzeuge, um zuverlässig und nachvollziehbar an einer Applikation zu arbeiten. Der letzte Faktor ist die Agilität: Auch verteilte Teams können Bosh nutzen, weil es etliche der Standards erfüllt, die die moderne, agile Software-Entwicklung vorschreibt.

Unter der Haube begegnen Entwickler vielen Werkzeugen, die ihnen aus dem Alltag bereits bekannt sein dürften: Als Stammzelle firmiert in Bosh etwa ein nacktes Betriebssystem-Abbild, das die Grundlage für eine neue Bosh-Applikation bildet. Git ist ein andres zentrales Bosh-Werkzeug und sorgt für nachvollziehbare Versionsverwaltung.

Das schlagende Argument für Bosh sind die vielen kleinen Arbeitsschritte, um die Bosh sich im Hintergrund ab Werk kümmert: Eine so genannte Stemmcell bearbeiten Entwickler erst per Git, um Bosh im Anschluss ein fertiges Cloudimage generieren zu lassen, das sich direkt in Open Stack oder anderen Clouds nutzen lässt. Wer also Applikationen für Cloudumgebungen baut und bisher die einzelnen Workflow-Schritte per Hand abwickelt, sollte sich Bosh dringend genauer anschauen.

All-in: Manage IQ

Die bisher vorgestellten Lösungen befassen sich vorrangig mit der Frage, wie sich im Kontext einer Cloud Anwendungen sinnvoll verwalten und pflegen lassen. Manage IQ [6] setzt eine Ebene höher an und präsentiert sich als universelles Verwaltungswerkzeug für Cloudumgebungen aller Art. Als einen seiner vielen Vorteile preist das Projekt an, dass Manage IQ auch Workloads in hybriden Clouds managet: Der Admin definiert auf der Ebene von Manage IQ also Ressourcenpools in verschiedenen Clouds, Manage IQ kümmert sich dann darum, anfallende Arbeiten mit Hilfe dieser Ressourcenpools abzuwickeln.

Manage IQ erscheint in zwei Varianten: Das “echte” Manage IQ ist ein Open-Source-Projekt, das sich direkt über dessen Website herunterladen und nutzen lässt. Daneben finanziert Red Hat das Projekt maßgeblich und vertreibt es auch kommerziell als Teil seines Cloudforms-Produkts: Diese Version bietet kommerziellen Support und eine Reihe Zusatzfunktionen, die zum Teil aber sehr spezielle Anforderungen erfüllen. Zuallererst ist Manage IQ ein zentrales Tool, um unter der einheitlichen Oberfläche eines Programms verschiedene Plattformen – also auch Clouds – zu steuern.

Im Kern besteht Manage IQ aus einer Appliance, die die Managementzentrale enthält: Jene Appliance ist der Single Point of Administration für Admins. Sie enthält auch das Manage-IQ-Webinterface. Auf der Website steht die Manage-IQ-Appliance als fertiges Abbild etwa für diverse Public Clouds bereit zum Download. Hier leistet Red Hat ausgezeichnete Arbeit, denn viel schneller lässt sich eine komplexe Anwendung wie Manage IQ nicht in Betrieb nehmen.

Zur Appliance hinzu gesellen sich Agenten: Für jede konfigurierte Cloud etwa gibt es einen separaten Agenten im Hintergrund. Agenten wickeln die Kommunikation mit den jeweiligen Cloudumgebungen ab und leiten auch Befehle an sie weiter, um zum Beispiel eine neue VM zu starten.

Allerdings beschränkt sich Manage IQ nicht auf das Starten und Stoppen von VMs in Clouds. Die Lösung hat selbst eine Art Lifecycle-Management für Cloudapplikationen eingebaut und kann etwa auch Betriebssystem-Abbilder verwalten, die entsprechend vorkonfiguriert sind. Obendrein liefert Manage IQ einen großen Schatz an Automatisierungs- und Orchestrierungsfunktionen und wildert damit im selben Wald wie die bereits beschriebenen Komponenten Heat oder Ansible.

Der Umgang mit Orchestrierung gestaltet sich bei Manage IQ allerdings etwas leichter: Viele komplexe Hintergrundprozesse bekommt der Admin hier erst gar nicht zu sehen. Er legt sich – im Normalfall per GUI – die Ressourcen so an, wie er sie benötigt, und Manage IQ kümmert sich um den Rest. Dabei bietet es erfahrenen Admins aber auch die Möglichkeit, an wirklich jeder Stellschraube des Systems zu drehen. Wer alle internen Funktionen von Manage IQ durchdringen möchte, hat ein hohes Lernpensum vor sich (Abbildung 3).

Abbildung 3: Manage IQ erlaubt Multi-Cloud-Management und bietet eine riesige Menge von Konfigurationsmöglichkeiten.

Skalieren, überwachen, alarmieren

Als vollumfängliche Management-Lösung kümmert sich Manage IQ auch um Themen wie Monitoring und Alerting. In der Software darf der Admin etwa Parameter festlegen, die beim Überschreiten bestimmter Schwellenwerte einen Alarm auslösen. Die Agenten, die im Manage-IQ-Sprech auch Smartproxy heißen, holen sich dazu von den ihnen zugewiesenen Clouds in regelmäßigen Abständen verfügbare Metriken und werten diese entsprechend aus.

Die Monitoring- und Alarming-Funktionen sind ein gutes Beispiel für das bereits erwähnte Lernpensum: Soll hier am Ende eine nützliche Funktionalität herauskommen, steht zunächst das Lesen von viel Dokumentation auf dem Plan. Ähnliches gilt für Manage IQs Feature zum automatischen Skalieren in die Breite. Fest steht jedenfalls: Wer Workloads über mehrere Clouds hinweg organisieren möchte, sollte Manage IQ genauer studieren – und zwar im Vergleich zu …

Scalr

Scalr [7] muss als Proband im Test unmittelbar auf Manage IQ folgen, denn es hat im Wesentlichen die gleichen Ziele wie Red Hats Zögling: Auch Scalr möchte es für Admins leichter machten, Setups in hybriden Clouds zu betreiben. Wie der Konkurrent von den roten Hüten basiert auch Scalr auf dem Open-Source-Prinzip. Das Scalr-Entwicklungsmodell unterscheidet sich jedoch von Manage IQ: Bei Scalr hinkt die zum Download bereitstehende Community-Variante etwa neun Monate hinter dem gleichnamigen Enterpriseprodukt hinterher, üblicherweise fehlen ihr also diverse Features der Bezahlversion.

Wer sich für Scalr interessiert, kann die Software entweder durch Scalr selbst auf dessen Servern hosten lassen, der Einstiegspreis beträgt rund 100 US-Dollar pro Monat. Alternativ gibt es eine Enterprise-Variante für das eigene Rechenzentrum, die mit knackigen 30000 US-Dollar zu Buche schlägt – wenn man sich mit dem Basis-Paket begnügt.

In Sachen Funktionalität gibt sich Scalr solide: Dreh- und Angelpunkt aller Admin-Aktivität ist die Weboberfläche der Lösung. Diese bietet etwa die Option einer einheitlichen Benutzerverwaltung für die eigenen Endkunden – bei Wiederverkäufern –, und zwar über die Grenzen verschiedener Clouds hinweg. Entsprechend kümmert sich Scalr auch um das Thema Authentifizierung: Neben der Möglichkeit, eine eigene User-Datenbank zu pflegen, stehen auch LDAP sowie Active Directory als Quellen für Nutzerdaten zur Verfügung. Ein eigenes System zur Rollen- und Rechteverwaltung rundet das Konzept ab: Die Scalr-Leute haben sich hier erkennbar Mühe gegeben.

Nützlich ist auch die eigene Orchestrierungskomponente, die schon ab Werk mitgeliefert wird. Sie hat eine eigene Template-Engine, mit der sich typische VM-Konfigurationen automatisiert anlegen lassen. Die Scalr-Entwickler heben noch die Statistikfunktionen ihres Produkts hervor: Scalr gibt per Mausklick einen schnellen Überblick über verfügbare Ressourcen und die aktuell entstehenden Kosten des eigenen Setups.

Über entsprechende APIs stehen diese Informationen auch externen Applikationen zur Verfügung; denkbar wäre etwa, die Cloudlösung an ein Billing-System anzuschließen (Abbildung 4). Eine fertige Implementation einer solchen Integration existiert zumindest im Augenblick aber wohl noch nicht.

Abbildung 4: Scalr bietet ein ähnliches Feature-Set wie Manage IQ und verfügt auch über Funktionen, um wirtschaftliche Metriken auszugeben.

Scalr hinterlässt insgesamt einen guten ersten Eindruck und macht Lust auf mehr. Ob man letztlich zu Manage IQ oder Scalr greift, dürfte vorrangig von den eigenen Vorlieben abhängen: Einen Test im eigenen Haus sind beide Werkzeuge sicherlich wert.

Noch mehr Orchestrierung: Cloudify

Der nächste Kandidat ist die Orchestrierungslösung Cloudify [8] von Gigaspaces. Sie siedelt sich thematisch irgendwo zwischen Ansible auf der einen Seite und kompletten Umgebungen wie Manage IQ oder Scalr auf der anderen Seite an: Cloudify bietet Orchestrierung für verschiedene Clouds an und versteht sich auch auf den Umgang mit hybriden Clouds. Weitergehendes Management wie bei den beiden zuvor genannten Lösungen fehlt allerdings. Denn bei Cloudify steht – wie bei einer Orchestrierungslösung zu erwarten – der Lifecycle einer Cloudapplikation im Vordergrund (Abbildung 5).

Abbildung 5: Cloudify arbeitet mit Blueprints, die den gewünschten Zustand einer virtuellen Umgebung beschreiben, und setzt sie dann in der Ziel-Cloud um.

Keimzelle eines Cloudify-Setups ist eine einzelne VM. In ihr läuft der Cloudify Manager, er führt das Kommando: Informationen über Clouds, in denen VMs zu starten sind, sind hier hinterlegt. Die Manager-VM betreibt auch die auf Tosca basierende Orchestrierungsumgebung, an die Nutzer ihre Templates in Tosca schicken. Features wie das automatische Skalieren in die Breite sind über einen eigenen Agent gelöst, den die von Cloudify gestartete VM gleich mitliefert. Merken die Agents innerhalb einer Installation, dass die aktuelle Gesamtlast zu hoch ist, lädt Cloudify entsprechende Instanzen nach, wenn der Verfasser des Template das so vorgesehen hat.

Gigaspaces, die Firma hinter Cloudify, hebt dessen Vielfältigkeit als Hauptfeature hervor: Neben der Arbeit mit Open Stack beherrscht Cloudify auch die Anbindung an VMware-Virtualisierungsumgebungen und spricht zudem mit Docker oder Kubernetes-Installationen. Gigaspaces verspricht sogar, dass sich mit Cloudify bestehende Workloads aus konventionellen Umgebungen ohne Schwierigkeiten in die Cloud verlagern lassen; in eben jenem Versprechen hat der Name des Programms letztlich auch seinen Ursprung.

Weitere Features erlauben Monitoring sowie Auto-Healing: Stürzen laufende Instanzen einer von Cloudify gestarteten Umgebung ab, kümmert sich die Management-VM von sich aus um den Start von Ersatzsystemen. Wer darüber nachdenkt, Applikationen in die Cloud zu verlagern, findet in Cloudify ein praktisches Werkzeug genau dafür. Die Standardvariante von Cloudify steht auf der Projekt-Website kostenlos zum Download bereit; eine kommerzielle Variante kommt mit Support daher.

Operations-Automatisierung: Rundeck

Mit Rundeck [9] schließt dieser Tools-Überblick. Bei dieser Software handelt es sich weder um eine Orchestrierungslösung noch um eine Verwaltung für Clouds. Rundeck ist vielmehr eine Automatisierungshilfe für typische Aufgaben aus dem Bereich Operating: Das Werkzeug erlaubt es dem Anwender, standardisierte Workflows auf Hosts per Mausklick über ein Webinterface in Gang zu setzen. Anders als alle anderen Tools im Vergleich bisher setzt Rundeck also erst auf der Ebene der virtuellen Maschinen an, die gesamte VM-Verwaltung bleibt fast vollständig außen vor.

Fast vollständig, weil Rundeck auf Host-Ebene arbeitet: Das Programm ist also zumindest auf die Information angewiesen, für welche (auch virtuellen) Hosts es verantwortlich ist. Sobald diese Konfiguration hinterlegt ist, erlaubt es Rundeck über Templates, Aufgaben zu definieren (Abbildung 6). Ein fertiges Template lässt sich anschließend auf den Hosts einer VM-Umgebung in einer Cloud automatisiert ausführen. Rundeck ist damit bereits ein praktisches Werkzeug außerhalb des Cloudkontexts.

Abbildung 6: Rundeck ist nicht nur im Cloud Computing zu Hause, es lässt sich dort aber auch gut nutzen.

In Clouds eröffnet die Software eine andere praktische Option: Sie schlägt eine Brücke zwischen managed und unmanaged Setups. Obgleich Clouds regelmäßig durch IaaS im Fokus stehen, gibt es dennoch viele Kunden, die sowohl ihr Setup in die Cloud umziehen als auch dem Anbieter den Betrieb des Setups übertragen wollen. Das heißt normalerweise, dass Kunden auf diesen Systemen keine Befehle ausführen dürfen. Diese Barriere umgeht Rundeck: Entsprechend vorkonfigurierte Aktionen dürfen Kunden dann per Mausklick starten, ohne einen Login auf den VMs der virtuellen Umgebung zu benötigen.

Module für die Kommunikation mit verschiedenen Cloudsetups sind übrigens in Rundeck bereits integriert: Eine Anbindung an Ansible, Chef oder Amazon EC2 erlaubt das Herunterladen der Node-Listen von dort. Weil Rundeck zudem eine aktive Fangemeinde im Netz hat, kursieren gleich mehrere Plugins, um zum Beispiel VM-Listen und Ressourcen-Listen auch aus Open Stack zu beziehen ([10], [11]).

Fazit: Viel los

Die vorgestellten Applikationen sind ein Querschnitt durch den Markt von Cloudprodukten, der äußerst aktiv ist. Sie stehen exemplarisch für eine Entwicklung, bei der Admins sich für praktisch jede Ebene einer Cloudinstallation das passende Werkzeug heraussuchen dürfen: Von der Steuerung diverser Clouds über die Orchestrierung von virtuellen Diensten bis hin zur Ausführung spezifischer Kommandos in VMs ist für jeden etwas dabei. Das geht sicher auch so weiter – Unternehmen werden weiter versuchen diesen Markt zu bedienen. Für Admins heißt das: Noch mehr Serviceroboter, noch mehr Möglichkeiten.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.