Tandaan. transl.: Ang artikulong ito, na naging hit sa Medium, ay isang pangkalahatang-ideya ng mga pangunahing pagbabago (2010-2019) sa mundo ng mga programming language at ang nauugnay na ecosystem ng teknolohiya (na may espesyal na pagtuon sa Docker at Kubernetes). Ang orihinal na may-akda nito ay si Cindy Sridharan, na dalubhasa sa mga tool ng developer at mga distributed system - sa partikular, isinulat niya ang aklat na "Distributed Systems Observability" - at medyo sikat sa Internet space sa mga IT specialist, lalo na interesado sa paksa ng cloud native.
Sa pagtatapos ng 2019, gusto kong ibahagi ang aking mga saloobin sa ilan sa pinakamahalagang pagsulong at inobasyon ng teknolohiya sa nakalipas na dekada. Bilang karagdagan, susubukan kong tumingin nang kaunti sa hinaharap at balangkasin ang mga pangunahing problema at pagkakataon sa darating na dekada.
Gusto kong linawin na sa artikulong ito ay hindi ko sinasaklaw ang mga pagbabago sa mga lugar tulad ng data science (data science), artificial intelligence, frontend engineering, atbp., dahil ako mismo ay walang sapat na karanasan sa kanila.
Nagbabalik ang Typification
Isa sa mga pinaka-positibong trend ng 2010s ay ang muling pagkabuhay ng mga statically typed na wika. Gayunpaman, ang mga naturang wika ay hindi kailanman nawala (C++ at Java ay hinihiling ngayon; sila ay dominado sampung taon na ang nakalilipas), ngunit ang mga dynamic na na-type na wika (dynamics) ay nakaranas ng isang makabuluhang pagtaas sa katanyagan pagkatapos ng paglitaw ng kilusang Ruby on Rails noong 2005 . Ang paglago na ito ay sumikat noong 2009 gamit ang open source ng Node.js, na naging realidad ng Javascript-on-the-server.
Sa paglipas ng panahon, ang mga dinamikong wika ay nawala ang ilan sa kanilang apela sa larangan ng paglikha ng software ng server. Ang wikang Go, na pinasikat noong panahon ng container revolution, ay tila mas angkop sa paglikha ng mataas na pagganap, mahusay sa mapagkukunan, parallel processing server (kung saan ang lumikha ng Node.js mismo).
Ang Rust, na ipinakilala noong 2010, ay kasama ang mga pagsulong sa sa pagtatangkang maging isang ligtas at nai-type na wika. Sa unang kalahati ng dekada, ang pagtanggap ng industriya ng Rust ay medyo maligamgam, ngunit ang katanyagan nito ay tumaas nang malaki sa ikalawang kalahati. Kabilang sa mga kilalang kaso ng paggamit para sa Rust ang paggamit nito para sa , (napag-usapan namin ito sa β tinatayang. transl.), isang maagang WebAssembly compiler mula sa Fastly (bahagi na ngayon ng bytecodealliance), atbp. Sa pagsasaalang-alang ng Microsoft sa posibilidad na muling isulat ang ilang bahagi ng Windows OS sa Rust, ligtas na sabihin na ang wikang ito ay may magandang kinabukasan sa 2020s.
Kahit na ang mga dynamic na wika ay nakakuha ng mga bagong tampok tulad ng (mga opsyonal na uri). Unang ipinatupad ang mga ito sa TypeScript, isang wika na nagbibigay-daan sa iyong lumikha ng na-type na code at i-compile ito sa JavaScript. Ang PHP, Ruby at Python ay may sariling opsyonal na sistema ng pag-type (, ), na matagumpay na ginagamit sa .
Ibinabalik ang SQL sa NoSQL
Ang NoSQL ay isa pang teknolohiya na mas sikat sa simula ng dekada kaysa sa dulo. Sa tingin ko may dalawang dahilan para dito.
Una, ang modelong NoSQL, na may kakulangan ng schema, mga transaksyon, at mas mahinang mga garantiya sa pagkakapare-pareho, ay naging mas mahirap ipatupad kaysa sa modelo ng SQL. SA na may pamagat na "Bakit mas gusto mo ang matatag na pagkakapare-pareho hangga't maaari" (Bakit dapat kang pumili ng malakas na pagkakapare-pareho, hangga't maaari) Sumulat ang Google:
Ang isa sa mga bagay na natutunan namin sa Google ay ang application code ay mas simple at ang oras ng pag-develop ay mas maikli kapag ang mga inhinyero ay maaaring umasa sa umiiral na storage upang pangasiwaan ang mga kumplikadong transaksyon at panatilihing maayos ang data. Upang banggitin ang orihinal na dokumentasyon ng Spanner, "Naniniwala kami na mas mainam para sa mga programmer na harapin ang mga problema sa pagganap ng application dahil sa pang-aabuso sa transaksyon habang umuusbong ang mga bottleneck, sa halip na palaging isipin ang kawalan ng mga transaksyon."
Ang pangalawang dahilan ay dahil sa pagtaas ng "scale-out" na ipinamahagi na mga database ng SQL (tulad ng ΠΈ ) sa pampublikong espasyo sa ulap, pati na rin ang mga alternatibong Open Source tulad ng CockroachDB (pinag-uusapan din natin siya - tinatayang. transl.), na lumulutas sa marami sa mga teknikal na problema na naging sanhi ng tradisyonal na mga database ng SQL na "hindi sukat." Maging ang MongoDB, na dating ehemplo ng kilusang NoSQL, ay ngayon ipinamahagi na mga transaksyon.
Para sa mga sitwasyong nangangailangan ng atomic na pagbabasa at pagsusulat sa maraming dokumento (sa isa o higit pang mga koleksyon), sinusuportahan ng MongoDB ang mga multi-document na transaksyon. Sa kaso ng mga ipinamamahaging transaksyon, maaaring gamitin ang mga transaksyon sa maraming operasyon, koleksyon, database, dokumento, at shards.
Kabuuang streaming
Ang Apache Kafka ay walang duda na isa sa pinakamahalagang imbensyon sa nakalipas na dekada. Binuksan ang source code nito noong Enero 2011, at sa paglipas ng mga taon, binago ng Kafka ang paraan ng pagtatrabaho ng mga negosyo gamit ang data. Nagamit na ang Kafka sa bawat kumpanyang pinagtrabahuan ko, mula sa mga startup hanggang sa malalaking korporasyon. Ang mga garantiya at mga kaso ng paggamit na ibinibigay nito (pub-sub, stream, event-driven na arkitektura) ay ginagamit sa iba't ibang gawain, mula sa pag-iimbak ng data hanggang sa pagsubaybay at pag-stream ng analytics, na hinihiling sa maraming lugar tulad ng pananalapi, pangangalaga sa kalusugan, pampublikong sektor, tingian at iba pa.
Tuloy-tuloy na Pagsasama (at sa mas mababang antas ng Patuloy na Deployment)
Ang Continuous Integration ay hindi lumitaw sa nakalipas na 10 taon, ngunit sa nakalipas na dekada ito kumalat na sa ganoong lawak, na naging bahagi ng karaniwang daloy ng trabaho (magpatakbo ng mga pagsubok sa lahat ng mga kahilingan sa paghila). Ang pagtatatag ng GitHub bilang isang platform para sa pagbuo at pag-iimbak ng code at, higit sa lahat, pagbuo ng isang daloy ng trabaho batay sa ay nangangahulugan na ang pagpapatakbo ng mga pagsubok bago tumanggap ng pull request para makabisado ay solong daloy ng trabaho sa pag-unlad, pamilyar sa mga inhinyero na nagsimula ng kanilang mga karera sa nakalipas na sampung taon.
Ang Continuous Deployment (pag-deploy ng bawat commit bilang at kapag tumama ito sa master) ay hindi kasing laganap ng tuluy-tuloy na pagsasama. Gayunpaman, sa dami ng iba't ibang cloud API para sa pag-deploy, ang lumalagong kasikatan ng mga platform tulad ng Kubernetes (na nagbibigay ng standardized na API para sa mga deployment), at ang paglitaw ng multi-platform, multi-cloud na tool tulad ng Spinnaker (built on top of those standardized API), ang mga proseso ng deployment ay naging mas awtomatiko, naka-streamline, at, sa pangkalahatan, mas secure.
Mga lalagyan
Ang mga lalagyan ay marahil ang pinaka-hyped, tinalakay, na-advertise at hindi nauunawaan na teknolohiya noong 2010s. Sa kabilang banda, isa ito sa pinakamahalagang inobasyon ng nakaraang dekada. Ang bahagi ng dahilan para sa lahat ng cacophony na ito ay nakasalalay sa magkahalong signal na natatanggap namin mula sa halos lahat ng dako. Ngayon na medyo humina na ang hype, ang ilang bagay ay naging mas matalas na pokus.
Naging tanyag ang mga container hindi dahil ang mga ito ang pinakamahusay na paraan upang magpatakbo ng isang application na nakakatugon sa mga pangangailangan ng pandaigdigang komunidad ng developer. Naging tanyag ang mga container dahil matagumpay silang umangkop sa isang kahilingan sa marketing para sa isang partikular na tool na lumulutas sa isang ganap na naiibang problema. Docker pala hindi kapani-paniwala isang tool sa pag-develop na nilulutas ang pagpindot sa isyu sa compatibility ("gumagana sa aking makina").
Mas tiyak, ang rebolusyon ay ginawa Larawan ng docker, dahil nalutas nito ang problema ng pagkakapare-pareho sa pagitan ng mga kapaligiran at nagbigay ng tunay na portability hindi lamang ng application file, kundi pati na rin ng lahat ng software at operating dependencies nito. Ang katotohanan na ang tool na ito sa paanuman ay nag-udyok sa katanyagan ng "mga lalagyan," na mahalagang isang napakababang antas ng detalye ng pagpapatupad, ay nananatili sa akin marahil ang pangunahing misteryo ng nakaraang dekada.
Walang server
Gusto kong tumaya na ang pagdating ng "serverless" computing ay mas mahalaga kaysa sa mga container dahil ito ay tunay na gumagawa ng pangarap ng on-demand na computing na isang katotohanan (on-demand). Sa nakalipas na limang taon, nakita ko ang serverless approach na unti-unting lumalawak sa saklaw sa pamamagitan ng pagdaragdag ng suporta para sa mga bagong wika at runtime. Ang paglitaw ng mga produkto tulad ng Azure Durable Functions ay tila ang tamang hakbang patungo sa pagpapatupad ng stateful functions (kasabay nito ay isang mapagpasyang nauugnay sa mga limitasyon ng FaaS). Panoorin ko nang may interes kung paano bubuo ang bagong paradigm na ito sa mga darating na taon.
Pag-aautomat
Marahil ang pinakamalaking benepisyaryo ng trend na ito ay ang operations engineering community, dahil binigyang-daan nito ang mga konsepto tulad ng imprastraktura bilang code (IaC) na maging isang katotohanan. Bukod pa rito, ang hilig para sa automation ay kasabay ng pag-usbong ng "kultura ng SRE," na naglalayong kumuha ng mas software-centric na diskarte sa mga operasyon.
Pangkalahatang API-fication
Ang isa pang kawili-wiling tampok ng nakaraang dekada ay ang API-fication ng iba't ibang mga gawain sa pag-unlad. Ang mahusay, nababaluktot na mga API ay nagbibigay-daan sa developer na lumikha ng mga makabagong daloy ng trabaho at tool, na nakakatulong naman sa pagpapanatili at pagpapabuti ng karanasan ng user.
Bilang karagdagan, ang API-fication ay ang unang hakbang patungo sa SaaS-fication ng ilang functionality o tool. Ang trend na ito ay kasabay din ng pagtaas ng katanyagan ng mga microservice: Ang SaaS ay naging isa lamang serbisyo na maaaring ma-access sa pamamagitan ng API. Marami na ngayong mga tool sa SaaS at FOSS na magagamit sa mga lugar tulad ng pagsubaybay, mga pagbabayad, pagbabalanse ng load, patuloy na pagsasama, mga alerto, paglipat ng tampok (feature flagging), CDN, traffic engineering (hal. DNS), atbp., na umunlad sa nakalipas na dekada.
Pagmamasid
Ito ay nagkakahalaga ng noting na ngayon ay mayroon kaming access sa mas advanced mga tool upang masubaybayan at masuri ang gawi ng aplikasyon kaysa dati. Maaaring tawagan ang Prometheus monitoring system, na nakatanggap ng Open Source status noong 2015 ang pinakamahusay monitoring system mula sa kung saan ako nagtrabaho. Hindi ito perpekto, ngunit maraming bagay ang ipinatupad sa eksaktong tamang paraan (halimbawa, suporta para sa mga sukat [dimensionalidad] sa kaso ng mga sukatan).
Ang distributed tracing ay isa pang teknolohiya na pumasok sa mainstream noong 2010s, salamat sa mga inisyatiba tulad ng OpenTracing (at ang kahalili nitong OpenTelemetry). Bagama't medyo mahirap ilapat ang pagsubaybay, ang ilan sa mga pinakabagong pag-unlad ay nagbibigay ng pag-asa na mabubuksan natin ang tunay na potensyal nito sa 2020s. (Tandaan: Basahin din sa aming blog ang pagsasalin ng artikulong ""sa pamamagitan ng parehong may-akda.)
Nakatingin sa kinabukasan
Sa kasamaang palad, maraming mga punto ng sakit na naghihintay ng resolusyon sa darating na dekada. Narito ang aking mga saloobin sa kanila at ilang potensyal na ideya kung paano mapupuksa ang mga ito.
Paglutas ng Problema sa Batas ni Moore
Ang pagtatapos ng batas sa pag-scale ni Dennard at ang pagkahuli sa batas ni Moore ay nangangailangan ng mga bagong inobasyon. John Hennessy sa nagpapaliwanag kung bakit ang mga adik sa problema (tiyak ng domain) ang mga arkitektura tulad ng TPU ay maaaring isa sa mga solusyon sa problema ng pagkahuli sa Batas ni Moore. Tulad ng mga toolkit mula sa Google ay tila isang magandang hakbang pasulong sa direksyong ito:
Dapat suportahan ng mga compiler ang mga bagong application, madaling ma-port sa bagong hardware, mag-link ng maraming layer ng abstraction mula sa dynamic, pinamamahalaang mga wika hanggang sa mga vector accelerators at mga storage device na kontrolado ng software, habang nagbibigay ng mga high-level na switch para sa auto-tuning, na nagbibigay ng just- sa functionality -time, diagnostics, at pamamahagi ng impormasyon sa pag-debug tungkol sa paggana at pagganap ng mga system sa buong stack, habang sa karamihan ng mga kaso ay nagbibigay ng pagganap na makatwirang malapit sa hand-written assembler. Nilalayon naming ibahagi ang aming pananaw, pag-unlad, at mga plano para sa pagpapaunlad at pagiging available sa publiko ng naturang compilation infrastructure.
CI / CD
Habang ang pagtaas ng CI ay naging isa sa mga pinakamalaking trend ng 2010s, Jenkins pa rin ang gintong pamantayan para sa CI.
Ang espasyong ito ay lubhang nangangailangan ng pagbabago sa mga sumusunod na lugar:
- user interface (DSL para sa pag-encode ng mga pagtutukoy ng pagsubok);
- mga detalye ng pagpapatupad na gagawin itong tunay na nasusukat at mabilis;
- integrasyon sa iba't ibang kapaligiran (staging, prod, atbp.) upang ipatupad ang mas advanced na mga paraan ng pagsubok;
- patuloy na pagsubok at deployment.
Mga Tool ng Developer
Bilang isang industriya, nagsimula kaming lumikha ng lalong kumplikado at kahanga-hangang software. Gayunpaman, pagdating sa aming sariling mga tool, ang sitwasyon ay maaaring maging mas mahusay.
Ang collaborative at remote (sa pamamagitan ng ssh) na pag-edit ay nakakuha ng ilang katanyagan, ngunit hindi kailanman naging bagong pamantayang paraan ng pag-unlad. Kung ikaw, tulad ko, ay tinatanggihan ang mismong ideya ng ang pangangailangan isang permanenteng koneksyon sa Internet para lang makapagprograma, pagkatapos ay ang pagtatrabaho sa pamamagitan ng ssh sa isang malayuang makina ay malamang na hindi angkop sa iyo.
Ang mga lokal na kapaligiran sa pag-unlad, lalo na para sa mga inhinyero na nagtatrabaho sa malalaking arkitektura na nakatuon sa serbisyo, ay isang hamon pa rin. Sinusubukan ng ilang proyekto na lutasin ito, at interesado akong malaman kung ano ang magiging hitsura ng pinaka-ergonomic na UX para sa isang naibigay na kaso ng paggamit.
Magiging interesante din na palawigin ang konsepto ng "mga portable na kapaligiran" sa iba pang mga lugar ng pag-unlad tulad ng pagpaparami ng bug (o ) na nangyayari sa ilalim ng ilang partikular na kundisyon o setting.
Gusto ko ring makakita ng higit pang pagbabago sa mga lugar tulad ng semantic at context-sensitive na paghahanap ng code, mga tool upang maiugnay ang mga insidente ng produksyon sa mga partikular na bahagi ng codebase, atbp.
Pag-compute (ang kinabukasan ng PaaS)
Kasunod ng hype sa mga container at serverless noong 2010s, ang hanay ng mga solusyon sa pampublikong cloud space ay lumawak nang malaki sa nakalipas na ilang taon.
Nagtataas ito ng ilang mga interesanteng tanong. Una sa lahat, ang listahan ng mga magagamit na opsyon sa pampublikong ulap ay patuloy na lumalaki. Ang mga tagapagbigay ng serbisyo sa cloud ay may mga kawani at mapagkukunan upang madaling makasabay sa mga pinakabagong pag-unlad sa mundo ng Open Source at maglabas ng mga produkto tulad ng "mga walang server na pod" (pinaghihinalaan ko sa pamamagitan lamang ng paggawa ng sarili nilang mga runtime ng FaaS na sumusunod sa OCI) o iba pang katulad na magagarang bagay.
Maiinggit lamang ang isa sa mga gumagamit ng mga solusyon sa ulap na ito. Sa teorya, ang mga cloud offering ng Kubernetes (GKE, EKS, EKS sa Fargate, atbp.) ay nagbibigay ng cloud provider-independent API para sa pagpapatakbo ng mga workload. Kung gumagamit ka ng mga katulad na produkto (ECS, Fargate, Google Cloud Run, atbp.), malamang na nasusulit mo na ang mga pinakakawili-wiling feature na inaalok ng service provider. Bukod pa rito, habang lumalabas ang mga bagong produkto o paradigma sa pag-compute, malamang na maging simple at walang stress ang paglipat.
Isinasaalang-alang kung gaano kabilis umuusbong ang hanay ng mga naturang solusyon (magugulat ako kung hindi lilitaw ang ilang bagong opsyon sa malapit na hinaharap), maliliit na "platform" na mga koponan (mga pangkat na nauugnay sa imprastraktura at responsable para sa paglikha ng mga on-premise na platform para sa pagpapatakbo ng mga kumpanya ng workloads) ay magiging napakahirap makipagkumpetensya sa mga tuntunin ng functionality, kadalian ng paggamit at pangkalahatang pagiging maaasahan. Nakita ng 2010s ang Kubernetes bilang isang tool para sa pagbuo ng PaaS (platform-as-a-service), kaya parang walang kabuluhan sa akin na bumuo ng isang panloob na platform sa ibabaw ng Kubernetes na nag-aalok ng parehong pagpipilian, pagiging simple at kalayaan na magagamit sa publiko espasyo sa ulap. Ang pag-frame ng container-based na PaaS bilang isang "diskarteng Kubernetes" ay katumbas ng sadyang pag-iwas sa mga pinaka-makabagong kakayahan ng cloud.
Kung titingnan mo ang available ngayon mga kakayahan sa pag-compute, nagiging halata na ang paggawa ng sarili mong PaaS na nakabatay lamang sa Kubernetes ay katumbas ng pagpipinta ng iyong sarili sa isang sulok (hindi isang napaka-forward-thinking na diskarte, ha?). Kahit na may magpasya na bumuo ng isang containerized na PaaS sa Kubernetes ngayon, sa loob ng ilang taon ay magmumukha itong luma kumpara sa mga kakayahan sa cloud. Bagama't nagsimula ang Kubernetes bilang isang open source na proyekto, ang ninuno at inspirasyon nito ay isang panloob na tool ng Google. Gayunpaman, ito ay orihinal na binuo noong unang bahagi/kalagitnaan ng 2000s kapag ang computing landscape ay ganap na naiiba.
Gayundin, sa isang napakalawak na kahulugan, ang mga kumpanya ay hindi kailangang maging eksperto sa pagpapatakbo ng isang Kubernetes cluster, at hindi rin sila nagtatayo at nagpapanatili ng kanilang sariling mga data center. Ang pagbibigay ng maaasahang computing foundation ay isang pangunahing hamon mga tagapagbigay ng serbisyo sa ulap.
Sa wakas, pakiramdam ko ay medyo nag-regress tayo bilang isang industriya sa mga tuntunin ng karanasan sa pakikipag-ugnayan (). Inilunsad ang Heroku noong 2007 at isa pa rin sa pinaka madaling gamitin mga platform. Hindi maikakaila na ang Kubernetes ay higit na makapangyarihan, extensible, at programmable, ngunit nami-miss ko kung gaano kadaling magsimula at mag-deploy sa Heroku. Para magamit ang platform na ito, kailangan mo lang malaman ang Git.
Ang lahat ng ito ay humahantong sa akin sa sumusunod na konklusyon: kailangan namin ng mas mahusay, mas mataas na antas ng mga abstraction upang gumana (ito ay totoo lalo na para sa pinakamataas na antas ng abstraction).
Ang tamang API sa pinakamataas na antas
Ang Docker ay isang magandang halimbawa ng pangangailangan para sa mas mahusay na paghihiwalay ng mga alalahanin sa parehong oras tamang pagpapatupad ng pinakamataas na antas ng API.
Ang problema sa Docker ay na (hindi bababa sa) sa simula ang mga layunin ng proyekto ay masyadong malawak: lahat para sa kapakanan ng paglutas ng problema sa compatibility ("gumagana sa aking makina") gamit ang teknolohiya ng container. Ang Docker ay isang format ng imahe, isang runtime na may sarili nitong virtual network, isang CLI tool, isang daemon na tumatakbo bilang ugat, at marami pa. Sa anumang kaso, ang pagpapalitan ng mga mensahe ay pa nakakalito, hindi banggitin ang "mga magaan na VM", cgroup, namespace, maraming isyu sa seguridad at feature na may halong marketing call na "bumuo, maghatid, magpatakbo ng anumang application kahit saan".
Tulad ng lahat ng magagandang abstraction, nangangailangan ng oras (at karanasan at sakit) upang masira ang iba't ibang mga problema sa mga lohikal na layer na maaaring pagsamahin sa bawat isa. Sa kasamaang palad, bago maabot ng Docker ang katulad na kapanahunan, pumasok ang Kubernetes sa gulo. Napakaraming monopolyo nito ang ikot ng hype na ngayon ay sinusubukan ng lahat na makasabay sa mga pagbabago sa ecosystem ng Kubernetes, at ang container ecosystem ay nagkaroon ng pangalawang katayuan.
Ang Kubernetes ay nagbabahagi ng marami sa parehong mga problema tulad ng Docker. Para sa lahat ng usapan tungkol sa cool at composable abstraction, paghihiwalay ng iba't ibang mga gawain sa mga layer hindi masyadong naka-encapsulated. Sa kaibuturan nito, ito ay isang container orchestrator na nagpapatakbo ng mga container sa isang kumpol ng iba't ibang makina. Ito ay isang medyo mababang antas na gawain, na naaangkop lamang sa mga inhinyero na nagpapatakbo ng cluster. Sa kabilang banda, ganoon din ang Kubernetes abstraction ng pinakamataas na antas, isang CLI tool kung saan nakikipag-ugnayan ang mga user sa pamamagitan ng YAML.
Ang Docker ay (at hanggang ngayon) malamig tool sa pag-unlad, sa kabila ng lahat ng mga pagkukulang nito. Sa isang pagtatangka na makasabay sa lahat ng "hares" nang sabay-sabay, nagawa ng mga developer nito na maipatupad nang tama abstraction sa pinakamataas na antas. Sa pamamagitan ng abstraction sa pinakamataas na antas ang ibig kong sabihin subset functionality na talagang interesado ang target na audience (sa kasong ito, ang mga developer na gumugol ng halos lahat ng kanilang oras sa kanilang mga lokal na kapaligiran sa pag-unlad) at nakatulong ito nang mahusay sa labas ng kahon..
Dockerfile at CLI utility docker ay dapat na isang halimbawa ng kung paano bumuo ng isang mahusay na "pinakamataas na antas ng karanasan ng gumagamit". Ang isang ordinaryong developer ay maaaring magsimulang magtrabaho kasama ang Docker nang hindi alam ang anumang bagay tungkol sa mga intricacies mga pagpapatupad na nag-aambag sa karanasan sa pagpapatakbogaya ng mga namespace, cgroup, memory at mga limitasyon ng CPU, atbp. Sa huli, ang pagsusulat ng Dockerfile ay hindi gaanong naiiba sa pagsulat ng shell script.
Ang Kubernetes ay inilaan para sa iba't ibang target na grupo:
- mga administrator ng kumpol;
- mga inhinyero ng software na nagtatrabaho sa mga isyu sa imprastraktura, pagpapalawak ng mga kakayahan ng Kubernetes at paglikha ng mga platform batay dito;
- end user na nakikipag-ugnayan sa Kubernetes sa pamamagitan ng
kubectl.
Ang "isang API na angkop sa lahat" na diskarte ng Kubernetes ay nagpapakita ng isang hindi sapat na naka-encapsulated na "bundok ng pagiging kumplikado" na walang gabay sa kung paano ito sukatin. Ang lahat ng ito ay humahantong sa isang unjustifiably pinahaba pag-aaral trajectory. Paano Adam Jacob, "Nagdala si Docker ng isang pagbabagong karanasan ng gumagamit na hindi pa nalampasan. Tanungin ang sinumang gumagamit ng K8 kung nais nilang gumana ito tulad ng una docker run. Ang sagot ay oo":
Gusto kong magtaltalan na ang karamihan sa teknolohiya sa imprastraktura ngayon ay masyadong mababa ang antas (at samakatuwid ay itinuturing na "masyadong kumplikado"). Ang Kubernetes ay ipinatupad sa medyo mababang antas. Ibinahagi ang pagsubaybay sa nito (maraming span na pinagsama-sama upang bumuo ng isang traceview) ay ipinapatupad din sa napakababang antas. Ang mga tool ng developer na nagpapatupad ng "mga abstraction sa pinakamataas na antas" ay malamang na ang pinakamatagumpay. Ang konklusyong ito ay totoo sa nakakagulat na bilang ng mga kaso (kung ang teknolohiya ay masyadong kumplikado o mahirap gamitin, kung gayon ang "pinakamataas na antas ng API/UI" para sa teknolohiyang iyon ay hindi pa matutuklasan).
Sa ngayon, nakakalito ang cloud native ecosystem dahil sa mababang antas ng focus nito. Bilang isang industriya, dapat tayong magbago, mag-eksperimento, at turuan kung ano ang hitsura ng tamang antas ng "maximum, pinakamataas na abstraction."
Pagtitingi
Noong 2010s, nanatiling hindi nagbabago ang karanasan sa digital retail. Sa isang banda, ang kadalian ng online na pamimili ay dapat na tumama sa mga tradisyonal na retail na tindahan, sa kabilang banda, ang online na pamimili sa panimula ay nanatiling halos hindi nagbabago sa loob ng isang dekada.
Bagama't wala akong tiyak na pag-iisip kung paano uunlad ang industriyang ito sa susunod na dekada, madidismaya ako kung mamimili tayo sa 2030 sa parehong paraan na gagawin natin sa 2020.
Pamantalaan
Lalo akong nadidismaya sa kalagayan ng pandaigdigang pamamahayag. Lalong nagiging mahirap na makahanap ng walang pinapanigan na mga pinagmumulan ng balita na nag-uulat nang may layunin at meticulously. Kadalasan ay malabo ang linya sa pagitan ng balita mismo at mga opinyon tungkol dito. Bilang isang tuntunin, ang impormasyon ay ipinakita sa isang bias na paraan. Ito ay totoo lalo na sa ilang mga bansa kung saan sa kasaysayan ay walang paghihiwalay sa pagitan ng balita at opinyon. Sa isang kamakailang artikulo na inilathala pagkatapos ng huling pangkalahatang halalan sa UK, si Alan Rusbridger, dating editor ng The Guardian, :
Ang pangunahing punto ay na sa loob ng maraming taon ay tumingin ako sa mga pahayagan sa Amerika at naawa sa aking mga kasamahan doon, na tanging responsable para sa balita, na iniiwan ang komentaryo sa ganap na magkakaibang mga tao. Gayunpaman, sa paglipas ng panahon, ang awa ay nauwi sa inggit. Sa tingin ko ngayon, dapat ihiwalay ng lahat ng pambansang pahayagan ng British ang kanilang responsibilidad para sa balita mula sa kanilang responsibilidad para sa komentaryo. Sa kasamaang palad, napakahirap para sa karaniwang mambabasaβlalo na sa mga online na mambabasaβna matukoy ang pagkakaiba.
Dahil sa medyo kahina-hinalang reputasyon ng Silicon Valley pagdating sa etika, hinding-hindi ako magtitiwala sa teknolohiya na "i-revolutionize" ang pamamahayag. Iyon ay sinabi, ako (at marami sa aking mga kaibigan) ay natutuwa kung mayroong isang walang kinikilingan, walang interes at mapagkakatiwalaang mapagkukunan ng balita. Bagama't wala akong ideya kung ano ang hitsura ng gayong plataporma, tiwala ako na sa isang panahon kung saan ang katotohanan ay lalong nagiging mahirap na matukoy, ang pangangailangan para sa tapat na pamamahayag ay higit kailanman.
Mga Network na Panlipunan
Ang mga social media at mga platform ng balita sa komunidad ay ang pangunahing pinagmumulan ng impormasyon para sa maraming tao sa buong mundo, at ang kawalan ng katumpakan at pag-aatubili ng ilang mga platform na gawin kahit na ang pangunahing fact-checking ay humantong sa mga mapaminsalang kahihinatnan tulad ng genocide, panghihimasok sa halalan, at higit pa .
Ang social media ay isa ring pinakamakapangyarihang tool sa media na umiral. Binago nila ang pampulitikang kasanayan. Binago nila ang advertising. Binago nila ang kultura ng pop (halimbawa, ang pangunahing kontribusyon sa pag-unlad ng tinatawag na kultura ng pagkansela [mga kultura ng ostracism - approx. transl.] kontribusyon ng mga social network). Ang mga kritiko ay nangangatuwiran na ang social media ay napatunayang matabang lupa para sa mabilis at pabagu-bagong mga pagbabago sa mga pagpapahalagang moral, ngunit nagbigay din ito ng pagkakataon sa mga miyembro ng mga marginalized na grupo na mag-organisa sa mga paraang hindi pa nila nararanasan noon. Sa esensya, binago ng social media ang paraan ng pakikipag-usap at pagpapahayag ng mga tao sa kanilang sarili sa ika-XNUMX siglo.
Gayunpaman, naniniwala din ako na ang social media ay naglalabas ng pinakamasamang mga impulses ng tao. Ang pagsasaalang-alang at pag-iisip ay madalas na napapabayaan sa pabor ng katanyagan, at halos imposible na ipahayag ang makatuwirang hindi pagkakasundo sa ilang mga opinyon at posisyon. Ang polariseysyon ay madalas na nawawalan ng kontrol, na nagreresulta sa publiko na hindi nakakarinig ng mga indibidwal na opinyon habang ang mga absolutist ay kumokontrol sa mga isyu ng online etiquette at katanggap-tanggap.
Nagtataka ako kung posible bang lumikha ng isang "mas mahusay" na platform na nagpo-promote ng mas mahusay na kalidad ng mga talakayan? Pagkatapos ng lahat, ito ang nagtutulak sa "pakikipag-ugnayan" na kadalasang nagdadala ng pangunahing kita sa mga platform na ito. Paano Kara Swisher sa New York Times:
Posibleng bumuo ng mga digital na pakikipag-ugnayan nang hindi pumupukaw ng poot at hindi pagpaparaan. Ang dahilan kung bakit ang karamihan sa mga social media site ay tila nakakalason ay dahil ang mga ito ay ginawa para sa bilis, pagiging viral, at atensyon, sa halip na nilalaman at katumpakan.
Talagang nakakalungkot kung, sa loob ng ilang dekada, ang tanging pamana ng social media ay ang pagguho ng nuance at pagiging angkop sa pampublikong diskurso.
PS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- Β«";
- Β«";
- Β«'.
Pinagmulan: www.habr.com