console.log()

Bericht von der BaselOne 2017

| 1 Kommentar

Am 19.10.2017 besuchte ich die BaselOne 2017, eine Java Konferenz, die zum zweiten Mal nach 2016 stattfand. Trotz der Umbenennung von JavaOne in BaselOne blieb es inhaltlich bei einem sehr starken Java Schwerpunkt dieser Konferenz.

Im Angebot standen 4 Tracks mit 22 Vorträgen und 25 internationalen Speakern. Die ca. 220 Teilnehmer kamen vornehmlich aus der Schweiz und Deutschland sowie Frankreich, was bei der grenznahen Lage von Basel im Dreiländer Eck nicht überrascht.

Die Location in der Basler Markthalle bildete für die Konferenz den passenden Rahmen, nicht zuletzt da die zentrale Freifläche in der Halle einen natürlichen Anlaufpunkt für gemeinsamen Austausch anbot.

Ausgewählte Vorträge

Inhaltlich waren die allgemeinen Trends in der Java Welt zu Cloud Computing, Microservices und DevOps sowie erwartungsgemäß die Java 9 Version mit dem neuen Modul System auch auf der BaselOne 2017 sehr präsent.

In ihrem Vortrag „Restrukturierung der Code Basis mit Java 9“ stellte Rabea Gransberger sehr praktisch anhand einer Demo Applikation den schrittweisen Umbau einer bestehenden Java Applikation zu einem entkoppelten Aufbau mit Java 9 Modulen vor. Das Vorgehen, wie in einem Legacy Projekt Module identifiziert und anhand von klaren Refactoring Schritten voneinander entkoppelt werden können, wurde sehr nachvollziehbar vorgestellt. Auch die Auflösung der beim Umbau neu enstehenden Probleme wurde aufgezeigt. Schön zu sehen war, wie während des Vortrags aus einem Code mit zyklischen Abhängigkeiten eine modularisierte und für andere Anwendungsfälle erweiterbare Applikation entstand.

Noch tiefer auf Möglichkeiten des neuen Java 9 Modulsystems ging Nicolai Parloq in seinem sehr interessanten Vortrag „The Java 9 Module System – Beyond the Basics“ ein. Er sprach über die Stolperfallen einer Java 9 Migration zeigte aber gleichzeitig Möglichkeiten zur Analyse und Lösung dieser neuen Herausforderungen anhand passender JDK Tools auf.

Wie schon erwähnt, bildete das Dreigespann  Cloud Native Programming, Microservices und DevOps ein großen inhaltlichen Schwerpunkt auf der Konferenz. In den Vorträgen „Cloud Native Java – Getting started“ (Christian Schwörer), „Programming for the Cloud – Lösungen mit Amazon Elastic Beanstalk“ (Daniel Hasler), „Infrastructure as Code oder Provisionierung von Dockerhosts und Containern“ (Remigius Stalder) wurden verschiedene technische Ansätze vorgestellt, wie eine Java Applikation in Cloud gebracht, dort betrieben, gemanagt und deployt werden kann. Diese Ansätze unterschieden sich vor allem durch ihre technische Komplexität und Abstraktion für den Entwickler. Anhand der Vielzahl der Möglichkeiten, ergibt sich natürlich die Frage nach der Vergleichbarkeit dieser Ansätze in Bezug auf technische Möglichkeiten, Limitierungen und nicht zuletzt der laufenden Kosten. Hier war der gemeinsame Konsens, dass ein grundsätzlicher Vergleich der großen Cloud Anbieter bei einem neuen Cloud Projekt natürlich unumgänglich ist. Gleichzeitig ist ein bis in die letzte Tiefe gehender Vergleich sehr zeitaufwändig und letztendlich auch nicht immer sinnvoll, da sich die Big Player in ihrem Kosten- und Leistungsmodell inzwischen sehr aneinander angeglichen haben.

Im letzten Vortrag den ich an diesem Tag besuchte, wurde „Von API Design und glücklichen Usern“ auf sehr kurzweilige Weise gesprochen. Christoph Engelbert und David Sondermann von Hazelcast präsentierten sieben Sünden im Entwurf von APIs und wie sich diese konkret umgehen lassen. Dabei streuten sie immer wieder unterhaltsame Anekdoten aus ihrem Arbeitsalltag ein, welche den Zuhörer an schlecht strukturiertem Code „mitleiden“ ließen und den Zuhörer zu einer „Eat your own dogfood“ Haltung motivierten, die letzendlich den Anwender der API glücklich machen.

