Manchem Administrator hängt das Thema Cloud mittlerweile aus verständlichen Gründen zum Hals heraus. Seit über zehn Jahren schwappt nun schon Welle um Welle an Veränderung durch die IT und zwingt Admins immer wieder, sich an neue Prinzipien, neue Programme und neue Technologien zu gewöhnen. Während eine ganze Weile der Fokus auf den Hyperscalern wie AWS oder Azure lag, beschäftigen Firmen sich in jüngerer Vergangenheit auch wieder verstärkt mit On-Premises-Ansätzen. Die Gründe dafür sind vielfältig: Mal spielt der Schutz von Daten und geistigem Eigentum eine Rolle, mal ist der eigene Workload in AWS oder Azure einfach nicht kostenffizient zu betreiben.

Das Beste aus beiden Welten bekommen Admins, wenn sie auf hybride Setups setzen. Somit können sie die günstigen Kosten für virtuelle CPUs und virtuellen RAM auf eigener Infrastruktur mit der wichtigen Flexibilität durch die Ressourcen der Hyperscaler kombinieren. Was in der Theorie einfach klingt, kommt in der Praxis allerdings mit ein paar handfesten Problemen daher. Eines davon, vielleicht sogar das größte: Wie verwaltet der Admin seine hybriden Workloads effizient?

Die Lösung sollte nicht darin bestehen, die benötigten Ressourcen in der privaten Cloud und bei AWS oder Azure händisch zu konfigurieren und hinterher mühselig zusammenzukleben. Nötig sind stattdessen Werkzeuge, die für Hybrid-Setups konzipiert wurden. Zum Beispiel Cloudify und Pulumi, die sich auf hybride Umgebungen spezialisieren oder Terraform und Ansible, die nicht speziell für hybride Workloads designt sind, aber mit diesen trotzdem gut funktionieren.

Bevor wir näher auf die genannten Tools eingehen, möchten wir uns kurz den technischen Herausforderungen hybrider Setups widmen. Denn nur der Admin, der diese Anforderungen kennt und ihre Komplexität versteht, findet zielgerichtet das passende Werkzeug für seine spezifischen Herausforderungen.

Wer in der IT arbeitet, kennt sicher das Bonmot, dass Standards eine tolle Sache sind, vor allem, weil es so viele von ihnen gibt. Das Problem trifft durchaus auch auf Clouds zu. Das Prinzip Cloud Computing fußt ja auf der Idee, dass Kunden Dienstleistungen wie Compute und Storage bei Bedarf buchen. Sie zahlen die in Beschlag genommenen Ressourcen nur, solange sie diese auch nutzen. Automation und Orchestrierung spielen in Clouds zudem eine wichtige Rolle: Nur wenn Nutzer Ressourcen ohne lange Vorbereitungs- oder Einrichtungszeit verwenden können, kann von Cloud Computing überhaupt die Rede sein.

AWS, Azure und jede private IaaS-Umgebung bieten entsprechende APIs, die aber nicht kompatibel zueinander sind. Beim Betrieb hybrider Workloads – ganz gleich, ob Sie sich in mehrere Clouds begeben oder einen Teil on-premises und einen Teil in der Cloud betreiben – bekommen Sie es insofern zwangsweise mit unterschiedlichen APIs zu tun. Und diese sind nicht der einzige fundamentale Unterschied. Andere Details wie etwa die Art und Weise, wie eine Cloud virtuelle Netzwerke nutzt, sind meist ebenfalls unterschiedlich zwischen den Zielplattformen. Werkzeuge, die hybride Workloads verwalten, müssen deshalb mehrere Fähigkeiten beherrschen. Einerseits sollten sie im Backend die APIs verschiedener Clouds auf dem Kasten haben, um dynamisch Ressourcen in Hyperscalern wie AWS & Co. anzulegen. Anderseits sollten sie ein grobes Verständnis der Art und Weise haben, wie spezifische Dienste – etwa virtuelle private Netze – in den jeweiligen Plattformen funktionieren. Und nicht zuletzt ist es wichtig, dass die Tools all diese Funktionen unter einer einheitlichen, einfach zu bedienenden Oberfläche für Sie als Administrator bereitstellen.

