Technologiewechsel 2014: Dos & Don'ts

Der Jahreswechsel ist ein guter Zeitpunkt, um darüber nachzudenken, was man in den nächsten 12 Monaten verändern möchte. Änderungen sind notwendig, um Stillstand – und damit Rückschritt – zu vermeiden. Doch nicht jede Änderung ist auch sinnvoll. Im Folgenden gebe ich ein paar Ratschläge zu Technologiewechseln, die man 2014 in größeren Softwareprojekten angehen sollte, und zu solchen, von denen man besser die Finger lässt – entsprechend meiner persönlichen und subjektiven Einschätzung.

Grundregeln

Grundsätzlich sollte man bei solchen Entscheidungen drei wichtige Regeln beachten, um an den richtigen Stellen anzusetzen:

1. Die erreichten Verbesserungen sichtbar machen: Das Ziel jeder Veränderung ist eine Verbesserung, doch nicht immer ist diese offensichtlich. Damit die Projektbeteiligten diese und folgende Transformationen unterstützen, sollten frühzeitig erreichte Erfolge dem Aufwand gegenüberstellbar sein.
2. Den Wert bewährter Technologien schätzen: Die Informatik blickt auf über 50 Jahre Forschung und Entwicklung zurück. Während dieser Zeit haben sich viele kluge Leute viele sinnvolle Dinge überlegt. Reife und Erfahrung sind nicht zu unterschätzen.
3. Auf tatsächliche Herausforderungen fokussieren: Jede Anwendung und jedes System hat seine eigenen Anforderungen. Entsprechend eignen sich manche Technologien für die einen Projekte sehr gut wohingegen sie für scheinbar ähnliche Projekte untauglich sind. Wichtig ist, die eigenen Herausforderungen zu verstehen und zu adressieren, anstatt Probleme zu lösen, die man überhaupt nicht hat.

Programmiersprachen

C++ hat mit C++11/14 einen großen Schritt nach vorn gemacht. Die wichtigsten Hersteller sind beteiligt, und die Unterstützung aller Plattformen durch drei verschiedene Compiler ist absehbar. Bei einer solchen Entscheidung kann man wenig falsch machen, da sie früher oder später eh kommen wird, die neuen Möglichkeiten überzeugend und die Risiken aufgrund der Abwärtskompatibilität minimal sind.

Ähnlich verhält es sich mit Java 8. Die neue Version wird im Frühjahr erwartet und bringt nach fast einjähriger Beta-Phase die bedeutendsten Änderungen seit Java 5 mit sich. Im Gegensatz zu C++ sollte man bei Java den Wechsel allerdings behutsam angehen. Denn aufgrund des Umfangs der Standardbibliothek kommt es immer wieder zu Kompatibilitätsproblemen – insbesondere in Kombination mit großen Frameworks und Bibliotheken. Schulungen für Java 8 bieten sich dagegen jederzeit an.

Weiterhin keine Aufmerksamkeit braucht man dagegen den alternativen Sprachen auf der JVM zu schenken. Zwar enthalten sie einige interessante und gut durchdachte Konzepte, doch die Bedeutendsten finden mittelfristig auch ihren Weg nach Java. Die babylonische Sprachvielfalt führt vor allem zu Problemen. Wer möchte schon an Projekten arbeiten, die zu je einem Drittel aus Clojure, Groovy und Scala bestehen? Und wie soll man in fünf Jahren erfahrene Entwickler für Ceylon, Kotlin oder Nice finden, die den Code pflegen und weiterentwickeln? Die polyglotte Programmierung lässt grüßen!

