Zum Inhalt springen
  • Von: Christian Luda
  • ijug Java Javaland
  • 06.02.2019

Ed Burns: „JavaLand ist groß genug, um internationale Referenten zu bieten, und klein genug, um mit ihnen ins Gespräch kommen"

Wir haben uns mit Ed Burns, Co-Spec Lead bei JavaServer Faces, über seinen Werdegang sowie seine kommende Keynote auf der JavaLand 2019 unterhalten.

Ed, im März bist du Keynote Speaker auf der JavaLand 2019. Kannst du einen kleinen Ausblick geben, was die Teilnehmer erwartet?

Darauf freue ich mich sehr, ich bin bei der JavaLand von Anfang an dabei gewesen und habe keine Konferenz verpasst. Ich werde eine Vergleichsanalyse darüber anstellen, was eine Programmiersprachenplattform erfolgreich macht. Ich habe darin ein wenig Erfahrung und war an der Entwicklung von JavaServer Faces (JSF) beteiligt, was man als Plattform bezeichnen könnte, auch wenn es im Grunde ein Web Framework ist. Im weitesten Sinne kann alles, worauf andere Software aufgebaut wird, als Plattform betrachtet werden. Während meines Mitwirkens an der JSF-Community und
-Technologie habe ich einen Einblick bekommen, was funktioniert und was nicht. Zu wissen, was eine erfolgreiche Plattform ist, hilft sowohl bei der Auswahl einer Technologie als auch beim Versuch, eine eigene Plattform aufzubauen. Meine Keynote wirft einen Blick auf Java, Go, SWIFT, Node JavaScript sowie Python und vergleicht diese auf technischer, ökologischer und ökonomischer Ebene. Außerdem erörtern wir die Entscheidungen, die die jeweiligen Vertreter getroffen haben, um ihre Sprachen dahin zu bringen, wo sie heute sind.

Wie du bereits sagtest, bist du nicht zum ersten Mal auf der Konferenz. Was gefällt dir besonders an der JavaLand?

Da gibt es für mich zwei Perspektiven. Zunächst die Besucherperspektive: Die Konferenz ist groß genug, um internationale Referenten sowie viele verschiedene Sichtweisen und Ideen zu bieten, aber gleichzeitig klein und informell genug, um es den Besuchern zu ermöglichen, mit den Referenten ins Gespräch zu kommen und auf verschiedene Weisen zu interagieren. Außerhalb der Session Rooms gibt es zahlreiche Möglichkeiten für Interaktion. Und dann bietet das Phantasialand natürlich eine vergnügliche Atmosphäre – die Open Park Night ist großartig, wenn das Wetter mitspielt. Aus Referentensicht kann ich sagen: Alles, was die DOAG veranstaltet, ist erstklassig, sehr gut organisiert und sehr professionell. Es ist immer eine Freude, mit der DOAG zusammenzuarbeiten – sowohl auf der Hauptkonferenz in Nürnberg als auch auf der JavaLand.

Wirst du etwas Zeit haben, Land und Leute zu erkunden?

Definitiv. Ich komme liebend gern nach Deutschland. Während der DOAG-Konferenz im November 2018 habe ich dort ungefähr einen Monat verbracht und alte Freunde aus der JSF-Community besucht. Das werde ich dieses Mal genauso machen. Ich habe ein paar gute Freunde in Köln. Dort gibt es den großartigen Club Barinton, wo donnerstags immer eine Open Jazz Jam stattfindet. Nach der Konferenz, wenn ich meinen Schulungstag mit Oliver Szymanski beendet habe, schlage ich dort mit meiner Trompete auf und spiele ein wenig.

Du hast einen Bachelorabschluss in Computerwissenschaft mit Deutsch als Nebenfach. Was hat dich damals bewogen, Deutsch zu studieren?

Als ich mich für meine Universität entschieden habe, gefiel mir die Tatsache, dass dort für Studenten der Ingenieurswissenschaften keine Fremdsprache vorausgesetzt wurde. Ironischerweise habe ich dann im zweiten Jahr eine Informationsveranstaltung für ein Austauschprogramm in Österreich besucht, und das hat mich sofort angesprochen. Es hat mich gepackt, und daran hat sich bis heute nichts geändert. Das war im Jahr 1994. Ich habe an dem Programm teilgenommen und jeweils einen halben Sommer in Wien und Deutschland verbracht. Seither liebe ich die deutsche Sprache und Kultur.

