Was wir auf der JAX London gelernt haben – Tag 2

JAX London: 6 Erkenntnisse für Software-Entwickler

Redaktion JAXenter

Photo: S&S Media / Katura Jensen

Was tun, wenn Microservices ausfallen? Was tun, wenn Programmierer scheitern? Was sind die Risiken von Unit Tests? Wir werfen einen Blick auf die wichtigsten Erkenntnisse, die der zweite Tag der diesjährigen JAX London uns mit auf den Weg gegeben hat.

1. Wir müssen über das Scheitern nachdenken

Ausfälle sind unvermeidbar, insbesondere in hochverfügbaren Systemen, so der Speaker Jeremy Deane. Und hat man sich nicht um ein angemessenes Monitoring gekümmert, erfährt man im Zweifelsfall erst davon, wenn man von einer Flut aus verärgerten Tweets und Nachrichten der User überrollt wird. Spätestens dann muss man alles stehen und liegen lassen und sich um das Problem kümmern, so Deane.

„Implementiert man resiliente Prinzipien und Techniken, so kann man in den meisten Fällen nicht nur sehr schnell reagieren, sondern häufig auch Selbstheilung hinzufügen. Der Verantwortliche muss also nicht mitten in der Nacht herausgeklingelt werden, um das Problem zu beheben. Das Problem behebt sich selbst.“

Deane wies zudem darauf hin, dass man nach derartigen Ausfällen die Unternehmenskultur unter die Lupe nehmen sollte. Zeigen wir sofort mit dem Finger auf andere? Oder wollen wir vielmehr eine Kultur schaffen, in der Mitarbeiter keine Angst davor haben, ihr Scheitern mit dem Rest der Belegschaft zu teilen, damit alle davon lernen können?

2. Wir sollten darüber nachdenken, warum Microservices ausfallen

In ihrer Session „Microservices: From dream to reality in an hour“ erläuterte Dr. Holly Cummins die Wichtigkeit von Ausfällen für Microservices.

„Über Ausfälle nachzudenken, ist von entscheidender Bedeutung“, so Cummins. „Stell dir einen winzig kleinen Microservice vor, der sich in den rauen Gewässern des Netzwerks auf- und abbewegt, zwischendurch schlägt auch noch ein Hardware-Blitz ein. Ausfälle sind da nicht nur eine Möglichkeit, sondern praktisch eine Gewissheit. Die Fehlertoleranz muss in alle Ebenen eingebaut und in jeder Phase der Tests ausgeübt werden.“

Apropos Arten des Scheiterns: Ohne DevOps sollte man über eine Annäherung an Microservices nicht einmal nachdenken, so Cummins weiter.

3. Die testgetriebenen Entwicklung hat viele Gesichter – Vorsicht bei der Wahl

Abgesehen davon, dass sie leichter zu verstehen ist, gerät man im Rahmen des Classicist-Ansatzes (Detroit School of TDD) nur selten in Gefahr, Overengineering zu betreiben. Aus diesem Grund ist der vor allem durch Kent Beck populär gemachte Ansatz eine gute Wahl, wenn man nicht hundertprozentig sicher ist, was man tut, bzw. wenn man sich, in Sandro Mancusos Worten, „auf Erkundungstour“ befindet.

Allerdings stellt er nicht die einzige Option dar: Im Gegensatz zum Classicist-Ansatz, der den Fokus auf zustandsbasierte Tests richtet, bietet sich bei Tests des Verhaltens der Outside-In-Ansatz an.

Doch wo passt das Design bei alldem hin? Anhänger des Classicist-Ansatzes verorten es in der Refaktorierungsphase, während es für Freunde des Outside-In-Ansatzes in der roten Phase, ohne jedwedes Feedback vom Code, stattfindet.

4. Nicht die Software hat sich verbessert sondern die Hardware

Die Probleme ändern sich nicht, sie werden bloß größer. Und da sich die Geschichte in der IT „etwa alle 17 Jahre“ wiederholt, spannte John Davies rasch den Bogen zu seiner Ansicht, dass nicht die Software, sondern die Hardware die Dinge verbessert hat: „Der wirkliche Vorteil liegt in der Hardware. Da sie sich praktisch täglich weiterentwickelt, registrieren wir es kaum. Die uns zur Verfügung stehende Hardware ist tausende male besser.“

Der Apollo Guidance Computer, der bei den Apollo-Raumflügen eingesetzt wurde, verfügte über einen Prozessor, der intern mit 16-Bit-Datenworten arbeitete, sowie über RAM mit einer Kapazität von 4Ki Datenworten und ROM mit einer Kapazität von 32Ki Datenworten. Heute sehen wir uns 1 GB große Filme in 1080p auf unseren Smartphones an.

„Die Software bremst uns aus“, so Davies. Wie haben Abstraktionsschicht um Abstraktionsschicht hinzugefügt, um die Komplexität der Hardware zu verstecken. Auch wenn dieses Vorgehen gut sein kann, sollte man darauf achten, wie es einen verlangsamt.

5. Datenbanken zu testen ist schwer

In vielen Fällen können sich Unit Tests zu einem echten Hindernis entwickeln, wenn man seinen Job effektiv erledigen will – meint zumindest Colin Vipurs, JAX London-Speaker und Veteran in Testdingen. Besonders gegen Mocking spricht er sich aus:

As with mocking any code you don’t own, what you’re validating is that you’re calling the third-party code in the way you think you should, but, and here’s the important part – this might be incorrect. Unless you have higher lever tests covering your code, you’re not going to know until it hits production. In addition to this, mocking raw JDBC is hard, like really hard.

6. Java ist schneller als JavaScript!

Java-Entwickler können die Sektkorken knallen lassen, denn: Java übertrifft JavaScript nun ganz offiziell – zumindest wenn es um Computational Workloads und Dinge wie Kalkulationen und Transaktionen geht. Selbst im Falle eines einfachen „hello world“-Tests hat Java Performancetechnisch die Nase vorn.

Das heißt allerdings nicht, dass JavaScript seinen Vorsprung im Bereich Web-Applikationen nicht zurückgewinnen kann. Darüber hinaus muss die Frage auch nicht „Java oder JavaScript?“ lauten – JavaScript ist immer noch die beste Wahl für das Front-End, so der Speaker Chris Bailey.

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: