Opmerking. vert.: Dit artikel, dat een hit werd op Medium, is een overzicht van belangrijke (2010-2019) veranderingen in de wereld van programmeertalen en het bijbehorende technologie-ecosysteem (met speciale aandacht voor Docker en Kubernetes). De oorspronkelijke auteur is Cindy Sridharan, die gespecialiseerd is in ontwikkelaarstools en gedistribueerde systemen (ze schreef in het bijzonder het boek 'Distributed Systems Observability') en is behoorlijk populair op internet onder IT-specialisten, vooral geïnteresseerd in het onderwerp cloud native.
Nu 2019 ten einde loopt, wilde ik mijn gedachten delen over enkele van de belangrijkste technologische ontwikkelingen en innovaties van het afgelopen decennium. Daarnaast zal ik proberen een beetje in de toekomst te kijken en de belangrijkste problemen en kansen van het komende decennium te schetsen.
Ik wil duidelijk maken dat ik in dit artikel niet inga op veranderingen op gebieden als data science (datawetenschap), kunstmatige intelligentie, frontend engineering, enz., aangezien ik er persoonlijk niet voldoende ervaring mee heb.
Typering slaat terug
Een van de meest positieve trends van de jaren 2010 was de heropleving van statisch getypeerde talen. Dergelijke talen zijn echter nooit verdwenen (C++ en Java zijn tegenwoordig in trek; ze domineerden tien jaar geleden), maar dynamisch getypeerde talen (dynamics) kenden een aanzienlijke toename in populariteit na de opkomst van de Ruby on Rails-beweging in 2005. . Deze groei bereikte een hoogtepunt in 2009 met de open source van Node.js, waardoor Javascript-on-the-server werkelijkheid werd.
In de loop van de tijd hebben dynamische talen een deel van hun aantrekkingskracht verloren op het gebied van het maken van serversoftware. De Go-taal, populair geworden tijdens de containerrevolutie, leek beter geschikt voor het creëren van krachtige, hulpbronnenefficiënte servers met parallelle verwerking (waarmee de maker van Node.js zelf).
Rust, geïntroduceerd in 2010, omvatte vooruitgang in in een poging een veilige en getypte taal te worden. In de eerste helft van het decennium was de ontvangst van Rust door de industrie nogal lauw, maar de populariteit ervan nam in de tweede helft aanzienlijk toe. Opmerkelijke gebruiksscenario's voor Rust zijn onder meer het gebruik ervan voor , (we hebben er over gesproken in — ca. vert.), een vroege WebAssembly-compiler van Fastly (nu onderdeel van bytecodealliance), enz. Nu Microsoft de mogelijkheid overweegt om sommige delen van het Windows-besturingssysteem in Rust te herschrijven, kunnen we veilig zeggen dat deze taal in de jaren 2020 een mooie toekomst heeft.
Zelfs dynamische talen kregen nieuwe functies zoals (optionele typen). Ze werden voor het eerst geïmplementeerd in TypeScript, een taal waarmee u getypte code kunt maken en deze in JavaScript kunt compileren. PHP, Ruby en Python hebben hun eigen optionele typesystemen (, ), die met succes worden gebruikt .
SQL terugsturen naar NoSQL
NoSQL is een andere technologie die aan het begin van het decennium veel populairder was dan aan het einde. Ik denk dat daar twee redenen voor zijn.
Ten eerste bleek het NoSQL-model, met zijn gebrek aan schema, transacties en zwakkere consistentiegaranties, moeilijker te implementeren dan het SQL-model. IN met de titel "Waarom je waar mogelijk de voorkeur zou moeten geven aan sterke consistentie" (Waarom je waar mogelijk voor een sterke consistentie moet kiezen) Google schrijft:
Een van de dingen die we bij Google hebben geleerd, is dat applicatiecode eenvoudiger is en de ontwikkeltijd korter is wanneer technici kunnen vertrouwen op bestaande opslag om complexe transacties af te handelen en gegevens op orde te houden. Om de originele Spanner-documentatie te citeren: “Wij zijn van mening dat het voor programmeurs beter is om met applicatieprestatieproblemen als gevolg van transactiemisbruik om te gaan wanneer er knelpunten ontstaan, dan voortdurend de afwezigheid van transacties in gedachten te houden.”
De tweede reden is te wijten aan de opkomst van ‘scale-out’ gedistribueerde SQL-databases (zoals и ) in de publieke cloudruimte, evenals Open Source-alternatieven zoals CockroachDB (we hebben het ook over haar - ca. vert.), die veel van de technische problemen oplossen die ervoor zorgden dat traditionele SQL-databases ‘niet konden schalen’. Zelfs MongoDB, ooit de belichaming van de NoSQL-beweging, is dat nu gedistribueerde transacties.
Voor situaties waarin atomaire lees- en schrijfbewerkingen in meerdere documenten (in een of meer collecties) nodig zijn, ondersteunt MongoDB transacties met meerdere documenten. In het geval van gedistribueerde transacties kunnen transacties worden gebruikt voor meerdere bewerkingen, verzamelingen, databases, documenten en shards.
Totale streaming
Apache Kafka is zonder twijfel een van de belangrijkste uitvindingen van het afgelopen decennium. De broncode werd in januari 2011 geopend en door de jaren heen heeft Kafka een revolutie teweeggebracht in de manier waarop bedrijven met data werken. Kafka is gebruikt in elk bedrijf waar ik voor heb gewerkt, van startups tot grote bedrijven. De garanties en gebruiksscenario's die het biedt (pub-sub, streams, gebeurtenisgestuurde architecturen) worden gebruikt in een verscheidenheid aan taken, van gegevensopslag tot monitoring en streaming-analyses, waar veel vraag naar is op veel gebieden, zoals de financiële sector, de gezondheidszorg, de publieke sector, detailhandel en enz.
Continue integratie (en in mindere mate continue implementatie)
Continue Integratie is niet de afgelopen tien jaar ontstaan, maar de afgelopen tien jaar wel heeft zich zo ver verspreid, dat onderdeel is geworden van de standaardworkflow (tests uitvoeren op alle pull-aanvragen). Het opzetten van GitHub als platform voor codeontwikkeling en -opslag en, nog belangrijker, het ontwikkelen van een workflow op basis van betekent dat het uitvoeren van tests voordat een pull-verzoek naar master wordt geaccepteerd, is единственный workflow in ontwikkeling, bekend bij ingenieurs die hun carrière in de afgelopen tien jaar zijn begonnen.
Continue implementatie (het implementeren van elke commit zodra deze de master bereikt) is niet zo wijdverspreid als continue integratie. Echter, met de overvloed aan verschillende cloud-API’s voor implementatie, de groeiende populariteit van platforms zoals Kubernetes (die een gestandaardiseerde API bieden voor implementaties) en de opkomst van multi-platform, multi-cloud tools zoals Spinnaker (gebouwd bovenop de gestandaardiseerde tools). API's) zijn de implementatieprocessen meer geautomatiseerd, gestroomlijnd en, in het algemeen, veiliger geworden.
containers
Containers zijn misschien wel de meest gehypte, besproken, geadverteerde en onbegrepen technologie van de jaren 2010. Aan de andere kant is het een van de belangrijkste innovaties van het afgelopen decennium. Een deel van de reden voor al deze kakofonie ligt in de gemengde signalen die we bijna overal vandaan ontvingen. Nu de hype wat geluwd is, zijn sommige zaken scherper in beeld gekomen.
Containers zijn niet populair geworden omdat ze de beste manier zijn om een applicatie uit te voeren die voldoet aan de behoeften van de wereldwijde ontwikkelaarsgemeenschap. Containers werden populair omdat ze met succes pasten in een marketingvraag naar een bepaald hulpmiddel dat een heel ander probleem oplost. Docker bleek dat te zijn fantastisch een ontwikkelingstool die het dringende compatibiliteitsprobleem oplost (“werkt op mijn machine”).
Om precies te zijn, de revolutie was gemaakt Docker-afbeelding, omdat het het probleem van de pariteit tussen omgevingen oploste en zorgde voor echte portabiliteit, niet alleen van het applicatiebestand, maar ook van al zijn software- en operationele afhankelijkheden. Het feit dat deze tool op de een of andere manier de populariteit van ‘containers’ heeft gestimuleerd, die in wezen een implementatiedetail op een zeer laag niveau zijn, blijft voor mij misschien wel het belangrijkste mysterie van het afgelopen decennium.
Serverless
Ik durf te wedden dat de komst van ‘serverless’ computing zelfs nog belangrijker is dan containers, omdat het de droom van on-demand computing werkelijk werkelijkheid maakt (On-demand). De afgelopen vijf jaar heb ik de serverloze aanpak geleidelijk in omvang zien uitbreiden door ondersteuning voor nieuwe talen en runtimes toe te voegen. De opkomst van producten als Azure Sustainable Functions lijkt de juiste stap te zijn richting de implementatie van stateful functies (tegelijkertijd een beslissende stap in de richting van de implementatie van stateful functies). gerelateerd aan FaaS-beperkingen). Ik zal met belangstelling zien hoe dit nieuwe paradigma zich de komende jaren ontwikkelt.
Automatisering
Misschien wel de grootste begunstigde van deze trend is de gemeenschap van operations engineering, omdat deze het mogelijk heeft gemaakt dat concepten als infrastructuur als code (IaC) werkelijkheid zijn geworden. Bovendien viel de passie voor automatisering samen met de opkomst van de ‘SRE-cultuur’, die tot doel heeft een meer softwaregerichte benadering van de bedrijfsvoering te hanteren.
Universele API-ficatie
Een ander interessant kenmerk van het afgelopen decennium was de API-ficatie van verschillende ontwikkelingstaken. Goede, flexibele API’s stellen de ontwikkelaar in staat innovatieve workflows en tools te creëren, die op hun beurt helpen bij het onderhoud en de gebruikerservaring verbeteren.
Daarnaast is API-ficatie de eerste stap richting SaaS-ficatie van een bepaalde functionaliteit of tool. Deze trend viel ook samen met de stijgende populariteit van microservices: SaaS is gewoon een dienst geworden die via API toegankelijk is. Er zijn nu veel SaaS- en FOSS-tools beschikbaar op gebieden als monitoring, betalingen, load-balancing, continue integratie, waarschuwingen, functiewisseling (functiemarkering), CDN, verkeerstechniek (bijv. DNS), enz., die de afgelopen tien jaar tot bloei zijn gekomen.
Waarneembaarheid
Het is vermeldenswaard dat we er vandaag toegang toe hebben veel geavanceerder tools om applicatiegedrag te monitoren en te diagnosticeren dan ooit tevoren. Wellicht mag het monitoringsysteem Prometheus, dat in 2015 de Open Source status kreeg, genoemd worden het beste monitoringsysteem van de systemen waarmee ik heb gewerkt. Het is niet perfect, maar een aanzienlijk aantal zaken is precies op de juiste manier geïmplementeerd (bijvoorbeeld ondersteuning bij metingen). [dimensionaliteit] in het geval van metrieken).
Gedistribueerde tracering was een andere technologie die in de jaren 2010 mainstream werd, dankzij initiatieven als OpenTracing (en de opvolger daarvan OpenTelemetry). Hoewel tracering nog steeds vrij moeilijk toe te passen is, geven enkele van de nieuwste ontwikkelingen hoop dat we het ware potentieel ervan in de jaren 2020 zullen ontsluiten. (Let op: Lees ook in onze blog de vertaling van het artikel “"door dezelfde auteur.)
Op zoek naar de toekomst
Helaas zijn er veel pijnpunten die de komende tien jaar op een oplossing wachten. Hier zijn mijn gedachten erover en enkele mogelijke ideeën over hoe u er vanaf kunt komen.
Het probleem van de wet van Moore oplossen
Het einde van de schaalwet van Dennard en de vertraging achter de wet van Moore vereisen nieuwe innovaties. John Hennessy in verklaart waarom probleemverslaafden (domeinspecifiek) architecturen als TPU kunnen een van de oplossingen zijn voor het probleem van het achterblijven bij de wet van Moore. Toolkits zoals van Google lijken al een goede stap voorwaarts in deze richting te zijn:
Compilers moeten nieuwe toepassingen ondersteunen, gemakkelijk kunnen worden geporteerd naar nieuwe hardware, meerdere abstractielagen koppelen, variërend van dynamische, beheerde talen tot vectorversnellers en softwaregestuurde opslagapparaten, terwijl ze schakelaars op hoog niveau bieden voor auto-tuning, waardoor just- in functionaliteit - tijd, diagnostiek en het distribueren van foutopsporingsinformatie over het functioneren en de prestaties van systemen door de hele stapel, terwijl in de meeste gevallen prestaties worden geleverd die redelijk dicht bij de handgeschreven assembler liggen. Wij zijn van plan onze visie, voortgang en plannen voor de ontwikkeling en publieke beschikbaarheid van een dergelijke compilatie-infrastructuur te delen.
CI / CD
Hoewel de opkomst van CI een van de grootste trends van de jaren 2010 is geworden, is Jenkins nog steeds de gouden standaard voor CI.
Deze ruimte heeft dringend behoefte aan innovatie op de volgende gebieden:
- gebruikersinterface (DSL voor het coderen van testspecificaties);
- implementatiedetails die het echt schaalbaar en snel maken;
- integratie met verschillende omgevingen (staging, prod, etc.) om meer geavanceerde vormen van testen te implementeren;
- continu testen en implementeren.
Ontwikkelaarstools
Als branche zijn we begonnen met het creëren van steeds complexere en indrukwekkendere software. Als het echter om onze eigen instrumenten gaat, zou de situatie veel beter kunnen zijn.
Samenwerken en bewerken op afstand (via ssh) won enige populariteit, maar werd nooit de nieuwe standaardmanier van ontwikkelen. Als je, net als ik, het idee alleen al verwerpt behoefte een permanente verbinding met internet nodig heeft om te kunnen programmeren, dan is werken via ssh op een externe machine waarschijnlijk niet geschikt voor jou.
Lokale ontwikkelomgevingen, vooral voor ingenieurs die aan grote servicegerichte architecturen werken, vormen nog steeds een uitdaging. Sommige projecten proberen dit op te lossen, en ik zou graag willen weten hoe de meest ergonomische UX eruit zou zien voor een bepaalde gebruikssituatie.
Het zou ook interessant zijn om het concept van "draagbare omgevingen" uit te breiden naar andere ontwikkelingsgebieden, zoals de reproductie van bugs (of ) die optreden onder bepaalde omstandigheden of instellingen.
Ik zou ook graag meer innovatie zien op gebieden als semantisch en contextgevoelig zoeken naar code, tools om productie-incidenten te correleren met specifieke delen van de codebase, enz.
Computergebruik (de toekomst van PaaS)
Na de hype rond containers en serverless in de jaren 2010 is het aanbod aan oplossingen in de publieke cloud de afgelopen jaren aanzienlijk uitgebreid.
Dit roept een aantal interessante vragen op. Allereerst groeit de lijst met beschikbare opties in de publieke cloud voortdurend. Cloudserviceproviders hebben het personeel en de middelen om gemakkelijk de nieuwste ontwikkelingen in de open source-wereld bij te houden en producten uit te brengen zoals "serverless pods" (ik vermoed simpelweg door hun eigen FaaS-runtimes OCI-compatibel te maken) of andere soortgelijke mooie dingen.
Je kunt alleen maar jaloers zijn op degenen die deze cloudoplossingen gebruiken. In theorie bieden Kubernetes-cloudaanbiedingen (GKE, EKS, EKS op Fargate, enz.) cloudprovider-onafhankelijke API's voor het uitvoeren van workloads. Als u vergelijkbare producten gebruikt (ECS, Fargate, Google Cloud Run, enz.), maakt u waarschijnlijk al gebruik van de interessantste functies die de serviceprovider biedt. Bovendien zal migratie, naarmate er nieuwe producten of computerparadigma's ontstaan, waarschijnlijk eenvoudig en zonder stress verlopen.
Gezien hoe snel het aanbod van dergelijke oplossingen evolueert (het zal mij zeer verbazen als er in de nabije toekomst geen nieuwe opties verschijnen), kleine “platform”-teams (teams die betrokken zijn bij de infrastructuur en verantwoordelijk zijn voor het creëren van on-premise platforms voor bedrijven die workloads uitvoeren) zullen ongelooflijk moeilijk te concurreren zijn op het gebied van functionaliteit, gebruiksgemak en algehele betrouwbaarheid. In de jaren 2010 werd Kubernetes gezien als een tool voor het bouwen van PaaS (platform-as-a-service), dus het lijkt mij volkomen zinloos om bovenop Kubernetes een intern platform te bouwen dat dezelfde keuze, eenvoud en vrijheid biedt die beschikbaar is voor het publiek. wolken ruimte. Het framen van op containers gebaseerde PaaS als een “Kubernetes-strategie” komt neer op het opzettelijk vermijden van de meest innovatieve mogelijkheden van de cloud.
Als je kijkt naar het beschikbare vandaag computercapaciteiten wordt het duidelijk dat het creëren van je eigen PaaS, uitsluitend gebaseerd op Kubernetes, neerkomt op jezelf in een hoek zetten (geen erg vooruitstrevende aanpak, hè?). Zelfs als iemand vandaag besluit om een op Kubernetes gebaseerde gecontaineriseerde PaaS te bouwen, zal het er over een paar jaar verouderd uitzien vergeleken met de mogelijkheden in de cloud. Hoewel Kubernetes begon als een open source-project, is de voorloper en inspiratiebron een interne Google-tool. Het werd echter oorspronkelijk ontwikkeld in het begin/midden van de jaren 2000, toen het computerlandschap compleet anders was.
Bovendien hoeven bedrijven, in zeer brede zin, geen experts te worden in het runnen van een Kubernetes-cluster, noch hoeven ze hun eigen datacenters te bouwen en te onderhouden. Het bieden van een betrouwbare computerbasis is een kernuitdaging aanbieders van clouddiensten.
Ten slotte heb ik het gevoel dat we als sector een beetje achteruit zijn gegaan in termen van interactie ervaring (). Heroku werd gelanceerd in 2007 en is nog steeds een van de meest makkelijk te gebruiken platforms. Het valt niet te ontkennen dat Kubernetes veel krachtiger, uitbreidbaarder en programmeerbaarder is, maar ik mis hoe gemakkelijk het is om aan de slag te gaan en te implementeren in Heroku. Om dit platform te gebruiken, hoef je alleen Git te kennen.
Dit alles brengt mij tot de volgende conclusie: we hebben betere abstracties op een hoger niveau nodig om te kunnen werken (dit geldt vooral voor abstracties op het hoogste niveau).
De juiste API op het hoogste niveau
Docker is een mooi voorbeeld van de noodzaak om tegelijkertijd de belangen beter te scheiden correcte implementatie van de API op het hoogste niveau.
Het probleem met Docker is dat (tenminste) de doelstellingen van het project aanvankelijk te breed waren: allemaal ter wille van het oplossen van het compatibiliteitsprobleem (“werkt op mijn machine”) met behulp van containertechnologie. Docker was een afbeeldingsformaat, een runtime met een eigen virtueel netwerk, een CLI-tool, een daemon die als root draaide en nog veel meer. De berichtenuitwisseling was er in ieder geval meer verwarrend, om nog maar te zwijgen van "lichtgewicht VM's", cgroups, naamruimten, talloze beveiligingsproblemen en functies vermengd met de marketingoproep om "elke applicatie overal te bouwen, te leveren en uit te voeren".
Zoals bij alle goede abstracties kost het tijd (en ervaring en pijn) om verschillende problemen op te splitsen in logische lagen die met elkaar kunnen worden gecombineerd. Helaas, voordat Docker een vergelijkbare volwassenheid kon bereiken, ging Kubernetes de strijd aan. Het monopoliseerde de hypecyclus zozeer dat nu iedereen de veranderingen in het Kubernetes-ecosysteem probeerde bij te houden, en het container-ecosysteem een secundaire status kreeg.
Kubernetes deelt veel van dezelfde problemen als Docker. Ondanks al het gepraat over coole en composeerbare abstractie, verschillende taken in lagen verdelen niet erg goed ingekapseld. In de kern is het een containerorkestrator die containers op een cluster van verschillende machines draait. Dit is een taak van vrij laag niveau, die alleen van toepassing is op technici die het cluster bedienen. Aan de andere kant is Kubernetes dat ook abstractie van het hoogste niveau, een CLI-tool waarmee gebruikers communiceren via YAML.
Docker was (en is nog steeds) koel ontwikkelingsinstrument, ondanks al zijn tekortkomingen. In een poging om alle "hazen" tegelijk bij te houden, slaagden de ontwikkelaars erin het correct te implementeren abstractie op het hoogste niveau. Met abstractie op het hoogste niveau bedoel ik een subset functionaliteit waar de doelgroep (in dit geval ontwikkelaars die het grootste deel van hun tijd in hun lokale ontwikkelomgevingen doorbrachten) echt in geïnteresseerd was en die out-of-the-box prima werkte.
Dockerfile en CLI-hulpprogramma docker zou een voorbeeld moeten zijn van hoe je een goede “gebruikerservaring op het hoogste niveau” kunt opbouwen. Een gewone ontwikkelaar kan met Docker aan de slag zonder iets van de fijne kneepjes te weten implementaties die bijdragen aan operationele ervaringzoals naamruimten, cgroups, geheugen- en CPU-limieten, enz. Uiteindelijk verschilt het schrijven van een Dockerfile niet veel van het schrijven van een shellscript.
Kubernetes is bedoeld voor verschillende doelgroepen:
- clusterbeheerders;
- software-ingenieurs die zich bezighouden met infrastructuurproblemen, de mogelijkheden van Kubernetes uitbreiden en daarop gebaseerde platforms creëren;
- eindgebruikers die communiceren met Kubernetes via
kubectl.
De ‘one API fits all’-aanpak van Kubernetes presenteert een onvoldoende ingekapselde ‘berg van complexiteit’ zonder richtlijnen over hoe deze moet worden geschaald. Dit alles leidt tot een onterecht langdurig leertraject. Hoe Adam Jacob: “Docker zorgde voor een transformatieve gebruikerservaring die nog nooit is overtroffen. Vraag iedereen die een K8s gebruikt of hij of zij zou willen dat deze net zo zou werken als hun eerste docker run. Het antwoord zal ja zijn":
Ik zou willen stellen dat de meeste infrastructuurtechnologie tegenwoordig van een te laag niveau is (en daarom als "te complex" wordt beschouwd). Kubernetes wordt op een vrij laag niveau geïmplementeerd. Gedistribueerde tracering in zijn (veel overspanningen aan elkaar gestikt om een traceview te vormen) wordt ook op een te laag niveau geïmplementeerd. Ontwikkelaarstools die de ‘abstracties op het hoogste niveau’ implementeren, zijn doorgaans het meest succesvol. Deze conclusie geldt in een verrassend aantal gevallen (als de technologie te complex of moeilijk te gebruiken is, moet de “hoogste API/UI” voor die technologie nog ontdekt worden).
Op dit moment is het cloud-native ecosysteem verwarrend vanwege de focus op een laag niveau. Als industrie moeten we innoveren, experimenteren en leren hoe het juiste niveau van ‘maximale, hoogste abstractie’ eruit ziet.
Detailhandel
In de jaren 2010 bleef de digitale winkelervaring grotendeels onveranderd. Aan de ene kant zou het gemak van online winkelen de traditionele winkels moeten hebben getroffen, aan de andere kant is online winkelen in tien jaar tijd fundamenteel vrijwel onveranderd gebleven.
Hoewel ik geen specifieke ideeën heb over hoe deze sector zich de komende tien jaar zal ontwikkelen, zou ik zeer teleurgesteld zijn als we in 2030 op dezelfde manier winkelen als in 2020.
Journalistiek
Ik raak steeds meer gedesillusioneerd door de toestand van de mondiale journalistiek. Het wordt steeds moeilijker om onpartijdige nieuwsbronnen te vinden die objectief en nauwgezet rapporteren. Heel vaak is de grens tussen het nieuws zelf en de meningen erover vaag. In de regel wordt informatie op een bevooroordeelde manier gepresenteerd. Dit geldt vooral in sommige landen waar er historisch gezien geen scheiding is geweest tussen nieuws en opinie. In een recent artikel gepubliceerd na de laatste algemene verkiezingen in Groot-Brittannië, zegt Alan Russell, voormalig redacteur van The Guardian, :
Het belangrijkste punt is dat ik jarenlang naar Amerikaanse kranten keek en medelijden had met mijn collega's daar, die als enige verantwoordelijk waren voor het nieuws en het commentaar aan totaal andere mensen overlieten. Na verloop van tijd veranderde medelijden echter in jaloezie. Ik denk nu dat alle Britse nationale kranten hun verantwoordelijkheid voor nieuws moeten scheiden van hun verantwoordelijkheid voor commentaar. Helaas is het voor de gemiddelde lezer – vooral online lezers – te moeilijk om het verschil te onderscheiden.
Gezien de nogal twijfelachtige reputatie van Silicon Valley als het om ethiek gaat, zou ik er nooit op vertrouwen dat technologie de journalistiek een ‘revolutie’ zou brengen. Dat gezegd hebbende, zou ik (en veel van mijn vrienden) blij zijn als er een onpartijdige, ongeïnteresseerde en betrouwbare nieuwsbron was. Hoewel ik geen idee heb hoe zo’n platform eruit zou kunnen zien, ben ik ervan overtuigd dat in een tijdperk waarin de waarheid steeds moeilijker te onderscheiden wordt, de behoefte aan eerlijke journalistiek groter is dan ooit.
Sociale Netwerken
Sociale media en gemeenschapsnieuwsplatforms zijn de belangrijkste informatiebron voor veel mensen over de hele wereld, en het gebrek aan nauwkeurigheid en de onwil van sommige platforms om zelfs maar basisfeiten te controleren heeft tot rampzalige gevolgen geleid, zoals genocide, verkiezingsinmenging en meer. .
Sociale media zijn ook de krachtigste mediatool die ooit heeft bestaan. Ze hebben de politieke praktijk radicaal veranderd. Ze hebben de reclame veranderd. Ze veranderden de popcultuur (bijvoorbeeld de belangrijkste bijdrage aan de ontwikkeling van de zogenaamde annuleringscultuur). [culturen van ostracisme - ca. vert.] sociale netwerken dragen bij). Critici beweren dat sociale media een vruchtbare voedingsbodem zijn gebleken voor snelle en grillige veranderingen in morele waarden, maar dat het ook leden van gemarginaliseerde groepen de mogelijkheid heeft geboden zich te organiseren op manieren die ze nog nooit eerder hebben gehad. In wezen hebben sociale media de manier veranderd waarop mensen communiceren en zich uitdrukken in de XNUMXe eeuw.
Ik geloof echter ook dat sociale media de ergste menselijke impulsen naar boven brengen. Overweging en bedachtzaamheid worden vaak verwaarloosd ten gunste van populariteit, en het wordt bijna onmogelijk om op redelijke gronden het oneens te zijn met bepaalde meningen en standpunten. Polarisatie loopt vaak uit de hand, waardoor het publiek eenvoudigweg geen individuele meningen hoort, terwijl absolutisten de kwesties van online-etiquette en aanvaardbaarheid beheersen.
Ik vraag me af of het mogelijk is om een “beter” platform te creëren dat discussies van betere kwaliteit bevordert? Het is tenslotte wat de ‘engagement’ drijft die vaak de grootste winst voor deze platforms oplevert. Hoe Kara Swisher in de New York Times:
Het is mogelijk digitale interacties te ontwikkelen zonder haat en intolerantie uit te lokken. De reden dat de meeste sociale-mediasites zo giftig lijken, is omdat ze zijn gebouwd voor snelheid, viraliteit en aandacht, in plaats van inhoud en nauwkeurigheid.
Het zou echt ongelukkig zijn als over een paar decennia de enige erfenis van sociale media de erosie van nuance en gepastheid in het publieke discours zou zijn.
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com