Was nehme ich mit?

Der Besuch der BaselOne 2017 war für mich als Java Entwickler auf jeden Fall sehr lohnenswert. Neben den oben beschriebenen thematischen Schwerpunkten gab es auch Talks zu ganz anderen Java Themen. Ein inhaltlich breites Angebot war vorhanden, auch abseits dieser Trends waren interessante Themen gesetzt, so dass die Entscheidung, welchen Talk zu besuchen mit teilweise schwer fiel.

Auf der Heimfahrt versuchte ich für mich ein Resumé zu ziehen. Was kann man von dieser Konferenz neben vielen kleinen konkreten Impulsen und Inspirationen mitnehmen? Welche Entwicklungen auf höherer Flughöhe sind für die Java Welt abzusehen?

Hier sind mir folgende Punkte wichtig geworden:

  • Einerseits bin ich fasziniert von der Einfachheit, mit der sich heute schon skalierbare, verteilte Applikationen  entwickeln und (in die Cloud) deployen lassen. Den gestiegenen Erwartungen und Anforderungen an moderne Enterprise Applikationen kann man als Java Entwickler heute so einfach wie nie begegnen. Es gibt so viele Bibliotheken, Services und Infrastruktur, die dem Entwickler viel Arbeit auf diesem Gebiet abnehmen.
  • Gleichzeitig geht damit aber auch eine gestiegene Komplexität einher. Was sich erstmal widersprüchlich anhört, ist durch die Vielzahl der technischen Möglichkeiten, die schon beschriebene schwer erzielbare Vergleichbarkeit erklärbar. Hier hoffe ich auf eine baldige Standardisierung. Man kann sagen, dass die Komplexität in der Enterprise Entwicklung auf eine andere Ebene gerutscht ist. Wo man sich heutzutage kaum noch mit der Skalierung, Ausfallsicherheit und der Durchführung von Deployments einzelner Applikationskomponenten beschäftigen muss (alles kann recht einfach automatisiert werden), gilt es um so mehr die Architektur der verteilten Gesamtapplikation sorgfältig zu planen und das Zusammenspiel der Komponenten im Überblick zu behalten und zu monitoren.
  • Ein ähnliches Muster zeichnet sich meiner Meinung nach für die Dokumentation der Architektur von Applikationen ab. Mit dem neuen Modulsystem von Java 9 lassen sich endlich Komponenten in einer Java Applikation wirklich kapseln, deren gegenseitige Verwendung sauber einschränken und auch technisch sicherstellen. Und das Ganze nicht in irgendwelchen Architektur-Dokumenten oder Schaubildern (oder noch schlimmer: nur in den Köpfen eines Architekten) sondern im Code! Hier ist es einerseits viel einfacher eine Architektur für andere Entwickler sauber und nachvollziehbar zu dokumentieren. Erkauft wird das aber mit zusätzlichen Komplexitäten (Stichwort: Modul- vs. Classpath, Split Packages), die man als Java Entwickler erst einmal wieder neu beherrschen muss.
  • Gleiches gilt für die Dokumentation von Betriebs- und Deploymentprozessen. Durch Automatisierung mittels Infrastructure as Code ist eine weitere Dokumentation die manuell nachgezogen werden muss, hinfällig. Hurra! Doch vor einem laufenden vollautomatiserten Cloud Deployment muss Wissen über eine Menge Tools und Techniken (Docker, Kubernetes, Anisible, terraform, lxd, Cloud Foundry, AWS usw.) erlernt werden…

Leben wir also in der schönen neuen Java Welt? Vielleicht ist die Antwort im nächsten Jahr bei der BaselOne 2018 etwas klarer…

 

 

 

 

Ein Kommentar

  1. HI Marco. VIelen Dank für den Bericht – hat Spaß gemacht ihn zu lesen!

    Auch hier zeigt sich mir wieder: Die Cloud ist mehr als bereit, auch von uns genutzt zu werden!
    Automatisierung über Infrastructure as a Code, Modularisierung, Cloud-Services… das hält auch komplexe Applikationen kontrollierbar.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.