So'nggi o'n yillikning texnologiyasiga qarash

Eslatma. tarjima.: Medium-da xitga aylangan ushbu maqola dasturlash tillari dunyosidagi asosiy (2010-2019) o'zgarishlar va tegishli texnologiya ekotizimining umumiy ko'rinishidir (Alohida e'tibor Docker va Kubernetesga qaratilgan). Uning asl muallifi Sindi Sridxaran bo'lib, u ishlab chiquvchilar vositalari va taqsimlangan tizimlarga ixtisoslashgan - xususan, u "Tarqatilgan tizimlarni kuzatish" kitobini yozgan va Internet makonida IT-mutaxassislari orasida juda mashhur, ayniqsa bulutlilik mavzusiga qiziqadi.

So'nggi o'n yillikning texnologiyasiga qarash

2019 yil yakuniga yetar ekan, men so‘nggi o‘n yillikdagi eng muhim texnologik yutuqlar va innovatsiyalar haqida o‘z fikrlarimni baham ko‘rmoqchi edim. Bundan tashqari, men kelajakka bir oz qarashga harakat qilaman va kelgusi o'n yillikning asosiy muammolari va imkoniyatlarini belgilayman.

Shuni ta'kidlashni istardimki, ushbu maqolada men ma'lumotlar fani kabi sohalardagi o'zgarishlarni qamrab olmaganman (ma'lumotlar fan), sun'iy intellekt, frontend muhandisligi va boshqalar, chunki menda shaxsan ularda yetarlicha tajriba yo'q.

Tipifikatsiya orqaga zarba beradi

2010-yillarning eng ijobiy tendentsiyalaridan biri statik tarzda yozilgan tillarning qayta tiklanishi edi. Biroq, bunday tillar hech qachon yo'q bo'lib ketmagan (bugungi kunda C++ va Java talab qilinmoqda; ular o'n yil oldin hukmronlik qilgan), ammo 2005 yilda Ruby on Rails harakati paydo bo'lganidan keyin dinamik ravishda yozilgan tillar (dinamika) mashhurlikning sezilarli o'sishini boshdan kechirdi. . Bu o‘sish 2009-yilda Node.js’ning ochiq manbasi bilan eng yuqori cho‘qqisiga chiqdi, bu esa Javascript-on-the-serverni haqiqatga aylantirdi.

Vaqt o'tishi bilan dinamik tillar server dasturlarini yaratish sohasida o'zlarining jozibadorligini yo'qotdi. Konteyner inqilobi davrida ommalashgan Go tili yuqori unumdor, resurslarni tejaydigan, parallel ishlov berish serverlarini yaratish uchun ko'proq mos bo'lib tuyuldi (ular bilan). Men roziman Node.js yaratuvchisining o'zi).

2010-yilda taqdim etilgan Rust, o'z ichiga yutuqlarni o'z ichiga oladi tip nazariyalari xavfsiz va yozilgan tilga aylanishga urinishda. O'n yillikning birinchi yarmida sanoatda Rustni qabul qilish juda iliq edi, ammo ikkinchi yarmida uning mashhurligi sezilarli darajada oshdi. Rust uchun muhim foydalanish holatlari uning uchun ishlatilishini o'z ichiga oladi Dropbox-da sehrli cho'ntak, Firecracker AWS tomonidan (biz bu haqda gaplashdik Ushbu maqola - taxminan. tarjima.), dastlabki WebAssembly kompilyatori Lucet dan Fastly (hozirda bytecodealliancening bir qismi) va boshqalar. Microsoft Windows operatsion tizimining ba'zi qismlarini Rustda qayta yozish imkoniyatini hisobga olgan holda, 2020-yillarda bu tilning porloq kelajagi borligini ishonch bilan aytish mumkin.

Hatto dinamik tillar ham yangi xususiyatlarga ega bo'ldi ixtiyoriy turlari (ixtiyoriy turlari). Ular birinchi bo'lib TypeScript-da amalga oshirildi, bu sizga terilgan kodni yaratish va uni JavaScript-ga kompilyatsiya qilish imkonini beradi. PHP, Ruby va Python o'zlarining ixtiyoriy yozish tizimlariga ega (mypy, Hack) da muvaffaqiyatli qo'llanilmoqda Ishlab chiqarish.

SQLni NoSQL ga qaytarish

NoSQL - bu o'n yillikning boshida oxiriga qaraganda ancha mashhur bo'lgan yana bir texnologiya. Menimcha, buning ikkita sababi bor.

Birinchidan, NoSQL modeli sxemasi, tranzaksiyalari va mustahkamlik kafolatlarining zaifligi bilan SQL modeliga qaraganda amalga oshirish qiyinroq bo‘lib chiqdi. IN blog posti sarlavhasi bilan "Nega iloji boricha kuchli mustahkamlikni afzal ko'rishingiz kerak" (Nima uchun iloji boricha kuchli mustahkamlikni tanlashingiz kerak) Google yozadi:

Google'da biz o'rgangan narsalardan biri shundaki, muhandislar murakkab tranzaktsiyalarni bajarish va ma'lumotlarni tartibda saqlash uchun mavjud xotiraga tayanishi mumkin bo'lsa, dastur kodi soddaroq va ishlab chiqish vaqti qisqaroq. Asl Spanner hujjatlaridan iqtibos keltirish uchun, "Biz dasturchilar uchun tranzaksiyalarning yo'qligini doimo yodda tutgandan ko'ra, tranzaksiyalarni suiiste'mol qilish sababli dasturlarning ishlashi bilan bog'liq muammolarni hal qilish yaxshiroq deb hisoblaymiz."

Ikkinchi sabab, "kengaytirilgan" taqsimlangan SQL ma'lumotlar bazalarining ko'payishi bilan bog'liq (masalan Bulut kaliti и AWS Aurora) ommaviy bulut makonida, shuningdek, CockroachDB kabi ochiq manbali alternativalar (Biz u haqida ham gapiramiz yozgan - taxminan. tarjima.), bu an'anaviy SQL ma'lumotlar bazalarining "miqyoslanishiga" sabab bo'lgan ko'plab texnik muammolarni hal qiladi. Hatto bir paytlar NoSQL harakatining timsoli bo'lgan MongoDB ham hozir takliflar taqsimlangan tranzaktsiyalar.

Bir nechta hujjatlarda (bir yoki bir nechta to'plamlar bo'ylab) atomik o'qish va yozishni talab qiladigan vaziyatlar uchun MongoDB ko'p hujjatli tranzaksiyalarni qo'llab-quvvatlaydi. Tarqalgan tranzaktsiyalar bo'lsa, tranzaktsiyalar bir nechta operatsiyalar, to'plamlar, ma'lumotlar bazalari, hujjatlar va parchalar bo'ylab ishlatilishi mumkin.

Jami oqim

Apache Kafka, shubhasiz, so'nggi o'n yillikning eng muhim ixtirolaridan biridir. Uning manba kodi 2011 yil yanvar oyida ochilgan va yillar davomida Kafka korxonalarning ma'lumotlar bilan ishlash usulini inqilob qildi. Kafka men ishlagan har bir kompaniyada, startaplardan tortib yirik korporatsiyalargacha ishlatilgan. U taqdim etadigan kafolatlar va foydalanish holatlari (pub-sub, oqimlar, voqealarga asoslangan arxitekturalar) turli vazifalarda, ma'lumotlarni saqlashdan monitoring va oqim tahliligacha, moliya, sog'liqni saqlash, davlat sektori kabi ko'plab sohalarda talab qilinadi. chakana savdo va boshqalar.

Uzluksiz integratsiya (va kamroq darajada doimiy joylashtirish)

Uzluksiz integratsiya so'nggi 10 yil ichida paydo bo'lmadi, lekin so'nggi o'n yil ichida paydo bo'ldi shu darajada tarqaldi, bu standart ish oqimining bir qismiga aylandi (barcha tortish so'rovlari bo'yicha testlarni o'tkazing). GitHub-ni kodni ishlab chiqish va saqlash uchun platforma sifatida yaratish va eng muhimi, ish jarayonini ishlab chiqish. GitHub oqimi Masterga tortish so'rovini qabul qilishdan oldin sinovlarni o'tkazish degani yakka so'nggi o'n yil ichida o'z faoliyatini boshlagan muhandislarga tanish bo'lgan rivojlanishdagi ish oqimi.

Uzluksiz joylashtirish (har bir topshiriqni masterga kelganda va qachon joylashtirish) uzluksiz integratsiya kabi keng tarqalgan emas. Biroq, tarqatish uchun turli xil bulutli API-larning ko'pligi bilan Kubernetes (o'rnatish uchun standartlashtirilgan API taqdim etadi) kabi platformalarning tobora ommalashib borishi va Spinnaker (standartlashtirilganlar ustiga qurilgan) kabi ko'p platformali, ko'p bulutli vositalarning paydo bo'lishi. API), joylashtirish jarayonlari yanada avtomatlashtirilgan, soddalashtirilgan va umuman, xavfsizroq bo'ldi.

