Notiz. übersetzen: Dieser Artikel, der auf Medium ein Hit wurde, ist ein Überblick über die wichtigsten (2010-2019) Veränderungen in der Welt der Programmiersprachen und des damit verbundenen Technologie-Ökosystems (mit besonderem Fokus auf Docker und Kubernetes). Die ursprüngliche Autorin ist Cindy Sridharan, die sich auf Entwicklertools und verteilte Systeme spezialisiert hat – insbesondere hat sie das Buch „Distributed Systems Observability“ geschrieben – und im Internetbereich bei IT-Spezialisten sehr beliebt ist, insbesondere am Thema Cloud Native.
Zum Ende des Jahres 2019 möchte ich meine Gedanken zu einigen der wichtigsten technologischen Fortschritte und Innovationen des letzten Jahrzehnts mitteilen. Darüber hinaus werde ich versuchen, ein wenig in die Zukunft zu blicken und die wesentlichen Probleme und Chancen des kommenden Jahrzehnts zu skizzieren.
Ich möchte klarstellen, dass ich in diesem Artikel nicht auf Änderungen in Bereichen wie Data Science eingehen werde (Datenwissenschaft), künstliche Intelligenz, Frontend-Engineering usw., da ich persönlich nicht über ausreichende Erfahrung darin verfüge.
Typisierung schlägt zurück
Einer der positivsten Trends der 2010er Jahre war die Wiederbelebung statisch typisierter Sprachen. Solche Sprachen sind jedoch nie verschwunden (C++ und Java sind heute gefragt; sie dominierten vor zehn Jahren), aber dynamisch typisierte Sprachen (Dynamics) erlebten nach dem Aufkommen der Ruby on Rails-Bewegung im Jahr 2005 einen deutlichen Anstieg der Popularität . Dieses Wachstum erreichte 2009 seinen Höhepunkt mit der Open Source von Node.js, die Javascript-on-the-Server zur Realität machte.
Im Laufe der Zeit haben dynamische Sprachen im Bereich der Erstellung von Serversoftware etwas an Attraktivität verloren. Die Go-Sprache, die während der Container-Revolution populär wurde, schien besser geeignet zu sein, leistungsstarke, ressourceneffiziente Server mit paralleler Verarbeitung zu erstellen (womit der Schöpfer von Node.js selbst).
Rust wurde 2010 eingeführt und beinhaltete Fortschritte in in dem Versuch, eine sichere und typisierte Sprache zu werden. In der ersten Hälfte des Jahrzehnts wurde Rust in der Branche eher verhalten aufgenommen, doch in der zweiten Hälfte nahm seine Popularität deutlich zu. Zu den bemerkenswerten Anwendungsfällen für Rust gehört die Verwendung für , (wir haben darüber gesprochen in - ca. übersetzt), ein früher WebAssembly-Compiler von Fastly (jetzt Teil von bytecodealliance) usw. Da Microsoft die Möglichkeit in Betracht zieht, einige Teile des Windows-Betriebssystems in Rust neu zu schreiben, kann man mit Sicherheit sagen, dass diese Sprache in den 2020er Jahren eine glänzende Zukunft hat.
Sogar dynamische Sprachen haben neue Funktionen wie (optionale Typen). Sie wurden zunächst in TypeScript implementiert, einer Sprache, die es Ihnen ermöglicht, getippten Code zu erstellen und ihn in JavaScript zu kompilieren. PHP, Ruby und Python verfügen über ihre eigenen optionalen Typisierungssysteme (, ), die erfolgreich eingesetzt werden .
Rückgabe von SQL an NoSQL
NoSQL ist eine weitere Technologie, die zu Beginn des Jahrzehnts weitaus beliebter war als am Ende. Ich denke, dafür gibt es zwei Gründe.
Erstens erwies sich das NoSQL-Modell aufgrund seines Mangels an Schemata, Transaktionen und schwächeren Konsistenzgarantien als schwieriger zu implementieren als das SQL-Modell. IN mit dem Titel „Warum Sie wann immer möglich eine starke Konsistenz bevorzugen sollten“ (Warum Sie wann immer möglich eine starke Konsistenz wählen sollten) Google schreibt:
Eines der Dinge, die wir bei Google gelernt haben, ist, dass Anwendungscode einfacher und die Entwicklungszeit kürzer ist, wenn Ingenieure sich auf den vorhandenen Speicher verlassen können, um komplexe Transaktionen abzuwickeln und die Daten in Ordnung zu halten. Um die Originaldokumentation von Spanner zu zitieren: „Wir glauben, dass es für Programmierer besser ist, sich mit Anwendungsleistungsproblemen aufgrund von Transaktionsmissbrauch zu befassen, wenn Engpässe entstehen, als ständig das Fehlen von Transaktionen im Auge zu behalten.“
Der zweite Grund liegt im Aufkommen „skalierbarer“ verteilter SQL-Datenbanken (z. B и ) im öffentlichen Cloud-Bereich sowie Open-Source-Alternativen wie CockroachDB (Wir reden auch über sie - ca. übersetzt), die viele der technischen Probleme lösen, die dazu führten, dass herkömmliche SQL-Datenbanken „nicht skalierbar“ waren. Sogar MongoDB, einst der Inbegriff der NoSQL-Bewegung, ist es jetzt verteilte Transaktionen.
Für Situationen, die atomare Lese- und Schreibvorgänge über mehrere Dokumente (über eine oder mehrere Sammlungen hinweg) erfordern, unterstützt MongoDB Transaktionen mit mehreren Dokumenten. Bei verteilten Transaktionen können Transaktionen über mehrere Vorgänge, Sammlungen, Datenbanken, Dokumente und Shards hinweg verwendet werden.
Totales Streaming
Apache Kafka ist zweifellos eine der wichtigsten Erfindungen des letzten Jahrzehnts. Der Quellcode wurde im Januar 2011 geöffnet und im Laufe der Jahre hat Kafka die Art und Weise revolutioniert, wie Unternehmen mit Daten arbeiten. Kafka wurde in jedem Unternehmen eingesetzt, für das ich gearbeitet habe, vom Start-up bis zum Großkonzern. Die bereitgestellten Garantien und Anwendungsfälle (Pub-Sub, Streams, ereignisgesteuerte Architekturen) werden in einer Vielzahl von Aufgaben eingesetzt, von der Datenspeicherung bis zur Überwachung und Streaming-Analyse, und sind in vielen Bereichen wie Finanzen, Gesundheitswesen, öffentlicher Sektor usw. gefragt. Einzelhandel usw.
Kontinuierliche Integration (und in geringerem Maße kontinuierliche Bereitstellung)
Kontinuierliche Integration ist nicht in den letzten 10 Jahren aufgetaucht, sondern im letzten Jahrzehnt hat sich so weit verbreitet, das Teil des Standard-Workflows wurde (Tests für alle Pull-Anfragen ausführen). Etablierung von GitHub als Plattform für die Entwicklung und Speicherung von Code und, was noch wichtiger ist, für die Entwicklung eines darauf basierenden Workflows bedeutet, dass Tests ausgeführt werden, bevor eine Pull-Anfrage an den Master angenommen wird lediglich Workflow in der Entwicklung, vertraut für Ingenieure, die ihre Karriere in den letzten zehn Jahren begonnen haben.
Continuous Deployment (Bereitstellung jedes Commits, sobald es den Master erreicht) ist nicht so weit verbreitet wie Continuous Integration. Angesichts der Vielzahl verschiedener Cloud-APIs für die Bereitstellung, der wachsenden Beliebtheit von Plattformen wie Kubernetes (die eine standardisierte API für Bereitstellungen bereitstellen) und dem Aufkommen von plattformübergreifenden Multi-Cloud-Tools wie Spinnaker (die auf den standardisierten basieren). APIs) sind Bereitstellungsprozesse automatisierter, rationalisierter und im Allgemeinen sicherer geworden.
Container
Container sind vielleicht die am meisten gehypte, diskutierte, beworbene und am meisten missverstandene Technologie der 2010er Jahre. Andererseits handelt es sich um eine der wichtigsten Innovationen des vergangenen Jahrzehnts. Ein Grund für diese ganze Kakophonie liegt zum Teil in den gemischten Signalen, die wir von fast überall erhielten. Nachdem der Hype nun etwas nachgelassen hat, sind einige Dinge stärker in den Fokus gerückt.
Container sind nicht deshalb populär geworden, weil sie die beste Möglichkeit zum Ausführen einer Anwendung darstellen, die den Anforderungen der globalen Entwicklergemeinschaft entspricht. Container wurden populär, weil sie erfolgreich in eine Marketinganfrage für ein bestimmtes Tool passen, das ein völlig anderes Problem löst. Es stellte sich heraus, dass es Docker war Fantastisch ein Entwicklungstool, das das dringende Kompatibilitätsproblem („funktioniert auf meinem Rechner“) löst.
Genauer gesagt, die Revolution wurde gemacht Docker-Image, weil es das Problem der Parität zwischen Umgebungen löste und eine echte Portabilität nicht nur der Anwendungsdatei, sondern auch aller ihrer Software- und Betriebsabhängigkeiten ermöglichte. Die Tatsache, dass dieses Tool irgendwie die Popularität von „Containern“ vorangetrieben hat, bei denen es sich im Wesentlichen um Implementierungsdetails auf sehr niedriger Ebene handelt, bleibt für mich vielleicht das größte Rätsel des letzten Jahrzehnts.
Serverlos
Ich würde wetten, dass das Aufkommen des „serverlosen“ Computings noch wichtiger ist als Container, weil es den Traum vom On-Demand-Computing wirklich Wirklichkeit werden lässt (On-Demand). In den letzten fünf Jahren habe ich gesehen, wie der Umfang des serverlosen Ansatzes durch die Unterstützung neuer Sprachen und Laufzeiten schrittweise erweitert wurde. Das Aufkommen von Produkten wie Azure Durable Functions scheint der richtige Schritt zur Implementierung zustandsbehafteter Funktionen zu sein (und gleichzeitig ein entscheidender Schritt). im Zusammenhang mit FaaS-Einschränkungen). Ich werde mit Interesse beobachten, wie sich dieses neue Paradigma in den kommenden Jahren entwickelt.
Automatisierung
Der vielleicht größte Nutznießer dieses Trends ist die Operations-Engineering-Community, da sie die Verwirklichung von Konzepten wie Infrastructure as Code (IaC) ermöglicht hat. Darüber hinaus fiel die Leidenschaft für Automatisierung mit dem Aufkommen der „SRE-Kultur“ zusammen, die auf einen stärker softwarezentrierten Ansatz für den Betrieb abzielt.
Universelle API-Fizierung
Ein weiteres interessantes Merkmal des letzten Jahrzehnts war die API-Fizierung verschiedener Entwicklungsaufgaben. Gute, flexible APIs ermöglichen es dem Entwickler, innovative Workflows und Tools zu erstellen, die wiederum bei der Wartung helfen und das Benutzererlebnis verbessern.
Darüber hinaus ist die API-Fizierung der erste Schritt zur SaaS-Fizierung einiger Funktionen oder Tools. Dieser Trend ging auch mit der zunehmenden Beliebtheit von Microservices einher: SaaS ist zu einem weiteren Dienst geworden, auf den über eine API zugegriffen werden kann. Mittlerweile sind viele SaaS- und FOSS-Tools in Bereichen wie Überwachung, Zahlungen, Lastausgleich, kontinuierliche Integration, Warnungen und Funktionswechsel verfügbar (Funktionskennzeichnung), CDN, Traffic Engineering (z. B. DNS) usw., die im letzten Jahrzehnt eine Blüte erlebt haben.
Beobachtbarkeit
Es ist erwähnenswert, dass wir heute Zugriff darauf haben viel fortgeschrittener Tools zur Überwachung und Diagnose des Anwendungsverhaltens als je zuvor. Zu nennen ist vielleicht das Überwachungssystem Prometheus, das 2015 den Open-Source-Status erhielt das Beste Überwachungssystem von denen, mit denen ich gearbeitet habe. Es ist nicht perfekt, aber viele Dinge sind genau richtig implementiert (z. B. Unterstützung für Messungen). [Dimensionalität] im Fall von Metriken).
Distributed Tracing war eine weitere Technologie, die in den 2010er Jahren dank Initiativen wie OpenTracing (und seinem Nachfolger OpenTelemetry) Einzug in den Mainstream hielt. Obwohl die Rückverfolgung immer noch recht schwierig anzuwenden ist, geben einige der neuesten Entwicklungen Anlass zur Hoffnung, dass wir ihr wahres Potenzial in den 2020er Jahren erschließen werden. (Hinweis: Lesen Sie auch in unserem Blog die Übersetzung des Artikels „„vom selben Autor.)
In die Zukunft schauen
Leider gibt es viele Probleme, die im kommenden Jahrzehnt gelöst werden müssen. Hier sind meine Gedanken dazu und einige mögliche Ideen, wie man sie loswerden kann.
Lösung des Mooreschen Gesetzesproblems
Das Ende des Dennard-Skalierungsgesetzes und der Rückstand gegenüber dem Moore-Gesetz erfordern neue Innovationen. John Hennessy in erklärt, warum Süchtige problematisch sind (domänenspezifisch) Architekturen wie TPU könnten eine der Lösungen für das Problem sein, dem Mooreschen Gesetz hinterherzuhinken. Toolkits wie von Google scheinen bereits ein guter Schritt in diese Richtung zu sein:
Compiler müssen neue Anwendungen unterstützen, sich leicht auf neue Hardware portieren lassen, mehrere Abstraktionsebenen verknüpfen, die von dynamischen, verwalteten Sprachen bis hin zu Vektorbeschleunigern und softwaregesteuerten Speichergeräten reichen, und gleichzeitig High-Level-Switches für die automatische Optimierung bereitstellen, die nur in Funktionalität – Zeit, Diagnose und Verteilung von Debugging-Informationen über die Funktionsweise und Leistung von Systemen im gesamten Stapel, während in den meisten Fällen eine Leistung bereitgestellt wird, die einigermaßen nahe an handgeschriebenem Assembler liegt. Wir beabsichtigen, unsere Vision, Fortschritte und Pläne für die Entwicklung und öffentliche Verfügbarkeit einer solchen Kompilierungsinfrastruktur zu teilen.
CI / CD
Während der Aufstieg von CI zu einem der größten Trends der 2010er Jahre geworden ist, ist Jenkins immer noch der Goldstandard für CI.
Dieser Bereich benötigt dringend Innovationen in den folgenden Bereichen:
- Benutzeroberfläche (DSL zur Kodierung von Testspezifikationen);
- Implementierungsdetails, die es wirklich skalierbar und schnell machen;
- Integration mit verschiedenen Umgebungen (Staging, Produktion usw.), um fortgeschrittenere Testformen zu implementieren;
- Kontinuierliche Tests und Bereitstellung.
Entwicklerwerkzeuge
Als Branche haben wir begonnen, immer komplexere und beeindruckendere Software zu entwickeln. Bei unseren eigenen Werkzeugen könnte die Situation jedoch deutlich besser sein.
Die kollaborative und Remote-Bearbeitung (über SSH) erfreute sich einiger Beliebtheit, wurde jedoch nie zur neuen Standardmethode für die Entwicklung. Wenn Sie, wie ich, die bloße Idee davon ablehnen müssen Wenn Sie eine permanente Verbindung zum Internet haben, nur um programmieren zu können, ist die Arbeit über SSH auf einem Remote-Rechner wahrscheinlich nicht das Richtige für Sie.
Lokale Entwicklungsumgebungen, insbesondere für Ingenieure, die an großen serviceorientierten Architekturen arbeiten, stellen immer noch eine Herausforderung dar. Einige Projekte versuchen, dieses Problem zu lösen, und mich würde interessieren, wie die ergonomischste UX für einen bestimmten Anwendungsfall aussehen würde.
Es wäre auch interessant, das Konzept der „tragbaren Umgebungen“ auf andere Entwicklungsbereiche wie die Reproduktion von Fehlern (bzw ), die unter bestimmten Bedingungen oder Einstellungen auftreten.
Ich würde mir auch mehr Innovationen in Bereichen wie der semantischen und kontextsensitiven Codesuche, Tools zur Korrelation von Produktionsvorfällen mit bestimmten Teilen der Codebasis usw. wünschen.
Computing (die Zukunft von PaaS)
Nach dem Hype um Container und Serverless in den 2010er Jahren hat sich das Lösungsangebot im Public-Cloud-Bereich in den letzten Jahren deutlich erweitert.
Dies wirft mehrere interessante Fragen auf. Erstens wächst die Liste der verfügbaren Optionen in der Public Cloud ständig. Cloud-Dienstanbieter verfügen über das Personal und die Ressourcen, um problemlos mit den neuesten Entwicklungen in der Open-Source-Welt Schritt zu halten und Produkte wie „serverlose Pods“ (ich vermute, einfach dadurch, dass sie ihre eigenen FaaS-Laufzeiten OCI-kompatibel machen) oder andere ähnlich ausgefallene Dinge zu veröffentlichen.
Man kann diejenigen, die diese Cloud-Lösungen nutzen, nur beneiden. Theoretisch bieten Kubernetes-Cloud-Angebote (GKE, EKS, EKS auf Fargate usw.) Cloud-Provider-unabhängige APIs für die Ausführung von Workloads. Wenn Sie ähnliche Produkte (ECS, Fargate, Google Cloud Run usw.) verwenden, profitieren Sie wahrscheinlich bereits von den interessantesten Funktionen des Dienstanbieters. Wenn außerdem neue Produkte oder Computerparadigmen auf den Markt kommen, dürfte die Migration einfach und stressfrei vonstatten gehen.
Wenn man bedenkt, wie schnell sich die Palette solcher Lösungen weiterentwickelt (ich wäre sehr überrascht, wenn in naher Zukunft nicht ein paar neue Optionen auftauchen), werden kleine „Plattform“-Teams (Teams, die mit der Infrastruktur verbunden sind und für die Erstellung von On-Premise-Plattformen verantwortlich sind). Unternehmen, die Workloads betreiben) werden in Bezug auf Funktionalität, Benutzerfreundlichkeit und Gesamtzuverlässigkeit unglaublich schwer zu konkurrieren sein. In den 2010er Jahren wurde Kubernetes als Tool zum Aufbau von PaaS (Platform-as-a-Service) gesehen. Daher erscheint es mir völlig sinnlos, auf Kubernetes eine interne Plattform aufzubauen, die die gleiche Auswahl, Einfachheit und Freiheit bietet, die auch der Öffentlichkeit zur Verfügung steht Wolkenraum. Containerbasiertes PaaS als „Kubernetes-Strategie“ zu formulieren, kommt einer bewussten Vermeidung der innovativsten Funktionen der Cloud gleich.
Wenn man sich das Verfügbare anschaut heute Angesichts der Rechenkapazitäten wird deutlich, dass die Erstellung eines eigenen PaaS, das ausschließlich auf Kubernetes basiert, gleichbedeutend damit ist, sich selbst in die Enge zu treiben (kein sehr zukunftsorientierter Ansatz, oder?). Selbst wenn sich heute jemand dafür entscheidet, ein containerisiertes PaaS auf Kubernetes aufzubauen, wird es in ein paar Jahren im Vergleich zu Cloud-Funktionen veraltet aussehen. Obwohl Kubernetes als Open-Source-Projekt begann, ist sein Vorläufer und seine Inspiration ein internes Google-Tool. Es wurde jedoch ursprünglich Anfang/Mitte der 2000er Jahre entwickelt, als die Computerlandschaft noch völlig anders war.
Außerdem müssen Unternehmen im weitesten Sinne keine Experten für den Betrieb eines Kubernetes-Clusters werden und auch keine eigenen Rechenzentren aufbauen und warten. Die Bereitstellung einer zuverlässigen Computergrundlage ist eine zentrale Herausforderung Cloud-Dienstleister.
Abschließend habe ich das Gefühl, dass wir als Branche in Bezug auf Folgendes etwas zurückgegangen sind Interaktionserfahrung (). Heroku wurde 2007 eingeführt und ist immer noch eines der beliebtesten Einfach zu verwenden Plattformen. Es lässt sich nicht leugnen, dass Kubernetes viel leistungsfähiger, erweiterbarer und programmierbarer ist, aber ich vermisse, wie einfach der Einstieg und die Bereitstellung auf Heroku ist. Um diese Plattform nutzen zu können, müssen Sie lediglich Git kennen.
All dies führt mich zu folgender Schlussfolgerung: Wir brauchen bessere Abstraktionen auf höherer Ebene, um zu funktionieren (dies gilt insbesondere für Abstraktionen auf höchstem Niveau).
Die richtige API auf höchstem Niveau
Docker ist ein großartiges Beispiel für die Notwendigkeit einer gleichzeitig besseren Trennung von Belangen korrekte Implementierung der API der höchsten Ebene.
Das Problem mit Docker besteht darin, dass das Projekt (zumindest) anfangs zu weit gefasste Ziele verfolgte: alles nur, um das Kompatibilitätsproblem („funktioniert auf meiner Maschine“) mithilfe der Containertechnologie zu lösen. Docker war ein Image-Format, eine Laufzeitumgebung mit eigenem virtuellen Netzwerk, ein CLI-Tool, ein als Root laufender Daemon und vieles mehr. Auf jeden Fall klappte der Nachrichtenaustausch mehr verwirrend, ganz zu schweigen von „leichtgewichtigen VMs“, Cgroups, Namespaces, zahlreichen Sicherheitsproblemen und Funktionen, gemischt mit dem Marketingaufruf „Jede Anwendung überall erstellen, bereitstellen und ausführen“.
Wie bei allen guten Abstraktionen braucht es Zeit (und Erfahrung und Mühe), verschiedene Probleme in logische Schichten zu zerlegen, die miteinander kombiniert werden können. Leider mischte sich Kubernetes in den Kampf ein, bevor Docker eine ähnliche Reife erreichen konnte. Es monopolisierte den Hype-Zyklus so stark, dass nun jeder versuchte, mit den Veränderungen im Kubernetes-Ökosystem Schritt zu halten, und das Container-Ökosystem einen zweitrangigen Status einnahm.
Kubernetes hat viele der gleichen Probleme wie Docker. Für all das Gerede über coole und zusammensetzbare Abstraktion, Unterteilung verschiedener Aufgaben in Ebenen nicht sehr gut gekapselt. Im Kern handelt es sich um einen Container-Orchestrator, der Container auf einem Cluster verschiedener Maschinen ausführt. Dies ist eine ziemlich einfache Aufgabe, die nur für Ingenieure gilt, die den Cluster betreiben. Andererseits ist es auch Kubernetes Abstraktion auf höchstem Niveau, ein CLI-Tool, mit dem Benutzer über YAML interagieren.
Docker war (und ist) Cool Trotz aller Mängel ist es ein Entwicklungstool. Um mit allen „Hasen“ gleichzeitig Schritt zu halten, gelang den Entwicklern eine korrekte Implementierung Abstraktion auf höchstem Niveau. Mit Abstraktion auf höchstem Niveau meine ich Eine Teilmenge Funktionalität, an der die Zielgruppe (in diesem Fall Entwickler, die die meiste Zeit in ihren lokalen Entwicklungsumgebungen verbrachten) wirklich interessiert war und die sofort einsatzbereit war.
Dockerfile- und CLI-Dienstprogramm docker sollte ein Beispiel dafür sein, wie man eine gute „Benutzererfahrung auf höchstem Niveau“ aufbaut. Ein normaler Entwickler kann mit Docker arbeiten, ohne etwas über die Feinheiten zu wissen Implementierungen, die zum Betriebserlebnis beitragenwie Namespaces, Kontrollgruppen, Speicher- und CPU-Limits usw. Letztendlich unterscheidet sich das Schreiben einer Docker-Datei nicht wesentlich vom Schreiben eines Shell-Skripts.
Kubernetes ist für unterschiedliche Zielgruppen gedacht:
- Cluster-Administratoren;
- Softwareentwickler, die an Infrastrukturproblemen arbeiten, die Fähigkeiten von Kubernetes erweitern und darauf basierende Plattformen erstellen;
- Endbenutzer interagieren mit Kubernetes über
kubectl.
Der Ansatz „Eine API für alle“ von Kubernetes stellt einen unzureichend gekapselten „Berg an Komplexität“ dar, für dessen Skalierung es keine Anleitung gibt. All dies führt zu einem ungerechtfertigt langen Lernweg. Wie Adam Jacob: „Docker hat eine transformative Benutzererfahrung gebracht, die noch nie übertroffen wurde. Fragen Sie jeden, der einen K8 verwendet, ob er sich wünscht, dass er wie sein erster funktioniert docker run. Die Antwort wird ja sein“:
Ich würde argumentieren, dass die meisten Infrastrukturtechnologien heute zu niedrig sind (und daher als „zu komplex“ gelten). Kubernetes ist auf einem relativ niedrigen Niveau implementiert. Verteilte Ablaufverfolgung in seinem (viele Spans zusammengefügt, um eine Traceansicht zu bilden) wird ebenfalls auf einer zu niedrigen Ebene implementiert. Entwicklertools, die die „Abstraktionen auf höchster Ebene“ implementieren, sind in der Regel am erfolgreichsten. Diese Schlussfolgerung trifft in überraschend vielen Fällen zu (wenn die Technologie zu komplex oder zu schwierig zu verwenden ist, muss die „höchste API/UI“ für diese Technologie noch entdeckt werden).
Derzeit ist das Cloud-native-Ökosystem aufgrund seines niedrigen Fokus verwirrend. Als Branche müssen wir innovativ sein, experimentieren und darüber aufklären, wie das richtige Maß an „maximaler, höchster Abstraktion“ aussieht.
Einzelhandel
In den 2010er Jahren blieb das digitale Einzelhandelserlebnis weitgehend unverändert. Einerseits hätte die Leichtigkeit des Online-Shoppings den traditionellen Einzelhandel erreichen sollen, andererseits ist das Online-Shopping seit einem Jahrzehnt grundsätzlich nahezu unverändert geblieben.
Ich habe zwar keine konkreten Vorstellungen darüber, wie sich diese Branche im nächsten Jahrzehnt entwickeln wird, wäre aber sehr enttäuscht, wenn wir im Jahr 2030 genauso einkaufen würden wie im Jahr 2020.
Journalismus
Ich bin zunehmend desillusioniert über den Zustand des globalen Journalismus. Es wird immer schwieriger, unvoreingenommene Nachrichtenquellen zu finden, die objektiv und sorgfältig berichten. Sehr oft ist die Grenze zwischen den Nachrichten selbst und den Meinungen darüber fließend. In der Regel werden Informationen voreingenommen dargestellt. Dies gilt insbesondere für einige Länder, in denen es historisch gesehen keine Trennung zwischen Nachrichten und Meinungen gab. In einem kürzlich nach den letzten britischen Parlamentswahlen veröffentlichten Artikel sagte Alan Rusbridger, ehemaliger Herausgeber von The Guardian: :
Der Hauptpunkt ist, dass ich viele Jahre lang in amerikanische Zeitungen geschaut habe und Mitleid mit meinen Kollegen dort hatte, die allein für die Nachrichten verantwortlich waren und die Kommentare ganz anderen Leuten überließen. Doch mit der Zeit verwandelte sich das Mitleid in Neid. Ich denke jetzt, dass alle britischen Nationalzeitungen ihre Verantwortung für Nachrichten von ihrer Verantwortung für Kommentare trennen sollten. Leider ist es für den Durchschnittsleser – insbesondere für Online-Leser – zu schwierig, den Unterschied zu erkennen.
Angesichts des eher zweifelhaften Rufs des Silicon Valley, wenn es um Ethik geht, würde ich niemals darauf vertrauen, dass Technologie den Journalismus „revolutioniert“. Abgesehen davon wären ich (und viele meiner Freunde) froh, wenn es eine unparteiische, unparteiische und vertrauenswürdige Nachrichtenquelle gäbe. Obwohl ich keine Ahnung habe, wie eine solche Plattform aussehen könnte, bin ich zuversichtlich, dass in einer Zeit, in der die Wahrheit immer schwieriger zu erkennen ist, der Bedarf an ehrlichem Journalismus größer denn je ist.
Social Networks
Soziale Medien und Community-News-Plattformen sind für viele Menschen auf der ganzen Welt die wichtigste Informationsquelle, und der Mangel an Genauigkeit und die Zurückhaltung einiger Plattformen, auch nur eine grundlegende Faktenprüfung durchzuführen, hat zu katastrophalen Folgen wie Völkermord, Wahleinmischung und mehr geführt .
Social Media ist auch das mächtigste Medientool, das es je gab. Sie veränderten die politische Praxis radikal. Sie haben die Werbung geändert. Sie haben die Popkultur verändert (zum Beispiel den Hauptbeitrag zur Entwicklung der sogenannten Cancel-Kultur). [Kulturen der Ausgrenzung – ca. Übers.] soziale Netzwerke tragen dazu bei). Kritiker argumentieren, dass soziale Medien sich als fruchtbarer Boden für schnelle und launische Veränderungen moralischer Werte erwiesen haben, aber sie haben auch Mitgliedern marginalisierter Gruppen die Möglichkeit geboten, sich auf eine Weise zu organisieren, die sie noch nie zuvor hatten. Im Wesentlichen haben soziale Medien die Art und Weise verändert, wie Menschen im 21. Jahrhundert kommunizieren und sich ausdrücken.
Allerdings glaube ich auch, dass soziale Medien die schlimmsten menschlichen Impulse hervorbringen. Rücksichtnahme und Nachdenklichkeit werden oft zugunsten der Popularität vernachlässigt, und es wird fast unmöglich, begründete Ablehnung bestimmter Meinungen und Positionen zum Ausdruck zu bringen. Die Polarisierung gerät oft außer Kontrolle, was dazu führt, dass die Öffentlichkeit einzelne Meinungen einfach nicht hört, während Absolutisten Fragen der Online-Etikette und -Akzeptanz kontrollieren.
Ich frage mich, ob es möglich ist, eine „bessere“ Plattform zu schaffen, die qualitativ hochwertigere Diskussionen fördert? Schließlich ist es das, was das „Engagement“ antreibt, das diesen Plattformen oft den größten Gewinn bringt. Wie Kara Swisher in der New York Times:
Es ist möglich, digitale Interaktionen zu entwickeln, ohne Hass und Intoleranz zu provozieren. Der Grund dafür, dass die meisten Social-Media-Seiten so giftig erscheinen, liegt darin, dass sie eher auf Geschwindigkeit, Viralität und Aufmerksamkeit als auf Inhalt und Genauigkeit ausgelegt sind.
Es wäre wirklich bedauerlich, wenn in ein paar Jahrzehnten das einzige Erbe der sozialen Medien die Erosion von Nuancen und Angemessenheit im öffentlichen Diskurs wäre.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com