ThoughtWorks Technology Radar 2021

Plattformteams, Monorepos und SQL: Aktuelle Makrotrends in der Technologiebranche

Mike Mason

© Shutterstock / pp.ng

Zweimal jährlich veröffentlicht die globale Technologieberatung ThoughtWorks ihren Technology Radar, der einen Überblick über Trends in der Softwareentwicklung liefert. Da der Report nicht für alle Trends Platz bietet, greift dieser Artikel einige Makrotrends der Tech-Branche auf und erläutert sie näher.

Monorepos: Erfolg ist mit Aufwand verbunden

Das Konzept des Monorepos – ein einziges großes Quellcode-Repository, das Code und Assets über alle Projekte innerhalb einer Organisation speichert – hat in den letzten Jahren an Zugkraft gewonnen. Diesen Ansatz hat Google populär gemacht. Die Hauptvorteile sind: Monorepos vereinfachen die teamübergreifende, gemeinsame Nutzung eines Quellcodes und sogar das Refactoring der gesamten unternehmensweiten Codebasis. Der Erfolg, den Google mit dieser Technik hat, bedeutet allerdings nicht, dass sie für die gesamte Branche replizierbar ist. Ein einziger Build-Prozess für alles im Repository wird oft als Schlüsselfaktor für den Erfolg genannt, aber es erfordert Disziplin und technischen Aufwand.

Es gibt Unternehmen, die den Wunsch haben, mehrere „Mono“-Repos innerhalb einer Organisation zu erstellen. Das mag vernünftig sein, beeinträchtigt jedoch den Wert eines Monorepos. Daher erfordert es eine sorgfältige Überlegung, welche Assets in welchem Repository leben. Es ist schwierig, hier eine Empfehlung abzugeben. Aber falls die Idee eines Monorepos für ein Unternehmen verlockend ist, sollte es definitiv prüfen, ob die Anwendungsfälle, die organisatorische Struktur und die technischen Tools zur Verfügung stehen, die erforderlich sind, damit sich der Ansatz lohnt: Nicht jedes Unternehmen ist Google!

Entwicklung und Einsatz von Plattformteams

Der sinnvolle Einsatz von Plattformen kann die Produktivstellung von Produkten und Funktionen beschleunigen. Dabei spielt es keine Rolle, ob die Plattformen auf der Ebene der Infrastruktur, Daten, APIs oder Business Capabilities genutzt werden. Doch wie baut man Plattformen am besten auf? Die Antwort lautet immer öfter, ein Plattformteam zu bilden, dem die Aufgabe zukommt, ein überzeugendes Angebot zu erstellen, das andere Teams nutzen können, um ihre Arbeit zu beschleunigen. Das Konzept des Plattformteams reift, und es finden sich in der Branche sowohl gute als auch schlechte Methoden in der Umsetzung:

  • Entscheidend ist, die Entwicklungsteams als Kunden für die Plattform zu haben und diese als ein Produkt zu betrachten — das bedeutet, die Plattform langfristig zu finanzieren, sorgfältig darüber nachzudenken, welchen Wert sie schafft und die Anwendungsfälle zu verstehen. Es kann nicht bedeuten, eine Plattform im luftleeren Raum aufzubauen und zu hoffen, dass die Anwendungsfälle sich später ergeben. Wichtig ist auch, eine Marke für die Plattform aufzubauen und daran zu arbeiten. Das sorgt dafür, dass die Teams sie annehmen und einen Nutzen daraus ziehen können.
  • Die Strukturierung von Teams über und rund um eine Plattform erfordert sorgfältige Überlegungen. Empfehlenswert ist ein strukturierter Ansatz für die Organisation von Teams und ein kontinuierlicher Verbesserungszyklus aufgrund von Erfahrungen, so wie es im Buch Team Topologies beschrieben wird.
  • Neue Muster zeichnen sich ab, wie zum Beispiel ein technologieorientiertes Team, das alte und neue Tools kombiniert, um Verbesserungen und Upgrades effizienter und kontrollierter ausführen zu können. Beispielsweise könnte ein Team für die Pipeline-Tools des gesamten Unternehmens verantwortlich sein und so Migrationspfade optimieren sowie die Sicherheits- und Compliance-Kontrollen gewährleisten. Das bildet einen Kontrast zu einem Ansatz, der ein neues Team zusammenbringt, um ein neues Tool zu schreiben. Das Problem dabei ist, dass das neue Team in der Regel nicht auf das gesamte Wissen und die Kompetenzen des ursprünglichen Technologieteams zugreifen kann.
  • Es besteht ein gewisses Spannungsverhältnis zwischen dem Ansatz eines Plattformteams und dem einzelner Teams, die sowohl die Anwendung als auch die Infrastruktur verantworten. In kleinerem Maßstab funktioniert die Strategie mit einem einzigen Team gut, aber mit zunehmender Skalierung wird sie unpraktisch, da man das Wissen über alle Plattformbelange nicht wirklich in eine große Anzahl von Anwendungsteams einbetten kann. In dem Maße, in dem ein Unternehmen wächst, kann es sinnvoll werden, mehrere Plattformteams zu schaffen, von denen jedes für verschiedene Teile des Technologiebereichs verantwortlich zeichnet.
  • Leider verstecken einige Organisationen ihre ‚Plattformen‘ hinter einem überholten Ticketing-System. Das erhöht jedoch die Reibung und die Teams können nicht eigenständig agieren oder ihren Code auf dem Weg in die Produktivstellung verwalten.

Plattformteams sind in der Lage, mit technischen Exzellenzzentren zusammenzuarbeiten, um gute Muster zu definieren. Dabei befähigen sie die Teams, neuere cloud-native Technologien zu integrieren. Dies ist eine sehr viel bessere Alternative als Teams, die ihre Zeit damit verbringen müssen, diese Muster selbst zu erlernen.

Die Konsolidierung der All-in-One-Bereitstellungsinfrastruktur: Eine Gefahr für Innovation

In den Tagen der traditionellen On-Premise-Client/Server-Software hörte man oft, ein Unternehmen sei „ein Microsoft-Shop“ und verwende dieses Toolset für alles. So konnte es passieren, dass ein Team am Ende Visual Studio für die Entwicklung und SQL Server als Datenbank verwendete, selbst wenn eine Oracle-Datenbank bestimmte Funktionen aufwies, die sie für einen bestimmten Anwendungsfall zur besseren Wahl gemacht hätte. Ein „Microsoft-Shop“ zu sein, war eine valide Entscheidung und bot Klarheit bei der Wahl des Tech-Stacks sowie der Konsolidierung von Entwicklungs- und Betriebskompetenzen. Oft war es auch ein einfacherer Weg bei der Beschaffung – jeder hatte einen Microsoft-Lizenzvertrag und konnte diese Tools beliebig hinzufügen.

Heute bieten große Cloud-Plattformen wie AWS, GCP und vor allem Azure „Front-to-Back“-Tools für den Lebenszyklus der Cloud-Anwendungsentwicklung, einschließlich Anforderungsmanagement, Quellcodekontrolle, den Aufbau von Pipelines, die Produktionsbereitstellung und Trouble Ticketing – zwar in einem analogen „Stack“, aber für das Cloud-Zeitalter geeignet. Dies macht die Standardauswahl leicht verständlich und einfach zu beschaffen, und bietet einem Team alle erforderlichen Tools, um Software in die Produktion zu bringen. Die Vorteile sind vergleichbar mit denen, die sich in den 2000er Jahren mit der Wahl eines einzelnen Tech-Stacks erzielen ließen.

Das Problem dabei ist, dass diese „Gut genug“-Entscheidungen möglicherweise hinter einer unabhängigen branchenführenden Alternative zurückbleiben. Das bedroht die gesamte Innovationsfähigkeit, da sich die Standards nun im Besitz und unter der Kontrolle großer Cloud-Anbieter befinden. Und Teams akzeptieren oft die Standardauswahl, da sie (meistens) gut genug funktioniert und es sich einfach nicht lohnt, sich auf der Suche nach einer anderen Option durch Beschaffungs- oder Genehmigungsprozesse zu kämpfen.

Der Kampf um Cloud-Marktanteile motiviert die großen Anbieter dazu, weiterhin diese Art von Ergebnissen zu schaffen. Pseudo-„Walled Gardens“ für jede Cloud erhöhen die Bindung und die Kosten für einen Wechsel. Es steht viel auf dem Spiel – in ihrem Wettlauf um Marktanteile hat Googles Cloud-Sparte im Jahr 2020 5,6 Mrd. Dollar verloren, Geld, das das Unternehmen langfristig durch Kundenbindung zurückverdienen will. Unsere Empfehlung: Unternehmen sollten mit offenen Augen an dieses Thema herangehen. Es ist wichtig zu wissen, dass ein höheres Maß an Bequemlichkeit unter Umständen einen gewissen Preis hat, der aber akzeptabel ist, wenn es den Vorteil der Zweckmäßigkeit wert ist.

Der Fall und Aufstieg von SQL

Vor dem „Big Data“-Trend waren relationale Datenbanken in starkem Maße für die Festplattenspeicherung optimiert. Sie waren zentralisiert, vertikal skaliert und enthielten eine eng integrierte Abfrage-Engine. Die Datenbankoperationen favorisierten Schreibvorgänge mit wenig Duplikation, aber vielen verknüpften Aktivitäten beim Lesen. War die Datenbank nicht schnell genug, konnte man eine größere Box kaufen, und die integrierte Abfragesprache verstärkte alle diese Merkmale.

Diese Designentscheidungen standen im Widerspruch zu den Hardware-Innovationen, die in dieser Zeit stattfanden. Festplatten wurden billiger und hatten eine höhere Kapazität, Solid-State-Laufwerke veränderten die Leistungscharakteristika von Speicher vollständig und die Anzahl der CPU-Kerne stieg schneller als die Taktrate. Dies führte zur Entwicklung des Hadoop-Dateisystems und löste eine kambrische Explosion in der Datentechnologie aus.

