Der Himmel kann warten

Kommentar: Keine Wolke (JEE) 7

Bernhard Löwenstein

Die Spezifikation für Java EE 7 soll im Frühjahr 2013 offiziell verabschiedet werden. Nach
einigem Hin und Her steht nun fest, dass sie das Thema Cloud gänzlich außen vor lassen
wird. Aller Kritik zum Trotz: Diese Entscheidung war absolut richtig.

Java Magazin

Thomas Becker

Der Kommentar „Keine Wolke (JEE) 7“ von Bernhard Löwenstein erschien zuerst im Java Magazin 2.2013

www.javamagazin.de

„Sie liebt mich – sie liebt mich nicht – sie liebt mich – .“ Millionen von Margeriten

mussten für dieses Kinderspiel sicherlich schon ihre Blüten lassen. Was hat das nun mit Java zu tun?

Lesern, die eifrig alle Nachrichten verfolgen, die über die Java-Editionen veröffentlicht werden,

kommt wohl langsam der Verdacht auf, dass nach einem ähnlichen Verfahren entschieden wird,

wenn es um die Aufnahme von neuen Features und Technologien in eine der Plattformeditionen

geht. So hieß es anfänglich, dass die Modularisierung der Plattform und die Java-Module mit Java

SE 8 kommen sollen. Daraus wird nun aber doch nichts, denn das Thema wurde auf Version 9

verschoben. Ähnlich gestaltete es sich mit Java EE 7 und den Cloud-Features. Den anfänglichen

Plänen nach sollte diese Version ganz im Zeichen der Wolke stehen. Seit einigen Wochen steht

allerdings fest, dass dies nicht der Fall sein wird, da die Java-Community die Zeit als noch nicht

für reif dafür erachtet. Diese beiden Verschiebungen degradieren jedenfalls beide Editionen zu

besseren Zwischenversionen, die ein paar nette Verbesserungen enthalten. In meinem Kopf hat

sich durch die häufigen Wechsel jedenfalls ein Bild eingeprägt, das ich nicht mehr loswerde: Ich

sehe Larry Ellison, umgeben von seinen technologischen Chefberatern, in seinem Büro sitzen – mit

einer Margerite in der Hand – und jedes Mal, wenn er an der Blume zupft, geht eine aktualisierte

Pressemitteilung raus.

Trotz meiner kritischen Worte halte ich die Entscheidung, die nächste Generation der Java-

Enterprise-Plattform noch frei von sämtlichen wolkigen Funktionalitäten zu halten, für absolut richtig. Dass dies

auch viele andere Java-Freunde so sehen, bestätigt eine entsprechende Umfrage von JAXenter, bei der fast zwei Drittel die Entscheidung gutheißen. Wie sich bereits bei EJB3 gezeigt hat, kann

der Code-First-Ansatz – im Gegensatz zur Spec-First-Devise bei EJB2 – wahre Wunder bewirken

und uns letztendlich mit einer Technologie beglücken, die sich kaum eleganter spezifizieren lässt.

Dem Spring Framework sei Dank, denn es übernahm in Verbindung mit EJB3 quasi die Code-First-

Rolle. Da selbst Oracle kein Orakel im Keller stehen hat, das die Zukunft vorhersagt, und die Zahl

der von irgendwelchen Elfenbeinturmpredigern erstellten Technologiespezifikationen mittlerweile

groß genug ist, kann man den in der Java-Welt eingekehrten Pragmatismus durchaus sehr positiv

sehen.

Dass heute noch keiner so recht weiß, wohin die Reise überhaupt genau gehen soll, zeigt

sich am breiten Spektrum der aktuell verfügbaren Cloud-Lösungen. Das Java Magazin stellte

passend dazu erst kürzlich in einer vierteiligen PaaS-Serie ausgewählte Vertreter vor: Heroku [1],

Windows Azure [2], Amazon Beanstalk [3] und Red Hat OpenShift [4]. Auch auf der W-JAX 2012

in München konnten sich die Besucher bei der PaaS-Parade über die unterschiedlichen Cloud-

