Analyse zum Thoughtworks Technology Radar, Vol. 26 Was die IT- und Technologiebranche 2022 bewegt

Im sogenannten Technology Radar beschäftigt sich Thoughtworks mit Technologien und Trends, die gerade in der IT-Branche Fuß fassen. Mike Mason von Thoughtworks erläutert im Folgenden einige der Makrotrends.

Beständige Spannung zwischen Client- und Server-Logik

Lange Branchenzyklen führen dazu, dass der Schwerpunkt der Implementierung von Geschäftslogik zwischen Server und Client pendelt. In der Ära Mainframe haben wir uns auf zentrale Datenverarbeitung und einfache Terminals verlassen, sodass sämtliche Logik – auch die Cursor-Bewegungen! – vom Server geregelt wurde.

Im Anschluss brach die Zeit von Windows und Desktop-Apps an, in der weit mehr Logik und Funktionalität auf Clients verlagert wurden. „Two-tier“- Anwendungen, die den Server meistens als Datenspeicher nutzten und die gesamte Logik mit Hilfe von Clients abwickelten, waren an der Tagesordnung.

In der Frühzeit des Internets übernahm der Browser im Wesentlichen nur das Rendering der Webseiten. Der Großteil der Berechnungen wurde vom Server übernommen. In Zeiten von Web 2.0 und mobilem sowie Edge Computing wird die Logik wieder mehr und mehr in den Clients implementiert.

In dieser Radar-Ausgabe widmen wir uns in einigen Teilen diesem weiterhin bestehenden Spannungsfeld. Server-driven UI ermöglicht eine gewisse Weiterentwicklung von Handy-Apps, ohne die Apps selbst aktualisieren zu müssen. Erreicht wird dies dadurch, dass der Server die Art der Benutzerelemente festlegt, die zur Darstellung einer Serverantwort verwendet werden. TinyML ermöglicht umfangreiche Machine-Learning- kurz ML-Modelle auf günstigen Geräten mit begrenzten Ressourcen und schafft unter Umständen die Verlagerung von ML in die äußersten Randbereiche des Netzwerks.

Wir nehmen an dieser Stelle mit, dass es keinen neuen „richtigen“ Weg zur Strukturierung der Logik und Daten eines Systems gibt. Es handelt sich vielmehr um einen fortlaufenden Kompromiss, den wir immer wieder neu bewerten müssen. Mit zunehmenden Möglichkeiten und Ressourcen bei Geräten, Cloud-Plattformen, Netzwerken und Middleware ist dieser Kompromiss veränderlich und eine gewählte Architektur sollte jederzeit auf dem Prüfstand stehen dürfen.

Die „Schwerkraft“ von Software

Wir beschäftigen uns im Rahmen des Radars oft mit den Dingen, die in der Branche schieflaufen. Es kommt häufig vor, dass ein gutes Tool an so vielen Stellen zum Einsatz kommt, dass es insgesamt einen negativen Einfluss hat. Genauso schädlich kann es sein, wenn eine bestimmte Komponente über die Grenzen ihrer tatsächlichen Anwendbarkeit hinaus verwendet wird.

Ganz besonders fällt uns auf, dass etliche Teams viel zu häufig zu Kubernetes greifen – „Kubernetes all the things!“ – auch wenn es keine Universallösung für sämtliche Probleme der Tech-Branche darstellt. API-Gateways, die dazu missbraucht werden, Probleme mit der API im Backend zu lösen, anstatt das Problem direkt anzugehen, konnten wir auch entdecken.

Wir meinen, dass die „Schwerkraft“ von Software diese Antipatterns erklären dürfte. Entwicklerteams sehen für Ablauf, Logik, Orchestrierung, eine Art Gravitationszentrum, dem aus Bequemlichkeit Funktion um Funktion hinzugefügt wird. Bis schließlich diese Komponente zum Zentrum des Universums des Teams wird. Probleme beim Genehmigen und Bereitstellen von Alternativen verstärken die Anziehungskraft dieser allgegenwärtigen Systemkomponenten noch mehr.

Der veränderte Blick der Branche auf Open Source

Open-Source-Software hatte immense Auswirkungen auf die Welt. Linux, entwickelt von einem jungen Programmierer, der sich kein kommerzielles Unix-System leisten konnte, hat sich zu einem der meistgenutzten Betriebssysteme unserer Zeit gemausert. Die besten 500 Supercomputer laufen durchweg mit Linux und 90 Prozent der Cloud-Infrastrukturen verwenden das Betriebssystem.

Open Source ist täglicher Bestandteil des Arbeitslebens eines modernen Software Engineers – von Betriebssystemen über mobile Frameworks bis hin zu Datenanalyseplattformen und Programmierbibliotheken. Wir als Branche – und als Gesellschaft im Ganzen – mussten allerdings feststellen, dass einige sehr wichtige Open-Source Software-Lösungen auf einem Fundament beruhen, das man nicht zu stark erschüttern sollte.

Heartbleed lautet der Name eines Bugs in OpenSSL, einer Library, die benutzt wird, um die Kommunikation zwischen Webservern und Browsern abzusichern. Der Bug ermöglichte Angreifern den Zugriff auf die privaten Keys eines Servers und damit die Übernahme von Cookies und Passwörtern einer Benutzersession. Der Bug wurde von Experten als „katastrophal„ bezeichnet und betraf etwa 17 Prozent der mit HTTPS abgesicherten Server im Internet.

Die OpenSSL-Maintainer sorgten innerhalb von einer Woche nach Meldung des Bugs für einen entsprechenden Patch. Allerdings mussten auch hunderttausende kompromittierte Zertifikate neu ausgestellt werden. Nach dem Vorfall stellte sich heraus, dass OpenSSL, eine sicherheitskritische Library, die etwa 500.000 Zeilen Code umfasst, von lediglich zwei Personen gepflegt wird.

Unter der Bezeichnung Log4Shell wurde erst kürzlich ein Problem mit der weit verbreiteten Logging Library Log4j bekannt. Der Bug ermöglichte den Fernzugriff auf Systeme und wurde von Sicherheitsexperten ebenfalls als Problem mit apokalyptischen Ausmaßen angesehen. Obwohl den Projektbetreuern das Problem gemeldet wurde, gingen etwa zwei Wochen ins Land, bis eine Lösung zur Verfügung stand.

In der Zwischenzeit wurde der Bug von Hackern ausgenutzt. Die Beseitigung des Bugs verlief zudem übereilt, die Sicherheitslücken waren nur in Teilen behandelt. Zudem waren zwei weitere Patches zur Lösung sämtlicher Probleme erforderlich. Alles in allem vergingen drei Wochen zwischen der ersten Meldung und einer verfügbaren und vollständig sicheren Log4j-Version.

An dieser Stelle betone ich, dass ich die Teams von OpenSSL und Log4j keineswegs kritisieren möchte. Bei Log4j handelt es sich um eine Gruppe von Freiwilligen, die sehr hart an der Absicherung ihrer Software gearbeitet und ihre Abende und Wochenenden vollkommen unbezahlt geopfert haben. Während sie an einer Lösung des Problems arbeiteten, mussten sie sich jedoch spitze Bemerkungen und ärgerliche Tweets gefallen lassen.

All das nur wegen eines obskuren Log4j-Features, dass niemand von Verstand tatsächlich verwenden wollen würde und das nur aus Gründen der Rückwärtskompatibilität existierte. Die Grundsorge bleibt: Open-Source-Software wird in globaler Hinsicht immer wichtiger, aber auf Grundlage von sehr unterschiedlichen Modellen geschaffen und gepflegt.

Open Source existiert im Spagat zwischen zwei Extremen. Unternehmen wie Google, Netflix, Facebook und Alibaba veröffentlichen Open-Source-Software, die intern entwickelt, deren Weiterentwicklung finanziert, und die mit Nachdruck beworben wird. Ich würde diese Software als „professionelle Open-Source-Software „ bezeichnen.

Der Vorteil einer solchen Software liegt für diese Konzerne hauptsächlich im Recruiting: Software wird mit der indirekten Absicht veröffentlicht, dass Programmierer auf den Zug aufspringen und an den Programmen mit gewissem Coolness-Faktor arbeiten können. Auf der anderen Seite steht Open-Source-Software, die von einer einzigen Person aus Leidenschaft für die Sache geschaffen wird.

Software ist hier die Antwort auf ein persönliches Interesse oder die Motivation, dass eine bestimmte Softwarelösung vorteilhaft für andere sein könnte. Hinter dieser Art Software steht kein Vermarktungsgedanke, niemand wird dafür bezahlt. Die Software existiert, weil eine Handvoll Menschen davon begeistert ist.

Auf halber Strecke zwischen diesen beiden Systemen stehen Projekte, die bis zu einem gewissen Grad rechtlich oder administrativ unterstützt werden, etwa von der Apache Foundation. Im Vergleich zu den kleineren Projekten ist hier eine größere Gruppe von Maintainern am Werk und eine „Kommerzialisierung von Open Source“ findet insofern statt als die Software selbst kostenlos ist, Scaling und Support aber zusätzlich bezahlt werden müssen.

Die Landschaft ist also komplex. Wir fördern Open-Source-Software und setzen uns für die Verwendung ein. Wir würden uns freuen, wenn ihre Finanzierung besser gewährleistet wäre. Die abstruse Folge wäre aber wahrscheinlich, dass eine Finanzierung von Liebhaberprojekten sich genau gegensätzlich auswirken könnte. Es steht zu befürchten, dass Motivation genauso wie der Spaß und Glaube an eine Sache mit der Bezahlung verschwinden. Es wäre dann nur noch ein Job. Ein Dilemma!

Wir sind allerdings der Meinung, dass große Unternehmen, die Open-Source-Software nutzen, besser darüber nachdenken sollten, wie man die Open-Source-Community unterstützen und ihr etwas zurückgeben kann. Und sie sollten immer berücksichtigen, wie gut der Support ist, noch bevor ein Feature aufgegriffen wird. Das Gute an Open Source ist, dass jeder den Code verbessern kann. Wenn Sie den Code also verwenden, sollten Sie auch darüber nachdenken, wie man Probleme damit lösen oder ihn verbessern kann.

Absicherung der Software-Lieferkette

Ist der Server sicher und gepatcht? Hat man bei der Anwendung mit SQL-Injection Möglichkeiten oder Cross-Site Scripting Bugs zu kämpfen, die für Angriffe ausgenutzt werden könnten? Sobald eine Software in Produktion geht, steht in aller Regel ihre Sicherheit stark im Fokus. Die Angriffe werden jedoch immer raffinierter und greifen zunehmend den gesamten „Produktionspfad“ von Systemen an. Angefangen bei dem Versionskontrollsystem bis hin zu Servern für Continuous Delivery.

Unterwandert ein Angreifer den Prozess an irgendeinem Punkt entlang dieses Pfades, kann er den Code ändern und absichtlich Schwachstellen oder Hintertüren einbauen und so die laufenden Systeme gefährden. Selbst wenn der endgültige Server, auf dem er läuft, sehr gut abgesichert ist.

Der jüngste Exploit für Log4j, um den es im vorherigen Abschnitt über Open Source ging, zeigt eine weitere Schwachstelle des Produktionspfads auf.

Software wird in der Regel aus einer Codekombination erstellt, die auf die zugrunde liegende geschäftliche Frage zugeschnitten ist, sowie aus Library oder Utility Code, der zusätzliche Probleme löst und wiederverwendet werden kann, um die Softwareentwicklung zu beschleunigen. Bei Log4Shell handelte es sich um eine Schwachstelle in Log4j, so dass jeder, der diese Library verwendet hatte, potenziell anfällig war. Da Log4j seit mehr als einem Jahrzehnt existiert und verwendet wird, könnten das sehr viele Systeme sein.

Die Problemstellung lautete nun herauszufinden, ob die Software Log4j enthält und falls ja, welche Version. Dieser Prozess gestaltet sich ohne automatisierte Tools sehr mühsam, vor allem, wenn in einem typischen Großunternehmen tausende von Software-Komponenten im Einsatz sind.

Die Branche ist sich dieses Problems inzwischen bewusst und wir konnten bereits feststellen, dass sogar das Weiße Haus in den USA die Notwendigkeit einer Absicherung der „Software-Lieferkette“ herausgestellt hat. In Anlehnung an einen anderen Begriff aus der Fertigungsindustrie wird die IT-Branche durch eine Direktive der US-Regierung angewiesen, eine „Software-Stückliste“ (SBOM) zu erstellen, in der alle in einem System enthaltenen Softwarekomponenten aufgeführt sind.

Dank der Unterstützung von Tools zur automatischen Erstellung einer SBOM und zum Abgleich von Schwachstellen mit einer SBOM würde sich das Problem der Feststellung, ob ein System eine anfällige Version von Log4J enthält, auf eine einfache Abfrage und einige Sekunden Verarbeitungszeit reduzieren. Teams können sich auch an den Supply Chain Levels for Software Artifacts (SLSA, ausgesprochen „Salsa“) orientieren und mit dieser Rückendeckung Checklisten erstellen.

Der Untergang von eigenständigen Pipeline-Tools

Das Wort „Untergang“ ist sicherlich etwas übertrieben. Unsere Radar-Arbeitsgruppe hat allerdings viel über Github Actions, Gitlab CI/CD und Azure Pipelines gesprochen, bei denen alle Pipeline-Tools entweder in der Repo- oder der Hosting-Umgebung untergebracht sind. Einige der eigenständigen Pipeline-Tools könnten im Zusammenhang mit der zuvor beobachteten Tendenz von Teams einen schweren Stand haben, da sie das Standardtool in ihrem Ökosystem (Github, Azure, AWS usw.) verwenden, statt nach dem besten Tool, der besten Technik oder der besten Plattform für ihre Bedürfnisse zu suchen.

Wir haben immer wieder „eigenständige“ Pipeline-Tools, wie z.B. CircleCI, vorgestellt. Doch selbst unser interner Review-Zyklus hat unterschiedliche Meinungen zutage gefördert. Es fand sich auch jemand, der behauptete, dass Github Actions alles liefere, was man brauche, und Teams kein eigenständiges Tool verwenden sollten. Wir empfehlen, sowohl „Standard“- als auch Stand-Alone-Pipeline-Tools in Betracht zu ziehen und sie je nach ihren Vorzügen zu bewerten. Dazu zählen sowohl Features als auch die Erleichterung der Integration.

SQL weiterhin vorherrschende ETL-Sprache

Wir wollen nicht unbedingt behaupten, dass das eine gute Sache ist. Die ehrwürdige Structured Query Language ist aber nach wie vor das Werkzeug, auf das die Branche bei der Abfrage oder Umwandlung von Daten am häufigsten zurückgreift. Ganz gleich wie fortschrittlich unsere Tools oder Plattformen sind, SQL ist der gemeinsame Nenner der Datenverarbeitung. Ein gutes Beispiel dafür ist die Vielzahl von Streaming-Datenplattformen, die SQL-Abfragen über ihren Zustand erlauben oder SQL verwenden, um ein Abbild der Verarbeitungsdaten zu erstellen, z. B. ksqlDB.

SQL hat den Vorteil, dass sie bereits seit den 1970er Jahren existiert und die meisten Programmierer sie irgendwann einmal benutzt haben. Das ist auch ein erheblicher Nachteil – viele von uns haben gerade genug SQL gelernt, um gefährlich statt kompetent zu sein. Mit Hilfe zusätzlicher Tools kann SQL gezähmt, getestet, effizient und zuverlässig werden. Besonders gut gefallen haben uns dbt (ein Datenumwandlungstool mit einem überaus guten SQL-Editor) und SQLfluff (ein Linter, der bei der Erkennung von Fehlern im SQL-Code unterstützt).

Die unendliche Suche nach dem Stammdatenkatalog

Ein in der Branche ständig diskutiertes Thema ist die Bedeutung und der latente Wert von Unternehmensdaten, wobei immer mehr Anwendungsfälle zur Datennutzung entstehen. Sie sind häufig mit interessanten und unerwarteten neuen Möglichkeiten gekoppelt, die sich aus maschinellem Lernen und künstlicher Intelligenz ergeben.

Seit Unternehmen Daten sammeln, bemüht man sich stets, die Daten zu kategorisieren, zu katalogisieren und sie in ein einheitliches Format zusammenzuführen und umzuwandeln. So werden Daten besser zugänglich und wiederverwendbar und der in den Daten steckende Wert lässt sich leichter „freisetzen“.

Eine Strategie zur Wertschöpfung des Potenzials von Daten beinhaltet häufig die Erstellung eines so genannten „Stammdatenkatalogs“ – ein von oben nach unten angelegtes, einheitliches Unternehmensverzeichnis aller Daten im gesamten Unternehmen. Es gibt immer mehr ausgeklügelte Tools, die sich an dieses Kunststück heranwagen.

Dabei folgt allerdings immer wieder die Kollision mit der harten Realität – nämlich, dass Daten komplex, mehrdeutig, doppelt vorhanden und sogar widersprüchlich sind. In letzter Zeit sind eine Reihe von Datenkatalog-Tools wie z.B. Collibra auf dem Radar aufgetaucht. Gleichzeitig bewegt sich die Branche weg von zentralisierten Datendefinitionen und hin zu dezentraler Datenverwaltung durch Techniken wie z.B. Data Mesh.

Dieser Ansatz trägt der inhärenten Komplexität von Unternehmensdaten Rechnung, indem Dateneigentum und -ermittlung entlang von Geschäftsbereichen separiert werden. Sofern Datenprodukte dezentral gespeichert und von unabhängigen, bereichsorientierten Teams kontrolliert werden, lassen sich die auf dieser Grundlage entstehenden Datenkataloge einfacher und leichter pflegen.

Der Bedarf an komplexen Datenkatalog-Tools und Verwaltungsplattformen für Stammdaten wird durch diese Aufschlüsselung des Problems ebenfalls reduziert. Während die Branche also weiterhin nach einer Antwort auf die Frage nach „dem“ Stammdatenkatalog sucht, lautet unsere Einschätzung, dass dies wahrscheinlich die falsche Fragestellung ist und kleinere, dezentrale Kataloge die Antwort sind.

* Als Global Head of Technology ist Mike Mason bei ThoughtWorks für die strategische Ausrichtung der Technologie sowie für den Erfolg der Kundenprojekte verantwortlich. Es ist seine Leidenschaft, Spitzentechnologie zur Lösung geschäftlicher Herausforderungen einzusetzen und die Kunden zu beraten, auf welche Weise Technologie ein kritischer Teil ihres Geschäfts sein kann.

(ID:48402393)