Entwicklung und Bereitstellung von Java auf Middleware und in der Cloud: Aufstieg der Virtual Appliance?

Von Java EE über Google App Engine bis hin zu GigaSpaces - die Idee, gegen eine Middleware- oder "Infrastruktur"-API zu entwickeln, ist in der Java-Welt fest etabliert. Aber das sind feste Umgebungen. Mit dem (Wieder-)Aufkommen der Virtualisierung wird es nun möglich, eine eigene, auf die Bedürfnisse Ihrer Anwendung zugeschnittene Umgebung zu packen und schnell bereitzustellen. Die großen Middleware-Anbieter haben erkannt, dass es nicht nur möglich, sondern sogar notwendig ist, solche virtuellen Appliances zu erstellen: Die Einrichtung einer Produktionsanwendung umfasst zwangsläufig mehr als nur ein paar EARs. Hier werden wir uns den aktuellen Stand der Cloud- und Middleware-Bereitstellungswerkzeuge ansehen, mögliche zukünftige Entwicklungen untersuchen und Parallelen zwischen der Bereitstellung und verwandten Prozessen ziehen.

Wolke: Das Ende vom Anfang

Die erste Welle von IaaS-Cloud-Anbietern führte zu einem Haufen von Infrastrukturdiensten mit täuschend ähnlichen Spezifikationen, aber frustrierend unterschiedlichen, proprietären APIs, Parametern, Konzepten und Formaten. Die erste Welle von Cloud-Tools hat versucht, diesen Portabilitätsalptraum durch die Einführung gemeinsamer APIs und Terminologien zu bewältigen. Gleichzeitig gibt es Vorschläge für offene Formate für virtuelle Bilder und Hypervisor-APIs, aber es gibt noch keine Anzeichen für eine kurzfristige breite Akzeptanz. Eine Schwierigkeit bei den derzeitigen "Meta-API"^-Ansätzen1 ist die Tatsache, dass eine generische Unterstützung, d.h. die Bereitstellung von Funktionen, die von allen Anbietern unterstützt werden, zu einem kleinsten gemeinsamen Nenner führt, der zu klein ist, um von großem praktischen Nutzen zu sein. Der TemplateBuilder von jclouds ist ein interessanter Versuch, dieses Problem anzugehen, aber letztendlich wird nur die Einführung eines IaaS-Standards dieses Problem beseitigen können. Aus der Sicht eines Entwicklers besteht ein grundlegenderes Problem darin, dass ein "roher" Rechner, wie er durch ein virtuelles Image-Profil dargestellt wird, einfach zu unbedeutend ist, um nützlich zu sein. IaaS-Anbieter kommen dann aus der Welt der Bereitstellung, die sich mit Servern, Racks und Kernen beschäftigt. Aber Entwickler sind es gewohnt, gegen "Umgebungsdienste^"2 zu entwickeln, sei es ein Java EE-Cluster, ein LAMP-Stack oder eine ^{Hadoop-Installation3}.

Middleware: Java EE und einige mehr

Nach dem großen anfänglichen Aufwand für die Zusammenstellung von "Unternehmens"-Java EE-Implementierungen gingen die großen Unternehmensanbieter schnell dazu über, den Funktionsumfang der für Anwendungen verfügbaren Ressourcen zu erweitern, wie z.B. persistente Warteschlangen oder geclusterte Datenquellen. Als die Entwickler diese Funktionen entdeckten und nutzten, wurden die Anwendungen immer stärker an bestimmte, oft proprietäre Middleware-Plattformen gebunden. Infolgedessen umfasste die "Entwicklungsleistung" nicht nur die von Java EE vorgesehenen EARs, sondern auch eine Vielzahl von Konfigurationsoptionen und Ressourcendefinitionen für den Middleware-Container.Diese losen Pakete im Auge zu behalten und bereitzustellen und gleichzeitig daran zu denken, die entsprechenden Änderungen für die Zielumgebung vorzunehmen, hat sich als schwierige, zeitaufwändige und fehleranfällige Aufgabe erwiesen. In der Tat sehen die Benutzer die automatische Verwaltung dieser Pakete als einen der Hauptvorteile des Deployit-Produkts von XebiaLabs an. Langsam erkennen jedoch auch die großen Anbieter, dass eine effektive "Verwaltungseinheit" für die heutigen Java-Anwendungen über Java EE-Artefakte hinausgeht und auch Informationen über die Middleware-Konfiguration enthalten muss: eine "Virtual Appliance", könnte man sagen. Sowohl IBMs WebSphere CloudBurst als auch Oracles kommender Assembly Builder versuchen, dieses Problem anzugehen, indem sie es ermöglichen, WebSphere- und WebLogic-Konfigurationen zu erfassen, sie zu ändern und auf verschiedene Installationen anzuwenden. Beide Tools laufen nur im Kontext virtualisierter Umgebungen - tatsächlich bauen sie weitgehend auf den Virtualisierungsangeboten der Anbieter auf - und scheinen immer noch auf die IBM- bzw. WebLogic-Stacks beschränkt zu ^sein4.

Auf dem Weg zu konfigurierbaren virtuellen Appliances

Aktuelle virtuelle Bildformate sind im Wesentlichen eine lange Liste von Bits und Bytes des Arbeitsspeichers und des Festplattenspeichers. Über die API kann ich vielleicht einige einfache Infrastrukturdetails wie IP-Adressen oder die Anzahl der Kerne abrufen, aber darüber hinaus ist die beste Informationsquelle über den tatsächlichen Inhalt dieses Images ein Freitext-"Beschreibungs"-Feld, das hauptsächlich der menschlichen Lesbarkeit dient. Selbst wenn ich also eine Websphere ND 7.1-Installation mit einer Datenbank und einem Cluster gemäß den Unternehmensrichtlinien konfiguriert habe, gehen die meisten Details der Installation verloren. Natürlich ist es sehr schwierig, Abhängigkeiten programmatisch zu überprüfen, Richtlinien durchzusetzen oder sogar ein Image zu finden, das bestimmte Softwareanforderungen erfüllt (Java installiert, Version >1.5, neueste Betriebssystem-Patches usw.). Eine interessante Möglichkeit ist es, ein Image als Basisbetriebssystem zusammen mit einer Liste von yum-, rpm- oder ^{Conary-Paketen5} zu definieren. Dadurch erhalten Sie einen besseren Überblick über den Inhalt des Images und müssen das Rad der Paketierung und Installation nicht neu erfinden. Leider sind diese Paketmanager jedoch alle betriebssystemspezifisch und lassen nicht viel Spielraum für die individuelle Anpassung der Paketinstallation und -konfiguration.

Schablonen, nicht Klone

Bit-für-Bit-Beschreibungen von virtuellen Appliances machen es einfach, viele Klone einer Maschine zu instanziieren. In den meisten Fällen müssen wir jedoch eine Appliance instanziieren, die sich nur geringfügig vom Original unterscheidet - denken Sie an die Anmeldeinformationen für die Datenquelle, die Namenskonventionen oder die Portnummern. Tatsächlich ist unser "Image" in den meisten Fällen eher eine Vorlage, die instanziiert werden muss, als ein Master, der nur geklont werden muss. ^Leider6 unterstützen die aktuellen Formate für virtuelle Maschinen dies nicht. Cloudlets sind ein interessanter Ansatz in dieser Richtung. Sie ermöglichen es Ihnen, den Dateisystembaum des Images festzulegen und dabei gegebenenfalls Vorlagendateien zu verwenden. Damit kommen Sie in Unix-Umgebungen schon sehr weit, lösen aber immer noch nicht alle Probleme: Die Parametrisierung einer WebLogic-Domäne durch Änderung der XML-Konfigurationsdateien ist schwierig und wird übrigens nicht unterstützt. Oder denken Sie an binäre Konfigurationen, Tablespaces in einer Datenbankinstallation oder die Windows Registry. Außerdem ist aus der Sicht eines Entwicklers in der Regel der von der virtuellen Appliance gelieferte Dienst interessant; ob Ihr GigaSpaces XAP-Grid ein oder 100 Images benötigt, um zu laufen, spielt eigentlich keine Rolle. jclouds' NodeSet, das die transparente Verwaltung und Skalierung mehrerer Images ermöglicht, scheint hier ein wichtiger konzeptioneller Fortschritt zu sein.

Virtuelle Appliances: eine Wunschliste der Funktionen

