Agile, DevOps und Continuous Delivery – eine Bestandsaufnahme

Meyen: Das sagen JRuby-Fans wie ihr?

Fowler: Obwohl wir viel mehr JRuby verwenden, sind das Ruby-Projekte, für die wir die JVM als Plattform benutzen. Aber bei älteren Bibliotheken gibt es nicht viele Verbindungen zwischen der Java und der Ruby-Welt. Mit Scala gibt es wesentlich mehr Verbindungsmöglichkeiten: Man hat ein wenig Java-Code und ein wenig Scala-Code. Möchte man die beiden verbinden, greift man also viel stärker und viel direkter auf die Java-Bibliothek zurück.

Dörnenburg: Es gibt auch eine psychologische Sichtweise. JRuby assoziieren die meisten Menschen noch immer mit der Zeit, in der sie zum ersten Mal von dieser verrückten Idee hörten, andere Programmiersprachen auf der JVM zu kreieren. Wie so oft bei radikalen Veränderungen, verwarf man diese Idee. Man dachte, das könne nicht funktionieren. Das hat der Außenwahrnehmung von JRuby etwas geschadet. Außerdem führt JRuby unverkennbar Ruby im Namen, seinerseits eine sehr starke Marke, die wiederum mit Rails, Startups und schnellen Webprojekten assoziiert wird. All das zusammengenommen hat bewirkt, dass JRuby auf der psychologischen Schiene nicht so gut bei Geschäftskunden angekommen ist, unabhängig davon, ob es technisch eine gute Wahl gewesen wäre.

Meyen: Was die Geschichte von Java betrifft, lautet die Formel: Sprache plus Framework. Seid ihr der Ansicht, dass die moderneren Sprachen das Konzept eines Frameworks benötigen, weil wir es nicht anders gewohnt sind?

Fowler: Absolut. Das ist das Großartige an der JVM: Sie gibt dir diese ganzen Frameworks. Wenn man versucht, eine neue Sprache zu entwickeln, ist es von Vorteil, auf die bereits bestehenden Bibliotheken und Frameworks zurückgreifen zu können, statt selbst welche aus dem Boden zu stampfen. Im Moment sind die einzigen Möglichkeiten Java (alle JVM-basierten Sprachen), .NET oder die Standard-Linux-Skriptsprachen. Die JVM ist deswegen so attraktiv, weil sie plattformunabhängig und relativ offen ist, obwohl Oracle gerade, so scheint es, sein Bestes tut, das mit der Offenheit der Plattform gründlich zu vermasseln, dadurch, dass es alle in der Open-Source-Welt verschreckt. Man wird sehen, ob sie in den nächsten Jahren etwas dazu lernen. Ich hoffe es in jedem Fall.

Meyen: Wohin gehen eurer Einschätzung nach weitere Entwicklungen? Ist Java eher geeignet, große Systeme zu schreiben als direkt auf REST- und Webebene zu arbeiten?

Fowler: Immer wichtiger wird die Frage, wie sich monolithische Systeme in komponentenorientierte Services aufteilen lassen. Eine sehr interessante Evolution ist in dem Projekt für die Zeitung „The Guardian“ zu beobachten, in das Erik sehr involviert war. Das ursprüngliche Hibernate-Spring-System war eine sehr erfolgreiches Lösung. Die Evolution bestand darin, Teile der Architektur mit der Zeit in kleinere „Microservices“ zu zerlegen, die ich auch „Microsites“ nenne. Insgesamt zeichnet sich eine Tendenz zu kleineren Services mit eigenem, integriertem Datenspeicher ab. Diese produzieren jeweils eigenes HTML, aus dem die Seiten zusammengesetzt werden. Das ist auch die Quintessenz mehrerer Projekte, die ich besucht habe, und die Vorgehensweise, die wir den Leuten als eine mögliche Richtung ans Herz legen.

Dörnenburg: Entscheidend ist es, selbstsicher genug zu sein, sich nicht von den Tools beeinflussen zu lassen, sondern diese anhand der wirklichen Ziele passend auszusuchen. Bei Web-as-a-Platform ist die klassische Frage: Braucht man eine Registry? Braucht man einen weiteren Service, der einem verrät, wo der Endpunkt ist? Eigentlich haben wir schon ein wunderbares, hervorragend skalierbares Registry-System mit einem verteilten Cache, das wir täglich milliardenfach verwenden und das da heißt DNS. Man braucht keinen UDDI-Standard und kompliziertes Tooling. Man kann viele Probleme mit sehr einfacher Webtechnologie lösen. Deswegen hat Martin ja auch bejaht, dass Java für solche Einsatzgebiete sehr gut geeignet ist.

Meyen: Mit anderen Worten: Lean Architecture ist wichtiger als die Technologien, die eingesetzt werden. Die Technologie ist da, man findet sie in Ordnung, sie funktioniert, und letztendlich kommt es darauf an, was man daraus macht.

Dörnenburg: Es ist wohl kein Standard, aber wer heutzutage mit JSON arbeitet, der kann einfach ein Paar Java-Objekte kreieren, sie an den Jackson Serializer weitergeben, und der erzeugt JSON. Kein Standard, einfach ein Open-Source-Projekt von Codehaus. Es gibt nichts in Java, das es weniger geeignet machen würde als andere Sprachen, vielleicht das Fehlen dynamischer Typisierung, aber das ist nebensächlich.

Meyen: Hast du zum Schluss noch ein Give-Away für die Entwickler? Es geht ums Finden der richtigen Tools, oder?

Fowler: Das ist zwar langweilig, aber ich sage immer: Was zählt, ist gutes Design. Man muss zuerst verstehen, wie man Systeme designt, Design-Patterns sinnvoll einsetzt und mit Bedacht selbsttestenden Code schreibt, ganz grundlegende Dinge. Es geht nicht um Frameworks, Bibliotheken, Sprachen, nicht einmal um Plattformen. Es gibt Leute, die sich sicher und effektiv zwischen den Ruby-, Java- und .NET-Plattformen hin- und herbewegen, weil sie mit den wesentlichen Designprinzipien vertraut sind, die letztendlich das Kostbarste sind, was ein Entwickler überhaupt lernen und zur Anwendung bringen kann. Denn sie sind von Dauer.

Dörnenburg: Stimmt. Man kann ein gutes Design mit schlechten Tools implementieren. Das tut zwar weh, aber es geht. Aber umgekehrt, wenn man keine Ahnung von Design hat und ein Werkzeug aussucht, in der Hoffnung, dass das Design damit irgendwie auftaucht, steckt man in tiefen Problemen.

Schlegel: Werkzeuge sind zweitrangig. Viel viel wichtiger ist die Art und Weise, wie Leute miteinander interagieren.

Meyen: Vielen Dank für das Gespräch!

Kommentare

Schreibe einen Kommentar

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