Das Interesse für Computer begann bei dir mit der Leidenschaft für das Computerspiel „Tunnels of Doom", für das du auch eine Fanpage unterhältst. Was fasziniert dich insbesondere an diesem Spiel?

Als ich mein Buch „Secrets of the Rockstar Programmers” geschrieben habe, hatte ich den Gedanken, dass Leute einer bestimmten Altersgruppe, jene die jetzt Mitte bis Ende vierzig sind, den besonderen Vorteil hatten, in einer Zeit aufzuwachsen, in der die ersten Personal Computer auf den Markt kamen. Da konnte man sich gar nicht widersetzen. Wenn du damals ein Kind warst, hattest du wahrscheinlich einen Atari, Commodore 64 oder Apple. Bei mir war es der Texas Instruments TI-99/4A. Alle Leute, mit denen ich für das Buch gesprochen habe – Rod Johnson, James Gosling, Nikhil Kothari –, hatten ähnliche Geschichten über ihre Anfänge und ersten Programmierplattformen. Das Spiel war großartig, es war ein frühes Rollenspiel, im Grunde ein Dungeon Crawler. Es gab Charaktere mit verschiedenen Attributen: einen Ritter, einen Zauberer, einen Dieb usw. Ich fragte mich schließlich, wer dieses Spiel geschrieben hatte, spürte ihn auf und interviewte ihn. Die Idee, Programmierer über ihre Arbeit zu interviewen, ist also etwas, was ich bereits seit fast 20 Jahren mache. Das Interview mit ihm habe ich im Jahr 2002 geführt. Er erklärte mir den Prozess des Programmierens für Texas Instruments. Er hatte dabei mehrere Auswahlmöglichkeiten. Die fortschrittlicheren Spiele wurden direkt in Assembler-Sprache programmiert. Die Firma versuchte eine Plattform aufzubauen, auf der Entwickler in einer einfacheren Sprache mit einem Basic Type Interface programmieren konnten. Aber die Möglichkeiten waren begrenzt, weshalb man schon damals die Vorstellung einer Auswahl von verschiedenen Plattformen für die Hardware hatte – und das sieht man heute noch. In Java werden noch immer bestimmte Technologien verwendet, die native Sprachbindungen und Abhängigkeiten aufweisen. Das zeigt, dass es immer gewisse Optionen gibt, wie man das Beste aus der Hardware, dem Betriebssystem und der virtuellen Maschine herausholen kann.

Auf der JavaLand leitest du zusammen mit Oliver Szymanski einen Workshop über Docker und Kubernetes. Was sind die Hauptvorteile der Verwendung von Containern anstelle von klassischen virtuellen Maschinen?

Der erste Vorteil ist Heterogenität. Bei virtuellen Maschinen verwenden die meisten aktuellen Unternehmensanwendungen eine breite Palette von Standard- und meist Open-Source-Technologien: Prometheus, Grafana, Kibana – alle möglichen Cloud-Modelle werden primär als Docker-Container verteilt und dann mit Kubernetes orchestriert. Das bietet die Freiheit, den eigenen Code als Teil der Geschäftslogik und spezifischen Unternehmensanwendungen zu nehmen und zu containerisieren. Zudem können bereits containerisierte Technologien einbezogen werden, die alle Unternehmen heutzutage verwenden. Es gibt aber auch einige Herausforderungen bei der gezielten gemeinsamen Verwendung von Java und Containern, da sich die beiden Technologien zu sehr unterschiedlichen Zeiten entwickelt haben. Container entstanden in den letzten sechs Jahren, Java Virtual Machines hingegen Mitte der neunziger Jahre. Es gilt, Vorkehrungen zu treffen, damit diese beiden weitestgehend zusammenarbeiten. Das geschieht, indem man die Metriken, Telemetrie- und Speicherverwaltungsparameter, die die virtuelle Maschine anpassen, mit den Aktionen der Docker-Container und vor allem der Kubernetes-Umgebung synchronisiert. So vermeidet man, dass die virtuelle Maschine unerwartet abstürzt, weil ihr der Heap-Speicherplatz ausgeht und sie immer wieder von Kubernetes neu gestartet wird, obwohl die Anwendung eigentlich nur das tut, was sie normalerweise tut. Werden die Parameter nicht korrekt übergeben, kratzt sich der Anwender am Kopf, weil er nicht weißt, was er tun soll.

Mit der Einführung von Docker hat sich die Containerisierung durchgesetzt. Was unterscheidet Docker von früheren Container-Tools?