Konteynerlar

Konteynerlar, ehtimol, 2010-yillarning eng qizg'in, muhokama qilingan, reklama qilingan va noto'g'ri tushunilgan texnologiyasidir. Boshqa tomondan, bu o'tgan o'n yillikning eng muhim yangiliklaridan biridir. Bu kakofoniya sabablarining bir qismi biz deyarli hamma joydan olgan aralash signallarda yotadi. Endi shov-shuv biroz so‘ndi, ba’zi narsalar diqqat markazida bo‘ldi.

Konteynerlar global ishlab chiquvchilar hamjamiyatining ehtiyojlarini qondiradigan dasturni ishga tushirishning eng yaxshi usuli bo'lgani uchun emas, balki mashhur bo'ldi. Konteynerlar mashhur bo'ldi, chunki ular butunlay boshqa muammoni hal qiladigan ma'lum bir vosita uchun marketing so'roviga muvaffaqiyatli mos keladi. Docker bo'lib chiqdi fantastik dolzarb muvofiqlik muammosini hal qiladigan ishlab chiqish vositasi ("mening mashinamda ishlaydi").

Aniqroq aytganda, inqilob amalga oshirildi Docker tasviri, chunki u muhitlar o'rtasidagi paritet muammosini hal qildi va nafaqat dastur faylining, balki uning barcha dasturiy ta'minoti va operatsion bog'liqliklarining haqiqiy portativligini ta'minladi. Ushbu vosita qandaydir tarzda "konteynerlar" ning mashhurligiga turtki bo'lganligi, aslida juda past darajadagi amalga oshirish detali, men uchun so'nggi o'n yillikdagi asosiy sir bo'lib qolmoqda.

Serversiz

Men "serversiz" hisoblashning paydo bo'lishi konteynerlardan ko'ra muhimroqdir, chunki u haqiqatan ham talab bo'yicha hisoblash orzusini haqiqatga aylantiradi. (so'rov bo'yicha; talabda). So'nggi besh yil ichida men serversiz yondashuv yangi tillar va ish vaqtlarini qo'llab-quvvatlash orqali asta-sekin kengayib borayotganini ko'rdim. Azure Durable Functions kabi mahsulotlarning paydo bo'lishi davlat funktsiyalarini amalga oshirish yo'lidagi to'g'ri qadam bo'lib tuyuladi (shu bilan birga hal qiluvchi ba'zi muammolarFaaS cheklovlari bilan bog'liq). Kelgusi yillarda ushbu yangi paradigma qanday rivojlanishini qiziqish bilan kuzataman.

Avtomatlashtirish

Ehtimol, ushbu tendentsiyadan eng katta foyda oluvchi operatsion muhandislik hamjamiyatidir, chunki u infratuzilmani kod sifatida (IaC) kabi tushunchalarni haqiqatga aylantirish imkonini berdi. Bundan tashqari, avtomatlashtirishga bo'lgan ishtiyoq operatsiyalarga ko'proq dasturiy ta'minotga asoslangan yondashuvni qo'llashni maqsad qilgan "SRE madaniyati" ning yuksalishiga to'g'ri keldi.

Universal API-fication

O'tgan o'n yillikning yana bir qiziqarli xususiyati turli xil rivojlanish vazifalarini API-fikrlash edi. Yaxshi, moslashuvchan APIlar ishlab chiquvchiga innovatsion ish oqimlari va vositalarini yaratishga imkon beradi, bu esa o'z navbatida texnik xizmat ko'rsatish va foydalanuvchi tajribasini yaxshilashga yordam beradi.

Bundan tashqari, API-fication - bu ba'zi funksiyalar yoki vositalarning SaaS-fikatsiyasiga qaratilgan birinchi qadamdir. Ushbu tendentsiya mikroservislarning mashhurligi oshishi bilan ham mos keldi: SaaS API orqali kirish mumkin bo'lgan yana bir xizmatga aylandi. Hozirda monitoring, toʻlovlar, yuklarni muvozanatlash, uzluksiz integratsiya, ogohlantirishlar, funksiyalarni almashtirish kabi sohalarda koʻplab SaaS va FOSS vositalari mavjud. (xususiyatni belgilash), CDN, transport muhandisligi (masalan, DNS) va h.k., so'nggi o'n yil ichida gullab-yashnagan.