Wichtig dabei: Die Integration der einzelnen Clouddienste zueinander muss stimmig sein. Ein Werkzeug, das es Ihnen erlaubt, Workloads in den Hyperscalern auszurollen, ist zwar toll – es hilft aber nur bedingt, wenn es die Workloads im Anschluss nicht auch miteinander verweben kann. Das könnte beispielsweise bedeuten, dass in AWS gestartete VMs einen funktionierenden Kommunikationspfad mit den VMs in Ihrer On-Premises-Plattform haben. Vorweg sei verraten: Nicht alle Werkzeuge im Teilnehmerfeld beherrschen alle beschriebenen Features gleichermaßen. Das ist allerdings weniger mangelnder Entwicklerlust geschuldet, sondern mehr dem Willen zu spezialisieren. Den Aufschlag macht allerdings ein echter Cloud-Tausendsassa: Cloudify.

Cloudify ist ganz offensichtlich für die Verwendung in hybriden Clouds ausgelegt. Denn bei der Orchestrierungsplattform ist genau dieses Feature der Markenkern der Funktionalität, also jenes, mit dem der gleichnamige Hersteller auf Kundenfang geht. In einer früheren IT-AdministratorAusgabe war Cloudify bereits Thema [1], sodass wir das Werkzeug an dieser Stelle nur in aller Kürze vorstellen. Cloudify Spire schickt sich an, dem Admin das Verwalten diverser Workloads in hybriden Umgebungen zu erleichtern – bis hin zu einer Landkarte, auf der ein Admin in aller Kürze erkennen kann, wo genau die verschiedenen Teile seiner Ressourcen gerade laufen.

Ganz intuitiv arbeitet das Programm dabei allerdings nicht – denn Cloudify nutzt eine Vielzahl eigener Begriffe, mit denen der Admin sich zunächst befassen muss. Unter der Haube setzt Cloudify durchgehend auf TOSCA, eine XML-basierte Markup-Sprache mit dem Fokus auf die Nutzung in der Cloud. In TOSCA legen Sie sogenannte Blueprints Ihrer Applikation an. Ein Blueprint ist eine Beschreibung des gesamten Workloads, also aller VMs, die zu diesem gehören, ebenso wie die Ressourcen, die für diese nötig sind. Die virtuellen Netze gehören mithin ebenfalls in die Blueprints. Praktisch ist Cloudify damit eine Abstraktionsebene für die bestehenden Orchestrierungsdienste, die fast jede Cloud bietet. Aus Adminsicht bietet Cloudify den Vorteil, nur Kenntnisse zu einer Orchestrierungssprache vorauszusetzen. Würde sich der Admin stattdessen mit dem Orchestrieren der einzelnen Hyperscaler und IaaS-Lösungen wie OpenStack beschäftigen, wäre der Lernaufwand deutlich höher.

In mehrerlei Hinsicht unterscheidet sich Cloudify dabei gar nicht von den Orchestrierern der Konkurrenz. Es selbst setzt ebenfalls auf APIs, die mit den Werkzeugen kommunizieren, über die Cloudify Befehle vom Admin erhält. Der Workload ist denkbar einfach: Der Admin übergibt Cloudify ein Template in TOSCA, das wahlweise selbst geschrieben ist oder sich per Client-GUI auch zusammenklicken lässt. Cloudify interpretiert die darin enthaltenen Anweisungen. Ist es mit Logindaten für IaaS-Umgebungen oder Hyperscaler versorgt, loggt es sich bei diesen automatisch ein und erstellt die erbetenen Ressourcen. In der Benutzeroberfläche sieht der Admin anschließend einen Cloudify-Stack, dessen Ressourcen Cloudify bei den diversen Cloudplattformen im Hintergrund verwaltet. Mit den einzelnen Clouds kommt Sie dabei gar nicht in Berührung, was eine echte Erleichterung darstellt.

