Suche
5 Take-aways von der W-JAX 2018

IBM vs. Red Hat, Angular vs. React, Cloud-native vs. Java

Hartmut Schlosser

© Shutterstock / Kim Reinick (modifiziert)

Open Source, Vue.js, Microservices, Cloud-native – auch der dritte Tag auf der W-JAX 2018 war spannend und aufschlussreich! Wir fassen hier kurz und knackig zusammen, was wir auf der Konferenz Neues gelernt und Spannendes gesehen haben. Wie immer erheben wir keinen Anspruch auf Vollständigkeit.

Take-away #1: IBM, Red Hat und eine Open-Source-Geschichte

IBM erzählt eine Open-Source-Geschichte. Auf der Keynote-Bühne der W-JAX. Warum eigentlich?

Mal überlegen… Hat es mit des Red-Hat-Übernahme zu tun? Hmm, eigentlich kommt Red Hat in dem IBM-Vortrag nicht vor. Oder doch? Schauen wir genauer hin!

Die Keynote heißt Who Pays for Open Source? A Case for Open Governance & Enterprise Contributions, und es ist kein Geringerer als Christopher Ferris von der IBM Digital Business Group, ehemaliger Sun Chefarchitekt, beteiligt an der Entwicklung von SOAP und XML, heute Co-Lead des Blockchain Frameworks Hyperledger Fabric, der in der Keynote die Frage stellt: Wer bezahlt eigentlich für Open Source?

Open Souce habe gewonnen, so Ferris. Mittlerweile hätten auch große Unternehmen erkannt, dass durch Open-Source-Mechanismen die Skills trainiert werden, die gute Entwickler ausmachen.

Drei Arten von Open-Source-Projekten unterscheidet Ferris: Erstens Projekte, die zur freien Nutzung auf GitHub gestellt werden (wie ein zu verschenkendes Sofa auf die Straße), die man sich greifen kann, für dessen weitere Zukunft man dann aber selbst verantwortlich ist. Zweitens Projekte wie Tensorflow, Redis, Linux, die von einem „wohltätigen Diktator“ (benevolent dictator) vorangetrieben werden, die zwar florieren können, aber immer auch verbunden sind mit dem Risiko des Single-Point-of-Failiure bzw. des Vendor-lock-in. Drittens Projekte, die unter einer “Open Governance” stehen, also von einer diversifizierten Community entwickelt werden, oft unter dem Schirm einer Open Source Foundation.

IBM, so Ferris‘ Geschichte, stehe für das letzte Modell, dem der Open Governance. IBM, das sei nur wenigen bewusst, sei eines der größten Open-Source-Unternehmen, gleich hinter Google und Red Hat, weit vor Microsoft und vielen anderen. IBM tue das weitgehend im Hintergrund, weil Projekte mit einer Open Governance sich als am langlebigsten, innovativsten, stabilsten erwiesen hätten.

Wie glaubwürdig ist das? Nun, IBM war beteiligt an der Gründung der Apache Foundation, ist Initiator der Eclipse Foundation, leistet(e) zahlreiche Beiträge für Open-Source-Projekte wie Apache Xerces, Cloud Foundry, Hadoop, Open Liberty, OpenJ9, Fabric, Qiskit. Soweit ist die Geschichte stimmig. Dennoch bleibt es Geschichte, denn aktuell hat IBM kaum den Ruf, eine der coolen Open-Source-Buden zu sein, die an der Speerspitze der (Cloud-)Innovation steht.

Und dann hat IBM Red Hat gekauft. Eine Community von Entwicklen mit Open Source Skills, die mit großer „Street Credebility“ das Thema (Hybrid) Cloud vorantreibt.

IBM hat wieder eine Open-Source-Geschichte zu erzählen.

Take-away #2: Vue.js ist angekommen

An JavaScript kommen auch Java-Entwickler nicht mehr vorbei. Marc Teufel von der Hama GmbH hat in seiner Session „Auf Entdeckungsreise: Vue.js für Einsteiger“ den Shooting-Star der JS-Framework-Szene vorgestellt. In einem dicht gepackten Saal lauschten über 150 Entwickler den Ausführungen zu Web Components und Vue, was zeigt, dass JavaScript durchaus auch die Neugierde des W-JAX-Publikums weckt.

Größter Vorteil von Vue sei die Leichtgewichtigkeit, Erweiterbarkeit und einsteigerfreundliche Dokumentation, so Marc Teufel. In Sachen GitHub Stars hat Vue Angular längst überholt und ist gleichauf mit React. Angular weist hingegen deutlich mehr Issues auf, was Marc Teufel so interpretiert, dass Angular stark im Enterprise-Bereich etabliert ist.

Aber vielleicht kommt Vue.js bei dem großen Interesse aus dem Java-Lager ja auch bald dahin?

Take-away #3: Framework Battle – Angular versus React

Wo wir gerade von JavaScript-Frameworks reden: Den ultimativen Framework-Battle zwischen Angular und React haben die beiden JavaScript-Experten Manfred Steyer (SOFTWAREarchitekt.at) und Sebastian Springer (MaibornWolff GmbH) ausgetragen. Manfred Steyer schätzt an Angular die große Bandbreite an Komponenten, die einen den ganzen Lebenszyklus eines Projekts über begleiten und wie aus einem Guss zusammen funktionieren.

Ja, erwidert Springer, dafür ist man bei Angular aber gezwungen, genau diesem Gesamtpaket mit seinen teils eigensinnigen Vorgaben zu folgen. React gebe dem Entwickler eben die Freiheit, nur das zu nutzen, was man auch wirklich braucht.

Der neue Angular Compiler werde in Sachen Performance einen riesigen Sprung nach vorne machen. React sei das Mittel der Wahl für funktionale Programmierung und prädestiniert für Anwendungen nach dem Redux-Muster.