Plattformen mit Java-Unterstützung informieren. Eine Kategorisierung der aktuell verfügbaren

Lösungen lässt sich unter anderem nach folgenden Kriterien vornehmen:

  • Unterstützt das Cloud-System Java oder Java Enterprise?
  • Stellt es lediglich eine Laufzeitumgebung bereit oder unterstützt es den Entwickler während

    des gesamten Zyklus der Applikationsentwicklung?

  • Ist es nur öffentlich nutzbar oder kann es auch in Form einer Private Cloud betrieben

    werden?

  • Welche zusätzlichen Dienste und Systeme stehen innerhalb der Cloud-Plattform zur

    Nutzung bereit?

Klar ist jedenfalls, dass Java (Enterprise) in der Wolke auf PaaS-Level verfügbar gemacht

und die Java-Enterprise-Plattform in Richtung Mehrmandantenfähigkeit adaptiert werden muss.

Das Rollenmodell sieht hierbei folgende Stakeholder vor: Cloud Provider, Cloud Account

Manager, Cloud Customer, Application Submitter, Application Administrator und End-User. Rege

Diskussionen gibt es hingegen noch in Bezug auf die Spezifikation der SLAs, QoS, Elastizität,

automatische Systemanpassung und bedarfsabhängige Kapazitätsbereitstellung.

Ein weiterer Grund, weshalb ich die Verschiebung für nicht besonders tragisch halte,

ist die Tatsache, dass das Thema in der Wirtschaft und in der Industrie noch gar nicht so recht Fuß

gefasst hat. Ich habe erst vor wenigen Wochen bei den IBM developerWorks Days 2012 in Zürich

das Auditorium gefragt, wie relevant Cloud Computing für die Kunden ist. Gerade mal für einen von

rund achtzig Entwicklern war das Thema von Bedeutung, und auch hier sollte lediglich die

vorsichtige Variante, nämlich eine in einem herkömmlichen Rechenzentrum betriebene Private

Cloud, zum Einsatz kommen. Das halte ich persönlich zwar für eine Fehlentwicklung, da das

elastische Verhalten der Wolkenmaschine – meiner Meinung nach das wichtigste

Unterscheidungsmerkmal im Vergleich zu den früheren Ansätzen – nur beschränkt erreichbar ist. Es

ist aber auf alle Fälle ein Einstieg in die Materie. Erst bei Nutzung einer Public PaaS oder dem

Aufbau einer privaten Cloud-Plattform auf Basis einer Public-IaaS-Lösung spielt diese ihre ganze

Stärke aus. Bei allen anderen Lösungen muss man nämlich selbst wiederum die Ressourcen für die

Lastspitzen vorhalten. Grundsätzlich lässt sich aber festhalten: Angekündigte Revolutionen finden

nun einmal selten statt – wie so oft wird auch hier der technologische Wandel langsam über viele

Jahre vonstatten gehen. Klar ist für mich mittlerweile aber, dass es sich bei Cloud Computing nicht

nur um einen temporären Hype handelt, sondern dieser Ansatz langfristig unsere Art, wie wir

Software entwickeln und vor allem betreiben, maßgeblich beeinflussen und verändern wird.

Wie sieht nun meine Vision für eine Java-Plattform in der Cloud aus? Lassen Sie uns

einen Blick in die Vergangenheit werfen. Vor etwas mehr als einem Jahrzehnt kamen die ersten

Applikationsserver zur Ausführung von Java Enterprise-Applikationen auf. Jene nehmen dem

Programmierer seitdem viel Arbeit ab, da sie durch die Bereitstellung diverser Dienste die

Entwicklung auf ein höheres Level heben. So ist es heute möglich, eine vollständig transaktional

ablaufende Geschäftsanwendung zu implementieren, ohne dass man dafür eine einzige Zeile Code

schreiben muss. Dank Convention over Configuration muss der Programmierer dieses

Verhalten nicht einmal mehr deklarativ festlegen. Denn der Container sorgt dafür, dass der Aufruf

jeder EJB-Methode im transaktionalen Kontext erfolgt. Der Entwickler kann sich voll und ganz auf