Zusätzlich fasst Cloudify mittlerweile vermehrt NFV-Themen ins Auge. Das Tool kommt aus einer netzwerklastigen Umgebung und beherrscht mit Leichtigkeit etwa die Integration externer Firewall-Appliances in den virtualisierten Workflow. Wer beispielsweise die Firewall-Appliances von F5 in seine Umgebung integrieren möchte, kann das aus Cloudify heraus per Mausklick tun. Das Steuern von Nicht-NFV-Ressourcen leidet unter der guten NFV-Integration aber keinesfalls. Obendrein macht Cloudify Ihnen Features zugänglich, die andernfalls nur mit viel Mehrarbeit auf die Beine zu stellen wären – etwa die automatisch konfigurierte Replikation von einzelnen Daten zwischen den Setups. Insgesamt eignet sich Cloudify besonders als Werkzeug für Admins, die schnell zu Resultaten kommen müssen – denn genau darauf setzt es den Fokus. Wer seine Work-loads gerne grafisch darstellt, ist bei Cloudify ebenfalls richtig, denn als eines der wenigen Multicloud-Management-Werkzeuge bringt Cloudify eine echte GUI mit – die der Hersteller erkennbar nicht stiefmütterlich behandelt.

In ein ähnliches Horn wie Cloudify stößt auch Terraform, obgleich hier manche Dinge etwas einfacher gehalten sind. Terraform kommt von HashiCorp, einer Firma, die dem einen oder anderen IT-Profi aus dem Cloudkontext ohnehin bekannt sein dürfte. Denn HashiCorp hat sich große Verdienste erworben etwa beim Design des "Cloud Ready"-Prinzips für Applikationen, das die Aufteilung in Microservices vorsieht. Diese sind deutlich leichter zu verwalten als die typischen Monolithen der Vergangenheit.

Ähnlich wie Cloudify ist auch Terraform [2] ein typischer Multicloud-Orchestrierer. Und wie Cloudify verfügt Terraform über eine eigene deklarative Skriptsprache, anhand derer Sie Templates für Ihre Ressourcen erstellen können. Danach stattet Sie Terraform mit den Credentials zu Accounts in diversen IaaS-Umgebungen aus, was die Hyperscaler ausdrücklich einschließt, und schon geht es los mit dem Ausrollen hybrider Workloads.

Praktisch: Terraform ist wie auch Cloudify ein Open-Source-Projekt, an dem die Community sich in den vergangenen Jahren sehr aktiv beteiligt hat. Weil Terraform eine Art Modulschnittstelle liefert, über die sich Funktionalitäten nachrüsten lassen, hat es tausende Module an Bord, um Support für die Zusatzdienste der einzelnen Hyperscaler zu implementieren. Die diversen Angebote in AWS etwa lassen sich aus Terraform heraus als Modul großteils nutzen.

Besonders zu schätzen gelernt haben Administratoren den Terraform-Workflow, der sich auf mehrere Schritte aufteilt. Hat der Admin eine Beschreibung des Workflows in Template-Form gebaut, gibt er diesen an Terraform weiter. Terraform generiert aus dem Workflow heraus zunächst einen Plan, legt die Ressourcen allerdings noch nicht unmittelbar in den Zielplattformen an. Das ist eine Art Netz und doppelter Boden für den Admin, der böse Überraschungen mit diesen Werkzeugen vermeiden kann. Erst wenn der Admin den Auftrag zum Ausführen gibt, legt Terraform los. Dasselbe gilt übrigens auch für Updates: Existierende virtuelle Umgebungen, die Terraform angelegt hat, lassen sich jederzeit aus der Plattform heraus modifizieren.