Ich bin sehr stolz darauf, so lange bei Sun gearbeitet zu haben, denn in vielerlei Hinsicht war es ein sehr technikgetriebenes Unternehmen. Bei einer der frühen Containerlösungen war unsere Herangehensweise, Probleme zu finden und dann zu lösen. Die Geschäftsseite versuchte, einen Weg zu finden, dies zu monetarisieren und zu nutzen, während die technische Integrität hochgehalten wurde. Vieles was wir heute haben, gab es bereits damals. Für die Containerisierung gab es Solaris Zones, für das Cloud Computing selbst gab es das, was wir Grid Computing nannten – das hatten wir bereits 2004. Um also auf die Frage zurückzukommen, was Docker auszeichnet, und darüber werde ich in der Keynote sprechen: Sie waren zur rechten Zeit am rechten Ort. Wenn du eine wirklich großartige Idee hast, die anderen Dinge um sie herum aber noch nicht in Kraft getreten sind, setzt sich diese Idee nicht durch. Im Falle von Docker glaube ich also wirklich, dass es die Allgegenwart von GNU/Linux war, bei deren Etablierung Google im Wesentlichen geholfen hat, und dann der Aufstieg von Cloud-Plattformen, die einen gemeinsamen Anwendungsspeichermechanismus benötigten, den Docker zur Verfügung stellte. Einer der größten Mehrwerte von Docker ist die gesamte Dockerfile-Sprache, in der du beschreiben kannst, wie deine Container aufgebaut sind. Ein weiteres wirklich wichtiges Feature ist die Popularität des Docker Hubs selbst. Es ist einer dieser Fälle, in denen eine bereits vorhandene Idee aufgegriffen, besonders gut umgesetzt und mit einer sehr guten Marketingleistung gekoppelt wurde. Sie wussten, welche Konferenzen sie aufsuchen mussten – DevRel war ein wichtiger Faktor –, und sie haben einfach sichergestellt, dass das Produkt die Leute überzeugt.

Zu den Unterstützern von Docker zählen große Unternehmen wie Microsoft, Red Hat, IBM, Cisco und Google. Wie wichtig war deren Unterstützung für den Erfolg von Docker?

Das war ebenfalls wichtig. Ursprünglich waren die erwähnten Namen eher skeptisch und warteten ab, ob die Technologie sich durchsetzen würde. Aber zusätzlich zu den bereits erwähnten Bemühungen versuchte Docker, Teil eines offenen Standards zu sein. Es gibt die Open Container Initiative (OCI), die Teil der Linux Foundation ist, wo die anderen konkurrierenden Containertechnologien, insbesondere rkt, sich anmelden und sich verpflichten, den OCI-Standard für das Dateisystem und den Container selbst einzuhalten. Während sie sich in Bezug auf Laufzeitumgebungen und die Art der Virtualisierungstechnologie unterschieden, einigte man sich auf einen gewissen Standard. Das erleichterte den genannten Big Players die Entscheidung, mit an Bord zu kommen. Das ist eine Erfahrung, die ich schon früh in meiner Karriere gemacht habe: Es entsteht ein Kompromiss zwischen einem Unternehmen, das versucht, eine proprietäre Technologie zu monetarisieren, und einem anderen Unternehmen, das versucht, andere Leute dazu zu bringen, sie zu benutzen, ohne dass sie sich zu sehr darüber aufregen, mitmachen zu müssen.

Was macht Kubernetes so wichtig für die Orchestrierung von Container-Tools wie Docker?

Das Kubernetes-Projekt begann bei Google und den Leuten, die es ursprünglich entwickelt hatten – Brendan Burns, mit dem ich im Rahmen meines „Secrets of the Rockstar Programmers“-Projekt gesprochen habe, und sein Kollege, an dessen Namen ich mich leider nicht erinnere. Brendan Burns verließ Google und ging zu Microsoft, wo er für Kubernetes warb. Das ist der übliche Lauf: Microsoft sagt sich, hey, dieses Ding ist erfolgreich, lasst uns die Hauptperson einstellen, ihn einbringen, Azure aufbauen und vor allem natürlich unser aktuelles Produktportfolio. Es war also eine Container-Orchestrierung erforderlich, um den gesamten IT-Betrieb zu kodieren, von der Geschäftslogik über die Laufzeitumgebungen bis hin zum DevOps-Teil, der die Telemetrie bereitstellt und es ermöglicht, die Systeme bei Bedarf zu überwachen und angemessen zu behandeln, während die Nachfrage steigt und fällt. Es gab eine Notwendigkeit und dafür verschiedene Angebote. Mesosphere und Kubernetes waren zwei der großen Namen, aber das Gleiche: Bedeutende Investitionen wurden durch das Kubernetes-Projekt getätigt – dabei gebührt Google viel Anerkennung, weil es Kubernetes den Weg frei gemacht hat, um sich auf einige der Dinge zu konzentrieren, über die ich in meiner Keynote spreche: eine starke Community, verantwortungsvolle Führung und eine Kerntechnologie, die die Probleme der Menschen löst. Ich denke, das war das Geheimrezept für den Erfolg von Kubernetes.

Welche weiteren neuen Möglichkeiten bieten Docker und Kubernetes?

Zum Leidwesen einiger der großen traditionellen On-Premises-Lizenzlösungen ermöglicht es Unternehmen, ihren bestehenden Stack zu übernehmen und zu migrieren. Es gibt verschiedene Ebenen von „Lift and Shift", aber im Grunde genommen kann der gesamte Geschäftsbetrieb so weit verschlüsselt werden, dass man ihn in eine Commodity-Cloud-Umgebung einbindet und damit einige Kosteneinsparungen erzielt. Aufgrund meiner Geschichte mit WebLogic und On-Premises Legacy - Monolith, wie einige es spöttisch nennen –, habe ich zudem eine besondere Sichtweise. Ich denke, weitere neue Möglichkeiten sind mehr Flexibilität und Agilität. Ich kann nun mehrmals täglich eine neue Version meines Stacks täglich einführen, wohingegen es zuvor Monate brauchte, um ein Upgrade auf den Monolithen durchzuführen. Als Entwickler möchte ich den schnellsten Weg, um den Code zu ändern, zu kompilieren, einzusetzen und zu sehen, dass die Änderungen wirksam werden. Aber ich möchte dies auf eine sichere Weise tun, die nichts Vorheriges gefährdet. Daher zählen kontinuierliche Integration und Lieferpraktiken zu den Reifegradfaktoren, die aktiviert werden müssen. Es gäbe also kein cloudbasiertes Entwicklungs- und Bereitstellungsmodell ohne ein Sicherheitsnetz, das eine gute kontinuierliche Integrations- und Bereitstellungspraxis bietet. Zusammenfassend lässt sich sagen, Kosteneinsparungen und mehr Agilität sind die beiden großen Möglichkeiten.

Ein Bedenken, das mit Containern einhergeht, ist Sicherheit. Eine beliebte Lösung ist SELinux, das auf dem FLASK-Konzept der NSA basiert – eine Tatsache, die für einige Anwender abschreckend sein könnte. Was ist dein Standpunkt zu diesem Thema?

Wenn man versucht, Docker in seiner Produktionsumgebung zu verwenden, muss man erkennen, dass man das nicht kostenlos erhält, sondern auf jede Schicht seines Stacks achten muss – beispielsweise bei der Verwendung des Basis-Images von Alpine Linux als Docker-Image. Docker hat ein Vererbungsprinzip: Wenn du deine Docker-Images definierst, kannst du sagen, dass du dieses bestehende Image, z.B. Alpine Linux Distribution, mitnehmen und einen Haufen zusätzliches Material darüberlegen möchtest. Du erbst also alles, was Alpine Linux bereits hat. Es ist nicht sicher, einfach zu sagen, gib mir das – du musst dir ansehen, was der Docker Hub hat. Docker hat es ein wenig einfacher gemacht, die Sicherheit zu überprüfen: Ein farbkodiertes Diagramm zeigt die bestehende CVE-Schwachstellen-Datenbank und die bekannten Patches zu diesen Schwachstellen. Hat das Image alle aktuellen Patches? Du kannst tatsächlich sehen, welche es gibt, und es gibt dir eine sehr klare, leicht verständliche Beschreibung der Schwachstelle für jedes Image. Du musst das nur abhängig von deinem Basis-Image überprüfen und sehen, ob es hat, was es braucht. Wenn du die SELinux-FLASK-Geschichte nicht magst, gibt es ein paar Alternativen. Du könntest dir das Docker Image ansehen und dich fragen, wovon es abhängig ist, und dich dann anstatt auf ein SELinux-Gerät auf ein niedrigeres Fundament verlassen und es selbst aufbauen. Wenn du also ein Image Published Docker Hub hast, kannst du genau sehen, was darin enthalten ist, und sogar das Dockerfile sehen, das verwendetet wurde, um das Image zu erstellen. Das ist eines der Dinge, die zum Erfolg von Docker beigetragen haben: Transparenz anstelle von Undurchsichtigkeit. Sie konnten sich das leisten, weil sie kein Systemanbieter waren. Im Gegensatz zu anderen Anbietern versuchten sie nicht, ihr eigenes Betriebssystem oder ihre eigene Hardware zu verkaufen.

