zurück zum Artikel

Ed Burns, Co-Spec Lead der JavaServer Faces, im Gespräch über seinen Werdegang sowie seine kommende Keynote auf dem JavaLand 2019.

heise Developer: Ed, im März bist du Keynote-Speaker der JavaLand-Konferenz. Kannst du einen kleinen Ausblick geben, was die Teilnehmer erwartet?

Ed Burns: Ich werde eine Vergleichsanalyse darüber anstellen, was eine Programmiersprachenplattform erfolgreich macht. Ich habe darin ein wenig Erfahrung, schließlich war ich an der Entwicklung der 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. Im Zuge 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.js beziehungsweise JavaScript sowie Python und vergleicht diese Sprachen auf technischer, ökologischer und ökonomischer Ebene. Außerdem erörtere ich die Entscheidungen, die die jeweiligen Vertreter getroffen haben, um ihre Sprachen dahin zu bringen, wo sie heute sind.

heise Developer: Du bist du nicht zum ersten Mal auf der Konferenz. Was gefällt dir besonders am JavaLand?

Burns: Ich bin beim JavaLand von Anfang an dabei gewesen und habe keine Auflage verpasst. Es gibt für mich zwei Perspektiven, die für das JavaLand sprechen. 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. Außerhalb der Session-Räume gibt es zahlreiche Möglichkeiten zur 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 (Deutsche Oracle-Anwendergruppe) 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 dem JavaLand.

Bezug zu Deutschland

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

Burns: Definitiv. Ich komme liebend gern nach Deutschland. Während der DOAG-Konferenz im November 2018 hatte ich dort ungefähr einen Monat verbracht und alte Freunde aus der JSF-Community besucht. Das werde ich dieses Mal genauso handhaben. 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 beendet habe, schlage ich dort mit meiner Trompete auf und spiele ein wenig.

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

Burns: 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. Interessanterweise habe ich dann im zweiten Jahr eine Informationsveranstaltung für ein Austauschprogramm in Österreich besucht, und das hat mich sofort angesprochen. Es hat mich im wahrsten Sinne des Wortes gepackt, und daran hat sich bis heute nichts geändert. Das war 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.

Fan von "Tunnels of Doom"

heise Developer: 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 [1]. Was fasziniert dich insbesondere an diesem Spiel?

Burns: Als ich mein Buch "Secrets of the Rockstar Programmers [2]" schrieb, hatte ich den Gedanken, dass Leute einer bestimmten Altersgruppe, jene die jetzt Mitte bis Ende 40 sind, den besonderen Vorteil hatten, in einer Zeit aufzuwachsen, in der die ersten Personal Computer auf den Markt kamen. Dem 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 allerdings 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 Crawl. 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 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 verschiedener 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.

Erfolge von Docker und Kubernetes

heise Developer: Auf dem JavaLand leitest du zusammen mit Oliver Szymanski einen Workshop über Docker und Kubernetes. Was sind die Hauptvorteile der Verwendung von Containern anstelle klassischer virtueller Maschinen?

Burns: Der erste Vorteil ist Heterogenität. Bei virtuellen Maschinen verwenden die meisten aktuellen Unternehmensanwendungen eine breite Palette von Standard- und meist Open-Source-Techniken: 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 Techniken einbezogen werden, die alle Unternehmen heute verwenden.

Es gibt aber auch einige Herausforderungen bei der gezielten gemeinsamen Verwendung von Java und Containern, da sich die beiden Techniken zu sehr unterschiedlichen Zeiten entwickelt haben. Heutige Container entstanden in den letzten sechs Jahren, Java Virtual Machines hingegen Mitte der 90er-Jahre. Es gilt, Vorkehrungen zu treffen, damit diese beiden weitgehend 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, kratzen sich Anwender am Kopf, weil sie nicht wissen, was sie tun sollen.

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