Kuzatish qobiliyati

Shuni ta'kidlash kerakki, bugungi kunda bizda foydalanish imkoniyati mavjud ancha rivojlangan ilovalar xatti-harakatlarini har qachongidan ham kuzatish va tashxislash uchun vositalar. 2015 yilda Ochiq manba maqomini olgan Prometey monitoring tizimini, ehtimol, deb atash mumkin. eng zo'r Men ishlaganlardan monitoring tizimi. Bu mukammal emas, lekin juda ko'p narsalar to'g'ri tarzda amalga oshiriladi (masalan, o'lchovlarni qo'llab-quvvatlash [o'lchovlilik] ko'rsatkichlar holatida).

Tarqatilgan kuzatuv OpenTracing (va uning vorisi OpenTelemetry) kabi tashabbuslar tufayli 2010-yillarda asosiy oqimga kirgan yana bir texnologiya edi. Kuzatuvni qo'llash hali ham juda qiyin bo'lsa-da, ba'zi so'nggi ishlanmalar biz uning haqiqiy salohiyatini 2020-yillarda ochishimizga umid qilmoqda. (Eslatma: Shuningdek, bizning blogimizda maqolaning tarjimasini o'qing "Tarqalgan kuzatuv: biz hammasini noto'g'ri qildik"O'sha muallif tomonidan.)

Kelajakka qarash

Afsuski, kelgusi o'n yillikda hal qilinishini kutayotgan ko'plab og'riqli nuqtalar mavjud. Mana ular haqidagi fikrlarim va ulardan qanday qutulish bo'yicha ba'zi potentsial g'oyalar.

Mur qonuni muammosini hal qilish

Dennardning miqyoslash qonunining tugashi va Mur qonunidan orqada qolishi yangi yangiliklarni talab qiladi. Jon Xennessi uning ma'ruzasi muammoli giyohvandlar nima uchun ekanligini tushuntiradi (domenga xos) TPU kabi arxitekturalar Mur qonunidan orqada qolish muammosining yechimlaridan biri bo'lishi mumkin. Asboblar to'plami kabi MLIR Google tomonidan allaqachon bu yo'nalishda yaxshi qadam bo'lganga o'xshaydi:

Kompilyatorlar yangi ilovalarni qo'llab-quvvatlashi, yangi uskunaga osongina ko'chirilishi, dinamik, boshqariladigan tillardan vektor tezlatgichlari va dasturiy ta'minot bilan boshqariladigan saqlash qurilmalarigacha bo'lgan bir nechta abstraksiya qatlamlarini bog'lashi kerak, shu bilan birga avtomatik sozlash uchun yuqori darajadagi kalitlarni taqdim etishi kerak. funksionallikda - vaqt, diagnostika va tizimlarning ishlashi va ishlashi haqidagi disk raskadrovka ma'lumotlarini stek bo'ylab tarqatish, aksariyat hollarda qo'lda yozilgan assemblerga yaqin bo'lgan ishlashni ta'minlaydi. Biz bunday kompilyatsiya infratuzilmasini rivojlantirish va ommaga taqdim etish bo'yicha o'z qarashlarimiz, taraqqiyotimiz va rejalarimizni baham ko'rish niyatidamiz.

CI / CD

CIning o'sishi 2010-yillarning eng katta tendentsiyalaridan biriga aylangan bo'lsa-da, Jenkins hali ham CI uchun oltin standartdir.

So'nggi o'n yillikning texnologiyasiga qarash

Ushbu makon quyidagi sohalarda innovatsiyalarga juda muhtoj:

  • foydalanuvchi interfeysi (test spetsifikatsiyalarini kodlash uchun DSL);
  • amalga oshirish tafsilotlari, bu uni haqiqatan ham kengaytiriladigan va tezkor qiladi;
  • sinovning yanada ilg'or shakllarini amalga oshirish uchun turli muhitlar (staging, prod va boshqalar) bilan integratsiya;
  • doimiy sinov va joylashtirish.

Dasturchi vositalari

Sanoat sifatida biz tobora murakkab va ta'sirchan dasturiy ta'minotni yaratishni boshladik. Biroq, o'z vositalarimiz haqida gap ketganda, vaziyat ancha yaxshi bo'lishi mumkin.

Birgalikda va masofaviy (ssh orqali) tahrirlash biroz mashhurlikka erishdi, lekin hech qachon rivojlanishning yangi standart usuli bo'lmadi. Agar siz, men kabi, g'oyani rad etsangiz ehtiyoj faqat dasturlashni amalga oshirish uchun Internetga doimiy ulanish, keyin masofaviy kompyuterda ssh orqali ishlash sizga mos kelmaydi.