Ein wenig anders ist es um ECMAScript 6 bestellt. Die Verabschiedung der neuen Sprachversion steht unmittelbar bevor. Sie wird die Sprache vor allem für Entwickler zugänglicher machen, die Erfahrungen in anderen Sprachen haben. Die Unterstützung durch die wichtigsten Browser wird nicht lange auf sich warten lassen. Dennoch: Für client-seitiges ECMAScript ist der kleinste gemeinsame Nenner der Nutzer maßgebend. Das rückt den Einsatz der neuen Version in weite Ferne – zumindest solange man nicht ECMAScript 6 automatisch nach ECMAScript 5 übersetzt, wie es beispielsweise TypeScript vormacht.

Datenbanken & Storage

Große Internet-Unternehmen setzen schon seit Jahren auf Alternativen zu SQL-Datenbanken. So ist beispielsweise Apache Cassandra bei Facebook entstanden, und Apache Hadoop basiert auf Googles Konzepten. Beide Technologien eignen sich ausgezeichnet für die Verwaltung gigantischer Datenbestände – so wie sich LKWs für den Transport großer Mengen Stückguts eignen. Möchte man jedoch lediglich ein Brot beim Bäcker holen, ist ein anderes Transportmittel angebrachter.

Das Gleiche gilt für Datenbanken: Wer keine Datenmengen in der Größenordnung von Google oder Facebook verarbeitet, ist mit klassischen Datenbanksystemen in der Regel besser bedient. SQL-Datenbanken sind besser als ihr Ruf. Aufgepeppt mit SSDs und viel Hauptspeicher können sie auf Commodity-Hardware über 50 000 Schreib- und über 500 000 Lese-Transaktionen pro Sekunde durchführen.

Die Vorurteile gegenüber relationalen Datenbanksystemen sind in der Regel auf die ineffiziente Verwendung zurückzuführen. Für eine gute Performance sollte man lediglich ein paar einfache Tipps beachten:

• Kapselung: Datenbanken sollten nie als Schnittstellen zwischen Systemen verwendet werden. Jede Datenbank gehört zu genau einem System und wird dadurch vollständig gekapselt.
• Spezialisierung: Das Datenbank-Schema sollte so gut wie möglich die Fachlichkeit wiederspiegeln. Generalisierungen sollten vermieden werden. Denn sie führen dazu, dass gleiche Strukturen für unterschiedliche Dinge verwendet werden, und behindern dadurch zukünftige Änderungen.
• Unvollständige Normalisierung: Die Normalisierung ist ein Werkzeug für den Datenbankentwurf, die sinnvoll eingesetzt werden muss. Insbesondere sollte sie nicht dogmatisch angewendet werden. Andernfalls führt sie zu einer Unzahl von Tabellen ohne klar verständliche Semantik.
• Zerlegung: Entgegen der klassischen Vorgehensweise sollten Datenstrukturen nicht grundsätzlich in ihre atomaren Bestandteile zerlegt werden. Die meisten relationalen Datenbanksysteme unterstützen XML und JSON für zusammengesetzte Objekte. Einzelne Spalten sind nur für Primär- und Fremdschlüssel sowie für Suchanfragen zwingend erforderlich.
• Persistenzlayer: Schlecht eingesetzte Persistenzlayer sind eine der Hauptursachen für eine gefühlt schlechte Datenbank-Performance. Häufig wird versucht mit einem Modell die komplette Datenbank abzudecken, wodurch die Klassen zu einer zentralen Infrastruktur werden. Stattdessen sollte man genau wie an anderen Stellen auf Modularisierung achten und die Persistenzschicht an den Use-Cases ausrichten – selbst wenn dadurch die gleichen Tabellen in unterschiedlichen Modulen durch unterschiedliche Klassen repräsentiert werden.

Wie bereits erwähnt sollte man darüber hinaus auf genügend Hauptspeicher in den Datenbank-Servern achten und auf SSDs umrüsten, sofern noch nicht geschehen. Damit sollten die Performance-Probleme nicht nur für den Augenblick sondern auch für die Zukunft gelöst sein. Denn insgesamt wächst das Angebot für Leistungsfähige Hardware schneller als der Bedarf nach Kapazität.

Netzwerk & Protokolle