Burns: Ich bin sehr stolz darauf, so lange bei Sun gearbeitet zu haben, denn in vielerlei Hinsicht war Sun 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, das 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: Die Technik und ihre Schöpfer 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 Fall von Docker glaube ich also, dass es die Allgegenwart von GNU/Linux war, bei deren Etablierung im Wesentlichen Google geholfen hat, und dann der Aufstieg von Cloud-Plattformen, die einen gemeinsamen Anwendungsspeichermechanismus benötigten, den Docker zur Verfügung stellte.

Ein sehr großer Mehrwert von Docker ist die Dockerfile-Sprache, in der du beschreiben kannst, wie deine Container aufgebaut sind. Ein weiteres wirklich wichtiges Feature ist die Popularität des Docker Hub. Bei Docker handelt es sich um einen dieser Fälle, in denen eine bereits vorhandene Idee aufgegriffen, besonders gut umgesetzt und mit einer sehr guten Marketingleistung gekoppelt wurde. Die Docker-Leute wussten, welche Konferenzen sie aufsuchen mussten – Developer Relations war ein wichtiger Faktor –, und sie haben einfach sichergestellt, dass das Produkt die Leute überzeugt.

Alle an einem Strang

heise Developer: 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?

Burns: Das war ebenfalls wichtig. Ursprünglich waren die erwähnten Namen eher skeptisch und warteten ab, ob sich die Technologie 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 verpflichteten, 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, das versucht, andere Leute dazu zu bringen, sie zu benutzen, ohne dass sie sich zu sehr darüber Sorgen machen müssen mitzumachen.

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

Burns: 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"-Projekts gesprochen habe, und seine Kollegen Joe Beda und Craig McLuckie. 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 involvieren, Azure aufzubauen 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 freigemacht 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.

Pro und contra Container

heise Developer: Welche weiteren neuen Möglichkeiten bieten Docker und Kubernetes?

Burns: Zum Leidwesen einiger der großen traditionellen On-Premises-Lizenzangebote 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. Weitere neue Möglichkeiten sind mehr Flexibilität und Agilität. Ich kann nun mehrmals täglich eine neue Version meines Stacks 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 Cloud-basiertes 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.

heise Developer: 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?

Burns: 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, zum Beispiel die 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 einen Image Published Docker Hub hast, kannst du genau sehen, was darin enthalten ist, und sogar das Dockerfile, 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.

Transparenz in der Java-Entwicklung

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

Burns: Das ist der Tatsache geschuldet, dass sich Open Source durchgesetzt hat. Das führt zur interessanten Debatte über Redefreiheit und Freiheit an sich, weil es um den Unterschied zwischen freier und Open-Source-Software geht. 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 er 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 (Cloud Native Computing Foundation) 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.

heise Developer: 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?

Burns: 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 "Java Offheap"-Podcast [3] unternommen, wofür ich sowohl Auszüge aus alten Interviews als auch neue Interviews mit unter anderem Bryan Cantrill von Node.js 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 Books Online (nun: O'Reilly Learning; Red.) 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.

Karrierehighlight

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

Burns: 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.

Das Interview erschien in leicht geänderter Form zuerst auf der Website des iJUG [4], der wie die DOAG und heise Developer Mitausrichter der JavaLand-Konferenz [5] ist, die von 19. bis 21. März im Phantasialand bei Brühl stattfindet. Die Fragen stellte Christian Luda. (ane [6])

URL dieses Artikels:
https://www.heise.de/-4303141

Links in diesem Artikel:
[1] http://ridingthecrest.com/edburns/classic-gaming/tunnels/
[2] http://ridingthecrest.com/
[3] https://www.javaoffheap.com/
[4] https://www.ijug.eu/de/home/news/?tx_news_pi1%5Bnews%5D=1850&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&cHash=edc17f4f32f1cda11166e3de34457ed2
[5] https://www.javaland.eu/de/home/
[6] mailto:ane@heise.de

Copyright © 2019 Heise Medien