ThoughtWorks Technology Radar November 2018

Quantencomputer, Kubernetes und weitere Makrotrends

Seite: 2/2

Firmen zum Thema

Um die JavaScript-Community ist es still geworden

Schon früher haben wir über das nachlassende Interesse am JavaScript-Ökosystem berichtet. Die Community scheint nach einer rasanten Wachstumsphase in ruhigeres Fahrwasser gelangt zu sein. Unsere Kontakte im Verlagswesen melden uns, dass die Suche nach JavaScript-Inhalten einem Interesse an verschiedenen Sprachen gewichen ist, allen voran Go, Rust, Kotlin und Python.

Ist vielleicht Atwoods Gesetz eingetreten – alles, was in JavaScript geschrieben werden kann, wurde bereits in JavaScript geschrieben –, und die Entwickler haben sich neuen Sprachen zugewandt? Dies könnte auch eine Folge der immer beliebteren Microservices sein, die einen mehrsprachigen Ansatz ermöglichen, sodass Entwickler ausprobieren können, welche Sprache für die jeweilige Komponente am besten ist. Jedenfalls ist JavaScript in dieser Radarausgabe weit weniger vertreten.

Langlebige Anti-Pattern in Unternehmen

In dieser Radarausgabe beziehen sich viele unserer „Hold“-Empfehlungen auf irrige Annahmen beim Aufbau von Unternehmenssystemen. Wir setzen neue Tools und Plattformen ein, neigen aber dazu, immer wieder die gleichen Fehler zu machen. Hier einige Beispiele:

  • Overambitious API gateways: Einer mustergültigen Technologie für Zugriffsmanagement und Ratenbegrenzung von APIs wird eine Transformations- und Geschäftslogik hinzugefügt.
  • Data-hungry packages: Wir erwerben ein Softwarepaket für einen bestimmten Zweck. Am Ende steuert es jedoch unser Unternehmen, weil es immer „datenhungriger“ wird und schließlich alles beherrscht. Gleichzeitig erfordert es einen hohen Integrationsaufwand.

Manche Dinge ändern sich einfach nicht. Wir machen Fehler, weil diese Technologien uns oftmals ein Patentrezept zur Lösung unserer Probleme in Aussicht stellen. MDM, ESBs und Paketsoftware sind allesamt vielversprechend, aber letzten Endes muss jedes Unternehmen die Balance zwischen Integration und Isolation finden, ein gutes Design entwickeln und sich im Vorfeld genügend Gedanken machen.

Unternehmen müssen sich an das Gesetz von Conway halten und sicherstellen, dass die Kommunikation zwischen den Teams so funktioniert, dass Probleme gelöst und Funktionen geliefert werden. Mit neuen Tools, Plattformen und Funktionen lösen wir Probleme zwar anders, lösen müssen wir sie aber immer noch. Es gibt keine Patentrezepte.

Cloud bleibt ein wichtiges Thema

Eines unserer aktuellen Radarthemen ist die erstaunliche „Hartnäckigkeit“ von Cloud-Anbietern. Diese haben es im engen Wettbewerb um weitere Hosting-Geschäfte perfektioniert, ihr Produkt um weitere Funktionen und Services zu ergänzen und so noch attraktiver zu gestalten.

Diese anbieterspezifischen Funktionen können einerseits zu einer unvorhergesehenen Abhängigkeit führen, beschleunigen aber andererseits die Bereitstellung und sind somit ein zweischneidiges Schwert. Wie immer empfehlen wir, sorgfältig abzuwägen und Anwendungsfälle, eine mögliche Abhängigkeit sowie die Kosten und Auswirkungen eines Anbieterwechsels zu bewerten.

Immer mehr Unternehmen wechseln erfolgreich in die public Cloud und zeigen in sachkundigen Gesprächen, dass sie verstehen, was das bedeutet. Größere Unternehmen – sogar Banken und andere regulierte Branchen – verlagern umfangreichere und sensiblere Workloads in die Cloud, und die betreffenden Regulierungsbehörden folgen ihnen.

In einigen Fällen bedeutet dies, dass sie eine Multi-Cloud-Strategie für diese beträchtlichen Workloads verfolgen müssen. Viele Blips im aktuellen Radar – Multi-Cloud-Fähigkeit, Finanzsympathie usw. – deuten darauf hin, dass die Cloud mittlerweile für alle Unternehmen selbstverständlich geworden ist und das lange Ende der Migration hier liegt.

Serverless Computing zunehmend im Trend, aber (noch) kein Erfolgsgarant