das Schreiben der eigentlichen Applikationslogik konzentrieren. Er muss seinen Quellcode lediglich

gegen die entsprechenden APIs entwickeln. Interessanterweise hat sich die Nutzung des

Applikationsservers über die Jahre grundlegend verändert. War es früher gang und gäbe, einen

einzigen schwergewichtigen Applikationsserver für all seine Applikationen zu verwenden, so ist

mittlerweile eindeutig ein Trend zu vielen leichtgewichtigen Applikationsserverinstanzen mit jeweils

einer Applikation an Bord erkennbar. Darauf zielen beispielsweise auch die Architekturänderungen

am JBoss AS7 ab. Zwecks besserer Skalierbarkeit und Ausfallsicherheit begnügt man sich meist

nicht mehr damit, seine Anwendung auf nur einem Knoten zu betreiben, sondern in den meisten

Fällen kommt ein ganzer Cluster zum Einsatz. Genau hier müsste meiner Meinung nach nun die

Java-PaaS ansetzen. Was mit dem Applikationsserver begann, sollte die Wolkenmaschine

weiterführen – und damit die Java-Entwicklung auf ein noch höheres Level als bisher heben. Was

gäbe es Schöneres, als wenn man seine Anwendung gemäß dem bisherigen Programmiermodell

entwickeln könnte, sich aber auch um Dinge wie Skalierbarkeit und Hochverfügbarkeit nicht mehr

selbst kümmern müsste – sondern lediglich das gewünschte Skalierungsverhalten innerhalb eines

Deployment Descriptors über ein paar Konfigurationsattribute anzugeben hätte? Durch die Wahl von

geschickten Voreinstellungen und Convention over Configuration ließen sich selbst

diese Einstellungen auf ein Minimum beschränken, wenn nicht sogar gänzlich einsparen. Das wäre

ein wahrer Mehrwert der wolkigen Java-Plattform gegenüber allen bisherigen Lösungen. Man

müsste sich dabei auch im Vorfeld keine technischen Gedanken mehr darüber machen, ob das

System mit der Last zurechtkommt. Darum kümmert sich dann nämlich einzig und allein die Cloud-

Plattform.

Die grundlegend erforderlichen Änderungen ließen sich meiner Meinung nach mit

adäquatem Aufwand hinbekommen. In der Java-EE-Spezifikation muss in Sachen Systemarchitektur

der Applikationsserver durch eine verteilte Laufzeitumgebung ersetzt werden. Das Thema

Skalierbarkeit lässt sich so gut in den Griff bekommen. Lediglich bei der Hochverfügbarkeit wird

man passen müssen. Der Ausfall einzelner Knoten lässt sich zwar durch das redundante Ablegen

aller Statusdaten bewältigen. Doch sobald ein ganzes Rechenzentrum ausfällt – wie wir erst kürzlich

gesehen haben, kann das durchaus der Fall sein -, ist einem Cloud-Nutzer damit nicht mehr geholfen.

Da müsste man die Daten schon über die Rechenzentrumsgrenzen hinweg replizieren. Das führt aber

schnell dazu, dass man mit unterschiedlichen Rechtssystemen konfrontiert wird. Am besten wäre es,

die Ausfallssicherheit seiner Softwaredienste durch Replikation über die Herstellergrenzen hinweg

sicherzustellen. Die wissenschaftliche Community spricht dann von Sky Computing.

Angesichts der aktuell noch zu klärenden Fragen in Zusammenhang mit der Cloud scheint mir dieses

Thema derzeit aber wenig praxisrelevant – anders formuliert: Der Himmel kann sicherlich noch ein

bisschen warten!

Bernhard Löwenstein (bernhard.loewenstein[ätt]java.at) ist als selbstständiger IT-Trainer und

Consultant für javatraining.at und weitere Organisationen tätig. Als Gründer und ehrenamtlicher

Obmann des Instituts zur Förderung des IT-Nachwuchses führt er außerdem altersgerechte Roboter-

Workshops für Kinder und Jugendliche durch, um diese für die IT und Technik zu begeistern.

Geschrieben von
Bernhard Löwenstein
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.