Die Hypes um Netzwerkprotokolle für die Kommunikation zwischen Anwendungen haben sich bisher alle als sehr kurzlebig erwiesen. Durchsetzen konnte sich bisher kein Ansatz. Klar scheint aktuell nur, dass schwergewichtige Protokolle wie IIOP, RMI und SOAP kaum noch eine Chance haben werden. Empfehlen lässt sich lediglich, auf einfache und interoperable Protokolle zu setzen.

Ein gutes Kriterium dafür ist die Menge an Code, die in den verbreiteten Programmiersprachen für produktionsreife Implementierungen notwendig ist – ausschließlich basierend auf den zugehörigen Standardbibliotheken. REST (genauer RESTful HTTP) geht in diese Richtung, wobei man die Komplexität jedoch nicht unterschätzen sollte. Weniger ist manchmal mehr, und so kann eine REST-like API, die im Wesentlichen nur auf HTTP und XML setzt, wesentlich sinnvoller als eine RESTful API sein.

Unabhängig vom Anwendungsprotokoll sollte man auf der Transportschicht jedoch stets auf starke Verschlüsselung achten – und zwar auf allen Kommunikationsstrecken. Das haben uns die zahlreichen Enthüllungen zur NSA-Überwachung in 2013 gelehrt. Naheliegend dafür ist der Einsatz von HTTPS in Kombination mit einer Public-Key-Infrastruktur (PKI). Noch besser ist, auch die Client-Authentifizierung über HTTPS abzuwickeln. Denn durch Client-Zertifikate reduziert sich die Menge notwendiger Secrets, und jede Anwendung muss sich nur noch um die Vertraulichkeit ihrer eigenen Schlüssel kümmern.

Performance

Aufgrund der niedrigen Preise für Hauptspeicher eignen sich Caches ausgezeichnet, um die Performance von Abfragen zu optimieren. Denn mit hundert Gigabyte lässt sich in der Regel mehr bewegen, als durch ein paar Tage Entwicklung. Doch helfen können die Caches nur, wenn sie richtig eingesetzt werden. Grundsätzlich sollten dazu zwei Betriebsmodi unterschieden werden:

• stale: Der Cache liefert potentiell veraltete Daten. Dabei steigt der Wirkungsgrad mit der zeitlichen Diskrepanz.
• consistent: Der Cache liefert stets valide Daten. Der Wirkungsgrad hängt jedoch vom Aufwand ab, der für die Gewährleistung der Konsistenz notwendig ist.

HTTP-Caches unterstützen typischerweise beide Modi. Ersterer ist für statische Inhalte sehr effektiv, für Webservices aufgrund fehlerhafter Ergebnisse jedoch praktisch ungeeignet. Letzterer liefert zwar stets korrekte Ergebnisse, erfordert dafür jedoch die Validierung bis zum Ursprung der Daten, was vergleichsweise viel Entwicklungsaufwand bedeutet. Sinnvoller ist daher die Caches dort einzusetzen, wo die Konsistenz effizient sichergestellt werden kann. Insbesondere bietet sich dafür der interne Cache der Datenbanksysteme an.

Das zweite wichtige Performance-Thema ist Parallelisierung – sowohl für die Auslastung mehrerer CPU-Kerne als auch zur Verdeckung von Netzwerklatenzen. In letzter Zeit sind die Stimmen zu Actor-basierten und Ereignis-gesteuerten Architekturen lauter geworden. Doch davon sollte man sich nicht blenden lassen. Beide Modelle sind über 40 Jahre alt und haben sich im Gegensatz zum Thread-Modell kaum weiterentwickelt. Nur Letzteres wird nativ und durchgehend von aktuellen Betriebssystemen unterstützt. Achten sollte man bei der Verwendung von Threads lediglich auf geeignete Abstraktionsebenen, die viele Programmiersprachen mit ihren Standardbibliotheken unterstützen.

Ein gutes und erfolgreiches Jahr 2014!