Technology Radar: Sorgfältige Wahl von Cloud-Features schützt vor Lock-in-Effekt

Die neue Ausgabe des ThoughtWorks-Berichts zeigt Fallstricke auf bei der Auswahl von Werkzeugsammlungen zum Verwalten, Entwickeln und Deployen in der Cloud.

In Pocket speichern vorlesen Druckansicht 8 Kommentare lesen
Lesezeit: 7 Min.
Von
  • Silke Hahn
Inhaltsverzeichnis

Die Softwareberatungsfirma ThoughtWorks hat die 24. Ausgabe ihres Technology Radar veröffentlicht. Das IT-Beratungsunternehmen erstellt den Bericht halbjährlich aus der Projekterfahrung seiner Beraterinnen und Berater, die darin Trends der Softwareentwicklung und weiterer IT-Techniken bewerten und Warnungen sowie Empfehlungen aussprechen. Schwerpunkt der aktuellen Ausgabe ist die zunehmende Menge an Toolpaketen, die zum Verwalten, Entwickeln und Deployment in der Cloud zur Auswahl stehen.

Eine Kernbeobachtung ist, dass Unternehmen bei konsolidierten Toolsets sorgfältig wählen sollten, welche Features der Cloud-Anbieter sie wirklich benötigen und sinnvoll einsetzen können. Für Teams in Entwicklung und Einkauf stellen Werkzeugsammlungen mit beispielsweise Wiki, CI/CD-Pipeline (Continuous Integration/Continuous Delivery), Artefakt-Repositorys und Versionsverwaltung eine zunächst praktische Lösung dar, jedoch sind sie in Summe offenbar "nicht immer die beste Wahl", wie es im Report heißt.

Laut Dr. Rebecca Parsons, CTO bei ThoughtWorks, sind integrierte Toolsets hinsichtlich ihrer meist guten Kompatibilität und dem Zusammenspiel der einzelnen Komponenten durchaus sinnvoll. Fallweise sei ein "Best-of-Breed"-Ansatz allerdings vorzuziehen, damit ein Unternehmen sich die Wahlfreiheit erhält, Workloads weiterhin zwischen Clouds unterschiedlicher Anbieter verschieben zu können. Hier gilt es offenkundig, das Bedürfnis nach Komfort gegen das Risiko eines Lock-in-Effekts sorgfältig abzuwägen. Konkret geht der Technology Radar auf Plattformen wie Azure DevOps und Ökosysteme wie GitHub ein.

Eine weitere Beobachtung betrifft den Trend hin zu "Plattform-Teams", die innerhalb von Unternehmen die Entwicklung einer speziellen Produktplattform als Taskforce leiten und unterstützen. Solche Teams sollen in den Augen der Firmen die Entwicklung von Anwendungen beschleunigen, indem sie Vorgänge weniger komplex machen und rascher zu einer Markteinführung gelangen. Bei diesem Ansatz fallen jedoch auch Schattenseiten auf, da es nach dem sehr rasch erfolgten Livegang oft noch lange dauern kann, bis die Plattform sich etabliert hat und auch einen Mehrwert abwirft. Konzepte der agilen Softwareentwicklung wie beim Product Thinking könnten hier einen Ausweg bieten, indem die Teams nicht gleich lospreschen, sondern zunächst genau klären, welche Funktionen für das Produkt (die zu entwickelnde Plattform) wesentlich sind. Als detaillierter Fall ist hier beispielsweise ein Ticketing-System genannt.

Beständig großes Interesse kommt laut Report der Softwarearchitektur zu, und hier speziell dem sogenannten Coupling (Kopplungsgrad) zwischen Microservices, Komponenten, Gateways, Hubs und dem jeweiligen Frontend. Offenbar ist zurzeit eine stärkere Entkopplung im Trend, wobei jedoch laut ThoughtWorks keine Patentrezepte dafür auszumachen sind. Auch hier empfehlen die Herausgeber eine Entscheidung "von Fall zu Fall" statt generischer Lösungen.

Eine Reihe von Themen gelten außerdem als zu komplex, um im Technology Radar unterzukommen, obwohl sie beständig in den Beratungsgesprächen und Projekten von ThoughtWorks auftauchen. Orchestrierungsrichtlinien für verteilte Architekturen, Branching-Modelle und Monorepos bereiten offenbar zahlreichen Unternehmen wiederkehrend Kopfschmerzen. Klare Empfehlungen kann der Bericht in diesem diffuseren Bereich jedoch nicht aussprechen, da es hier "zu viele Trade-Offs" gebe.

Technology Radar, Ausgabe 24: insgesamt 104 getestete Techniken, Tools, Plattformen und Sprachen/Frameworks

(Bild: ThoughtWorks)

Insgesamt nimmt die aktuelle Ausgabe 104 Objekte unter die Lupe. Am Report mitgewirkt hat ein Advisory Board aus 20 Senior Technologists. Der Radar soll bewusst einen subjektiv-eigensinnigen (opinionated) Leitfaden darstellen und ist untergliedert in die vier Quadranten Techniken, Tools, Plattformen und Languages/Frameworks. Innerhalb jedes Feldes spannen die vier Empfehlungsstufen Adopt, Trial, Assess und Hold den Bogen von starker Befürwortung des Einsatzes (Adopt) hin zu gebotener Vorsicht (Hold). Die Einträge sind darin visuell ausgezeichnet als neu, verändert (auf- beziehungsweise abgestuft) oder unverändert.

Bei den Sprachen und Frameworks schneiden Combine und LeakCanary besonders gut ab, wobei in dem Sektor als Einzigem von keinem der getesteten Frameworks abgeraten wird. Im Mobile-Bereich hat LeakCanary die Berater für die Android-Entwicklung überzeugen können, da es Entwicklungsteams offenbar das zeitaufwendige Troubleshooting auf mehreren Geräten ersparen kann. Combine ist Apples Reactive-Framework, und das ThoughtWorks-Team empfiehlt es als erste Wahl für den Support von iOS 13, da es einfacher zu erlernen sei als RxSwift und mit SwiftUI gut zusammenarbeite. Als Spezialtipp empfiehlt das Board RxCombine für alle, die eine bestehende Anwendung von Rx zu Combine konvertieren möchten. Bei den Plattformen schaut es anders aus, hier rät das Advisory Board zum Ausprobieren von beispielsweise Snowflake, Backstage, Materialize, Delta Lake und dem AWS Cloud Development Kit, während es zu Vorsicht aufruft beim Einsatz von Azure Machine Learning und auch von Eigenentwicklungen im Bereich Infrastructure as Code (IaC) eher abrät (beides "Hold").

Unter den Tools erhält Sentry eine klare Empfehlung als beste Option für das Error Reporting im Frontendbereich. Obwohl es sich dabei um ein SaaS-Angebot handelt (Software as a Service), ist der Quellcode öffentlich einsehbar und lässt sich kostenfrei für kleinere Projekte zum Selbsthosten einsetzen, wie das Advisory Board lobend betont. Die AWS CodePipeline rückt hingegen neuerdings in kritisches Licht: Sobald Teams damit komplexere Pipelines in Angriff nehmen, wird es laut Erfahrungen der ThoughtWorks-Berater ziemlich unhandlich, damit zu arbeiten. Während die AWS CodePipeline beim Einstieg und bei simplen Pipelines noch überzeugt, sollten Teams je nach Projekt genau prüfen, ob komplexere Deployments und Szenarien sowie nicht-triviale Abhängigkeiten mit diesem Tool für sie noch handhabbar sind.

Im Bereich der Techniken erhalten gleich mehrere uneingeschränkt grünes Licht (Adopt), so zum Beispiel Design-Systeme, der Einsatz von Produkt-Teams zum Entwickeln von Plattformen, Continuous Delivery für Machine Learning (CD4ML) und API Expand-Contract. Die "rote Karte" (Hold) zeigen die Sachverständigen hier hingegen GitOps, Ticket-getriebenen Modellen zum Betreiben von Plattformen und (wenig verwunderlich) unterkomplexen Passwortanforderungen, Plattform-Teams mit zu vielen Unterebenen und der getrennten Ownership von Code und Pipeline. Bemerkenswert ist die rote Karte für SAFe (Scaled Agile Framework), das im Enterprise-Bereich laut Gartner meistverwendete Agile-Framework.

Die ThoughtWorks-Experten haben laut Report zahlreiche Unternehmen im organisatorischen Change-Prozess erlebt und sind zu dem Schluss gekommen, dass die SAFe-Prozesse überstandardisiert seien und Reibungen in der Unternehmensstruktur verursachen können. Offenbar betont SAFe hier Silos eher als dass es sie abbauen würde, Top-Down-Strukturen würden die Wertschöpfung schwächen, Kreativität lähmen und Entwickler frustrieren. Statt sich mit genormten Zeremonien aufzuhalten, empfiehlt ThoughtWorks einen schlankeren, Wert-getriebenen Zugang, um die Interaktion von Teams untereinander zu verbessern. Als mögliche Alternative nennt der Report EDGE und team cognitive load.

Wer sich eingehender mit den beobachteten Trends auseinandersetzen will und die genauen Hintergründe der jeweiligen Einstufungen erfahren möchte, kann auf den vollständigen Bericht zugreifen: Die aktuelle Ausgabe des Technology Radar steht auf der Website von ThoughtWorks bereit – als interaktive Version (englisch) und zum PDF-Download in den Sprachen Englisch, Spanisch, Portugiesisch und Japanisch.

(sih)