Mahalliy rivojlanish muhiti, ayniqsa katta xizmatga yo'naltirilgan arxitekturada ishlaydigan muhandislar uchun hali ham qiyin. Ba'zi loyihalar buni hal qilishga harakat qilmoqda va men ma'lum bir foydalanish holati uchun eng ergonomik UX qanday ko'rinishini bilishga qiziqaman.

Shuningdek, "ko'chma muhitlar" kontseptsiyasini xatolarni ko'paytirish (yoki) kabi rivojlanishning boshqa sohalariga ham kengaytirish qiziqarli bo'lar edi. noaniq testlar) muayyan shartlar yoki sozlamalar ostida yuzaga keladigan.

Shuningdek, men semantik va kontekstga sezgir kodlarni qidirish, ishlab chiqarish hodisalarini kodlar bazasining muayyan qismlari bilan bog'lash vositalari va boshqalar kabi sohalarda ko'proq innovatsiyalarni ko'rishni xohlayman.

Hisoblash (PaaS kelajagi)

2010-yillarda konteynerlar va serversizlar haqidagi shov-shuvlardan so‘ng, so‘nggi bir necha yil ichida ommaviy bulut makonidagi yechimlar doirasi sezilarli darajada kengaydi.

So'nggi o'n yillikning texnologiyasiga qarash