Mit der aktuellen Generation von Tools können wir einen Katalog von möglicherweise verwandten Images zusammenstellen, die portabel genug sind, um nicht an einen Anbieter gebunden zu sein. Mit ein paar Tricks und ein bisschen Blut, Schweiß und Tränen können wir sogar eine Art dynamische Konfiguration erstellen, auch wenn diese in der Regel spezifisch für den Inhalt des Images ist.Auf der Entwicklerebene gibt es bereits eine Handvoll Projekte, die sich auf die Bereitstellung von Plattformen konzentrieren, wie z.B. Crane, oder die eine "Plattformscheibe" auf die Infrastruktur aufsetzen, wie webappVM 7. Aber auch diese Projekte sind in der Regel auf einen oder eine begrenzte Anzahl spezifischer Dienste zugeschnitten. Was kommt als nächstes? Hier ein paar Punkte von meiner "Wunschliste" an Funktionen für die nächste Generation von Virtual Appliances: Round-Trip-Vorlagen Sie haben das vom Unternehmen genehmigte Basis-OS-Image genommen und viel Zeit damit verbracht, Ihre Middleware zu installieren, die Konfiguration genau richtig zu machen und sie sogar parametrisierbar zu machen. Einige Monate später wird ein neues Basis-Image veröffentlicht, und Ihr altes wird in der Produktion nicht mehr unterstützt. Derzeit behandeln wir Images als eine atomare Einheit, so dass es keine Möglichkeit gibt, den "Basis"-Teil, der vermutlich vom Operations-Team stammt, vom "Plattform"-Teil zu trennen, der wahrscheinlich von einem Entwickler installiert und konfiguriert wurde^.8 Strukturierte Metadaten Sie versuchen, ein Problem zu reproduzieren, auf das Sie in der Produktion gestoßen sind, und möchten schnell einen WebSphere-Cluster auf Ihrem Produktionsbetriebssystem aufsetzen, um es zu untersuchen. Heute werden Sie wahrscheinlich verschiedene Image-Bibliotheken nach geeigneten Vorlagen durchforsten. "WebSphere AS 6.1. auf Ubuntu" sieht vielversprechend aus, aber ist es die richtige Version des Betriebssystems? Wie hoch ist der Patch-Level von WebSphere? Welche Version von Java läuft darauf? Hoffentlich wird es bald möglich sein, diese Art von Anforderungen genau zu formulieren (und viele andere interessante, wie z.B. maximale Ausgaben oder erforderliche SLA) und die richtigen Images automatisch auszuwählen, bereitzustellen und zu konfigurieren, vielleicht sogar über mehrere Clouds hinweg. Service-basierte Bereitstellung Sie haben interessante Dinge über Terracotta gelesen und möchten herausfinden, ob es bei der gemeinsamen Nutzung von Sitzungen helfen könnte. Sie möchten also schnell einen Java EE-Container aufsetzen und Terracotta einbinden. Wie viele Images beteiligt sind und wie die genaue Version des Betriebssystems lautet, ist nicht einmal interessant - es geht Ihnen als Entwickler um den konfigurierten Dienst. Sie können Crane bereits bitten, Ihnen eine bestimmte Art der Hadoop-Installation zu liefern, und WebSphere CloudBurst unterstützt dies in begrenztem Umfang für bestimmte IBM-Produkte. Ich hoffe, dass dies bald für viele weitere Arten von Diensten möglich sein wird.

Waren wir hier nicht schon einmal?

Strukturierte Metadaten, Abhängigkeiten zwischen Images, Verwaltung von Composites, parametrisierbare Konfiguration... all diese Themen kommen den meisten Entwicklern furchtbar bekannt vor. Tatsächlich sind dies genau die Probleme, für die Tools wie Maven während des Build-Prozesses entwickelt wurden. Sicherlich ist das Spektrum möglicher Abhängigkeiten, Funktionen und Konfigurationsoptionen bei der Instanziierung und Erweiterung einer Multi-Image-Plattform weitaus größer als bei einem Software-Build, aber es gibt hier viele Räder, die hoffentlich nicht neu erfunden werden müssen. Vielleicht ist die Erkenntnis, dass das Festhalten an bestimmten Konventionen und der Verzicht auf die Möglichkeit, alle möglichen willkürlichen Änderungen vorzunehmen (oder sich zumindest nicht darum zu kümmern, es einfach zu machen), eine wichtige Lektion, die es zu lernen gilt.