Der Orchestrierer eignet sich bestens für hybride Workflows. Das ergibt sich bereits aus der Tatsache, dass er Backends für mehrere Cloudplattformen beinhaltet und auch den Umgang etwa mit OpenStack beherrscht. Hilfreich: Auf Wunsch verwebt Terraform die Ressourcen unterschiedlicher Plattformen miteinander. Wer etwa Webserver auf AWS und einer lokalen IaaS-Umgebung ausrollt, kann per Terraform diverse CDNs dazu bringen, eingehende Anfragen automatisiert auf die verschiedenen Ziele zu verteilen. Dem Programm kommt dabei zugute, dass es auch mit externen Diensten wie Cloudflare oder DNSimple kommunizieren kann, und nicht nur mit Hyperscalern und typischen Cloudumgebungen.

Ähnlich wie bei Cloudify gibt es auch bei Terraform einen Wermutstropfen. Denn das Werkzeug ist im Kern zwar quelloffen, doch umfasst das lediglich die CLI-Edition. Wer ein grafisches Frontend will, setzt auf das kostenpflichtige "Terraform Cloud". Die Preise halten sich aber in Grenzen verglichen mit dem Aufwand, den der Admin aufbringen müsste, um den Umgang mit den verschiedenen Cloud-APIs selbst zu erlernen.

Einen sehr modernen Ansatz im Kontext von hybriden Cloudumgebungen bietet Pulumi [3]. Hybride Workloads auszurollen, steht hier gar nicht an erster Stelle – viel wichtiger ist die Art und Weise, wie Pulumi Entwicklern Effizienz ermöglichen will. Zur Erinnerung: Cloudify und Teraform haben beide eine ähnliche Zielsetzung. Sie dienen dem Administrator als eine Art zentrale Schnittstelle für die diversen Orchestrierer der IaaS-Plattformen, egal ob on-premises oder bei AWS und anderen Hyperscalern. Sie zwingen den Admin allerdings beide dazu, eine neue deklarative Skriptsprache zu lernen, um Ressourcentemplates für das Ausrollen in den Zielplattformen zu erstellen.

Genau hier setzt Pulumi an. Denn es bezeichnet sich selbst weniger als ein Orchestrierungswerkzeug und mehr als ein Software Development Kit (SDK), um Ressourcen in Clouds zu programmieren. Folgerichtig erfindet Pulumi auch keine eigene Skriptsprache, sondern verwendet Module, die sich über die Syntax verschiedener Programmiersprachen ansteuern lassen. Was abstrakt klingt, ist im Grunde ganz simpel. Ist ein Entwickler oder Administrator etwa die Arbeit mit Python gewohnt, ermöglicht Pulumi es ihm, seine Ressourcendefinition als Modul in Python zu verfassen. Dasselbe gilt für JavaScript und eine Reihe weiterer Skriptsprachen. Infrastructure-as-Code bekommt hier nochmal eine ganz eigene Bedeutung, weil es sich ja letztlich um Code handelt – wenn auch um Pseudo-Code, der durch den eigentlichen Interpreter so nicht zur Ausführung kommt.

Denn das ist die Kehrseite von Pulumi: Der Administrator hat kein lokales Binary, mit dem er seine Pulumi-Module unmittelbar ausführen kann. Stattdessen schickt er diese zu einem zentralen Pulumi-Dienst namens "Pulumi App" – ein webbasierter Service, dessen Nutzung für Einzelentwickler kostenlos ist. Wer den Dienst als Team nutzen will, braucht einen der Leistungspläne, die pro Jahr mit 50 Euro (Starter), 225 Euro (Pro) sowie einem variablen Preisschild (Enterprise) daherkommen. De facto ist Pulumi damit ein cloudbasierter Deployment-Dienst für hybride Umgebungen.

Hybride Workloads lassen sich mit Pulumi gut ausrollen; insbesondere unterstützt der Dienst die hybriden Ressourcentypen der gängigen Hyperscale-Umgebungen sowie IaaS-Dienste. Aus einer Pulumi-Anwendung heraus können Sie freilich auch Ressourcen in mehreren Umgebungen parallel anlegen und miteinander verweben, solange die jeweils genutzten Ressourcentypen das zulassen.

