Hinweis.: Dieser Artikel, ein Hit auf Medium, ist eine Übersicht über die wichtigsten (von 2010 bis 2019) Veränderungen in der Welt der Programmiersprachen und der dazugehörigen Technologiekecosysteme, wobei besonderes Augenmerk auf Docker und Kubernetes gelegt wird. Der ursprüngliche Autor ist Cindy Sridharan, die sich auf Entwicklerwerkzeuge und verteilte Systeme spezialisiert hat — insbesondere hat sie das Buch „Distributed Systems Observability“ geschrieben — und in der Online-Welt unter IT-Experten recht bekannt ist, insbesondere bei denen, die sich für cloud native Themen interessieren.
Das Jahr 2019 ist zu Ende gegangen, und ich möchte meine Gedanken zu einigen der bedeutendsten technologischen Errungenschaften und Innovationen des letzten Jahrzehnts teilen. Außerdem werde ich versuchen, einen Blick in die Zukunft zu werfen und die Hauptprobleme sowie Chancen des kommenden Jahrzehnts zu skizzieren.
Ich möchte gleich klarstellen, dass ich in diesem Artikel keine Veränderungen in Bereichen wie der Datenwissenschaft (data science), künstlicher Intelligenz, Frontend-Engineering usw. behandle, da ich persönlich nicht über genügend Erfahrung in diesen Bereichen verfüge.
Typisierung schlägt zurück
Eine der positivsten Tendenzen der 2010er Jahre war die Wiederbelebung statisch typisierter Sprachen. Dennoch sind solche Sprachen nie wirklich verschwunden (C++ und Java sind heute gefragt; sie dominierten auch vor zehn Jahren), jedoch erlebten dynamisch typisierte Sprachen (dynamische Sprachen) nach dem Aufkommen der Ruby on Rails-Bewegung im Jahr 2005 einen erheblichen Anstieg an Beliebtheit. Dieser Anstieg erreichte 2009 mit der Veröffentlichung des Quellcodes von Node.js seinen Höhepunkt, wodurch JavaScript-Server zur Realität wurde.
Im Laufe der Zeit haben dynamische Sprachen einen Teil ihrer Attraktivität für die Entwicklung von Server-Software verloren. Die Sprache Go, die während der Container-Revolution popularisiert wurde, schien besser geeignet zu sein, hochleistungsfähige, ressourcenschonende Server mit paralleler Datenverarbeitung zu erstellen (was Schöpfer von Node.js selbst bestätigt).
Rust, das 2010 vorgestellt wurde, hat Erkenntnisse aus der in dem Versuch, eine sichere und typisierte Sprache zu werden. In der ersten Hälfte des Jahrzehnts war die Einstellung zur Programmiersprache Rust in der Branche eher kühl, jedoch stieg ihre Popularität in der zweiten Hälfte erheblich an. Zu den bemerkenswerten Anwendungen von Rust gehören , (darüber haben wir berichtet in — Anmerkung des Übersetzers)., einem frühen WebAssembly-Compiler von Fastly (jetzt Teil von bytecodealliance) und anderen. Angesichts der Tatsache, dass Microsoft in Erwägung zieht, Teile des Windows-Betriebssystems in Rust neu zu schreiben, kann man mit Sicherheit sagen, dass die Zukunft dieser Sprache in den 2020er Jahren vielversprechend aussieht.
Sogar dynamische Sprachen haben neue Möglichkeiten wie (optional types). Diese wurden erstmals in TypeScript implementiert – einer Sprache, die typisierten Code erstellt und in JavaScript kompiliert. PHP, Ruby und Python haben eigene Systeme für optionale Typisierung erhalten (, ), die erfolgreich in .
Die Rückkehr von SQL zu NoSQL
NoSQL ist eine weitere Technologie, die zu Beginn des Jahrzehnts wesentlich beliebter war als am Ende. Ich denke, dafür gibt es zwei Gründe.
Erstens ist das NoSQL-Modell ohne Schema, Transaktionen und mit schwächeren Konsistenzgarantien schwieriger umzusetzen als das SQL-Modell. In mit dem Titel „Warum man strenge Konsistenz wann immer möglich bevorzugen sollte“ (Why you should pick strong consistency, whenever possible) schreibt Google:
Eine der Erkenntnisse, die wir bei Google gewonnen haben, ist, dass der Anwendungscode einfacher ist und die Entwicklungszeiten kürzer sind, wenn Ingenieure sich auf bestehende Speicher verlassen können, um komplexe Transaktionen zu verarbeiten und die Ordnung der Daten aufrechtzuerhalten. Um die ursprüngliche Dokumentation zu Spanner zu zitieren: „Wir glauben, dass es besser ist, wenn Programmierer sich mit Anwendungsleistungsproblemen aufgrund von Missbrauch von Transaktionen befassen, wenn Engpässe auftreten, als dass sie ständig im Hinterkopf behalten müssen, dass es keine Transaktionen gibt.“
Ein weiterer Grund hängt mit dem Aufstieg von „skalierbaren“ verteilten SQL-Datenbanken (wie und ) im öffentlichen Cloudraum sowie Open Source-Alternativen wie CockroachDB (über die wir ebenfalls — Anm. d. Red.), die viele der technischen Probleme lösen, aufgrund derer traditionelle SQL-Datenbanken "nicht skalierten". Selbst MongoDB, einst das Symbol der NoSQL-Bewegung, ist nun verteilte Transaktionen.
In Situationen, die Atomarität bei Lese- und Schreiboperationen über mehrere Dokumente (in einer oder mehreren Sammlungen) erfordern, unterstützt MongoDB Transaktionen über mehrere Dokumente. Bei verteilten Transaktionen können Transaktionen für viele Operationen, Sammlungen, Datenbanken, Dokumente und Shards verwendet werden.
Totale Strimifizierung
Apache Kafka ist ohne Zweifel eine der wichtigsten Erfindungen des vergangenen Jahrzehnts. Sein Quellcode wurde im Januar 2011 veröffentlicht, und in diesen Jahren hat Kafka eine echte Revolution in der Arbeit mit Daten bewirkt. Kafka wurde in allen Unternehmen eingesetzt, in denen ich gearbeitet habe, von Start-ups bis hin zu großen Konzernen. Die gewährten Garantien und Einsatzmöglichkeiten (Pub-Sub, Streams, ereignisorientierteArchitekturen) kommen in verschiedenen Aufgabenbereichen zum Tragen: von der Datenorganisation bis hin zu Monitoring und Streaming-Analytik, die in vielen Bereichen gefragt sind, wie Finanzen, Gesundheitswesen, öffentlicher Sektor, Einzelhandel usw.
Kontinuierliche Integration (und in geringerem Maße kontinuierliches Deployment)
Kontinuierliche Integration (Continuous Integration) gibt es nicht erst seit den letzten 10 Jahren, jedoch hat sie in der letzten Dekade so stark an Verbreitung gewonnen, dass sie Teil des Standardarbeitsprozesses geworden ist (Tests auf allen Pull-Requests). Die Etablierung von GitHub als Plattform für die Entwicklung und Speicherung von Code und, noch wichtiger, die Entwicklung eines auf bedeutet, dass das Durchführen von Tests vor der Annahme eines Pull Requests in das Master-Branch ein die einzige Workflow in der Entwicklung ist, der Ingenieuren vertraut ist, die ihre Karrieren in den letzten zehn Jahren begonnen haben.
Kontinuierliches Deployment (Continuous Deployment; die Bereitstellung jedes Commits genau dann, wenn er ins Master-Branch gelangt) ist nicht so weit verbreitet wie kontinuierliche Integration. Dennoch, mit einer Vielzahl von Cloud-APIs für die Bereitstellung, der wachsenden Beliebtheit von Plattformen wie Kubernetes (die einen standardisierten API für Bereitstellungen bieten) und der Entstehung von Multi-Plattform- und Multi-Cloud-Tools wie Spinnaker (die auf den genannten standardisierten APIs basieren), sind die Bereitstellungsprozesse automatisierter, geordneter und insgesamt sicherer geworden.
Container
Container können wohl als die angesagteste, am meisten diskutierte, beworbene und missverstandene Technologie der 2010er Jahre bezeichnet werden. Andererseits ist es eine der wichtigsten Innovationen des vergangenen Jahrzehnts. Teilweise liegt der Grund für dieses ganze Wirrwarr in den gemischten Signalen, die wir praktisch aus allen Richtungen erhalten haben. Jetzt, wo das Aufsehen etwas abgeklungen ist, haben einige Aspekte deutlichere Konturen angenommen.
Container wurden nicht populär, weil sie der beste Weg sind, eine Anwendung zu starten, der den Anforderungen der globalen Entwicklergemeinschaft gerecht wird. Container wurden populär, weil sie geschickt in die Marketingnachfrage nach einem Werkzeug passten, das ein ganz anderes Problem löst. Docker hat sich als fantastisches Werkzeug für die Entwicklung erwiesen, das ein dringendes Kompatibilitätsproblem löst ("läuft auf meinem Rechner").
Genauer gesagt, hat es eine Revolution ausgelöst. ein Docker-Image, da es das Problem der Parität zwischen Umgebungen gelöst hat und nicht nur die tatsächliche Portabilität der Anwendungsdatei, sondern auch aller ihrer Software- und Betriebssystemabhängigkeiten gewährleistet. Die Tatsache, dass dieses Tool irgendwie die Popularität von „Containern“ angeheizt hat, die im Grunde genommen eine sehr niedrigschwellige Implementierungsdetails darstellen, bleibt für mich wohl das größte Rätsel des vergangenen Jahrzehnts.
Serverless
Ich wette, dass die Einführung von „serverlosen“ Berechnungen sogar wichtiger ist als die von Containern, denn sie ermöglicht tatsächlich die Verwirklichung des Traums von Berechnungen auf Anfrage. (on-demand). In den letzten fünf Jahren habe ich eine schrittweise Ausweitung der Anwendungen des serverlosen Ansatzes beobachtet (Unterstützung neuer Sprachen und Laufzeitumgebungen wurde hinzugefügt). Die Entstehung von Produkten wie Azure Durable Functions scheint ein richtiger Schritt auf dem Weg zur Implementierung von zustandsbehafteten Funktionen zu sein (gleichzeitig werden , die mit den Einschränkungen von FaaS verbunden sind, gelöst). Ich werde mit Interesse verfolgen, wie sich dieses neue Paradigma in den kommenden Jahren entwickeln wird.
Automatisierung
Vielleicht hat die Gemeinschaft der Betriebsingenieure am meisten von diesem Trend profitiert, da er die Umsetzung von Konzepten wie "Infrastruktur als Code" (IaC) ermöglichte. Darüber hinaus fiel die Leidenschaft für Automatisierung mit dem Anstieg der "SRE-Kultur" zusammen, deren Ziel ein stärker programmorientierter Ansatz für den Betrieb ist.
Allgemeine APIifizierung
Ein weiteres interessantes Merkmal des vergangenen Jahrzehnts war die APIifizierung verschiedener Entwicklungsaufgaben. Gute, flexible APIs ermöglichen es Entwicklern, innovative Arbeitsabläufe und Tools zu schaffen, die wiederum bei der Wartung helfen und die Benutzerfreundlichkeit erhöhen.
Darüber hinaus ist die APIifizierung der erste Schritt zur SaaSifizierung bestimmter Funktionen oder Tools. Dieser Trend fiel auch mit der zunehmenden Beliebtheit von Mikroservices zusammen: SaaS wurde einfach zu einem weiteren Dienst, der über APIs genutzt werden kann. Derzeit gibt es zahlreiche SaaS- und FOSS-Tools in Bereichen wie Monitoring, Zahlungen, Lastverteilung, Continuous Integration, Benachrichtigungen und Funktionsschaltung. (feature flagging), CDN, Traffic Engineering (z.B. DNS) usw., die im letzten Jahrzehnt florierten.
Beobachtbarkeit
Es ist erwähnenswert, dass uns heute deutlich fortschrittlichere Werkzeuge zur Überwachung und Diagnose des Anwendungsverhaltens zur Verfügung stehen als je zuvor. Das Überwachungssystem Prometheus, das 2015 Open Source wurde, kann als das beste Überwachungssystem bezeichnet werden, mit dem ich je gearbeitet habe. Es ist nicht perfekt, jedoch sind viele Aspekte darin auf äußerst angemessene Weise umgesetzt (z.B. Unterstützung für Messungen [dimensionality] bei Metriken).
Distributed Tracing ist eine weitere Technologie, die dank Initiativen wie OpenTracing (und ihrem Nachfolger OpenTelemetry) in den 2010er Jahren mainstream wurde. Obwohl das Tracing nach wie vor recht kompliziert in der Anwendung ist, lassen einige der neuesten Entwicklungen hoffen, dass wir in den 2020er Jahren ihr wahres Potenzial entfalten werden. (Anm. d. Übs.: Lesen Sie auch in unserem Blog die Übersetzung des Artikels „“ desselben Autors.)
Einen Blick in die Zukunft werfen
Leider gibt es viele Herausforderungen, die im kommenden Jahrzehnt darauf warten, gelöst zu werden. Hier sind meine Gedanken dazu und einige potenzielle Ideen, wie man sie angehen kann.
Die Lösung des Problems des Mooreschen Gesetzes
Das Ende des Dennard-Skalierungsgesetzes und das Abweichen vom Mooreschen Gesetz erfordern neue Innovationen. John Hennessy erklärt in warum problemabhängige (domain specific) Architekturen wie TPU eine der Lösungen für das Abweichen vom Mooreschen Gesetz sein könnten. Werkzeuge wie von Google stellen bereits einen vielversprechenden Schritt in diese Richtung dar:
Compiler sollten neue Anwendungen unterstützen, die sich leicht auf neue Hardware portieren lassen, und viele Abstraktionsstufen verbinden, von dynamischen, verwalteten Sprachen bis hin zu Vektorbeschleunigern und softwaregesteuerten Speichergeräten. Gleichzeitig müssen sie hochentwickelte Schalter für die automatische Anpassung bereitstellen, Just-in-Time-Funktionalität bieten und Diagnose sowie Debugging-Informationen über den Betrieb und die Leistungssysteme im gesamten Stack verteilen. Dabei sollte die Leistung in den meisten Fällen nahe an der von handgeschriebenem Assembler liegen. Wir beabsichtigen, unsere Vision, Fortschritte und Pläne zur Entwicklung und öffentlichen Verfügbarkeit einer solchen Compiler-Infrastruktur zu teilen.
CI/CD
Obwohl das Wachstum der CI-Popularität zu einem der Haupttrends der 2010er Jahre geworden ist, bleibt Jenkins der Goldstandard für CI.
Dieser Bereich benötigt dringend Innovationen in folgenden Bereichen:
- Benutzeroberfläche (DSL zum Codieren von Testspezifikationen);
- Implementierungsdetails, die es wirklich skalierbar und schnell machen;
- Integration in verschiedene Umgebungen (Staging, Prod usw.) für fortgeschrittenere Testformen;
- kontinuierliche Überprüfung und Bereitstellung.
Entwickler-Tools
Als Branche haben wir begonnen, immer komplexere und beeindruckendere Software zu erstellen. Doch wenn es um unsere eigenen Tools geht, kann man sagen, dass es deutlich besser sein könnte.
Gemeinsames und remote (über SSH) Bearbeiten hat an Popularität gewonnen, hat sich jedoch nicht als neuer Standard in der Entwicklung etabliert. Wenn Sie, wie ich, die Idee ablehnen, die Notwendigkeit einer ständigen Internetverbindung nur um programmieren zu können, wird die Arbeit über SSH auf einem entfernten Rechner wahrscheinlich nicht für Sie geeignet sein.
Lokale Entwicklungsumgebungen, insbesondere für Ingenieure, die an großen serviceorientierten Architekturen arbeiten, stellen nach wie vor eine Herausforderung dar. Einige Projekte bemühen sich um Lösungen, und ich würde gerne erfahren, wie eine möglichst benutzerfreundliche UX für dieses Nutzungsszenario aussehen könnte.
Es wäre auch interessant, das Konzept der "tragbaren Umgebungen" auf andere Bereiche der Softwareentwicklung auszuweiten, wie zum Beispiel das Reproduzieren von Fehlern (oder ), die unter bestimmten Bedingungen oder mit spezifischen Einstellungen auftreten.
Ich würde auch gerne mehr Innovationen in Bereichen wie semantische und kontextabhängige Code-Suche, Werkzeuge zur Verknüpfung von Vorfällen in der Produktion mit bestimmten Teilen der Codebasis usw. sehen.
Berechnungen (die Zukunft von PaaS)
Vor dem Hintergrund des allgemeinen Hypes um Container und serverless Lösungen in den 2010er Jahren hat sich die Palette der Angebote im öffentlichen Cloud-Bereich in den letzten Jahren erheblich erweitert.
In diesem Zusammenhang stellen sich einige interessante Fragen. Vor allem wächst die Liste der verfügbaren Optionen in der öffentlichen Cloud ständig. Cloud-Anbieter verfügen über Personal und Ressourcen, um problemlos mit den neuesten Entwicklungen in der Open-Source-Welt Schritt zu halten und Produkte wie „serverless Pods“ herauszubringen (ich vermute, sie machen einfach ihre eigenen FaaS-Runtimes kompatibel mit OCI) oder andere ähnliche interessante Produkte.
Diejenigen, die diese Cloud-Lösungen nutzen, können nur beneidet werden. Theoretisch bieten die Cloud-Angebote von Kubernetes (GKE, EKS, EKS auf Fargate usw.) Anbieter-unabhängige APIs zum Ausführen von Arbeitslasten. Wenn Sie ähnliche Produkte verwenden (ECS, Fargate, Google Cloud Run usw.), nutzen Sie wahrscheinlich bereits die interessantesten Funktionen, die der Dienstanbieter bietet. Darüber hinaus wird die Migration bei neuen Produkten oder Rechenparadigmen wahrscheinlich einfach und sorgenfrei sein.
Angesichts der rasanten Entwicklung in diesem Bereich wäre ich sehr überrascht, wenn in naher Zukunft nicht ein oder zwei neue Optionen auftauchen. Kleineren „Plattform“-Teams (Teams, die mit Infrastruktur arbeiten und für die Schaffung von On-Premise-Plattformen zum Hosting von Arbeitslasten in Unternehmen verantwortlich sind) wird es unglaublich schwerfallen, in Bezug auf Funktionalitäten, Benutzerfreundlichkeit und Gesamtnetzwerkzuverlässigkeit mitzuhalten. Die 2010er Jahre standen im Zeichen von Kubernetes als Tool zur Erstellung von PaaS (Platform as a Service), daher scheint es mir völlig sinnlos, eine interne Plattform auf Basis von Kubernetes zu entwickeln, die dieselben Auswahlmöglichkeiten, Einfachheit und Freiheit bietet, die in der Öffentlichkeit verfügbaren Cloud-Umgebungen zur Verfügung stehen. Die Vorstellung einer auf „Containern“ basierenden PaaS als „Kubernetes-Strategie“ ist gleichbedeutend mit einem absichtlichen Verzicht auf die innovativsten Möglichkeiten der Cloud.
Wenn man sich die verfügbaren heute Wenn man die Rechenleistung betrachtet, wird deutlich, dass die Erstellung einer eigenen PaaS ausschließlich auf Basis von Kubernetes gleichbedeutend ist mit dem selbstauferlegten Gehörntwerden (nicht besonders vorausschauender Ansatz, oder?). Selbst wenn jemand heute beschließt, eine Container-PaaS auf Kubernetes-Basis zu erstellen, wird sie in ein paar Jahren im Vergleich zu den Cloud-Möglichkeiten veraltet erscheinen. Obwohl Kubernetes ursprünglich als Open-Source-Projekt begann, ist es von einem entsprechenden internen Werkzeug von Google inspiriert und entwickelt worden. Es wurde ursprünglich in den frühen/mittleren 2000er Jahren entwickelt, als die Rechnerlandschaft ganz anders war.
Darüber hinaus sollten Unternehmen im weitesten Sinne keine Experten im Umgang mit Kubernetes-Clustern werden, ebenso wenig, wie sie eigene Rechenzentren aufbauen und warten. Die Bereitstellung einer zuverlässigen Rechenbasis ist die Hauptaufgabe der Cloud-Anbieter.
Schließlich habe ich das Gefühl, dass wir als Branche in Bezug auf das Nutzererlebnis etwas zurückgefallen sind. (). Heroku wurde 2007 gegründet und ist bis heute eine der benutzerfreundlichsten Plattformen. Es steht außer Frage, dass Kubernetes viel mehr Leistung, Skalierbarkeit und Programmierbarkeit bietet, aber ich vermisse, wie einfach es war, mit Heroku zu starten und ein Deployment durchzuführen. Um diese Plattform zu nutzen, muss man lediglich Git kennen.
Das führt mich zu der nächsten Schlussfolgerung: Wir benötigen die besten, höherwertigen Abstraktionen (insbesondere gilt dies für Abstraktionen der höchsten Ebene).
Die richtige API der höchsten Ebene
Docker ist ein ausgezeichnetes Beispiel für die Notwendigkeit einer besseren Aufgabentrennung bei gleichzeitiger richtiger Implementierung der API der höchsten Ebene..
Das Problem mit Docker ist, dass (zumindest ursprünglich) die Ziele für das Projekt zu global gesteckt wurden: alles, um das Kompatibilitätsproblem („läuft auf meinem Rechner“) mit Hilfe von Container-Technologie zu lösen. Docker war sowohl ein Image-Format als auch ein Runtime mit eigenem virtuellen Netzwerk, ein CLI-Tool und ein Daemon, der als root läuft, und vieles mehr. Jedenfalls war die Nachrichtenübermittlung mehr als verwirrend, ganz zu schweigen von „leichgewichtigen VMs“, Kontrollgruppen, Namensräumen, zahlreichen Sicherheitsproblemen und Funktionen, die mit dem Marketingaufruf „jede Anwendung überall erstellen, bereitstellen und ausführen“ vermischt sind.
Wie bei allen guten Abstraktionen braucht es Zeit (sowie Erfahrung und Schmerz), um verschiedene Probleme in logisch kombinierbare Schichten zu zerlegen. Leider trat Kubernetes in den Ring, bevor Docker eine ähnliche Reife erreichen konnte. Es hat den Hype-Zyklus so monopolisiert, dass nun alle versuchten, bei den Veränderungen im Kubernetes-Ökosystem Schritt zu halten, während das Container-Ökosystem in den Hintergrund trat.
Kubernetes hat in vielerlei Hinsicht die gleichen Probleme wie Docker. Trotz aller Gespräche über eine coole und zusammensetzbare (composable) Abstraktion, die verschiedenen Aufgaben in Schichten aufzuteilen nicht besonders gut encapsuliert. Im Wesentlichen ist es ein Containerorchestrator, der Container in einem Cluster von verschiedenen Maschinen ausführt. Das ist eine recht niedrigstufige Aufgabe, die nur für Ingenieure zutrifft, die mit Clustern arbeiten. Andererseits ist Kubernetes auch eine hochgradige Abstraktion, ein CLI-Tool, mit dem Nutzer über YAML interagieren.
Docker war (und ist) ein großartiges Tool für die Entwicklung, trotz all seiner Mängel. In dem Versuch, all den „Hasen“ hinterherzulaufen, ist es den Entwicklern gelungen, eine hochgradige Abstraktion. Bei der hochgradigen Abstraktion meine ich eine Teilmenge Funktionalitäten, für die sich die Zielgruppe tatsächlich interessierte (in diesem Fall Entwickler, die die meiste Zeit in ihren lokalen Entwicklungsumgebungen verbrachten) und die „out-of-the-box“ großartig funktionierten..
Dockerfile und CLI-Utility docker sollten ein Beispiel für die Schaffung einer guten „hochgradigen Benutzeroberfläche“ sein. Ein durchschnittlicher Entwickler kann mit Docker anfangen, ohne etwas über die Feinheiten zu wissen. Implementierungen, die zur Benutzererfahrung beitragen, wie Namespaces, Kontrollgruppen, Speicher- und CPU-Beschränkungen usw. Letztendlich unterscheidet sich das Schreiben einer Dockerfile nicht wesentlich von der Erstellung eines Shell-Skripts.
Kubernetes richtet sich an verschiedene Zielgruppen:
- Cluster-Administratoren;
- Ingenieure, die sich mit Infrastrukturfragen befassen, Kubernetes erweitern und Plattformen darauf aufbauen;
- Endbenutzer, die über
kubectl.
den Ansatz „eine API für alles“ in Kubernetes verfügt über eine unzureichend verkapselte „Berg von Komplexität“, ohne anzugeben, wie sie skaliert werden kann. Dies führt zu einer unangemessen langen Lernkurve. Wie Adam Jacob sagt: „Docker hat Benutzern ein transformierendes Erlebnis gebracht, das bis heute unerreicht bleibt. Fragen Sie jeden, der K8s nutzt, ob sie möchten, dass es wie ihr erstes funktioniert docker run. Die Antwort wird bejahend sein:
Ich würde sagen, dass der Großteil der Infrastrukturtechnologie heute zu niedrigschwellig ist (und daher als „zu kompliziert“ angesehen wird). Kubernetes wird auf einem ziemlich niedrigen Niveau implementiert. Verteiltes Tracing in seiner (viele Spans, die zusammengenäht sind, um eine Traceview zu bilden) ist ebenfalls auf einem zu niedrigen Niveau realisiert. Entwicklerwerkzeuge, die „Abstraktionen höchster Ebene“ bereitstellen, sind in der Regel die erfolgreichsten. Diese Schlussfolgerung erweist sich in einer erstaunlichen Anzahl von Fällen als zutreffend (wenn eine Technologie zu komplex oder schwer zu bedienen ist, steht die „High-Level-API/UI“ für diese Technologie noch aus).
Gerade jetzt verunsichert das cloud-native Ökosystem mit seiner Fokussierung auf Niedrigstlevel. Als Branche müssen wir innovieren, experimentieren und lernen, wie das richtige Niveau der „höchsten Abstraktion“ aussieht.
Einzelhandel
In den 2010er Jahren hat sich das digitale Einkaufserlebnis im Einzelhandel kaum verändert. Einerseits hätte die Leichtigkeit des Online-Shoppings den klassischen Einzelhandelsgeschäften zusetzen müssen, andererseits hat sich das Online-Shopping über ein Jahrzehnt hinweg grundlegend fast nicht verändert.
Auch wenn ich keine konkreten Gedanken zur Entwicklung dieser Branche im nächsten Jahrzehnt habe, wäre ich sehr enttäuscht, wenn wir im Jahr 2030 einkaufen würden, wie wir es im Jahr 2020 tun.
Journalismus
Ich bin zunehmend enttäuscht über den Zustand des globalen Journalismus. Es wird immer schwieriger, unparteiische Nachrichtenquellen zu finden, die objektiv und sorgfältig berichten. Oftmals verschwimmt die Grenze zwischen der Nachricht selbst und der Meinung dazu. Informationen werden in der Regel voreingenommen präsentiert. Dies gilt insbesondere für einige Länder, in denen historisch gesehen keine Trennung zwischen Nachrichten und Meinungen darüber existierte. In einem kürzlich veröffentlichten Artikel, der nach den letzten allgemeinen Wahlen in Großbritannien erschien, schrieb Alan Rusbridger, der ehemalige Chefredakteur von The Guardian, :
Die Hauptaussage ist, dass ich über viele Jahre hinweg amerikanische Zeitungen betrachtet habe und um meine Kollegen vor Ort, die ausschließlich für die Nachrichten verantwortlich waren, bedauert habe, während das Kommentieren von völlig anderen Personen übernommen wurde. Im Laufe der Zeit verwandelte sich das Bedauern jedoch in Neid. Jetzt denke ich, dass alle britischen Tageszeitungen die Verantwortung für Nachrichten von der Verantwortung für Kommentare trennen sollten. Leider ist es für den durchschnittlichen Leser – insbesondere für den Online-Leser – viel zu schwierig, den Unterschied zu erkennen.
Angesichts des fragwürdigen rufs des Silicon Valley in Bezug auf Ethik würde ich unter keinen Umständen den Technologien die "Revolution" im Journalismus anvertrauen. Gleichzeitig wäre ich (und viele meiner Bekannten) erfreut, wenn eine unparteiische, uneigennützige und vertrauenswürdige Nachrichtenquelle entstehen würde. Ich kann mir derzeit nicht vorstellen, wie eine solche Plattform aussehen könnte, bin jedoch überzeugt, dass die Notwendigkeit für ehrlichen Journalismus in einer Zeit, in der die Wahrheit immer schwerer zu erkennen ist, größer ist als je zuvor.
Soziale Netzwerke
Soziale Netzwerke und kollektive Nachrichtenplattformen sind die Hauptquelle für Informationen für viele Menschen in verschiedenen Teilen der Welt. Der Mangel an Genauigkeit und die Weigerung einiger Plattformen, auch nur grundlegende Fakten zu überprüfen, führen zu katastrophalen Folgen wie Genozid, Wahlmanipulation usw.
Soziale Netzwerke sind auch das mächtigste Medium, das es je gegeben hat. Sie haben die politischen Praktiken grundlegend verändert. Sie haben die Werbung verändert. Sie haben die Popkultur verändert (zum Beispiel durch ihren Beitrag zur sogenannten Cancel Culture) [культуры остракизма — прим. перев.] was gerade durch soziale Netzwerke gefördert wird. Kritiker behaupten, dass soziale Netzwerke ein fruchtbarer Boden für rapide und "launische" Veränderungen in den moralischen Werten sind, jedoch haben sie auch marginalisierten Gruppen die Möglichkeit gegeben, sich zu vereinen (eine Möglichkeit, die sie zuvor nie hatten). Im Wesentlichen haben soziale Netzwerke die Art und Weise, wie Menschen im 21. Jahrhundert kommunizieren und sich ausdrücken, verändert.
Dennoch bin ich überzeugt, dass soziale Netzwerke die schlechtesten menschlichen Impulse fördern. Achtsamkeit und Nachdenklichkeit werden oft zugunsten von Popularität vernachlässigt, und es wird praktisch unmöglich, begründeten Widerspruch zu bestimmten Meinungen und Positionen zu äußern. Polarisierung gerät oft außer Kontrolle, sodass die breite Masse schlichtweg einzelne Meinungen nicht hört, während Absolutisten die Themen des Online-Etiketts und der Akzeptabilität kontrollieren.
Ich frage mich, ob man eine "bessere" Plattform schaffen kann, die die Qualität von Diskussionen fördert? Denn das, was die „Beteiligung“ antreibt, bringt oft den Hauptgewinn für diese Plattformen. Wie Kara Swisher in der New York Times:
Digitale Interaktionen können entwickelt werden, ohne Hass und Intoleranz zu schüren. Der Grund, warum die meisten sozialen Netzwerke so toxisch erscheinen, liegt darin, dass sie auf Geschwindigkeit, Viralität und Aufmerksamkeit und nicht auf Inhalt und Genauigkeit ausgerichtet sind.
Es wäre wirklich bedauerlich, wenn in ein paar Jahrzehnten das einzige Erbe der sozialen Netzwerke die Verwischung von Nuancen und Angemessenheit im öffentlichen Diskurs wäre.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