Bu bir nechta qiziqarli savollarni tug'diradi. Birinchidan, ommaviy bulutdagi mavjud variantlar ro'yxati doimiy ravishda o'sib bormoqda. Bulutli xizmat ko'rsatuvchi provayderlar Ochiq manba dunyosidagi so'nggi ishlanmalardan osongina xabardor bo'lish va "serversiz pods" kabi mahsulotlarni chiqarish uchun xodimlar va resurslarga ega (menimcha, o'zlarining FaaS ish vaqtlarini OCI bilan moslashtirish orqali) yoki shunga o'xshash boshqa narsalar.

Ushbu bulutli echimlardan foydalanadiganlarga faqat hasad qilish mumkin. Nazariy jihatdan, Kubernetes bulut takliflari (GKE, EKS, Fargate-dagi EKS va boshqalar) ish yuklarini bajarish uchun bulutli provayderdan mustaqil API-larni taqdim etadi. Agar siz shunga o'xshash mahsulotlardan foydalansangiz (ECS, Fargate, Google Cloud Run va boshqalar), ehtimol siz xizmat ko'rsatuvchi provayder tomonidan taqdim etilgan eng qiziqarli xususiyatlardan maksimal darajada foydalanayotgan bo'lsangiz kerak. Bundan tashqari, yangi mahsulotlar yoki hisoblash paradigmalari paydo bo'lishi bilan migratsiya oddiy va stresssiz bo'lishi mumkin.

Bunday echimlar assortimenti qanchalik tez rivojlanayotganini hisobga olsak (yaqin kelajakda bir nechta yangi variantlar paydo bo'lmasa, men juda hayron bo'laman), kichik "platforma" guruhlari (infratuzilma bilan bog'liq va mahalliy platformalarni yaratish uchun mas'ul bo'lgan jamoalar). ishlaydigan ish yuklari kompaniyalari) funksionallik, foydalanish qulayligi va umumiy ishonchlilik nuqtai nazaridan raqobatlash juda qiyin bo'ladi. 2010-yillar Kubernetes-ni PaaS (xizmat sifatida platforma) yaratish vositasi sifatida ko'rdi, shuning uchun men uchun Kubernetes tepasida bir xil tanlov, soddalik va jamoatchilikda mavjud erkinlikni taklif qiladigan ichki platforma qurish mutlaqo befoyda. bulutli makon. Konteynerga asoslangan PaaS-ni “Kubernetes strategiyasi” sifatida shakllantirish bulutning eng innovatsion imkoniyatlaridan ataylab qochish bilan barobar.

Agar mavjud bo'lganlarga qarasangiz bugun Hisoblash qobiliyatlarini hisobga olgan holda, faqat Kubernetes-ga asoslangan o'z PaaS-ni yaratish o'zingizni burchakka bo'yash bilan teng ekanligi ayon bo'ladi (juda istiqbolli yondashuv emas, ha?). Bugun kimdir Kubernetes-da konteynerli PaaS qurishga qaror qilsa ham, bir necha yil ichida u bulut imkoniyatlariga nisbatan eskirgan ko'rinadi. Kubernetes ochiq kodli loyiha sifatida boshlangan bo'lsa-da, uning ajdodi va ilhomi ichki Google vositasidir. Biroq, u dastlab 2000-yillarning boshlarida / o'rtalarida, hisoblash landshafti butunlay boshqacha bo'lganida ishlab chiqilgan.

Bundan tashqari, juda keng ma'noda, kompaniyalar Kubernetes klasterini boshqarish bo'yicha mutaxassis bo'lishlari shart emas, shuningdek, ular o'zlarining ma'lumotlar markazlarini qurishlari va ularga xizmat ko'rsatishlari shart emas. Ishonchli hisoblash bazasini ta'minlash asosiy vazifadir bulutli xizmat ko'rsatuvchi provayderlar.

Nihoyat, men sanoat nuqtai nazaridan biroz orqaga ketganimizni his qilyapman o'zaro ta'sir tajribasi (UX). Heroku 2007 yilda ishga tushirilgan va hozirgacha eng ko'plaridan biri hisoblanadi foydalanish oson platformalar. Kubernetes ancha kuchliroq, kengaytiriladigan va dasturlashtiriladigan ekanligini inkor etib bo'lmaydi, lekin men Heroku-ni ishga tushirish va joylashtirish qanchalik osonligini sog'inaman. Ushbu platformadan foydalanish uchun siz faqat Gitni bilishingiz kerak.

Bularning barchasi meni quyidagi xulosaga olib keladi: ishlash uchun bizga yaxshiroq, yuqori darajadagi abstraktsiyalar kerak (bu ayniqsa, eng yuqori darajadagi abstraktsiyalar).

Eng yuqori darajadagi to'g'ri API

Docker bir vaqtning o'zida tashvishlarni yaxshiroq ajratish zaruratining ajoyib namunasidir eng yuqori darajadagi APIni to'g'ri amalga oshirish.

Docker bilan bog'liq muammo shundaki, (hech bo'lmaganda) dastlab loyihaning maqsadlari juda keng edi: barchasi konteyner texnologiyasidan foydalangan holda muvofiqlik muammosini ("mening mashinamda ishlaydi") hal qilish uchun. Docker tasvir formati, o'zining virtual tarmog'iga ega ish vaqti, CLI vositasi, ildiz sifatida ishlaydigan demon va boshqalar edi. Har holda, xabarlar almashinuvi bo'ldi ko'proq chalkash, "engil VMlar", guruhlar, nomlar bo'shliqlari, ko'plab xavfsizlik muammolari va "har qanday dasturni istalgan joyda qurish, yetkazib berish, ishga tushirish" marketing chaqiruvi bilan aralashgan xususiyatlar.

So'nggi o'n yillikning texnologiyasiga qarash

Barcha yaxshi abstraktsiyalarda bo'lgani kabi, turli muammolarni bir-biri bilan birlashtirilishi mumkin bo'lgan mantiqiy qatlamlarga ajratish uchun vaqt (va tajriba va og'riq) kerak. Afsuski, Docker shunga o'xshash etuklikka erishmasdan oldin, Kubernetes kurashga kirishdi. U shov-shuv siklini shu qadar monopoliyaga oldiki, endi hamma Kubernetes ekotizimidagi o'zgarishlarni kuzatib borishga harakat qildi va konteyner ekotizimi ikkinchi darajali maqomga ega bo'ldi.

Kubernetes Docker bilan bir xil muammolarni baham ko'radi. Ajoyib va ​​tuzilgan mavhumlik haqidagi barcha gaplar uchun, turli vazifalarni qatlamlarga ajratish unchalik yaxshi qamrab olinmagan. Asosiysi, bu turli xil mashinalar klasterida konteynerlarni boshqaradigan konteyner orkestridir. Bu juda past darajadagi vazifa bo'lib, faqat klasterda ishlaydigan muhandislarga tegishli. Boshqa tomondan, Kubernetes ham eng yuqori darajadagi abstraksiya, foydalanuvchilar YAML orqali muloqot qiladigan CLI vositasi.

Docker edi (va hozir ham shunday) salqin barcha kamchiliklariga qaramay, rivojlanish vositasi. Bir vaqtning o'zida barcha "quyonlar" ni kuzatib borish uchun uni ishlab chiquvchilari to'g'ri amalga oshirishga muvaffaq bo'lishdi eng yuqori darajada abstraksiya. Eng yuqori darajadagi abstraksiya deganda men tushunaman kichik to'plam maqsadli auditoriya (bu holda, ko'p vaqtini mahalliy rivojlanish muhitida o'tkazgan ishlab chiquvchilar) haqiqatan ham qiziqadigan va qutidan tashqarida ajoyib ishlagan funksionallik.

Dockerfile va CLI yordam dasturi docker yaxshi "yuqori darajadagi foydalanuvchi tajribasini" qanday yaratishga misol bo'lishi kerak. Oddiy ishlab chiquvchi Docker bilan ishlashni nozik jihatlari haqida hech narsa bilmasdan boshlashi mumkin operatsion tajribaga hissa qo'shadigan ilovalarnomlar maydoni, guruhlar, xotira va protsessor chegaralari va boshqalar. Oxir oqibat, Dockerfile yozish qobiq skriptini yozishdan unchalik farq qilmaydi.

Kubernetes turli maqsadli guruhlar uchun mo'ljallangan:

  • klaster ma'murlari;
  • infratuzilma masalalari ustida ishlovchi dasturiy ta'minot muhandislari, Kubernetes imkoniyatlarini kengaytirish va uning asosida platformalarni yaratish;
  • orqali Kubernetes bilan o'zaro aloqada bo'lgan oxirgi foydalanuvchilar kubectl.

Kubernetesning "bitta API hammaga mos" yondashuvi etarli darajada qamrab olinmagan "murakkablik tog'ini" taqdim etadi, uni qanday o'lchash bo'yicha ko'rsatma yo'q. Bularning barchasi asossiz ravishda cho'zilgan o'quv traektoriyasiga olib keladi. Qanaqasiga U yozadi Adam Jeykob, “Docker hech qachon oshib bo'lmaydigan o'zgaruvchan foydalanuvchi tajribasini keltirdi. K8-dan foydalanadigan har bir kishidan u birinchisi kabi ishlashini xohlaydimi yoki yo'qligini so'rang docker run. Javob ha bo'ladi":

So'nggi o'n yillikning texnologiyasiga qarash

Men bugungi kunda aksariyat infratuzilma texnologiyalari juda past darajada (va shuning uchun "juda murakkab" deb hisoblanadi) deb bahslashaman. Kubernetes juda past darajada amalga oshiriladi. Uning ichida taqsimlangan kuzatuv joriy shakl (ko'p oraliqlar bir-biriga tikilgan va kuzatuv ko'rinishini hosil qiladi) ham juda past darajada amalga oshiriladi. "Eng yuqori darajadagi abstraksiyalarni" amalga oshiradigan ishlab chiquvchi vositalari eng muvaffaqiyatli bo'ladi. Bu xulosa hayratlanarli holatlarga to'g'ri keladi (agar texnologiya juda murakkab yoki foydalanish qiyin bo'lsa, bu texnologiya uchun "eng yuqori darajadagi API/UI" hali topilmagan).

Hozirda bulutli mahalliy ekotizim past darajadagi fokus tufayli chalkash. Sanoat sifatida biz innovatsiyalar kiritishimiz, tajriba o'tkazishimiz va "maksimal, eng yuqori mavhumlik" ning to'g'ri darajasi qanday ko'rinishini o'rgatishimiz kerak.

Chakana savdo

2010-yillarda raqamli chakana savdo tajribasi deyarli o'zgarishsiz qoldi. Bir tomondan, onlayn xarid qilishning qulayligi an'anaviy chakana savdo do'konlariga ta'sir qilishi kerak edi, boshqa tomondan, onlayn xaridlar o'n yil ichida deyarli o'zgarishsiz qoldi.

Kelgusi o'n yil ichida ushbu soha qanday rivojlanishi haqida aniq fikrga ega bo'lmasam-da, agar biz 2030 yildagi kabi 2020 yilda xarid qilsak, juda xafa bo'laman.

Jurnalistika

Men global jurnalistikaning holatidan ko'proq ko'nglim to'ldi. Ob'ektiv va sinchkovlik bilan xabar beradigan xolis axborot manbalarini topish tobora qiyinlashib bormoqda. Ko'pincha yangiliklarning o'zi va u haqidagi fikrlar o'rtasidagi chegara xiralashgan. Qoidaga ko'ra, ma'lumotlar noxolis tarzda taqdim etiladi. Bu, ayniqsa, tarixda yangiliklar va fikr o'rtasida hech qanday farq bo'lmagan ba'zi mamlakatlarda to'g'ri keladi. Buyuk Britaniyadagi so'nggi umumiy saylovlardan so'ng chop etilgan yaqinda nashr etilgan maqolada, The Guardianning sobiq muharriri Alan Rusbridjer, U yozadi:

Asosiy gap shundaki, men uzoq yillar Amerika gazetalarini ko‘rib, u yerdagi hamkasblarimga achindim, ular yangilik uchun faqat mas’ul bo‘lib, sharhni butunlay boshqa odamlarga topshirib qo‘yishdi. Biroq, vaqt o'tishi bilan achinish hasadga aylandi. Endi men Britaniyaning barcha milliy gazetalari yangiliklar uchun o'z mas'uliyatini sharhlash mas'uliyatidan ajratishi kerak deb o'ylayman. Afsuski, oddiy o'quvchi, ayniqsa onlayn o'quvchilar uchun farqni tushunish juda qiyin.

Silikon vodiysining axloqiy jihatdan shubhali obro'sini hisobga olsak, men texnologiya jurnalistikada "inqilob" qilishiga hech qachon ishonmayman. Aytgancha, men (va mening ko'plab do'stlarim) xolis, befarq va ishonchli axborot manbasi bo'lsa, xursand bo'lardim. Bunday platforma qanday ko‘rinishda bo‘lishi haqida hech qanday tasavvurga ega bo‘lmasam-da, ishonchim komilki, haqiqatni aniqlash tobora qiyinlashib borayotgan bir davrda halol jurnalistikaga ehtiyoj har qachongidan ham kuchaymoqda.

ijtimoiy Tarmoq

Ijtimoiy tarmoqlar va jamoat yangiliklari platformalari butun dunyo boʻylab koʻplab odamlar uchun asosiy maʼlumot manbai boʻlib, baʼzi platformalarning aniqligi yoʻqligi va hatto oddiy faktlarni tekshirishni istamasligi genotsid, saylovlarga aralashuv va boshqalar kabi halokatli oqibatlarga olib keldi. .

Ijtimoiy media ham mavjud bo'lgan eng kuchli media vositasidir. Ular siyosiy amaliyotni tubdan o'zgartirdilar. Ular reklamani o'zgartirdilar. Ular pop madaniyatini o'zgartirdilar (masalan, bekor qilish madaniyatining rivojlanishiga asosiy hissa qo'shdi [ostracizm madaniyatlari - taxminan. tarjima] ijtimoiy tarmoqlar hissa qo'shadi). Tanqidchilarning ta'kidlashicha, ijtimoiy media axloqiy qadriyatlarning tez va injiq o'zgarishlari uchun qulay zamin bo'lgan, ammo u marginal guruhlar a'zolariga ilgari hech qachon bo'lmagan tarzda tashkillashish imkoniyatini bergan. Aslini olganda, ijtimoiy tarmoqlar XXI asrda odamlarning muloqot qilish va o‘zini ifoda etish usullarini o‘zgartirdi.

Biroq, men ijtimoiy tarmoqlar eng yomon insoniy impulslarni keltirib chiqarishiga ham ishonaman. Mulohazakorlik va mulohazakorlik ko'pincha mashhurlik foydasiga e'tibordan chetda qoladi va ba'zi fikrlar va pozitsiyalar bilan asosli kelishmovchilikni bildirish deyarli mumkin emas. Polarizatsiya ko'pincha nazoratdan chiqib ketadi, natijada jamoatchilik shaxsiy fikrlarni eshitmaydi, absolyutistlar esa onlayn etiket va maqbullik masalalarini nazorat qiladi.

Qiziq, yanada sifatli munozaralarga yordam beradigan “yaxshiroq” platforma yaratish mumkinmi? Axir, ko'pincha ushbu platformalarga asosiy daromad keltiradigan "ishtirok etish" ga sabab bo'ladi. Qanaqasiga U yozadi Nyu-York Taymsdagi Kara Swisher:

Nafrat va murosasizlikni qo'zg'atmasdan raqamli shovqinlarni rivojlantirish mumkin. Aksariyat ijtimoiy media saytlari juda zaharli ko'rinishining sababi shundaki, ular kontent va aniqlik uchun emas, balki tezlik, viruslilik va e'tibor uchun yaratilgan.

Agar bir necha o'n yilliklar ichida ijtimoiy tarmoqlarning yagona merosi ommaviy nutqdagi nuans va moslikning emirilishi bo'lsa, bu haqiqatan ham achinarli bo'lar edi.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

a Izoh qo'shish