Steuern können Sie Ihre hybriden Applikationen anschließend über das GUI der Pulumi-App. Die gestarteten Apps erscheinen hier als "Stacks" mit einer Liste der zugeordneten Ressourcen. Auch das Verändern im laufenden Betrieb ist möglich. Wen die Notwendigkeit einer Subskription nicht abschreckt, der findet in Pulumi deshalb eine gute Alternative zu den anderen hybriden Werkzeugen mit viel weniger Lernaufwand.

Den vierten Proband hätte mancher Admin an dieser Stelle vermutlich gar nicht erwartet – Ansible [4] als klassischer Automatisierer darf in einem Beitrag über Werkzeuge zum Management hybrider Workloads aber durchaus vorkommen. Denn ähnlich wie die drei anderen Tools verfügt auch Ansible über eine breite Anbindung an die APIs verschiedener Hyperscaler und kann mit diversen On-Premises-IaaS-Plattformen umgehen. Red Hat selbst hat für Ansible den Hybrid-Cloud-Usecase explizit als Ziel vorgegeben [5], wenn auch in etwas abgewandelter Form. Demnach kümmert Ansible sich um die Konfiguration bereits ausgerollter Ressourcen wie etwa VMs – diese entstehen aber auf Zuruf anderer Tools, etwa CloudForms. Praktisch nötig wäre das aber nicht: Ansible kann VMs, Volumes, Netzwerke, IP-Adressen und andere Ressourcen in Azure, AWS oder OpenStack (als Vertreter der privaten IaaS-Angebote) durchaus selbst anlegen.

Der Vorteil liegt freilich gerade für jene Unternehmen auf der Hand, die für ihre Infrastruktur ohnehin Ansible nutzen: Sie befeuern ihre Cloud-Workloads aus denselben Quellen wie den Rest ihrer Infrastruktur auch. Daraus ergibt sich eine praktisch nahtlose Anbindung auch an bestehende Workflows wie CI/CD-Umgebungen und Bugtracker. Auch Infrastructure-as-Code ermöglicht Ansible auf diese Art und Weise. Zwar müssen Sie anders als bei Pulumi wieder eine eigene Syntax lernen, nämlich die von Ansible – falls Sie diese noch nicht beherrschen. Die Ansible-Syntax ist allerdings wohl eine der leichtesten Syntaxsprachen und stellt selbst absolute Anfänger nicht vor große Herausforderungen.

Einen Haken hat die Sache dann aber doch: Ansible ist nicht sonderlich gut darin, die Ressourcen, die es in Clouds anlegt, miteinander zu verweben. Ein Netz in AWS legt das Programm klaglos an – in dieses per Ansible anschließend jedoch eine Verbindung zu einem On-Premises-Standort hineinzubauen, ist automatisiert kaum möglich. Wer lediglich Ressourcen in den Zielplattformen anlegen will und bereits Ansible nutzt, sollte sich dessen Fähigkeiten aber durchaus einmal ansehen.

Hybride Workloads sind auch 2021 noch immer kein Selbstläufer. Die vorgestellten Werkzeuge leisten jeweils auf ihre Weise ausgezeichnete Arbeit und erleichtern dem Administrator das Leben erheblich. Wer auf bestimmte Sonderfunktionen verzichten kann und ohnehin bereits Ansible nutzt, findet hier ein mächtiges Tool, um den Workload in hybriden Umgebungen zu steuern. Am anderen Ende der Skala steht Cloudify, das geografisch verteilte Setups mit einer hübschen Oberfläche kombiniert und mittels TOSCA eine eigene Ressourcensprache mitbringt. Terraform und Pulumi sind in Sachen Funktionsumfang nicht nur zwischen diesen Lösungen angesiedelt, sondern stehen auch in gewisser Weise in unmittelbarer Konkurrenz zueinander. Wer also noch gar nicht etwa durch bestehende Infrastruktur festgelegt ist, sollte etwas Zeit einplanen, um die Probanden des Vergleichs auszuprobieren und ein Gefühl für ihre Leistungsfähigkeit zu bekommen.