Als Mitwirkender am Java Community Process (JCP) betonst du immer wieder die Bedeutung von Transparenz. Warum ist dir das ein so großes Anliegen?

Das ist der Tatsache geschuldet, dass sich Open Source durchgesetzt hat. Das ist eine interessante Debatte über Redefreiheit und Freiheit an sich, weil es um den Unterschied zwischen freier Software und Open-Source-Software geht. Das ist auch immer ein sehr lustiges Gesprächsthema bei der JavaLand-Community-Nacht, besonders nach ein paar guten Bieren – ich liebe JavaLand auch, weil es dort sehr gutes Kölsch gibt, und zwar so viel man möchte. Aber um auf die Frage der Transparenz zurückzukommen: Die Unternehmen haben entschieden, dass Open Source eine sehr nützliche Sache ist, und das geht Hand in Hand mit Transparenz. Das Schöne am JCP ist, dass es nicht so wild und verrückt wie das klassische alte Open Source ist. Der Prozess erlaubt es etwas konservativeren Unternehmen, die Kontrolle zu behalten. Außerdem wird großer Wert auf geistiges Eigentum gelegt. Auf Open-Source-Seite wiederum hat man die Wichtigkeit dessen erkannt und sich darauf eingestellt. Auch CNCF und Eclipse wissen, wenn sie die Technologie anfassen, muss die Frage des geistigen Eigentums geklärt sein. Alles muss entweder direkt entschädigt werden oder einen Hinweis auf etwas geben, das direkt entschädigt wird. Aus diesem Grund halte ich Transparenz für so wichtig.

Du hast bereits vier Bücher veröffentlicht. Gibt es bereits Pläne für ein neues? Können wir uns auf eine Fortsetzung von „Secrets of the Rockstar Programmers" freuen?

Eines der Dinge, die ich seither gemacht habe, ist, „Secrets of the Rockstar Programmers" in einen Podcast umzuwandeln. Ich habe ein paar Anstrengungen mit dem „OffHeap"-Podcast unternommen, wofür ich sowohl Auszüge aus alten Interviews als auch neue Interviews mit u.a. Bryan Cantrill von Node JavaScript und dem bereits erwähnten Brendan Burns von Kubernetes verwendet habe. Das Bücherschreiben ist auf jeden Fall eine Arbeit, die mit sehr viel Liebe verbunden ist. Es ist jedoch schwer, die Zeit dafür zu finden. Für jedes meiner Bücher habe ich etwa 18 Monate benötigt, und die meisten anderen Autoren, mit denen ich gesprochen habe, sagen, dass es bei ihnen ähnlich lang dauert. Hinzu kommt, dass sich die Art und Weise geändert hat, wie Menschen lernen: Dinge, die früher in Büchern erklärt wurden, werden heute durch Lernsoftware wie Coursera, Pluralsight oder Safari vermittelt. Ich kenne viele erfolgreiche Autoren, die heute als virtuelle Professoren Lernsoftware herausbringen. Ich denke daher, dass meine nächste Arbeit in diesem Bereich nicht mehr ein vollständiges, 300-seitiges Nachschlagewerk sein wird, sondern ich würde mich ebenfalls bei einem Online-Kursanbieter anmelden und dort etwas veröffentlichen.

Im Laufe deiner Karriere hast du an vielen verschiedenen Projekten mitgewirkt. Gibt es bisher ein Karrierehighlight, das du benennen kannst?

Das wäre auf jeden Fall meine Arbeit an JSF, da sie so viele Dinge miteinander verbunden hat, die ich liebe. Dazu zählen der Aufbau von Communitys und das Glück, JSF im deutschsprachigen Europa zur Popularität zu verhelfen – dank der langen Partnerschaft mit Irian in Wien. Sie haben beim JCP mitgewirkt und halfen bei der Entwicklung von JSF. Sie hatten eine Konferenzreihe, die jedes Jahr in Wien stattfand, und sie haben weiterhin viel mit JSF und Java EE-Technologien gemacht. Dazu kommt, dass ich die Möglichkeit bekommen habe, mein Wertesystem von Respekt und Beteiligung in die Community einfließen zu lassen. Die Arbeit an JSF war in dieser Hinsicht lohnend und unterhaltsam.

Ed, vielen Dank für das Gespräch.