Macro-Trends in der Technologiebranche | Nov 2018

Zweimal jährlich äußern wir im Rahmen des Thoughtworks Technology Radar unsere Ansichten zu Entwicklungen in der Welt der Unternehmenstechnologie. Wir befassen uns ausführlich mit Tools, Techniken, Sprachen und Plattformen und gehen in der Regel auf über hundert einzelne Radarsignale, sogenannte „Blips“, auf dem Radar ein. Darüber hinaus schreiben wir über eine Handvoll übergreifender Themen, damit der Leser leichter den Überblick behält. In meinem Beitrag möchte ich nicht nur die Radarthemen ansprechen, sondern auch breitere Entwicklungen in der heutigen Technologiebranche. Die Artikel über „Macro-Trends“ sind nur mit Unterstützung der großen Technologiegemeinschaft bei Thoughtworks möglich. Daher möchte ich allen danken, die Ideen eingebracht und Entwürfe kommentiert haben.

An der Schwelle zum Quantencomputing

Die Dynamik auf dem Gebiet des Quantencomputings ist weiterhin spürbar. Forschungseinrichtungen und Unternehmen arbeiten partnerschaftlich zusammen, große Investitionen werden getätigt, und es entsteht eine Gemeinschaft von Start-ups und Universitäts-Spin-offs. Mit der Programmiersprache Q# von Microsoft können sich Entwickler in das Quantencomputing einarbeiten und nicht nur Algorithmen auf simulierten Computern laufen lassen, sondern auch Einblicke in echte Cloud-basierte Quantencomputer gewinnen. Das Alternativangebot von IBM heißt IBM Q, und auch hier gibt es Partnerschaften mit Unternehmen, Hochschulen und Start-ups. Auf lokaler Ebene haben wir Hack-Abende zum Thema Quantencomputing veranstaltet, die in der Community sehr großen Anklang fanden. Quantencomputer sind jedoch noch nicht bereit für die breite Anwendung.

Der größte aktuell verfügbare (nicht klassifizierte) Quantencomputer ist klein: Er verfügt gerade einmal über 72 Qubit. Wenn man den Schlagzeilen glauben darf, sind konventionelle Verschlüsselungsmethoden dem Untergang geweiht. Allerdings erfordern 2048-Bit-RSA-Schlüssel einen Quantencomputer mit mindestens 6000 Qubit, und moderne Algorithmen wie AES schützen vermutlich besser vor Angriffen von Quantencomputern. Ein kommerzieller Quantencomputer benötigt schätzungsweise mindestens 100 Qubit. Zudem müssen die Stabilität und die Fehlerbehebung gegenüber dem heutigen Stand verbessert werden. Praktische Anwendungen des Quantencomputings sind noch Gegenstand von Forschungsprojekten, beispielsweise die Modellierung der Eigenschaften komplexer Moleküle in der Chemie. Bis das Quantencomputing in Unternehmen zur Mainstream-Technologie wird, ist es wohl noch ein weiter Weg.

Beschleunigter Wandel

Schon oft haben wir beobachtet, dass der technologische Wandel nicht nur schnell, sondern immer schneller erfolgt. Als wir vor zehn Jahren mit dem Technology Radar begannen, blieben die Radarsignale (Blips) standardmäßig in mindestens zwei Radarausgaben (etwa ein Jahr) unverändert verzeichnet und verschwanden dann automatisch wieder. Entsprechend der Formel in einem unserer Radarthemen – Tempo = Strecke / Zeit – nimmt das Tempo des Wandels im Ökosystem der Softwareentwicklung jedoch zu. Die Zeit ist konstant geblieben (wir erstellen den Radar immer noch zweimal jährlich), allerdings wird bei der technologischen Innovation eine wesentlich weitere Strecke zurückgelegt. Dies ist ein weiterer Beweis dafür, was dem aufmerksamen Beobachter ohnehin schon klar ist: Das Tempo des technologischen Wandels zieht an. Alle vier Quadranten im Radar verändern sich schneller, und unsere Kunden greifen neue und unterschiedliche Technologien schneller auf. Da die Technologie mittlerweile in fast alle Bereiche des wirtschaftlichen, politischen und gesellschaftlichen Lebens Einzug gehalten hat, beschleunigt sich der Wandel auch in diesen anderen Bereichen. Als wichtige Konsequenz bleibt Unternehmen weitaus weniger Zeit, um neue Technologien und Geschäftsmodelle einzuführen. Der Leitgedanke lautet zwar immer noch „Anpassung oder Untergang“, der Druck ist jedoch höher denn je.

Keine Wettbewerbsfähigkeit ohne kontinuierliche Modernisierung

Dass ältere Technologie aufgerüstet oder ersetzt werden muss, ist nichts Neues. Seit es Computer gibt, ist stets ein neues Modell in Planung oder in greifbarer Nähe. Allerdings gewinnt man den Eindruck, dass der Modernisierungsdruck erheblich zugenommen hat. Unternehmen müssen schnell reagieren, was aber nicht möglich ist, wenn ihre veraltete Technologielandschaft sie ausbremst. Moderne Unternehmen konkurrieren um die höchste Kundenzufriedenheit. Markenbindung spielt kaum noch eine Rolle, und die Schnellsten haben meist die Nase vorn. Alle Unternehmen sind betroffen – sogar die Großen im Silicon Valley und die jungen Start-ups. Denn sobald etwas produziert wird, ist die Technologie auch schon wieder veraltet und kein Gewinn mehr, sondern ein Hemmschuh. Der Erfolg dieser Unternehmen beruht darauf, ihre Technologien und Plattformen laufend zu modernisieren und zu optimieren.

Mein Kollege George Earle und ich haben kürzlich in einer zweiteiligen Serie die Notwendigkeit einer Modernisierung sowie deren Planung dargelegt.

Branche bestätigt frühere bedeutende Entwicklungen    

Uns war von Anfang an klar, dass es ohne Container (insbesondere Docker) und Containerplattformen (insbesondere Kubernetes) nicht geht. In einem früheren Radar haben wir Kubernetes zum Sieger und zur modernen, empfehlenswerten Plattform gekürt; die Branche scheint dies nun zu bestätigen. Diese Radarausgabe enthält eine phänomenale Anzahl Kubernetes-bezogener Radarsignale: Knative, gVisor, Rook, SPIFFE, kube-bench, Jaeger, Pulumi, Heptio Ark und acs-engine, um nur einige zu nennen. All diese Tools unterstützen das Kubernetes-Ökosystem, Konfigurations-Scanning, Sicherheitsprüfungen, Disaster Recovery usw. Sie erleichtern uns den Aufbau zuverlässiger Cluster.

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:

• Recreating ESB antipatterns with Kafka — bei diesem „Spaghetticode“ wird eine einwandfreie Technologie (Kafka) für Zentralisierungs- oder Effizienzzwecke missbraucht.
• 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.

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.

Cloud bleibt ein wichtiges Thema

Eines unserer aktuellen Radarthemen ist die erstaunliche „Hartnäckigkeit“ von Cloud-Anbietern, die im engen Wettbewerb um weitere Hosting-Geschäfte oft Funktionen und Services ergänzen, um ihr Produkt 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.
 
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 in der 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.

Damit sind wir am Ende dieser Ausgabe zu den Macro-Trends. 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. Schauen Sie rein!