„Serverlose“ Architekturen sind derzeit einer der Haupttrends in der IT-Welt, werden vielleicht aber auch am häufigsten falsch verstanden. In dieser Radarausgabe heben wir keine Blips für serverlose Technologien hervor, weil – anders als in der Vergangenheit – nichts wirklich überzeugt hat. Das bedeutet allerdings nicht, dass sich in der serverlosen Welt nichts bewegt.

Amazon veröffentlichte kürzlich SLAs für Lambda, was für Amazon Web Services (AWS) ungewöhnlich ist, und fast alles auf der AWS-Plattform ist in irgendeiner Form mit Lambda verbunden. Andere größere Cloud-Anbieter bieten konkurrierende (aber ähnliche) Services an und reagieren in der Regel sofort auf entsprechende Maßnahmen von Amazon.

Kritisch wird es, wenn ein Unternehmen einfach davon ausgeht, dass seine Workload für serverlose Technologien geeignet ist und sich keine Gedanken darüber macht, was günstiger ist: eine funktionsbasierte Nutzung oder die Einrichtung und Wartung einer eigenen Serverinstanz. Unserer Ansicht nach muss das Serverless Computing in zwei Kernbereichen ausgereifter werden:

  • Einsatzgebiete: Architektur- und Workload-Modelle, bei denen die richtige Herangehensweise unklar ist. Es muss besser verstanden werden, wie eine Anwendung aus serverlosen Komponenten erstellt wird und wie es sich mit Containern und virtuellen Maschinen verhält.
  • Preismodell: Unzureichendes Verständnis und schwierige Abstimmung machen die Angelegenheit kostspielig und nur begrenzt anwendbar. Idealerweise sollten die Total Cost of Ownership (einschließlich Posten wie DevOps-Entwicklungszeit, Serverwartung usw.) verglichen werden.

Serverless Computing befindet sich just in jener Phase des Adopt-Lebenszyklus, in der wir es erwarten würden: Es verspricht eine neue Technologie, verzeichnete sowohl beachtliche Erfolge als auch einige Misserfolge und die zugehörigen Methoden und Tools entwickeln sich sprunghaft weiter. Architekten sollten den serverlosen Ansatz definitiv in ihrem Werkzeugkasten haben.

Softwareentwicklung zur Fehlerdiagnostik

In der Vergangenheit haben wir auf die Test-Tools der Simian Army von Netflix aufmerksam gemacht, die Ausfälle in einem Produktivsystem simulieren. Diese simulierten Angriffe sollen eine fehlertolerante Architektur sicherstellen. Ein solches Chaos Engineering setzt sich immer mehr durch und wurde auf verwandte Bereiche ausgedehnt. In diesem Radar heben wir das 1-%-Canary-Release und das Security Chaos Engineering als besondere Instanzen der Fehlerdiagnostik hervor.

Dauerhafte erprobte Methoden

Erfreulicherweise bestehen erprobte Methoden als positiver Gegenpol zu den Problemen mit langlebigen Anti-Pattern in der Branche fort. Wenn eine neue Technologie aufkommt, probieren wir sie aus und untersuchen, wofür sie sich am besten eignet, was sie kann und wo ihre Grenzen liegen.

Ein gutes Beispiel dafür ist die jüngste Nachfrage nach Data und Machine Learning. Nachdem wir die neue Technologie getestet haben und ihre Stärken und Schwächen kennen, müssen wir die anerkannten Regeln der Technik darauf anwenden Im Fall von Machine Learning empfehlen wir Continuous Intelligence – eine Kombination aus Methoden für automatisierte Tests und Continuous Delivery.

Der springende Punkt ist, dass sämtliche Methoden, die wir im Laufe der Jahre zur Softwareerstellung entwickelt haben, durchaus auch auf all die neuen Technologien anwendbar sind. Ganz gleich, wie sich die zugrunde liegende Technologie ändert: Softwareentwickler müssen nach wie vor ihr Handwerk verstehen.

Mike Mason
Mike Mason
(Bild: ThoughtWorks)

Damit sind wir am Ende dieser Ausgabe zu den Makrotrends. Wenn Ihnen diese Erläuterungen gefallen haben, interessieren Sie sich vielleicht auch für unsere neue Podcast-Serie, die von mir und einigen Kollegen bei ThoughtWorks gehostet wird. Alle zwei Wochen veröffentlichen wir einen Podcast zu Themen wie Agile Data Science, verteilte Systeme, Continuous Intelligence und IoT.

Mike Mason ist Global Head of Technology bei ThoughtWorks.

(ID:45634333)