Plötzlich konnten Daten außerhalb von relationalen Datenbanken leben. Die „NoSQL“-Bewegung machte viele Arten von Datenspeichern wie Schlüssel-/Werte-, Dokumenten- und Graph-Datenbanken populär. Daten konnten sogar außerhalb einer Datenbank in einem Data Lake oder einem S3-Bucket leben. Die Duplizierung von Daten wurde als akzeptabel erachtet, um die Leseleistung zu optimieren, da immer mehr Anwendungsfälle eine „webbasierte“ Anwendungs- und Datenbankleistung erforderten. Das Konzept einer entkoppelten Abfrage-Engine wurde eingeführt, mit eigenständigen Abfragesprachen, die in verschiedene Speichersysteme eingebunden werden können.

Diese verteilten Datenspeicher brachten ihre Herausforderungen mit sich, und während einige Unternehmen mit all den beweglichen Teilen und der allgemeinen Schwierigkeit eines Modells zu kämpfen hatten, das nicht einfach nur aus einem „Atomic Commit“ bestand, lernte die traditionelle Datenbankindustrie und entwickelte sich weiter. Viele SQL-Datenbanken fügten Funktionen hinzu, wie z.B. Postgres, das einen Schlüssel/Werte-Speicher unterstützt. Speicher-Engines verbesserten sich durch die Hybrid-Unterstützung für zeilen- und spaltenbasierte Speicherung und boten damit mehr Flexibilität – sowohl für transaktionale als auch analytische Workloads.

Dann kam die Cloud, und mit ihr Anbieter, die cloud-basierte Datenbanken bereitstellen, z.B. BigQuery, RedShift, Snowflake und Co. Sie bieten Entwickler*innen sowohl Skalierbarkeit als auch traditionellere „SQL-ähnliche“ Erfahrungen. Dies führte zu einer Renaissance von SQL-basierten Tools. Mit Tools wie dbt lassen sich nun große und komplexe Probleme mit kleinen unabhängigen SQL-Einheiten lösen, die sich in einer Pipeline testen und zusammensetzen lassen.

Und wo stehen wir heute? Mit ELT in Cloud-Data-Warehouses und Tools wie dbt, die Transformationen im Warehouse zulassen, entsteht ein Spannungsverhältnis zu Data Lakes. Oft kommt es zu einer ‚Verschlankung‘ des Data Lakes und zu einer Wiederkehr von Warehouses an der Peripherie. Die damit verbundene Sorge um die Dezentralisierung von Daten und die Demokratisierung des Zugriffs – die oft mit einem Ansatz wie Data Mesh gelöst wird – lässt sich derzeit vielleicht besser durch die Cloud Data Warehouses als durch das Lake-Ökosystem lindern. Wir sind der Ansicht, dass die nächste Grenze darin besteht, OLTP- und OLAP-Workloads in derselben Datenbank zu verschmelzen. Darauf haben derzeit weder die Cloud Data Warehouses noch das Data-Lake-Ökosystem eine gute Antwort.

Mainstream Machine Learning

Machine Learning (ML) spielt heute in fast jeder Art von Software eine wichtige Rolle. In der Tat spricht die Branche schon seit Jahren darüber. Aber vielleicht sind wir auch an einer Art Wendepunkt angelangt, an dem ML einfach zu einem Standard wird, den wir alle nutzen.

So sollten Unternehmen beispielsweise CD4ML nutzen, um Machine Learning-Modelle in Produktion zu bringen. Es sollte ein kontinuierlicher Prozess sein, genau wie alle anderen Aspekte der Softwareerstellung. Unsere Kolleginnen und Kollegen bei Fourkind sind optimistisch, was die Fähigkeit von Unternehmen, ihre eigenen ML-Modelle zu besitzen, angeht. Obwohl viele der Cloud-Anbieter KI als einen Dienst anbieten, ist es genau genommen kein Problem, ein Modell für einen eigenen Anwendungsfall zu erstellen. Dies hat den Vorteil der Eigentümerschaft und Kontrolle über das Modell, die Algorithmen und Trainingsdaten, und der Zugriff ist nicht an einen Cloud-Anbieter gebunden.

Der Technology Radar bildet auch das einfachste mögliche ML-Modell ab – eine Anregung, dass wir nicht immer in tiefe neuronale Netze eintauchen müssen, um Probleme zu lösen. Oft lässt sich mit moderner Kubernetes-Infrastruktur ein nützliches Modell einfach mit K8s oder ECS trainieren, anstatt mit eigenen ML-Umgebungen. Es scheint also, als sei ML in Bezug auf die Branche im Mainstream angekommen. Unternehmen, die ML immer noch mit übertriebener Ehrfurcht oder getrennt von den Prozessen behandeln, sollten eine engere Integration anstreben.

Geschrieben von
Mike Mason

Mike Mason ist Global Head of Technology bei ThoughtWorks.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: