Huomautus. käännös: Tämä artikkeli, josta tuli hitti Mediumissa, on yleiskatsaus keskeisiin (2010–2019) muutoksiin ohjelmointikielten maailmassa ja niihin liittyvässä teknologiaekosysteemissä (erityisesti Dockerissa ja Kubernetesissa). Sen alkuperäinen kirjoittaja on Cindy Sridharan, joka on erikoistunut kehittäjätyökaluihin ja hajautettuihin järjestelmiin - erityisesti hän kirjoitti kirjan "Distributed Systems Observability" - ja on melko suosittu Internet-avaruudessa IT-asiantuntijoiden keskuudessa, jotka ovat erityisen kiinnostuneita pilvipohjaisesta aiheesta.
Vuoden 2019 lähestyessä loppuaan halusin jakaa ajatukseni joistakin viime vuosikymmenen tärkeimmistä teknologisista edistysaskeleista ja innovaatioista. Lisäksi yritän katsoa hieman tulevaisuuteen ja hahmotella tulevan vuosikymmenen tärkeimpiä ongelmia ja mahdollisuuksia.
Haluan tehdä selväksi, että tässä artikkelissa en käsittele muutoksia sellaisilla aloilla kuin datatiede (tietotiede), tekoäly, frontend engineering jne., koska minulla ei henkilökohtaisesti ole niistä riittävästi kokemusta.
Tyypitys iskee takaisin
Yksi 2010-luvun positiivisimmista trendeistä oli staattisesti kirjoitettujen kielten elpyminen. Tällaiset kielet eivät kuitenkaan koskaan kadonneet (C++ ja Java ovat kysyttyjä nykyään; ne hallitsivat kymmenen vuotta sitten), mutta dynaamisesti kirjoitetut kielet (dynamiikka) kokivat merkittävän suosion kasvun Ruby on Rails -liikkeen syntymisen jälkeen vuonna 2005. . Kasvu saavutti huippunsa vuonna 2009 Node.js:n avoimen lähdekoodin myötä, mikä teki Javascript-on-the-serveristä todellisuutta.
Ajan myötä dynaamiset kielet ovat menettäneet osan vetovoimastaan palvelinohjelmistojen luomisen alalla. Konttivallankumouksen aikana suosituksi tullut Go-kieli näytti sopivan paremmin tehokkaiden, resurssitehokkaiden palvelimien luomiseen rinnakkaiskäsittelyllä (jolla itse Node.js:n luoja).
Vuonna 2010 esitelty Rust sisälsi edistysaskeleita yrittääkseen tulla turvalliseksi ja kirjoitetuksi kieleksi. Vuosikymmenen ensimmäisellä puoliskolla ruosteen vastaanotto teollisuudessa oli melko haalea, mutta sen suosio kasvoi merkittävästi toisella puoliskolla. Ruostin merkittäviin käyttötapauksiin kuuluu sen käyttö , (keskustelimme siitä - noin käännös.), varhainen WebAssembly-kääntäjä Fastlylta (nyt osa bytecodealliancea) jne. Microsoft harkitsee mahdollisuutta kirjoittaa uudelleen joitakin Windows-käyttöjärjestelmän osia Rustissa, joten on turvallista sanoa, että tällä kielellä on valoisa tulevaisuus 2020-luvulla.
Jopa dynaamiset kielet saivat uusia ominaisuuksia, kuten (valinnaiset tyypit). Ne otettiin käyttöön ensin TypeScriptillä, kielellä, jonka avulla voit luoda kirjoitettua koodia ja kääntää sen JavaScriptiksi. PHP:llä, Rubylla ja Pythonilla on omat valinnaiset kirjoitusjärjestelmänsä (, ), joita käytetään menestyksekkäästi .
SQL:n palauttaminen NoSQL:ksi
NoSQL on toinen tekniikka, joka oli paljon suositumpi vuosikymmenen alussa kuin sen lopussa. Mielestäni tähän on kaksi syytä.
Ensinnäkin NoSQL-malli skeeman, transaktioiden ja heikompien johdonmukaisuustakuineen osoittautui vaikeammaksi toteuttaa kuin SQL-malli. SISÄÄN otsikolla "Miksi sinun pitäisi suosia vahvaa johdonmukaisuutta aina kun mahdollista" (Miksi sinun pitäisi valita vahva johdonmukaisuus, aina kun mahdollista) Google kirjoittaa:
Yksi Googlessa oppimistamme asioista on se, että sovelluskoodi on yksinkertaisempi ja kehitysaika lyhyempi, kun insinöörit voivat luottaa olemassa olevaan tallennustilaan monimutkaisten tapahtumien käsittelyssä ja tietojen pitämisessä kunnossa. Lainatakseni alkuperäistä Spannerin dokumentaatiota: "Uskomme, että ohjelmoijien on parempi käsitellä tapahtumien väärinkäytöstä johtuvia sovellusten suorituskykyongelmia pullonkaulojen ilmaantuessa, kuin pitää jatkuvasti mielessä tapahtumien puuttuminen."
Toinen syy johtuu "skaalattujen" hajautettujen SQL-tietokantojen (esim и ) julkisessa pilvitilassa sekä avoimen lähdekoodin vaihtoehdot, kuten CockroachDB (puhumme myös hänestä - noin käännös.), jotka ratkaisevat monia teknisiä ongelmia, jotka aiheuttivat perinteisten SQL-tietokantojen "skaalautumattomuuden". Jopa MongoDB, joka oli aikoinaan NoSQL-liikkeen ruumiillistuma, on nyt hajautetut tapahtumat.
MongoDB tukee usean asiakirjan tapahtumia tilanteissa, joissa vaaditaan luku- ja kirjoitusasua useissa asiakirjoissa (yhdessä tai useammassa kokoelmassa). Hajautettujen tapahtumien tapauksessa tapahtumia voidaan käyttää useiden toimintojen, kokoelmien, tietokantojen, asiakirjojen ja sirpaleiden kesken.
Yhteensä suoratoisto
Apache Kafka on epäilemättä yksi viime vuosikymmenen tärkeimmistä keksinnöistä. Sen lähdekoodi avattiin tammikuussa 2011, ja vuosien varrella Kafka on mullistanut yritysten tiedonkäsittelyn. Kafkaa on käytetty kaikissa yrityksissä, joissa olen työskennellyt, startupeista suuriin yrityksiin. Sen tarjoamia takuita ja käyttötapauksia (pub-sub, streamit, tapahtumalähtöiset arkkitehtuurit) käytetään erilaisissa tehtävissä tiedon tallentamisesta seurantaan ja suoratoistoanalytiikkaan, ja niille on kysyntää monilla aloilla, kuten rahoitus, terveydenhuolto, julkinen sektori, vähittäiskauppa jne.
Jatkuva integrointi (ja vähemmässä määrin jatkuva käyttöönotto)
Jatkuva integraatio ei ilmestynyt viimeisen 10 vuoden aikana, mutta viimeisen vuosikymmenen aikana on levinnyt niin pitkälle, josta on tullut osa vakiotyönkulkua (suorita testit kaikille vetopyynnöille). GitHubin perustaminen alustaksi koodin kehittämiseen ja tallentamiseen, ja mikä tärkeintä, kehittämään työnkulkua, joka perustuu tarkoittaa, että testien suorittaminen ennen vetopyynnön hyväksymistä masterille on ainoa työnkulku kehitystyössä, tuttu viimeisten kymmenen vuoden aikana uransa aloittaneille insinööreille.
Jatkuva käyttöönotto (jokaisen vahvistuksen käyttöönotto silloin, kun se osuu pääkoneeseen) ei ole yhtä yleistä kuin jatkuva integrointi. Kuitenkin erilaisten pilvisovellusliittymien joukon käyttöönottoa, Kubernetesin kaltaisten alustojen (jotka tarjoavat standardoidun API:n käyttöönottoa varten) kasvava suosio ja monikäyttöiset monipilvityökalut, kuten Spinnaker (rakennettu standardisoitujen päälle). API), käyttöönottoprosessit ovat automatisoituneet, virtaviivaistuneet ja yleensä turvallisempia.
kontit
Säiliöt ovat ehkä 2010-luvun suosituin, keskusteltu, mainostettu ja väärinymmärretyin tekniikka. Toisaalta se on yksi edellisen vuosikymmenen tärkeimmistä innovaatioista. Osa syy tähän kakofoniaan piilee sekaisissa signaaleissa, joita saimme melkein kaikkialta. Nyt kun hype on vähän laantunut, jotkut asiat ovat tulleet terävämmäksi.
Säilöistä ei ole tullut suosittuja siksi, että ne olisivat paras tapa ajaa sovelluksia, jotka täyttävät globaalin kehittäjäyhteisön tarpeet. Konteista tuli suosittuja, koska ne sopivat onnistuneesti markkinointipyyntöön tietylle työkalulle, joka ratkaisee täysin erilaisen ongelman. Docker osoittautui fantastinen kehitystyökalu, joka ratkaisee kiireellisen yhteensopivuusongelman ("toimii koneellani").
Tarkemmin sanottuna vallankumous tehtiin Docker-kuva, koska se ratkaisi ympäristöjen välisen pariteettiongelman ja tarjosi todellisen siirrettävyyden paitsi sovellustiedoston myös kaikkien sen ohjelmistojen ja toimintariippuvuuksien osalta. Se tosiasia, että tämä työkalu jollain tapaa vauhditti "säilöjen", jotka ovat pohjimmiltaan hyvin matalan tason toteutusyksityiskohtia, suosiota, on minulle ehkä viime vuosikymmenen suurin mysteeri.
serverless
Veikkaisin, että "palvelimettoman" tietojenkäsittelyn tulo on vielä tärkeämpää kuin kontit, koska se todella tekee unelmasta tilauslaskentaa todeksi. (On-demand). Viimeisten viiden vuoden aikana olen nähnyt palvelimettoman lähestymistavan laajenevan vähitellen lisäämällä tuen uusille kielille ja suoritusajoille. Tuotteiden, kuten Azure Durable Functions, ilmestyminen näyttää olevan oikea askel kohti tilallisten toimintojen toteuttamista (samalla liittyvät FaaS-rajoituksiin). Seuraan mielenkiinnolla, miten tämä uusi paradigma kehittyy tulevina vuosina.
automaatio
Ehkä tämän trendin suurin hyötyjä on operaatioinsinööriyhteisö, joka on mahdollistanut sellaisten käsitteiden kuin infrastruktuuri koodina (IaC) toteutumisen. Lisäksi intohimo automaatioon on osunut samaan aikaan "SRE-kulttuurin" nousun kanssa, jonka tavoitteena on omaksua ohjelmistokeskeisempi lähestymistapa toimintaan.
Universal API-fikaatio
Toinen mielenkiintoinen piirre kuluneelta vuosikymmeneltä on ollut erilaisten kehitystehtävien API-fikaatio. Hyvien, joustavien API:iden avulla kehittäjä voi luoda innovatiivisia työnkulkuja ja työkaluja, jotka puolestaan auttavat ylläpidossa ja parantavat käyttökokemusta.
Lisäksi API-fication on ensimmäinen askel kohti jonkin toiminnon tai työkalun SaaS-fikaatiota. Tämä suuntaus osui myös yhteen mikropalvelujen suosion kasvun kanssa: SaaSista on tullut vain yksi palvelu, johon pääsee API:n kautta. Saatavilla on nyt monia SaaS- ja FOSS-työkaluja sellaisilla aloilla kuin valvonta, maksut, kuormituksen tasapainotus, jatkuva integrointi, hälytykset, toimintojen vaihtaminen (ominaisuusmerkintä), CDN, liikennetekniikka (esim. DNS) jne., jotka ovat kukoistaneet viimeisen vuosikymmenen aikana.
havaittavuus
On syytä huomata, että tänään meillä on pääsy paljon edistyneempää työkaluja sovellusten käyttäytymisen valvontaan ja diagnosointiin kuin koskaan ennen. Vuonna 2015 Open Source -statuksen saanut Prometheus-seurantajärjestelmä voidaan ehkä kutsua paras seurantajärjestelmä niiltä, joiden kanssa olen työskennellyt. Se ei ole täydellinen, mutta huomattava osa asioista on toteutettu täsmälleen oikealla tavalla (esim. mittausten tuki [ulottuvuus] mittareiden tapauksessa).
Hajautettu jäljitys oli toinen tekniikka, joka tuli valtavirtaan 2010-luvulla OpenTracingin (ja sen seuraajan OpenTelemetryn) kaltaisten aloitteiden ansiosta. Vaikka jäljitystä on vielä melko vaikea soveltaa, jotkut viimeisimmistä kehityssuunnista antavat toivoa, että saamme sen todellisen potentiaalin käyttöön 2020-luvulla. (Huomaa: Lue myös blogistamme artikkelin käännös ""samalta kirjoittajalta.)
Katse tulevaisuuteen
Valitettavasti on monia kipukohtia, jotka odottavat ratkaisua seuraavan vuosikymmenen aikana. Tässä on ajatuksiani niistä ja joitain mahdollisia ideoita kuinka päästä niistä eroon.
Mooren lain ongelman ratkaiseminen
Dennardin skaalauslain loppuminen ja Mooren lain jälkeen jääminen vaativat uusia innovaatioita. John Hennessy mukana selittää, miksi ongelmariippuvaiset (verkkotunnuskohtainen) TPU:n kaltaiset arkkitehtuurit voivat olla yksi ratkaisu Mooren lain jälkeen jäämisen ongelmaan. Työkalusarjat kuten Google näyttää jo olevan hyvä askel eteenpäin tähän suuntaan:
Kääntäjien on tuettava uusia sovelluksia, oltava helposti siirrettävissä uuteen laitteistoon, linkitettävä useita abstraktiokerroksia dynaamisista, hallituista kielistä vektorikiihdyttimiin ja ohjelmistoohjattuihin tallennuslaitteisiin sekä tarjottava korkean tason kytkimiä automaattista viritystä varten. toiminnallisuudessa -aika, diagnostiikka ja virheenkorjaustietojen jakaminen järjestelmien toimivuudesta ja suorituskyvystä koko pinossa, samalla kun useimmissa tapauksissa tarjotaan suorituskyky, joka on kohtuullisen lähellä käsin kirjoitettua kokoonpanoohjelmaa. Aiomme jakaa visiomme, edistymisemme ja suunnitelmamme tällaisen kokoamisinfrastruktuurin kehittämisestä ja julkisesta saatavuudesta.
CI / CD
Vaikka CI:n noususta on tullut yksi 2010-luvun suurimmista trendeistä, Jenkins on edelleen CI:n kultakanta.
Tämä tila tarvitsee kipeästi innovaatioita seuraavilla aloilla:
- käyttöliittymä (DSL testimäärittelyjen koodausta varten);
- toteutustiedot, jotka tekevät siitä todella skaalautuvan ja nopean;
- integrointi eri ympäristöihin (lavastaminen, tuotanto jne.) edistyneempien testausmuotojen toteuttamiseksi;
- jatkuva testaus ja käyttöönotto.
Kehittäjän työkalut
Toimialana olemme alkaneet luoda yhä monimutkaisempia ja vaikuttavampia ohjelmistoja. Omien työkalujemme osalta tilanne voisi kuitenkin olla paljon parempi.
Yhteistyö ja etämuokkaus (ssh:n kautta) saivat jonkin verran suosiota, mutta niistä ei koskaan tullut uutta standardikehitystapaa. Jos sinä, kuten minä, hylkäät itse ajatuksen tarve Pysyvä yhteys Internetiin vain ohjelmointia varten, silloin ssh:n kautta etäkoneella työskentely ei todennäköisesti sovi sinulle.
Paikalliset kehitysympäristöt, erityisesti suurissa palvelukeskeisessä arkkitehtuurissa työskenteleville insinööreille, ovat edelleen haaste. Jotkut projektit yrittävät ratkaista tätä, ja olisin kiinnostunut tietämään, miltä ergonomisin UX näyttäisi tietyssä käyttötapauksessa.
Olisi myös mielenkiintoista laajentaa "siirrettävien ympäristöjen" käsite koskemaan muita kehitysalueita, kuten virheiden lisääntymistä (tai ), joita esiintyy tietyissä olosuhteissa tai asetuksissa.
Haluaisin myös lisää innovaatioita sellaisilla aloilla kuin semanttinen ja kontekstikohtainen koodihaku, työkalut tuotantotapahtumien korreloimiseksi tiettyihin koodikannan osiin jne.
Tietotekniikka (PaaS:n tulevaisuus)
2010-luvun konttien ja palvelimettomuuden ympärillä vallinneen hypetyksen jälkeen julkisen pilvitilan ratkaisuvalikoima on laajentunut merkittävästi viime vuosina.
Tämä herättää useita mielenkiintoisia kysymyksiä. Ensinnäkin julkisen pilven käytettävissä olevien vaihtoehtojen luettelo kasvaa jatkuvasti. Pilvipalveluntarjoajilla on henkilökuntaa ja resursseja pysyäkseen helposti ajan tasalla avoimen lähdekoodin maailman uusimmasta kehityksestä ja julkaista tuotteita, kuten "palvelimettomia podeja" (epäilen yksinkertaisesti tekemällä omat FaaS-ajoajat OCI-yhteensopiviksi) tai muita vastaavia hienoja asioita.
Voi vain kadehtia niitä, jotka käyttävät näitä pilviratkaisuja. Teoriassa Kubernetesin pilvitarjoukset (GKE, EKS, EKS Fargatessa jne.) tarjoavat pilvipalveluntarjoajista riippumattomia API-liittymiä työkuormien suorittamiseen. Jos käytät samankaltaisia tuotteita (ECS, Fargate, Google Cloud Run jne.), hyödynnät todennäköisesti jo eniten palveluntarjoajan tarjoamista kiinnostavimmista ominaisuuksista. Lisäksi kun uusia tuotteita tai laskentaparadigmoja ilmaantuu, siirtyminen on todennäköisesti yksinkertaista ja stressitöntä.
Ottaen huomioon, kuinka nopeasti tällaisten ratkaisujen valikoima kehittyy (olen erittäin yllättynyt, jos pari uutta vaihtoehtoa ei ilmesty lähitulevaisuudessa), pienet "alusta" -tiimit (tiimejä, jotka liittyvät infrastruktuuriin ja vastaavat paikan päällä olevien alustojen luomisesta työtaakkayritykset) on uskomattoman vaikea kilpailla toimivuuden, helppokäyttöisyyden ja yleisen luotettavuuden suhteen. 2010-luvulla Kubernetes on nähty työkaluna PaaS:n (platform-as-a-service) rakentamiseen, joten minusta tuntuu täysin turhalta rakentaa Kubernetesin päälle sisäinen alusta, joka tarjoaa saman valinnanvaran, yksinkertaisuuden ja vapauden yleisön saatavilla. pilvi tilaa. Säiliöpohjaisen PaaS:n kehystäminen "Kubernetes-strategiaksi" merkitsee pilven innovatiivisimpien ominaisuuksien tahallista välttämistä.
Jos katsot saatavilla olevia tänään laskentaominaisuuksia, tulee ilmeiseksi, että oman PaaS:n luominen yksinomaan Kubernetesin pohjalta merkitsee itsensä maalaamista nurkkaan (ei kovin eteenpäin suuntautuva lähestymistapa, vai mitä?). Vaikka joku päättäisikin rakentaa Kubernetesille tänään konteitetun PaaS:n, parin vuoden kuluttua se näyttää vanhentuneelta pilviominaisuuksiin verrattuna. Vaikka Kubernetes aloitti avoimen lähdekoodin projektina, sen esi-isä ja inspiraation lähteenä on Googlen sisäinen työkalu. Se kehitettiin kuitenkin alun perin 2000-luvun alussa/puolivälissä, jolloin laskentaympäristö oli täysin erilainen.
Myöskään hyvin laajassa mielessä yritysten ei tarvitse tulla Kubernetes-klusterin johtamisen asiantuntijoiksi, eivätkä ne rakentaa ja ylläpitää omia palvelinkeskuksiaan. Luotettavan laskentaperustan tarjoaminen on keskeinen haaste pilvipalveluntarjoajat.
Lopuksi minusta tuntuu, että olemme hieman taantuneet toimialana vuorovaikutuskokemusta (). Heroku lanseerattiin vuonna 2007 ja on edelleen yksi parhaista helppokäyttöinen alustat. Ei voida kiistää, että Kubernetes on paljon tehokkaampi, laajennettavissa oleva ja ohjelmoitavampi, mutta kaipaan sitä, kuinka helppoa on aloittaa ja ottaa käyttöön Herokussa. Jotta voit käyttää tätä alustaa, sinun tarvitsee vain tuntea Git.
Kaikki tämä johtaa minut seuraavaan johtopäätökseen: tarvitsemme parempia, korkeamman tason abstraktioita toimiaksemme (tämä pätee erityisesti korkeimman tason abstraktiot).
Oikea API korkeimmalla tasolla
Docker on hyvä esimerkki tarpeesta erottaa huolenaiheet samalla kertaa paremmin korkeimman tason API:n oikea toteutus.
Dockerin ongelmana on, että (ainakin) alun perin projektin tavoitteet olivat liian laajat: kaikki vain yhteensopivuusongelman ("toimii koneellani") ratkaisun vuoksi konttiteknologian avulla. Docker oli kuvamuoto, ajonaika, jossa oli oma virtuaalinen verkko, CLI-työkalu, pääkäyttäjänä toimiva demoni ja paljon muuta. Joka tapauksessa viestien vaihto oli lisää hämmentäviä, puhumattakaan "kevyistä VM:istä", c-ryhmistä, nimitiloista, lukuisista tietoturvaongelmista ja ominaisuuksista, jotka on yhdistetty markkinointikutsuun "rakenna, toimita, suorita mitä tahansa sovelluksia missä tahansa".
Kuten kaikissa hyvissä abstraktioissa, vie aikaa (ja kokemusta ja tuskaa) erilaisten ongelmien hajottaminen loogisiksi kerroksiksi, jotka voidaan yhdistää toisiinsa. Valitettavasti ennen kuin Docker ehti saavuttaa samanlaisen kypsyyden, Kubernetes tuli taisteluun. Se monopolisoi hype-syklin niin paljon, että nyt kaikki yrittivät pysyä mukana Kubernetes-ekosysteemin muutoksissa, ja konttiekosysteemi sai toissijaisen tilan.
Kubernetes jakaa monia samoja ongelmia kuin Docker. Kaikelle viileästä ja koostettavissa olevasta abstraktiosta puhumisesta, erilaisten tehtävien jakaminen kerroksiin ei kovin hyvin kapseloitu. Pohjimmiltaan se on konttiorkesteri, joka ajaa kontteja erilaisten koneiden klusterissa. Tämä on melko matalan tason tehtävä, joka koskee vain klusteria käyttäviä insinöörejä. Toisaalta Kubernetes on myös korkeimman tason abstraktio, CLI-työkalu, jonka kanssa käyttäjät ovat vuorovaikutuksessa YAML:n kautta.
Docker oli (ja on edelleen) viileä kehitystyökalu kaikista puutteistaan huolimatta. Yrittäessään pysyä kaikkien "jänisten" tahdissa kerralla sen kehittäjät onnistuivat toteuttamaan oikein abstraktio korkeimmalla tasolla. Abstraktiolla korkeimmalla tasolla tarkoitan osajoukko toiminnallisuus, josta kohdeyleisö (tässä tapauksessa kehittäjät, jotka viettivät suurimman osan ajastaan paikallisessa kehitysympäristössään) olivat todella kiinnostuneita ja jotka toimivat erinomaisesti heti alusta alkaen.
Dockerfile- ja CLI-apuohjelma docker pitäisi olla esimerkki hyvän "korkeimman tason käyttäjäkokemuksen" rakentamisesta. Tavallinen kehittäjä voi aloittaa työskentelyn Dockerin kanssa tietämättä mitään monimutkaisuuksista toteutukset, jotka edistävät käyttökokemustakuten nimiavaruudet, c-ryhmät, muistin ja suorittimen rajoitukset jne. Lopulta Docker-tiedoston kirjoittaminen ei eroa paljoakaan komentotulkkikomentosarjan kirjoittamisesta.
Kubernetes on tarkoitettu eri kohderyhmille:
- klusterin ylläpitäjät;
- ohjelmistoinsinöörit, jotka työskentelevät infrastruktuuriasioissa, laajentavat Kubernetesin ominaisuuksia ja luovat siihen perustuvia alustoja;
- loppukäyttäjät, jotka ovat vuorovaikutuksessa Kubernetesin kanssa
kubectl.
Kubernetesin "yksi API sopii kaikille" -lähestymistapa esittelee riittämättömästi kapseloidun "monimutkaisuuden vuoren" ilman ohjeita sen skaalaamiseen. Kaikki tämä johtaa perusteettomasti pitkittyneeseen oppimisrataan. Miten Adam Jacob: "Docker toi muuttavan käyttökokemuksen, jota ei ole koskaan ylitetty. Kysy kaikilta, jotka käyttävät K8:aa, haluavatko he sen toimivan kuten heidän ensimmäinen docker run. Vastaus on kyllä":
Väittäisin, että suurin osa infrastruktuuriteknologiasta nykyään on liian matalatasoista (ja siksi sitä pidetään "liian monimutkaisena"). Kubernetes on toteutettu melko alhaisella tasolla. Jaettu jäljitys siinä (paljon jänneväliä ommeltu yhteen muodostamaan traceview) on myös toteutettu liian alhaisella tasolla. Kehittäjätyökalut, jotka toteuttavat "korkeimman tason abstraktioita", ovat yleensä menestyneimpiä. Tämä johtopäätös pitää paikkansa yllättävän monissa tapauksissa (jos tekniikka on liian monimutkaista tai vaikeasti käytettävä, niin "korkeimman tason API/UI" tälle teknologialle on vielä löytämättä).
Tällä hetkellä pilvipohjainen ekosysteemi on hämmentävä sen matalan tason keskittymisen vuoksi. Toimialana meidän on innovoitava, kokeiltava ja koulutettava, miltä oikea "maksimi, korkein abstraktion" taso näyttää.
Vähittäiskauppa
2010-luvulla digitaalisen vähittäiskaupan kokemus säilyi pääosin ennallaan. Toisaalta verkkokaupan helppouden olisi pitänyt iskeä perinteisiin vähittäiskauppoihin, toisaalta verkkokauppa on pysynyt pohjimmiltaan lähes ennallaan kymmenessä vuodessa.
Vaikka minulla ei ole erityisiä ajatuksia siitä, miten tämä ala kehittyy seuraavan vuosikymmenen aikana, olisin erittäin pettynyt, jos tekisimme ostoksia vuonna 2030 samalla tavalla kuin vuonna 2020.
journalismi
Olen yhä enemmän pettynyt globaalin journalismin tilaan. On yhä vaikeampaa löytää puolueettomia uutislähteitä, jotka raportoivat objektiivisesti ja huolellisesti. Hyvin usein itse uutisen ja sitä koskevien mielipiteiden välinen raja hämärtyy. Pääsääntöisesti tiedot esitetään puolueellisesti. Tämä pätee erityisesti joissakin maissa, joissa uutisten ja mielipiteiden välillä ei historiallisesti ole ollut eroa. Äskettäin julkaistussa artikkelissa, joka julkaistiin viime Yhdistyneen kuningaskunnan parlamenttivaalien jälkeen, Alan Rusbridger, entinen The Guardianin toimittaja, :
Pääasia on, että katsoin monta vuotta amerikkalaisia sanomalehtiä ja säälin siellä olevia kollegoitani, jotka olivat yksin vastuussa uutisista, jättäen kommentoinnin täysin eri ihmisille. Ajan myötä sääli kuitenkin muuttui kateudeksi. Olen nyt sitä mieltä, että kaikkien brittiläisten kansallisten sanomalehtien tulisi erottaa vastuu uutisista ja vastuu kommenteista. Valitettavasti keskivertolukijan – varsinkin verkkolukijoiden – on liian vaikeaa havaita eroa.
Ottaen huomioon Piilaakson melko kyseenalaisen maineen etiikan suhteen, en koskaan luottaisi teknologiaan "mullistamaan" journalismia. Tästä huolimatta minä (ja monet ystäväni) olisin iloinen, jos olisi puolueeton, välinpitämätön ja luotettava uutislähde. Vaikka minulla ei ole aavistustakaan, miltä tällainen alusta voisi näyttää, olen varma, että aikakaudella, jolloin totuutta on yhä vaikeampi havaita, tarve rehelliseen journalismiin on suurempi kuin koskaan.
Sosiaaliset verkostot
Sosiaalinen media ja yhteisön uutisalustat ovat ensisijainen tiedon lähde monille ihmisille ympäri maailmaa, ja joidenkin alustojen tarkkuus ja haluttomuus tehdä edes perustavanlaatuisia faktantarkistuksia on johtanut tuhoisiin seurauksiin, kuten kansanmurhaan, vaaleihin puuttumiseen ja muihin. .
Sosiaalinen media on myös tehokkain mediatyökalu, joka on koskaan ollut olemassa. He muuttivat radikaalisti poliittista käytäntöä. He muuttivat mainontaa. He muuttivat popkulttuuria (esimerkiksi tärkein panos ns. peruutuskulttuurin kehitykseen [ostracismin kulttuurit - n. käännös.] sosiaaliset verkostot osallistuvat). Kriitikot väittävät, että sosiaalinen media on osoittautunut hedelmälliseksi maaperäksi nopeille ja omituisille moraalisten arvojen muutoksille, mutta se on myös tarjonnut syrjäytyneiden ryhmien jäsenille mahdollisuuden järjestäytyä tavoilla, joilla heillä ei ole koskaan aikaisemmin ollut. Pohjimmiltaan sosiaalinen media on muuttanut ihmisten tapaa kommunikoida ja ilmaista itseään XNUMX-luvulla.
Uskon kuitenkin myös, että sosiaalinen media tuo esiin pahimmat inhimilliset impulssit. Harkinta ja pohdiskelu unohdetaan usein suosion puolesta, ja on lähes mahdotonta ilmaista perusteltua eri mieltä tiettyjen mielipiteiden ja näkemysten kanssa. Polarisaatio karkaa usein hallinnasta, mikä johtaa siihen, että yleisö ei yksinkertaisesti kuule yksittäisiä mielipiteitä, kun taas absolutistit hallitsevat online-etikettejä ja hyväksyttävyyttä.
Mietin, onko mahdollista luoda "parempi" foorumi, joka edistää laadukkaampaa keskustelua? Loppujen lopuksi juuri se, mikä ohjaa "sitoutumista", tuo usein suurimman voiton näille alustoille. Miten Kara Swisher New York Timesissa:
Digitaalista vuorovaikutusta on mahdollista kehittää aiheuttamatta vihaa ja suvaitsemattomuutta. Syy, miksi useimmat sosiaalisen median sivustot näyttävät niin myrkyllisiltä, johtuu siitä, että ne on rakennettu nopeutta, viraalisuutta ja huomiota ajatellen, eivät sisällön ja tarkkuuden vuoksi.
Olisi todella valitettavaa, jos parin vuosikymmenen kuluttua sosiaalisen median ainoa perintö olisi julkisen keskustelun vivahteiden ja tarkoituksenmukaisuuden eroosio.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com