Shën. përk.: Kyç kyç i kësaj artikulli që u bë hit në Medium, është një përmbledhje e ndryshimeve kryesore (nga viti 2010 deri në 2019) në botën e gjuhëve të programimit dhe ekosistemit të teknologjive të lidhura (duke u fokusuar veçanërisht në Docker dhe Kubernetes). Autori origjinal është Cindy Sridharan, e cila specializohet në mjete për zhvilluesit dhe sistemet e shpërndara — në veçanti, ajo ka shkruar librin «Distribuar Systems Observability» — dhe është mjaft popullore në hapësirën internetore mes specialistëve të IT-së, veçanërisht ata që janë të interesuar për temën cloud native.
Viti 2019 përfundoi, prandaj do të doja të ndaja mendimet e mia për disa nga arritjet dhe inovacionet më të rëndësishme teknologjike të dekadës së kaluar. Për më tepër, do të përpiqem të shoh pak në të ardhmen dhe të identifikoj problemet dhe mundësitë kryesore të dekadës që vjen.
Dua të theksoj që në këtë artikull nuk po mbuloj ndryshimet në fusha si shkenca e të dhënave (data science), inteligjenca artificiale, inxhinieria frontend etj., pasi që unë personalisht nuk kam përvojë të mjaftueshme në to.
Tipizimi po godet mbrapsht
Një nga tendencat më pozitive të viteve 2010 ishte rilindja e gjuhëve me tipizim statik. Megjithatë, këto gjuhë nuk kanë humbur kurrë (C++ dhe Java janë të kërkuara edhe sot; ato ishin dominues edhe dhjetë vjet më parë), por gjuhët me tipizim dinamik (dinamikët) përjetuan një rritje të madhe në popullaritet pas lindjes së lëvizjes Ruby on Rails në vitin 2005. Kjo rritje arriti kulmin në vitin 2009 me hapjen e burimit të kodit Node.js, e cila bëri që JavaScript në server të bëhej realitet.
Me kalimin e kohës, gjuhët dinamike humbën paksa tërheqjen e tyre në fushën e krijimit të softuerit server. Gjuha Go, e popullarizuar gjatë revolucionit të konteinerëve, dukej më e përshtatshme për krijimin e serverëve me performancë të lartë dhe efikasitet burimesh me procesim paralel të informacionit (këtë edhe krijuesi i Node.js).
Rust, i prezantuar në vitin 2010, përfshiu arritjet në në përpjekje për t'u bërë një gjuhë e sigurt dhe e tipizuar. Në gjysmën e parë të dekadës, qasja ndaj Rust në industrinë ishte mjaft e ftohtë, megjithatë në gjysmën e dytë, popullariteti i tij u rrit ndjeshëm. Disa nga shembujt e dallueshëm të përdorimit të Rust janë aplikimi për , (ne e kemi përmendur atë në — shënim i përkthyesit.), kompilatorin WebAssembly të paracaktuar nga Fastly (është tani pjesë e bytecodealliance) dhe të tjerë. Në kushtet kur Microsoft po shqyrton mundësinë për të riparuar disa pjesë të sistemit operativ Windows në Rust, mund të themi me siguri se në vitet 2020 ky gjuhë e pritet një të ardhme të ndritur.
Edhe gjuhët dinamike morën mundësi të reja si (optional types). Për herë të parë ata u realizuan në TypeScript — një gjuhë që lejon krijimin e kodit të tipizuar dhe kompilimin e tij në JavaScript. PHP, Ruby dhe Python morën sistemet e tyre të tipizimi opsional (, ), të cilat përdoren me sukses në .
Kthimi i SQL në NoSQL
NoSQL — një tjetër teknologji që në fillim të dekadës ishte shumë më e popullarizuar se sa në fund. Mendoj se ka dy arsye për këtë.
Së pari, modeli NoSQL pa skema, transaksione dhe më garantime më të dobëta për qëndrueshmërinë, u tregua më i ndërlikuar në zbatuar se sa modeli SQL. Në me titull “Pse duhet të zgjidhni qëndrueshmërinë e fortë, sa herë që është e mundur” (Why you should pick strong consistency, whenever possible) Google shkruan:
Një nga gjërat që ne mësuam në Google është se kodi i aplikacionit është më i thjeshtë dhe afatet e zhvillimit janë më të shkurtra, nëse inxhinierët mund të mbështeten në depozitat ekzistuese për trajtimin e transaksioneve të ndërlikuara dhe për të mbajtur rregullin e të dhënave. Duke cituar dokumentacionin origjinal të Spanner, “ne besojmë se është më mirë nëse programuesit të heqin dorë nga problemet e performancës së aplikacionit për shkak të abuzimeve me transaksionet kur shfaqen ngushticat, sesa të mbajnë vazhdimisht në mendje mungesën e transaksioneve.”
Arsyeja e dytë lidhet me rritjen e bazave të të dhënave SQL të ‘shkallëzuara’ (si dhe ) në hapësirën publike të cloud, si dhe alternativave me burim të hapur si CockroachDB (për të cilën ne gjithashtu — shën. përkth.), që zgjidhin shumë nga problemet teknike, për shkak të të cilave bazat tradicionale SQL ‘nuk u shkallëzuan’. Edhe MongoDB, që dikur ishte shpalla e lëvizjes NoSQL, tani transaksione të shpërndara.
Për situatat që kërkojnë atomikë operacionesh për lexim dhe shkruar në disa dokumente (në një ose disa koleksione), MongoDB mbështet transaksionet me shumë dokumente. Në rastin e transaksioneve të shpërndara, transaksionet mund të përdoren për një sërë operacionesh, koleksionesh, bazash të dhënash, dokumentesh dhe shard-esh.
Streamifikimi total
Apache Kafka, pa dyshim, është bërë një nga shpikjet më të rëndësishme të dekadës së kaluar. Kodi i tij burimor u bë publik në janar 2011, dhe që nga ato kohë Kafka ka sjellë një revolucion të vërtetë në mënyrën se si bizneset punojnë me të dhënat. Kafka është përdorur nga të gjitha kompanitë ku kam punuar, duke filluar nga start-up-et dhe duke përfunduar me korporatat e mëdha. Garancitë dhe mundësitë e ofruara (pub-sub, rrjedha, arkitekturë e orientuar nga ngjarjet) përdoren në një gamë të gjerë detyrash: nga organizimi i ruajtjes së të dhënave deri te monitorimi dhe analizat në kohë reale, të kërkuara në shumë fusha si financat, shëndetësia, sektori publik, tregtia me pakicë etj.
Integrimi i vazhdueshëm (dhe në një masë më të vogël ndërtimi i vazhdueshëm)
Integrimi i vazhdueshëm (Continuous Integration) nuk ka lindur vetëm në 10 vitet e fundit, megjithatë, gjatë dekadës së kaluar, ai u përhap në një masë të tillë, sa që u bë pjesë e standardeve të punës (ekzekutimi i testeve në të gjitha kërkesat për tërheqje). Konsolidimi i GitHub-it si një platformë për zhvillimin dhe ruajtjen e kodit dhe, më e rëndësishmja, zhvillimi i një procesi pune të bazuar në do të thotë që ekzekutimi i testeve para pranimit të kërkesës për tërheqje në master është një i vetmi proces pune në zhvillim, i njohur për inxhinierët që e filluan karrierën e tyre në 10 vitet e fundit.
Ndërtimi i vazhdueshëm (Continuous Deployment; shpërndarja e çdo komiti në momentin dhe në formën që ai arrin në master) nuk është aq i përhapur sa integrimi i vazhdueshëm. Megjithatë, me një sërë API-sh të ndryshme në cloud për shpërndarjen, rritjen e popullaritetit të platformave si Kubernetes (që ofrojnë një API të standardizuar për shpërndarje) dhe shfaqjen e mjeteve multi-platformë, multi-cloud si Spinnaker (ndërtuar mbi ato API të standardizuara), proceset e shpërndarjes janë bërë më të automatizuara, të rregullta dhe, në përgjithësi, më të sigurta.
Kontejnerët
En konteinerët mund të quhen ndoshta teknologjia më e flasur, më e reklamuar dhe më e keqkuptuar e viteve 2010. Megjithatë, ata janë një nga inovacionet më të rëndësishme të dekadës së fundit. Pjesërisht, arsyeja për gjithë këtë kaos që kemi përjetuar erdhi nga sinjalet e përziera që merrnim nga të gjitha anët. Tani, pasi zhurma është qetësuar pak, disa aspekte kanë fituar nuanca më të qarta.
Konteinerët nuk u bënë të njohur ashtu siç do të pritej, për shkak se janë mënyra më e mirë për të drejtuar një aplikacion që plotëson kërkesat e komunitetit global të zhvilluesve. Ata u bënë të njohur sepse përputheshin me kërkesën në treg për një mjet që zgjidh një problem tërësisht të ndryshëm. Docker doli të jetë fantastik si një mjet për zhvillim, duke zgjidhur një problem të rëndësishëm të kompatibilitetit (‘punon në makinën time’).
Më saktësisht, revolucioni u ndodhi Docker-image, sepse zgjidhi problemin e barazisë midis mjediseve dhe ofroi vërtetueshmërinë jo vetëm të skedarit të aplikacionit, por edhe të të gjitha varësive të tij programore dhe operative. Fakti që ky mjet në një mënyrë stimuluar popullaritetin e 'konteinerëve', të cilët në thelb përfaqësojnë një detaj mjaft të ulët të implementimit, për mua mbetet ndoshta misteri më i madh i dekadës së kaluar.
Pa Server
Jam gati të debatoj se shfaqja e kompjuterëve 'pa server' është madje më e rëndësishme se konteinerët, pasi ajo vërtet e bën të mundur realizimin e ëndrrës për kompresim sipas kërkesës (on-demand). Në pesë vitet e fundit kam parë zgjerimin gradual të aplikimit të qasjes pa server (u shtua mbështetje për gjuhë dhe mjedise ekzekutimi të reja). Shfaqja e produkteve si Azure Durable Functions, duket si një hap i saktë në realizimin e funksioneve stateful (duke zgjidhur përveç kësaj , që lidhen me kufizimet FaaS). Me interes do të shoh se si do të evoluojë kjo paradigmë e re në vitet e ardhshme.
Automatizimi
Ndoshta, më shumë se çdo gjë tjetër, ky trend ka sjellë përfitime për komunitetin e inxhinierëve të operacioneve, pasi ai ka mundësuar realizimin e koncepteve si "infrastruktura si kod" (IaC). Për më tepër, pasioni për automatizimin ka ndodhur paralel me rritjen e "kulturës SRE", qëllimi i së cilës është një qasje më programore ndaj operacioneve.
API-ifikimi i gjithanshëm
Një veçori tjetër interesante e dekadës së kaluar ishte API-ifikimi i detyrave të ndryshme të zhvillimit. API-të e mira dhe fleksibile lejojnë zhvilluesit të krijojnë procese punë dhe mjete inovative, të cilat, nga ana e tyre, ndihmojnë në mbështetje dhe përmirësojnë lehtësinë e punës.
Për më tepër, API-ifikimi është hapi i parë drejt SaaS-ifikimit të ndonjë funksionaliteti ose mjeti. Ky trend është dhënë paralelisht me rritjen në popullaritetin e mikroshërbimeve: SaaS është bërë thjesht një shërbim tjetër që mund të përdoret përmes API. Aktualisht, ekzistojnë shumë mjete SaaS dhe FOSS në fusha si monitorimi, pagesat, balancimi i ngarkesës, integrimi i vazhdueshëm, njoftimet, ndërrimi i funksionalitetit (feature flagging), CDN, inxhinierimi i trafikut (siç është DNS) etj., të cilat kanë lulëzuar në dekadën e kaluar. (feature flagging), CDN, inxhinierimi i trafikut (p.sh., DNS) etj., të cilat kanë lulëzuar në dekadën e kaluar.
Vëzhgimi
Është e rëndësishme të theksohet se sot ne kemi në dispozicion mjete shumë më të avancuara për monitorimin dhe diagnostikimin e sjelljes së aplikacioneve, se kurrë më parë. Sistemi i monitorimit Prometheus, i cili u bë Open Source në vitin 2015, mund të quhet ndoshta më i miri sistem monitorimi nga ato me të cilat kam pasur mundësinë të punoj. Nuk është i përsosur, megjithatë numri i konsiderueshëm i gjërave në të janë realizuar në mënyrë të saktë (p.sh., mbështetja për matjet [dimensionality] në rastin e metrikave).
Gjetja e shpërndarë u bë një tjetër teknologji që doli në çdo qendër në vitet 2010 falë nismave si OpenTracing (dhe pasardhëses së saj OpenTelemetry). Ndërsa gjurmimi ende mbetet mjaft sfidues për t'u aplikuar, disa nga zhvillimet e fundit na japin shpresë se në vitet 2020 do ta zbulojmë potencialin e saj të vërtetë. (Shënim përkthimi: Lexoni gjithashtu në blogun tonë përkthimin e artikullit "" të këtij autori.)
Duke shikuar përpara
Çfarë ndodh, ka shumë probleme që kërkojnë zgjidhje në dekadën që po vjen. Këtu janë mendimet e mia rreth tyre dhe disa ide potenciale për t'i zgjidhur.
Zgjidhja e problemit të ligjit të Murit
Mbyllja e ligjit të përmasave të Denard dhe prapambetjeja nga ligji i Murit kërkojnë inovacione të reja. John Hennessy në shpjegon pse arkitekturat e varura nga problemet (domain specific) si TPU mund të jenë një nga zgjidhjet për prapambetje nga ligji i Murit. Të gjithë setet e mjeteve si nga Google tashmë duken si një hap i mirë përpara në këtë drejtim:
Kompilatorët duhet të mbështesin aplikacione të reja, të jenë lehtësisht të portueshëm në harduer të ri, të lidhin shumë nivele të abstraksionit, duke filluar nga gjuhët dinamike të menaxhuara deri te akceleratorët vektorë dhe kujtesat e menaxhuara me program, ndërsa ofrojnë ndërprerës të nivelit të lartë për optimizimin automatik, duke siguruar funksionalitetin just-in-time, diagnostikimin dhe shpërndarjen e informacionit për ndihmën e funksionit dhe performancën e sistemeve në të gjithë stack-un, dhe në të njëjtën kohë në shumicën e rasteve ofrojnë performancë të mjaftueshme për t'u afruar me atë të shkruar për dorë me assembler. Ne kemi për qëllim të ndajmë vizionin tonë, përparimin dhe planet për zhvillimin dhe aksesin publik të kësaj infrastrukture kompiluese.
CI/CD
Ndërsa rritja e popullaritetit të CI ka qenë një nga trendet kryesore të viteve 2010, Jenkins vazhdon të jetë standardi i artë i CI.
Ky hapësirë ka nevojë urgjente për inovacione në fushat e mëposhtme:
- interfaca e përdoruesit (DSL për kodimin e specifikacioneve të testeve);
- detaljet e implementimit që do ta bëjnë atë të vërtetë përmasash dhe të shpejtë;
- integrimi me ambientet të ndryshme (staging, prodhimi etj.) për të realizuar forma më të avancuara të testimit;
- verifikim dhe shpërndarje të vazhdueshme.
Mjetet e zhvilluesve
Si industri, kemi filluar të krijojmë software gjithnjë e më kompleks dhe të impresionueshëm. Sidoqoftë, kur bëhet fjalë për mjetet tona, mund të themi se situata mund të ishte shumë më e mirë.
Redaktimi i përbashkët dhe të largët (përmes ssh) ka fituar disa popullaritet, por nuk është bërë standardi i ri i zhvillimit. Nëse ju, ashtu si unë, e refuzoni idenë e nevojës për një lidhje të vazhdueshme me internetin vetëm për të pasur mundësinë të programoni, atëherë puna përmes ssh në një makinë të largët vështirë se do t'ju përshtatet.
Mjediset lokale të zhvillimit, veçanërisht për inxhinierët që punojnë në arkitektura të mëdha të orientuara nga shërbimet, vazhdojnë të mbeten një problem. Disa projekte përpiqen ta zgjidhin këtë, dhe do të më interesonte të dija si do të duket UX më ergonomik për këtë skenar përdorimi.
Gjithashtu, do të ishte interesante të zhvillohej koncepti i "mjediseve të transportueshme" në fusha të tjera të zhvillimit, si përsëritja e gabimeve (ose ), që ndodhin në kushte të caktuara ose me cilësime specifike.
Gjithashtu, dëshiroj të shoh më shumë inovacione në fusha të tilla si kërkimi semantik dhe kontekstual i kodit, mjetet që lejojnë lidhjen e incidenteve në prodhim me pjesë specifike të bazës së kodit, etj.
Llogaritjet (të ardhmen e PaaS)
Në mes të gjithë entuziazmit për enët dhe serverless në vitet 2010, spektri i zgjidhjeve në hapësirën publike të cloud është zgjeruar ndjeshëm gjatë viteve të fundit.
Si rezultat, lindin disa pyetje interesante. Së pari, lista e mundësive të disponueshme në cloud-in publik po rritet vazhdimisht. Ofruesit e shërbimeve të cloud kanë personel dhe burime që i lejojnë ata të qëndrojnë lehtësisht në hap me arritjet më të fundit në botën e Open Source dhe të lëshojnë produkte si "pod-et serverless" (mendoj, thjesht duke bërë runtime-t e tyre FaaS kompatibilë me OCI) ose gjëra të tjera të çuditshme të ngjashme.
Ata të cilët përdorin këto zgjidhje cloud mund t'u kenë zili. Në teori, ofertat cloud si Kubernetes (GKE, EKS, EKS në Fargate etj.) ofrojnë API të pavarura nga ofruesi i cloud për të ekzekutuar ngarkesa pune. Nëse po përdorni produkte të tilla (ECS, Fargate, Google Cloud Run etj.), ka të ngjarë që tashmë të jeni duke shfrytëzuar maksimalisht funksionet më interesante që ofron ofruesi i shërbimeve. Për më tepër, me shfaqjen e produkteve të reja ose paradigmat kompjuterike, migrimi do të jetë me siguri i lehtë dhe pa shqetësime.
Duke marrë parasysh se sa shpejt po zhvillohet spektri i këtyre zgjidhjeve (do të isha shumë i habitur nëse brenda pak kohësh nuk do të shfaqeshin disa opsione të reja), ekipet e vogla «platformë» (grupet që lidhen me infrastrukturën dhe janë përgjegjëse për krijimin e platformave në vend për të ekzekutuar ngarkesa pune në kompani) do të kenë vështirësi të mëdha për të konkurruar në lidhje me mundësitë funksionale, lehtësinë e përdorimit dhe qëndrueshmërinë e përgjithshme. Vitët 2010 kaluan nën shenjën e Kubernetes si një mjet për krijimin e PaaS (platformë si shërbim), prandaj mua më duket e pamend të krijosh një platformë të brendshme mbi Kubernetes që ofron të njëjtat mundësi zgjedhjeje, lehtësi dhe liri si ato që janë të disponueshme në hapësirën publike të cloud. Koncepti i PaaS që bazohet në «kontejnerë» si një «strategji Kubernetes» është njëlloj si të heqësh dorë me vetëdije nga funksionalitetet më inovative të cloud.
Nëse shohim mundësitë e disponueshme sot
në fushën e llogaritjeve, bëhet e qartë se krijimi i një PaaS ekskluzivisht mbi Kubernetes është njësoj si të vetëizolohesh (nuk është një qasje shumë parashikuese, apo?). Edhe nëse dikush vendos të krijojë një PaaS konteiner mbi Kubernetes sot, pas disa vitesh ajo do të duket e përmbushur përballë mundësive të cloud. Megjithëse Kubernetes filloi si një projekt me kod të hapur, themeluesi dhe frymëzimi i tij vjen nga një instrument përkatës i brendshëm i Google. Sidoqoftë, ai u zhvillua fillimisht në fillim të/vitet '2000, kur peizazhi i llogaritjeve ishte krejt ndryshe. të ofruesve të shërbimeve cloud..
Së fundi, më ndjehet se kemi regresuar pak si industri në aspektin përvojës së bashkëpunimit. (). Heroku u lançua në vitin 2007 dhe deri tani mbetet një nga platforma më të lehta për t'u përdorur. Nuk ka dyshim, Kubernetes ka shumë më shumë fuqinë, shkallëzueshmërinë dhe programueshmërinë, megjithatë më mungon sa e thjeshtë ishte të fillosh dhe të realizosh një implementim në Heroku. Për të përdorur këtë platformë, mjafton të njihni Git.
Të gjitha këto më çojnë në këtë përfundim: për punën tonë, na nevojiten abstraksione më të mira, më të nivelit të lartë (sidomos kjo është e vërtetë për abstraksionet e nivelit më të lartë.).
API i duhur i nivelit më të lartë.
Docker është një shembull i shkëlqyer i nevojës për ndarje më të mirë të detyrave, ndërkohë që implementimi i saktë i API-së së nivelit më të lartë..
Problemi me Docker-in është se (të paktën) fillimisht, qëllimet ishin shumë globale: gjithçka për të zgjidhur problemin e përputhshmërisë (‘punon në makinën time’) me teknologjinë e konteinerëve. Docker-i ishte si format i imazheve, ashtu edhe runtime me rrjetin e tij virtual, si mjet CLI, si dhe demon që punonte nën root, dhe shumë gjëra të tjera. Në çdo rast, komunikimi ishte më i ngatërruar, për të mos folur për ‘VM-të e lehta’, grupet kontrolluese, hapësirat e emrave, shumë probleme sigurie dhe funksione të përziera me thirrjen marketingu ‘të krijoni, ofroni, ekzekutoni çdo aplikacion kudo’.
Si me të gjitha abstraksionet e mira, duhet kohë (po ashtu edhe përvojë dhe dhembje) për të ndarë problemet e ndryshme në nivele logjike që mund të kombinohen me njëra-tjetrën. Fatkeqësisht, para se Docker'i të arrinte një nivel të tillë pjekurie, Kubernetes hyri në skenë. Ai monopolizoi aq shumë ciklin e hype-it, saqë tani të gjithë po përpiqeshin të mos mbeteshin prapa ndryshimeve në ekosistemin e Kubernetes, dhe ekosistemi i konteinerëve mori një status dytësor.
Kubernetes ndan shumë aspekte ndahet me problemet e Docker-it. Pavarësisht të gjitha bisedave për abstrahimin e bukur dhe të ndarë (composable), ndarja e detyrave të ndryshme në nivele nuk është shumë e inkapsuluar. Në thelb, kjo është një orkestrator kontejnerësh që ekzekuton kontejnerë në një grumbull të përbërë nga makina të ndryshme. Kjo është një detyrë relativisht me nivel të ulët, që aplikohet vetëm për inxhinierët që menaxhojnë grumbullin. Nga ana tjetër, Kubernetes është gjithashtu një abstraksion në nivel të lartë, një mjet CLI, me të cilin përdoruesit ndërveprojnë përmes YAML.
Docker ka qenë (dhe mbetet) një mjet të shkëlqyer për zhvillim, pavarësisht të gjitha disavantazheve të tij. Në përpjekjen për të ndjekur të gjitha "dritat" njëkohësisht, zhvilluesit e tij arritën të implementojnë siç duhet një abstraksion në nivel të lartë. Me abstraksionin në nivel të lartë kuptoj nëngrup funksionalitetin në të cilin publikohet me të vërtetë interesi i audiencës së synuar (në këtë rast zhvilluesit, të cilët kalojnë shumicën e kohës në mjediset e tyre lokale të zhvillimit) dhe që funksionon shkëlqyer "nga kutia".
Dockerfile dhe mjeti CLI docker duhet të bëhen shembuj të ndërtimit të një "ndërfaqeje të përdoruesit në nivel të lartë". Një zhvillues i zakonshëm mund të fillojë të punojë me Docker-in, pa ditur asgjë për nuancat e implementimeve që ndikojnë në përvojën operative, si hapësirat e emrave, grupet e kontrollit, kufizimet e memories dhe CPU etj. Në fund të ditës, shkruajta e një Dockerfile nuk ndryshon shumë nga shkruajtja e një skenari shell.
Kubernetes është e destinuar për grupe të ndryshme të synuara:
- administratorët e grumbullit;
- inxhinierët e softuerit që merret me infrastrukturën, që zgjedhin mundësitë e Kubernetes-it dhe krijojnë platforma mbi të;
- përdoruesit përfundimtarë që ndërveprojnë me Kubernetes përmes
kubectl.
Qasja "një API përshtatet për të gjitha", e aplikuar në Kubernetes, përbën një "mal të kompleksitetit" që nuk është mjaft i inkapsuluar pa udhëzime se si të shkallëzohet. E gjithë kjo çon në një trajektore mësimi që është më e gjatë se ç’duhet. Siç thotë Adam Jacob, "Docker sjell një përvojë transformuese për përdoruesit, e cila ende nuk është tejkaluar. Pyetni këdo që përdor K8s nëse dëshironin që të punonte si i pari docker run. Përgjigja do të ishte po:
Do të thoja se pjesa kryesore e teknologjisë infrastrukturore sot është shumë në nivel të ulët (dhe, si rezultat, konsiderohet "shumë e komplikuar"). Kubernetes është i implementuar në një nivel të konsiderueshëm të ulët. Ndjekja e shpërndarë në formën e saj aktuale Tani për tani, ekosistemi cloud native është konfuz për përqendrimin e tij në nivelin e ulët. Si industri, ne duhet të nxjerrim inovacione, të eksperimentojmë dhe të mësojmë se si duket niveli i duhur "maksimal, më i lartë i abstraksionit".
Gjatë viteve 2010, përvoja digjitale në shitjet me ndërhyrje ka ndryshuar pak a shumë. Nga njëra anë, lehtësia e blerjeve online duhej të kishte goditur dyqanet tradicionale, ndërsa nga ana tjetër — blerjet online themelore gati as nuk janë ndryshuar për një dekadë.
Tregtia me pakicë
Edhe pse nuk kam mendime specifike për zhvillimin e kësaj industrie në dekadën e ardhshme, do të isha shumë e zhgënjyer nëse në vitin 2030 do të bëjmë bleje ashtu siç bëjmë në 2020.
Gazetaria
Po zhgënjehem gjithnjë e më shumë nga gjendja e gazetarisë globale. Po bëhet gjithnjë e më e vështirë për të gjetur burime lajmesh të paanshme, që transmetojnë objektivisht dhe me pedanteri. Shpesh, kufiri midis lajmit dhe mendimit për të fshihet. Informacioni zakonisht paraqitet në mënyrë të njëanshme. Kjo vlen veçanërisht për disa vende, ku historikisht nuk ka ekzistuar ndarja midis lajmit dhe mendimit për të. Në një artikull të fundit, të publikuar pas zgjedhjeve të fundit të përgjithshme në Britaninë e Madhe, Alan Rusbridger, ish-redaktor i The Guardian,
Po më shumë se sa ndiej zhgënjim për gjendjen e gazetarisë botërore. Po bëhet gjithnjë e më e vështirë të gjej burime informimi të paanshme që njësoj raportojnë objektivisht dhe me kujdes. Shumë shpesh, kufiri mes lajmit dhe opinionit mbi të fshihet. Si rregull, informacioni paraqitet në një mënyrë të njëanshme. Kjo është veçanërisht e vërtetë për disa vende ku historikisht nuk ka ekzistuar një ndarje midis lajmit dhe opinionit për të. Në një artikull të fundit, të publikuar pas zgjedhjeve të fundit në Britaninë e Madhe, Alan Rusbridger, ish-redaktor i The Guardian, :
Ideja kryesore është se për shumë vite e kam parë shtypin amerikan dhe kam pasur simpati për kolegët e atjeshëm, të cilët janë përgjegjës vetëm për lajmet, duke lënë komentimin për njerëz krejtësisht të tjerë. Megjithatë, me kalimin e kohës, ndjenja e simpatisë është shndërruar në xhelozi. Tani mendoj se të gjitha gazetat e mëdha britanike duhet të ndajnë përgjegjësinë për lajmet nga ajo për komentet. Fatkeqësisht, për lexuesin e zakonshëm – veçanërisht lexuesin online – është mjaft e vështirë të dallojë diferencën.
Duke marrë parasysh reputacionin mjaft të dyshimtë të Silicon Valley, kur bëhet fjalë për etikën, unë nuk do t’i besoja asnjëherë teknologjive "revolucion" në gazetari. Megjithatë, unë (dhe shumë shokë të mi) do të ishim të lumtur nëse do të shfaqej një burim lajmesh të paanshëm, të paarritshëm dhe të besueshëm. Për momentin, nuk e imagjinoj si mund të dukej një platformë e tillë, por jam e sigurt se në epokën kur e vërteta bëhet gjithnjë e më e vështirë për t'u dalluar, nevoja për gazetari të ndershme është më e madhe se kurrë më parë.
Mediet Sociale
Rrjetet sociale dhe platformat kolektive të lajmeve janë burimi kryesor i informacionit për shumë njerëz nëpër të gjithë botën, dhe mungesa e saktësisë dhe mosdëshira e disa platformave për të kryer madje edhe një kontroll të thjeshtë të fakteve, çojnë në pasojat e trishtueshme si gjenocidi, ndërhyrja në zgjedhje etj.
Rrjetet sociale gjithashtu janë mjeti më i fuqishëm mediatik që ka ekzistuar ndonjëherë. Ato kanë ndryshuar praktikën politike. Ato kanë ndryshuar reklamat. Ato kanë ndryshuar kulturën pop (p.sh. kontributi kryesor në zhvillimin e ashtuquajturës cancel culture [kultura e ostrakizmit — shënim i përkthyesit] vijnë pikërisht nga rrjetet sociale). Kritikët e argümentojnë se rrjetet sociale kanë qenë një terren pjellor për ndryshimet e shpejta dhe "kapriçioze" në vlerat morale, megjithatë ato gjithashtu ofrojnë mundësi për përfaqësuesit e grupeve marginale për t'u bashkuar (më parë ata nuk kishin kurrë një mundësi të tillë). Në thelb, rrjetet sociale kanë ndryshuar mënyrën e komunikimit dhe mënyrën e vetë-shprehjes së njerëzve në shekullin XXI.
Megjithatë, jam gjithashtu e bindur se rrjetet sociale kontribuojnë në shprehjen e impulseve më të këqija njerëzore. Kujdesi dhe reflektimi shpesh anashkalohen në favor të popullaritetit, dhe bëhet praktikisht e pamundur të shprehet një mosdakordësi e argumentuar me disa mendime dhe pozita. Polarizimi shpesh del jashtë kontrollit, duke bërë që publiku thjesht të mos dëgjojë mendime të veçanta, ndërsa absolutistët kontrollojnë çështjet e etikës online dhe pranueshmërisë.
Më pyet nëse është e mundur të krijohet një platformë "më e mirë" që inkurajon përmirësimin e cilësisë së diskutimeve? Sepse ajo që e motivon "pjesëmarrjen", shpesh është gjithashtu ajo që sjell shumicën e fitimeve për këto platforma. Si Kara Swisher në New York Times:
Mund të zhvillohet interaksioni digjital pa provokuar urrejtje dhe intolerancë. Arsyeja pse shumica e rrjeteve sociale duken kaq toksike është se ato janë krijuar për shpejtësi, viralitet dhe tërheqjen e vëmendjes, jo për përmbajtje dhe saktësi.
Do të ishte me të vërtetë e trishtueshme nëse pas disa dekadave, trashëgimia e vetme e rrjeteve sociale do të ishte shuarja e nuancave dhe përbërshmërisë në diskursin publik.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