Doch eigentlich waren sich die beiden mehr einig als uneinig: Beide Frameworks seien erstklassig, bewegten sich immer mehr aufeinander zu und böten Innovationen in einer Geschwindigkeit, von der die Java-Welt nur träumen könne.

“Dann schau mer mal, was mer den Java-Leuten noch so alles beibringen können, hier auf der W-JAX”, sagen die beiden zum Schluss und verabschieden sich in ihre nächsten Sessions „Speed up your Web Application“ und „Angular on Rails: Modellgetriebenes Angular mit Schematics, dem Scaffolding-Tool hinter der Angular CLI, und dem TypeScript Compiler API“

Take-away #4: Damit man über Microservices nicht stolpert

Vor drei Stolperfallen bei Microservices-Integrationen hat Bernd Rücker (Camunda) in seiner Session gewarnt. Denn das Beherrschen verteilter Systeme ist nicht trivial.

1. Die Kommunikation ist komplex. Das fängt bei der Frage an, wie kommuniziert werden soll (REST? gRPC? Messaging? Event-driven?) und geht bis zu schwierigen Entscheidungen rund um Choreographie vs. Orchestration. Es sei nicht leicht, das Problemfeld wirklich zu verstehen und eine sinnvolle Lösung – abseits von aktuellen Hypes oder vereinfachten Plattitüden – auszuwählen, meint Rücker.

2. Asynchronität erfordert die Implementierung von Time-outs. Die Resilienz könne dabei deutlich erhöht werden, wenn man nicht nur Millisekunden, sondern auch Minuten oder gar Stunden warten kann.

3. Verteilte Transaktionen können nicht einfach an Protokolle wie XA delegiert werden. Stattdessen muss man die Anforderung an Konsistenz auf neuen Wegen umsetzen.

“Microservices ergeben nur Sinn, wenn ich mit mehreren Teams arbeite”, sagt Rücker. “Das Vorgehen erfordert dann typischerweise auch einen hohen Reifegrad der Organisation, da viele Themen mitkommen:  automatisierte Deployment Pipelines, Registrys, Contract-based Testing, Observability, etc.“

Entwickler sollten sich also darauf einstellen, viel lernen zu müssen. Aber deshalb sind sie ja bestimmt auf die W-JAX gekommen….

Take-away #5: Cloud-native versus Java

An der Cloud führt kein Weg vorbei. Zunehmend werden neue Technologien entwickelt, die speziell auf den Betrieb in Cloud-Szenarien abgestimmt sind. „Cloud-native“ sagt man manchmal dazu. Und Cloud-native steht dann im Gegensatz zu älteren, “General-Purpose-Technologien”, die vor dem Cloud Hype entstanden sind. Wie beispielsweise Java.

In einem Keynote-Panel haben Elisabeth Engel (interfacewerk GmbH), Uwe Friedrichsen (codecentric AG), Roland Huß (Red Hat), Eberhard Wolff (INNOQ) und Sebastian Meyen (Software & Support Media) die Frage diskutiert, was Cloud-native eigentlich für Java-Entwickler bedeutet.

Java sei viele Jahre lang auf langlebige Prozesse und eine hohe Verfügbarkeit hin optimiert worden, beginnt Sebastian Meyen. Im Cloud-Kontext geht es hingegen um andere Werte, beispielsweise das schnelle Hochfahren von Services und den geringen Speicherverbrauch. Wie gut ist Java eigentlich für die Cloud aufgestellt?

Java ist eben das Cobol des 21. Jahrhundert, kommentiert Uwe Friedrichsen, und fügt hinzu: “Ich meine das aber durchaus wertschätzend.” Java ist in vielen Kernsystemen so verbreitet, dass es auch in einem Cloud-native-Umfeld seinen Platz haben wird. Andererseits gibt es durchaus auch Ansätze, Java selbst zu einer Cloud-native-Technologie zu machen: Spring Boot, MicroProfile und GraalVM sind hier die Stichworte. Roland Huß führt außerdem das riesige Java-Ökosystem ins Feld, in dem eine enorme Innovationskraft steckt und aus dem sich nicht zuletzt auch fähige Entwickler rekrutieren lassen.

Welche Vorteile bringt uns die Cloud? “Die Zäune werden weniger”, sagt Elisabeth Engel. Devs und Ops rücken näher zusammen, da Anwendungen nicht mehr vom Betrieb abstrahiert werden können.

Muss man als Dev dann die gesamte Ops-Disziplin beherrschen? Nein. Aber es ist durchaus vorteilhaft, als Entwickler ein Bewusstsein dafür zu haben, welche Konsequenzen mein Handeln für die Produktion hat. Außerdem läuft der Trend dahin, Infrastrukturaspekte mehr und mehr zu abstrahieren, sodass es sowohl Devs als auch Ops leichter haben werden, fügt Roland Huß hinzu – Knative, Istio und Serverless lauten hier die Buzzwords.

Für Eberhard Wolff ist Cloud-native eine Fortsetzung der Diskussion um Continuous Delivery. Mit den neuen Techniken ist es möglich, Projekte in wenigen Monaten, ja Wochen auszuliefern, für die man früher noch Jahre gebraucht hätte. Hier liege für viele Unternehmen noch ein enormes Potenzial, die Time-to-Market-Spanne zu verbessern.

Und schließlich gehe es auch darum, als Entwickler nicht alle zwei Monate das Wochenende durcharbeiten zu müssen, nur weil das Release wieder einmal nicht wie geplant funktioniert. Spätestens mit diesem Hinweis auf die bessere Work-life-Balance sollte klar sein: Cloud-native lohnt sich!

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: