Анхаарна уу. орчуулга.: Medium дээр хит болсон энэхүү нийтлэл нь програмчлалын хэл болон холбогдох технологийн экосистемд гарсан гол өөрчлөлтүүдийн тойм (2010-2019) юм (Докер болон Кубернетес дээр онцгой анхаарал хандуулсан). Үүний анхны зохиогч нь Синди Сридхаран бөгөөд хөгжүүлэгчийн хэрэгсэл, түгээлтийн системээр мэргэшсэн, ялангуяа тэрээр "Тархсан системийн ажиглалт" номыг бичсэн бөгөөд мэдээллийн технологийн мэргэжилтнүүдийн дунд интернетийн орон зайд нэлээд алдартай, ялангуяа үүлний сэдвийг сонирхож байна.
2019 он дуусах дөхөж байгаа энэ үед би сүүлийн арван жилийн хамгийн чухал технологийн дэвшил, инновацийн талаар санал бодлоо хуваалцахыг хүслээ. Үүнээс гадна би ирээдүйгээ бага зэрэг харж, ирэх арван жилийн гол бэрхшээл, боломжуудыг тоймлохыг хичээх болно.
Энэ нийтлэлд би мэдээллийн шинжлэх ухаан гэх мэт салбарт гарсан өөрчлөлтүүдийг тусгаагүй гэдгээ тодорхой хэлмээр байна (өгөгдлийн шинжлэх ухаан), хиймэл оюун ухаан, урд талын инженерчлэл гэх мэт, учир нь би хувьдаа энэ талаар хангалттай туршлагагүй.
Тэмдэглэл буцаах
2010-аад оны хамгийн эерэг хандлагын нэг бол статик хэлбэрээр бичигдсэн хэлийг сэргээх явдал байв. Гэсэн хэдий ч ийм хэлүүд хэзээ ч алга болоогүй (C++ болон Java нь өнөөдөр эрэлт хэрэгцээтэй байгаа; тэд арван жилийн өмнө давамгайлж байсан), гэхдээ 2005 онд Ruby on Rails хөдөлгөөн гарч ирсний дараа динамикаар бичсэн хэлүүд (динамикууд) ихээхэн алдаршсан. . Энэхүү өсөлт нь 2009 онд Node.js-ийн нээлттэй эх үүсвэртэй болсноор дээд цэгтээ хүрсэн нь сервер дээрх Javascript-ийг бодитой болгосон.
Цаг хугацаа өнгөрөхөд динамик хэлүүд серверийн програм хангамжийг бий болгох талбарт зарим сонирхол татахуйц байдлаа алдсан. Контейнерийн хувьсгалын үеэр алдаршсан Go хэл нь зэрэгцээ боловсруулалт бүхий өндөр хүчин чадалтай, нөөцийн хэмнэлттэй серверүүдийг бий болгоход илүү тохиромжтой мэт санагдсан. Node.js-ийг бүтээгч өөрөө).
2010 онд танилцуулагдсан Rust нь дэвшилтүүдийг багтаасан аюулгүй, бичигдсэн хэл болох оролдлого. Арван жилийн эхний хагаст зэвсгийн салбарынхны хүлээн авалт нэлээд дулаахан байсан ч хоёрдугаар хагаст түүний нэр хүнд мэдэгдэхүйц өссөн байна. Зэвийг ашиглах нь чухал тохиолдлуудад түүний хэрэглээ орно , (Бид энэ талаар ярилцсан - ойролцоогоор. орчуул.), эрт WebAssembly хөрвүүлэгч Fastly (одоо bytecodealliance-ийн нэг хэсэг) гэх мэт. Microsoft нь Windows үйлдлийн системийн зарим хэсгийг Rust дээр дахин бичих боломжийг харгалзан үзэж байгаа тул энэ хэл 2020-иод онд гэрэлт ирээдүйтэй гэж хэлж болно.
Динамик хэлүүд ч гэсэн шинэ боломжуудтай болсон (заавал биш төрөл). Тэдгээрийг анх TypeScript хэл дээр хэрэгжүүлсэн бөгөөд энэ нь шивсэн код үүсгэж, JavaScript-д хөрвүүлэх боломжийг олгодог. PHP, Ruby болон Python нь өөрийн гэсэн нэмэлт бичих системтэй (, ), амжилттай ашиглаж байна .
SQL-г NoSQL рүү буцаах
NoSQL бол арван жилийн эхэнд төгсгөлөөс хамаагүй илүү алдартай байсан өөр нэг технологи юм. Үүнд хоёр шалтгаан бий гэж бодож байна.
Нэгдүгээрт, NoSQL загвар нь схемгүй, гүйлгээгүй, тууштай байдлын баталгаа сул байсан нь SQL загвараас илүү хэрэгжүүлэхэд хэцүү болсон. IN "Яагаад та аль болох хүчтэй тууштай байдлыг илүүд үзэх ёстой вэ" гэсэн гарчигтай (Яагаад та аль болох хүчтэй тууштай байдлыг сонгох ёстой) Google бичдэг:
Google-ээс бидний сурсан нэг зүйл бол инженерүүд нарийн төвөгтэй гүйлгээг хийх, өгөгдлийг эмх цэгцтэй байлгахын тулд одоо байгаа хадгалах санд найдаж болох үед програмын код илүү хялбар бөгөөд боловсруулах хугацаа богино байдаг. Спаннерын анхны баримт бичгээс иш татахад, "Бид програмистууд гүйлгээ байхгүй гэдгийг байнга санаж байхын оронд гүйлгээний урвуулан ашигласны улмаас программ хангамжийн гүйцэтгэлийн асуудлыг шийдвэрлэх нь илүү дээр гэж үзэж байна."
Хоёрдахь шалтгаан нь тархсан SQL мэдээллийн сан (жишээ нь и ) нийтийн үүлэн орон зайд, мөн CockroachDB зэрэг Нээлттэй эхийн хувилбарууд (Бид бас түүний тухай ярьж байна - ойролцоогоор. орчуул.), энэ нь уламжлалт SQL мэдээллийн санг "хэмжээгүй" болоход хүргэсэн техникийн олон асуудлыг шийддэг. Нэгэн цагт NoSQL хөдөлгөөний үлгэр жишээ болсон MongoDB хүртэл одоо байна тараасан гүйлгээ.
Олон баримт бичигт (нэг буюу хэд хэдэн цуглуулгад) атомын уншигдах, бичих шаардлагатай нөхцөл байдлын хувьд MongoDB нь олон баримт бичгийн гүйлгээг дэмждэг. Тархсан гүйлгээний хувьд гүйлгээг олон үйлдэл, цуглуулга, мэдээллийн сан, баримт бичиг, хэлтэрхий дээр ашиглаж болно.
Нийт дамжуулалт
Апачи Кафка бол эргэлзээгүй сүүлийн арван жилийн хамгийн чухал бүтээлүүдийн нэг юм. Түүний эх код нь 2011 оны XNUMX-р сард нээгдсэн бөгөөд олон жилийн турш Кафка бизнесүүдийн өгөгдөлтэй ажиллах аргад хувьсгал хийсэн. Кафкаг миний ажиллаж байсан стартапаас эхлээд томоохон корпорацуудад хүртэл ашигласан. Түүний хангадаг баталгаа, ашиглалтын тохиолдлууд (pub-sub, streams, event-driven архитектурууд) нь санхүү, эрүүл мэнд, төрийн салбар, гэх мэт олон салбарт эрэлт хэрэгцээтэй байгаа өгөгдөл хадгалахаас эхлээд мониторинг, стриминг аналитик хүртэл төрөл бүрийн ажлуудад ашиглагддаг. жижиглэн худалдаа гэх мэт.
Тасралтгүй интеграци (ба бага хэмжээгээр Тасралтгүй байршуулалт)
Тасралтгүй интеграци нь сүүлийн 10 жилд гараагүй ч сүүлийн XNUMX жилд гарч ирсэн ийм хэмжээнд хүрээд байна, энэ нь стандарт ажлын урсгалын нэг хэсэг болсон (бүх татах хүсэлт дээр туршилт явуулах). GitHub-ийг код боловсруулах, хадгалах платформ болгон бий болгох, хамгийн чухал нь дээр суурилсан ажлын урсгалыг хөгжүүлэх. мастер руу татах хүсэлтийг хүлээн авахаас өмнө туршилтыг явуулж байна гэсэн үг цорын ганц сүүлийн арван жилд ажлын гараагаа эхэлсэн инженерүүдэд танил болсон хөгжлийн ажлын урсгал.
Тасралтгүй байршуулалт (амжилт бүрийг мастерт хүрэх үед нь байрлуулах) нь тасралтгүй интеграцчилал шиг өргөн тархсан зүйл биш юм. Гэсэн хэдий ч ашиглахад зориулагдсан олон тооны клоуд API-уудын ачаар Kubernetes (байршуулах стандарт API өгдөг) зэрэг платформууд улам бүр түгээмэл болж, Spinnaker зэрэг олон платформ, олон үүлэн хэрэглүүрүүд гарч ирэв (стандаршсан дээр суурилуулсан). API), байршуулах процессууд илүү автоматжсан, оновчтой, ерөнхийдөө илүү аюулгүй болсон.
Контейнер
Контейнер бол 2010-аад оны хамгийн их шуугиан дэгдээсэн, яригдсан, сурталчилсан, буруу ойлгогдсон технологи байж магадгүй юм. Нөгөөтэйгүүр, энэ нь өмнөх арван жилийн хамгийн чухал шинэчлэлүүдийн нэг юм. Энэ бүх какофонигийн нэг хэсэг нь бидний бараг бүх газраас хүлээн авсан холимог дохионд оршдог. Одоо шуугиан бага зэрэг намжсан тул зарим зүйл илүү хурцаар тавигдаж байна.
Контейнер нь дэлхийн хөгжүүлэгчдийн нийгэмлэгийн хэрэгцээнд нийцсэн програмыг ажиллуулах хамгийн сайн арга учраас биш харин түгээмэл болсон. Контейнерлер нь огт өөр асуудлыг шийддэг тодорхой хэрэгсэлд зориулсан маркетингийн хүсэлтэд амжилттай нийцсэн тул алдартай болсон. Докер болж хувирав гайхалтай Тохиромжтой байдлын тулгамдсан асуудлыг шийддэг хөгжүүлэлтийн хэрэгсэл ("миний машин дээр ажилладаг").
Бүр тодруулбал, хувьсгал хийсэн Докерын зураг, учир нь энэ нь орчны хоорондын тэгш байдлын асуудлыг шийдэж, зөвхөн програмын файл төдийгүй түүний бүх програм хангамж, үйлдлийн хамаарлыг жинхэнэ зөөвөрлөх боломжийг олгосон. Энэ хэрэгсэл нь маш бага түвшний хэрэгжилтийн нарийн ширийн зүйл болох "контейнер" -ийн алдар нэрийг ямар нэгэн байдлаар өдөөсөн нь сүүлийн арван жилийн гол нууц хэвээр үлдэж магадгүй юм.
Сервергүй
"Сервергүй" тооцоолол бий болсон нь чингэлэгээс ч илүү чухал гэж би бооцоо тавих болно, учир нь энэ нь эрэлт хэрэгцээний тооцоолол хийх мөрөөдлийг үнэхээр бодитой болгодог. (хүсэлтээр). Сүүлийн таван жилийн хугацаанд би сервергүй хандлагыг шинэ хэл болон ажиллах цагуудад дэмжлэг нэмснээр хамрах хүрээ нь аажмаар өргөжиж байгааг би харсан. Azure Durable Functions гэх мэт бүтээгдэхүүнүүд гарч ирсэн нь төлөв байдлын функцуудыг хэрэгжүүлэх зөв алхам юм шиг санагдаж байна (үүнтэй зэрэгцэн шийдвэрлэх FaaS хязгаарлалттай холбоотой). Ирэх жилүүдэд энэ шинэ парадигм хэрхэн хөгжихийг би сонирхон ажиглах болно.
Автоматжуулалт
Магадгүй энэ чиг хандлагын хамгийн том ашиг хүртэгч нь дэд бүтэц код (IaC) гэх мэт ойлголтуудыг бодитой болгох боломжийг олгосон үйл ажиллагааны инженерийн нийгэмлэг байж магадгүй юм. Нэмж дурдахад автоматжуулалтын хүсэл эрмэлзэл нь үйл ажиллагаанд илүү програм хангамж төвлөрсөн хандлагыг хэрэгжүүлэх зорилготой "SRE соёл" бий болсонтой давхцаж байна.
Universal API-fication
Сүүлийн XNUMX жилийн өөр нэг сонирхолтой онцлог нь янз бүрийн хөгжүүлэлтийн даалгавруудын API-ийн зохицол юм. Сайн, уян хатан API-ууд нь хөгжүүлэгчдэд шинэлэг ажлын урсгал, хэрэгслийг бий болгох боломжийг олгодог бөгөөд энэ нь эргээд засвар үйлчилгээ хийх, хэрэглэгчийн туршлагыг сайжруулахад тусалдаг.
Нэмж дурдахад API-fication нь зарим функц эсвэл хэрэгслийг SaaS-тай болгох эхний алхам юм. Энэ хандлага нь микро үйлчилгээний нэр хүнд өссөнтэй давхцаж байсан: SaaS нь API-ээр дамжуулан хандах боломжтой өөр нэг үйлчилгээ болжээ. Хяналт, төлбөр, ачааллыг тэнцвэржүүлэх, тасралтгүй нэгтгэх, сэрэмжлүүлэг, функцийг солих зэрэг олон салбарт SaaS болон FOSS хэрэгслүүд байдаг. (онцлогыг тэмдэглэх), CDN, замын хөдөлгөөний инженерчлэл (жишээ нь DNS) гэх мэт сүүлийн арван жилд цэцэглэн хөгжиж байна.
Ажиглах чадвар
Өнөөдөр бидэнд хандах боломжтой гэдгийг тэмдэглэх нь зүйтэй хамаагүй илүү дэвшилтэт урьд өмнө хэзээ ч байгаагүйгээр програмын үйл ажиллагааг хянах, оношлох хэрэгслүүд. 2015 онд Нээлттэй эхийн статусыг авсан Prometheus хяналтын системийг нэрлэж болно. Хамгийн сайн Миний ажиллаж байсан хүмүүсээс хяналтын систем. Энэ нь төгс биш, гэхдээ нэлээд олон зүйлийг яг зөв аргаар хэрэгжүүлдэг (жишээлбэл, хэмжилтийг дэмжих) [хэмжээ] хэмжүүрийн хувьд).
OpenTracing (болон түүний залгамжлагч OpenTelemetry) зэрэг санаачлагуудын ачаар 2010-аад онд тархсан мөрдөж эхэлсэн өөр нэг технологи байсан. Хэдийгээр мөрдлөгийг хэрэгжүүлэхэд нэлээд хэцүү хэвээр байгаа ч сүүлийн үеийн зарим бүтээн байгуулалтууд нь бид 2020-иод онд түүний жинхэнэ боломжийг нээх болно гэсэн найдвар төрүүлж байна. (Тэмдэглэл: "Өгүүллийн орчуулгыг манай блогоос уншина уу."ижил зохиогч.)
Ирээдүй рүү харж байна
Харамсалтай нь ойрын арван жилд шийдэгдэхийг хүлээж буй олон өвдөлтийн цэгүүд байна. Тэдгээрийн талаарх миний бодол, тэднээс хэрхэн ангижрах талаар зарим боломжит санаанууд энд байна.
Мурын хуулийн асуудлыг шийдэх
Деннардын хуулиа дуусгавар болгож, Мурын хуулиас хоцорч байгаа нь шинэ шинэчлэлийг шаарддаг. Жон Хеннесси орсон асуудалд донтогчдын шалтгааныг тайлбарлав (домайн тусгай) TPU гэх мэт архитектурууд нь Мурын хуулиас хоцрох асуудлыг шийдэх нэг шийдэл байж болох юм. Хэрэгслийн хэрэгсэл гэх мэт Google-ээс энэ чиглэлд урагшлах сайн алхам болсон бололтой:
Хөрвүүлэгчид шинэ програмуудыг дэмжиж, шинэ техник хангамжид хялбархан шилжүүлж, динамик, удирддаг хэлээс вектор хурдасгуур, програм хангамжийн хяналттай хадгалах төхөөрөмж хүртэлх хийсвэрлэлийн олон давхаргыг холбохын зэрэгцээ автоматаар тааруулах өндөр түвшний свичээр хангаж, зүгээр л функциональд - цаг хугацаа, оношилгоо, системийн ажиллагаа, гүйцэтгэлийн талаарх дибаг хийх мэдээллийг стек даяар түгээх ба ихэнх тохиолдолд гараар бичсэн ассемблертэй ойролцоо гүйцэтгэлийг хангадаг. Бид ийм эмхэтгэлийн дэд бүтцийг хөгжүүлэх, олон нийтэд хүртээмжтэй болгох талаар алсын хараа, ахиц дэвшил, төлөвлөгөөгөө хуваалцахыг зорьж байна.
CI / CD
CI-ийн өсөлт нь 2010-аад оны хамгийн том чиг хандлагын нэг болсон хэдий ч Женкинс CI-ийн алтан стандарт хэвээр байна.
Энэ орон зайд дараах чиглэлээр инноваци зайлшгүй шаардлагатай байна.
- хэрэглэгчийн интерфэйс (туршилтын үзүүлэлтүүдийг кодлох DSL);
- үүнийг үнэхээр өргөжүүлэх боломжтой, хурдан болгох хэрэгжилтийн дэлгэрэнгүй мэдээлэл;
- Туршилтын илүү дэвшилтэт хэлбэрийг хэрэгжүүлэхийн тулд янз бүрийн орчинтой (үе шатлал, үйлдвэрлэл гэх мэт) нэгтгэх;
- тасралтгүй туршилт, байршуулалт.
Хөгжүүлэгчийн хэрэгсэл
Салбарын хувьд бид улам бүр төвөгтэй, гайхалтай программ хангамжийг бүтээж эхэлсэн. Гэсэн хэдий ч, өөрсдийнхөө багаж хэрэгслийн тухай ярих юм бол нөхцөл байдал илүү дээр байх болно.
Хамтарсан болон алсын зайнаас (ssh-ээр дамжуулан) засварлах нь нэлээд алдартай болсон боловч хэзээ ч хөгжлийн шинэ стандарт арга болж чадаагүй юм. Хэрэв та надтай адил санаагаа үгүйсгэвэл хэрэгцээ зүгээр л програмчлал хийх чадвартай байхын тулд интернетэд байнгын холболт, дараа нь алсын машин дээр ssh-ээр ажиллах нь танд тохирохгүй байх магадлалтай.
Орон нутгийн хөгжлийн орчин, ялангуяа томоохон үйлчилгээнд чиглэсэн архитектур дээр ажиллаж буй инженерүүдийн хувьд бэрхшээлтэй хэвээр байна. Зарим төслүүд үүнийг шийдэхийг оролдож байгаа бөгөөд тухайн хэрэглээний тохиолдолд хамгийн эргономик UX ямар харагдахыг мэдэхийг хүсч байна.
Мөн "зөөврийн орчин" гэсэн ойлголтыг хөгжлийн бусад салбарт, тухайлбал алдааны нөхөн үржихүй (эсвэл) ) тодорхой нөхцөл эсвэл тохиргоонд тохиолддог.
Би мөн утгын болон контекст мэдрэмтгий код хайх, кодын баазын тодорхой хэсгүүдтэй үйлдвэрлэлийн ослыг уялдуулах хэрэгсэл гэх мэт салбарт илүү их шинэчлэл хийхийг хүсч байна.
Тооцоолох (PaaS-ийн ирээдүй)
2010-аад онд контейнер, сервергүй гэсэн шуугиан дэгдээсний дараа олон нийтийн үүлэн орон зай дахь шийдлүүдийн хүрээ сүүлийн хэдэн жилд мэдэгдэхүйц өргөжиж байна.
Энэ нь хэд хэдэн сонирхолтой асуултуудыг төрүүлдэг. Юуны өмнө нийтийн үүлэн дэх боломжтой сонголтуудын жагсаалт байнга нэмэгдэж байна. Үүлэн үйлчилгээ үзүүлэгчид нь Нээлттэй эхийн ертөнц дэх хамгийн сүүлийн үеийн хөгжил дэвшлийг хялбархан дагаж мөрдөх, "сервергүй pods" (би зүгээр л өөрсдийн FaaS ажиллах цагийг OCI-д нийцсэн болгосноор би сэжиглэж байна) эсвэл бусад ижил төстэй зүйлсийг гаргах боломжтой боловсон хүчин, нөөцтэй.
Эдгээр үүлэн шийдлүүдийг ашигладаг хүмүүст л атаархаж болно. Онолын хувьд Kubernetes үүлэн саналууд (GKE, EKS, Fargate дээрх EKS гэх мэт) нь ажлын ачааллыг ажиллуулахад зориулсан үүлэн үйлчилгээ үзүүлэгчээс хараат бус API-уудыг хангадаг. Хэрэв та ижил төстэй бүтээгдэхүүн (ECS, Fargate, Google Cloud Run гэх мэт) ашигладаг бол үйлчилгээ үзүүлэгчийн санал болгож буй хамгийн сонирхолтой функцуудыг аль хэдийн ашиглаж байгаа байх. Нэмж дурдахад, шинэ бүтээгдэхүүн эсвэл тооцооллын парадигмууд гарч ирэх тусам шилжилт хөдөлгөөн энгийн бөгөөд стрессгүй байх болно.
Ийм шийдлүүдийн цар хүрээ хэр хурдан хөгжиж байгааг харгалзан үзэхэд (ойрын ирээдүйд хэд хэдэн шинэ сонголт гарч ирэхгүй бол би маш их гайхах болно), жижиг "платформ" багууд (дэд бүтэцтэй холбоотой, газар дээр нь платформ үүсгэх үүрэгтэй багууд). Ачаалал ихтэй компаниуд ажиллаж байгаа) функциональ байдал, ашиглахад хялбар, ерөнхий найдвартай байдлын хувьд өрсөлдөхөд үнэхээр хэцүү байх болно. 2010-аад онуудад Kubernetes-ийг PaaS (үйлчилгээ болгон платформ) бий болгох хэрэгсэл гэж үзсэн тул Kubernetes дээр ижил сонголт, энгийн байдал, эрх чөлөөг санал болгодог дотоод платформыг бий болгох нь надад утгагүй юм шиг санагдаж байна. үүлний орон зай. Контейнер дээр суурилсан PaaS-ийг "Кубернетес стратеги" болгон ашиглах нь үүлний хамгийн шинэлэг боломжуудаас санаатайгаар зайлсхийсэнтэй адил юм.
Боломжтойг нь харвал өнөөдөр Зөвхөн Кубернетес дээр тулгуурлан өөрийн PaaS-ийг бий болгох нь өөрийгөө буланд будсантай адил зүйл болох нь тодорхой болж байна (маш их ирээдүйтэй хандлага биш, тийм үү?). Өнөөдөр хэн нэгэн Kubernetes-д суурилсан чингэлэгтэй PaaS бүтээхээр шийдсэн ч гэсэн хэдэн жилийн дараа энэ нь үүлний боломжуудтай харьцуулахад хуучирсан харагдах болно. Хэдийгээр Кубернетес нь нээлттэй эхийн төслөөр эхэлсэн ч түүний өвөг дээдэс, урам зориг нь Google-ийн дотоод хэрэгсэл юм. Гэсэн хэдий ч, энэ нь 2000-аад оны эхэн/дунд үед компьютерийн ландшафт огт өөр байсан үед бүтээгдсэн.
Түүнчлэн, маш өргөн утгаараа компаниуд Кубернетес кластерыг ажиллуулах мэргэжилтэн болох шаардлагагүй, мөн өөрсдийн мэдээллийн төвөө барьж, засвар үйлчилгээ хийдэггүй. Тооцооллын найдвартай суурийг бий болгох нь гол сорилт юм үүлэн үйлчилгээ үзүүлэгчид.
Эцэст нь хэлэхэд, бид салбарын хувьд бага зэрэг ухарсан юм шиг санагдаж байна харилцан үйлчлэлийн туршлага (). Heroku нь 2007 онд худалдаанд гарсан бөгөөд одоог хүртэл хамгийн алдартай нь юм хэрэглэхэд хялбар платформууд. Kubernetes нь илүү хүчирхэг, өргөтгөх боломжтой, програмчлагдах боломжтой гэдгийг үгүйсгэх аргагүй, гэхдээ би Хероку руу эхлүүлэх, байршуулах нь хичнээн хялбар болохыг санаж байна. Энэ платформыг ашиглахын тулд та зөвхөн Git-ийг мэдэх хэрэгтэй.
Энэ бүхэн намайг дараах дүгнэлтэд хүргэж байна: ажиллахын тулд илүү сайн, дээд түвшний хийсвэрлэл хэрэгтэй (энэ нь ялангуяа үнэн юм. хамгийн дээд түвшний хийсвэрлэлүүд).
Хамгийн дээд түвшний зөв API
Докер бол санаа зовоосон асуудлуудыг нэгэн зэрэг сайн салгах хэрэгцээний гайхалтай жишээ юм хамгийн дээд түвшний API-ийн зөв хэрэгжилт.
Docker-тэй холбоотой асуудал бол (наад зах нь) төслийн зорилго нь эхэндээ хэтэрхий өргөн хүрээтэй байсан: бүгд контейнер технологийг ашиглан нийцтэй байдлын асуудлыг шийдэхийн тулд ("миний машин дээр ажилладаг"). Docker нь зургийн формат, өөрийн виртуал сүлжээтэй ажиллах цаг, CLI хэрэгсэл, root хэлбэрээр ажилладаг дэмон болон бусад олон зүйл байсан. Ямар ч байсан мессеж солилцсон дэлгэрэнгүй "Хөнгөн VM-ууд", бүлгүүд, нэрсийн орон зай, олон тооны аюулгүй байдлын асуудлууд болон "аль ч програмыг хаана ч бүтээх, хүргэх, ажиллуулах" маркетингийн дуудлагатай холилдсон төөрөгдөл.
Бүх сайн хийсвэрлэлийн нэгэн адил янз бүрийн асуудлыг бие биетэйгээ нэгтгэж болох логик давхарга болгон задлахад цаг хугацаа (мөн туршлага, өвдөлт) хэрэгтэй. Харамсалтай нь, Докер ижил төлөвшилд хүрэхээс өмнө Кубернетес тэмцэлд оров. Энэ нь шуугиан дэгдээх циклийг маш их монопольчилж, одоо бүгд Кубернетес экосистемийн өөрчлөлтийг дагаж мөрдөхийг хичээж, контейнерийн экосистем хоёрдогч статустай болсон.
Кубернетес нь Docker-тэй адил олон асуудлыг хуваалцдаг. Сайхан, зохицсон хийсвэрлэлийн тухай бүх ярианы хувьд, янз бүрийн ажлуудыг давхарга болгон хуваах тийм ч сайн бүрхэгдээгүй. Үндсэндээ энэ нь янз бүрийн машинуудын кластер дээр контейнер ажиллуулдаг контейнер найруулагч юм. Энэ нь зөвхөн кластерийг ажиллуулж буй инженерүүдэд хамаарах нэлээд доогуур түвшний ажил юм. Нөгөөтэйгүүр, Кубернетес ч мөн адил хамгийн дээд түвшний хийсвэрлэл, хэрэглэгчид YAML-ээр дамжуулан харилцдаг CLI хэрэгсэл.
Докер байсан (одоо ч байгаа) сэрүүн бүх дутагдалтай талуудыг үл харгалзан хөгжүүлэх хэрэгсэл. Бүх "туулай" -ыг нэгэн зэрэг гүйцэх гэж оролдохын тулд түүнийг хөгжүүлэгчид зөв хэрэгжүүлж чадсан хамгийн дээд түвшинд хийсвэрлэл. Хамгийн дээд түвшний хийсвэрлэл гэж би хэлж байна дэд олонлог зорилтот үзэгчдийн (энэ тохиолдолд орон нутгийн хөгжлийн орчинд ихэнх цагаа зарцуулдаг хөгжүүлэгчид) үнэхээр сонирхож байсан функциональ байдал.
Dockerfile болон CLI хэрэгсэл docker нь "хамгийн дээд түвшний хэрэглэгчийн туршлага"-ыг хэрхэн бий болгох жишээ байх ёстой. Энгийн хөгжүүлэгч нарийн ширийн зүйлийн талаар юу ч мэдэхгүй Docker-тэй ажиллаж эхлэх боломжтой үйл ажиллагааны туршлагад хувь нэмэр оруулах хэрэгжилтнэрийн орон зай, бүлгүүд, санах ой болон CPU-ийн хязгаарлалт гэх мэт. Эцсийн эцэст, Dockerfile бичих нь бүрхүүлийн скрипт бичихээс тийм ч их ялгаатай биш юм.
Kubernetes нь янз бүрийн зорилтот бүлгүүдэд зориулагдсан:
- кластерын администраторууд;
- дэд бүтцийн асуудал дээр ажиллаж байгаа програм хангамжийн инженерүүд, Kubernetes-ийн чадавхийг өргөжүүлж, түүн дээр суурилсан платформ бий болгох;
- дамжуулан Kubernetes-тэй харилцаж буй эцсийн хэрэглэгчид
kubectl.
Кубернетесийн "нэг API нь бүгдэд нь тохирно" арга нь түүнийг хэрхэн масштаблах талаар зааварчилгаагүй, хангалтгүй багтаасан "нарийн төвөгтэй уул"-ыг харуулж байна. Энэ бүхэн үндэслэлгүйгээр сунжирсан сургалтын замнал руу хөтөлдөг. Хэрхэн Адам Жейкоб, “Докер хэзээ ч давж байгаагүй хувиргагч хэрэглэгчийн туршлагыг авчирсан. K8 ашигладаг хүн бүрээс анхных шигээ ажиллахыг хүсч байгаа эсэхийг асуу docker run. Хариулт нь тийм байх болно":
Өнөөдөр ихэнх дэд бүтцийн технологи нь хэтэрхий доогуур түвшний (тиймээс "хэт төвөгтэй" гэж тооцогддог) гэж би маргах болно. Kubernetes нь нэлээд доогуур түвшинд хэрэгждэг. Түүний дотор тархсан мөшгих (маш олон тооны зайг хооронд нь холбож, ул мөр үүсгэх) хэтэрхий бага түвшинд хэрэгждэг. "Хамгийн дээд түвшний хийсвэрлэл" -ийг хэрэгжүүлдэг хөгжүүлэгчийн хэрэгслүүд хамгийн амжилттай байх хандлагатай байдаг. Энэхүү дүгнэлт нь олон тооны тохиолдлуудад үнэн зөв байдаг (хэрэв технологи нь хэтэрхий төвөгтэй эсвэл ашиглахад хэцүү бол тухайн технологийн "хамгийн дээд түвшний API/UI" хараахан олдоогүй байна).
Яг одоо үүлний экосистем нь төвлөрөл багатай учраас төөрөгдөлтэй байна. Салбарын хувьд бид "хамгийн дээд, хамгийн дээд хийсвэрлэл" гэсэн зөв түвшин ямар байх талаар шинийг санаачилж, туршилт хийж, сургах ёстой.
Жижиглэн худалдаа
2010-аад онд дижитал жижиглэнгийн худалдааны туршлага үндсэндээ өөрчлөгдөөгүй хэвээр байв. Нэг талаас, онлайн худалдаа хийх хялбар байдал нь уламжлалт жижиглэнгийн дэлгүүрүүдэд хүрэх ёстой байсан бол нөгөө талаас онлайн худалдаа сүүлийн арван жилийн хугацаанд бараг өөрчлөгдөөгүй хэвээр байна.
Ирэх арван жилд энэ салбар хэрхэн хөгжих талаар тодорхой бодолгүй байгаа ч 2030 онд хийдэг шигээ 2020 онд дэлгүүр хэсэх юм бол би маш их сэтгэл дундуур байх болно.
Сэтгүүлзүй
Би дэлхийн сэтгүүлзүйн байдалд улам бүр урам хугарч байна. Бодит, нягт нямбай мэдээлдэг, шударга бус мэдээллийн эх сурвалжийг олоход улам хэцүү болж байна. Мэдээ өөрөө болон түүний талаархи санал бодол хоёрын хоорондох зааг ихэвчлэн бүдгэрдэг. Дүрмээр бол мэдээллийг нэг талыг барьсан байдлаар танилцуулдаг. Энэ нь ялангуяа түүхэндээ мэдээ, үзэл бодлын хооронд ямар ч ялгаа байхгүй байсан зарим оронд үнэн юм. The Guardian сонины редактор асан Алан Русбриджер Их Британийн сүүлчийн сонгуулийн дараа нийтэлсэн нийтлэлдээ: :
Хамгийн гол нь би олон жил Америкийн сонинуудыг үзэж, тэндхийн мэдээний хариуцлагыг дангаараа хариуцаж, тайлбарыг шал өөр хүмүүст даатгаж байсан хамт олондоо өрөвдсөн юм. Гэсэн хэдий ч цаг хугацаа өнгөрөхөд өрөвдөх сэтгэл нь атаархал болж хувирав. Би одоо Британийн бүх үндэсний сонинууд мэдээний хариуцлагыг тайлбар хийх хариуцлагаас салгах ёстой гэж би бодож байна. Харамсалтай нь жирийн уншигч, ялангуяа онлайн уншигчдад ялгааг ойлгоход хэцүү байдаг.
Цахиурын хөндийн ёс зүйн хувьд нэлээд эргэлзээтэй нэр хүндийг харгалзан би сэтгүүл зүйд "хувьсгал хийх" технологид хэзээ ч итгэхгүй. Үүнийг хэлэхэд би (мөн миний олон найз нар) шударга бус, сонирхолгүй, найдвартай мэдээллийн эх сурвалж байвал баяртай байх болно. Ийм платформ ямар байхыг мэдэхгүй ч үнэнийг ялгахад улам хэцүү болж байгаа энэ үед шударга сэтгүүл зүйн хэрэгцээ урьд өмнөхөөсөө илүү их болсон гэдэгт би итгэлтэй байна.
Нийгмийн сүлжээ
Олон нийтийн мэдээллийн хэрэгсэл, олон нийтийн мэдээллийн платформууд нь дэлхийн өнцөг булан бүрт байгаа олон хүмүүсийн мэдээллийн үндсэн эх сурвалж бөгөөд зарим платформ үнэн зөв биш, бүр энгийн баримт шалгахыг хүсэхгүй байгаа нь геноцид, сонгуульд хөндлөнгөөс оролцох гэх мэт гамшигт үр дагаварт хүргэж байна. .
Сошиал медиа бол урьд өмнө байгаагүй хамгийн хүчирхэг мэдээллийн хэрэгсэл юм. Тэд улс төрийн практикийг эрс өөрчилсөн. Тэд сурталчилгаагаа өөрчилсөн. Тэд поп соёлыг өөрчилсөн (жишээлбэл, цуцлах соёлыг хөгжүүлэхэд оруулсан гол хувь нэмэр [ гадуурхах соёлууд - ойролцоогоор. орчуул.] нийгмийн сүлжээнүүд хувь нэмэр оруулдаг). Сошиал медиа нь ёс суртахууны үнэлэмжийг хурдан бөгөөд хачирхалтай өөрчлөх үржил шимтэй газар болох нь батлагдсан ч гадуурхагдсан бүлгийн гишүүдэд урьд өмнө байгаагүй арга замаар зохион байгуулалтад орох боломжийг олгосон гэж шүүмжлэгчид үзэж байна. Нэг ёсондоо сошиал медиа XNUMX-р зуунд хүмүүсийн харилцах, өөрийгөө илэрхийлэх арга хэлбэрийг өөрчилсөн.
Гэсэн хэдий ч олон нийтийн мэдээллийн хэрэгсэл нь хүний хамгийн муу импульсийг бий болгодог гэдэгт би итгэдэг. Олны танил болохын тулд анхаарал халамж, бодол санааг үл тоомсорлодог бөгөөд тодорхой үзэл бодол, байр суурьтай үндэслэлтэй санал нийлэхгүй байгаагаа илэрхийлэх нь бараг боломжгүй юм. Туйлшрал нь ихэвчлэн хяналтаас гарч, олон нийт хувь хүний санаа бодлыг сонсдоггүй байхад үнэмлэхүй үзэлтнүүд онлайн ёс зүй, хүлээн зөвшөөрөгдөх байдлын асуудлыг хянадаг.
Чанартай хэлэлцүүлгийг дэмждэг "илүү сайн" платформ бий болгох боломжтой юу гэж би гайхаж байна уу? Эцсийн эцэст, эдгээр платформуудад гол ашгийг ихэвчлэн авчирдаг "оролцоо"-ыг өдөөдөг зүйл юм. Хэрхэн Нью Йорк Таймс сонинд Кара Свишер:
Үзэн ядалт, үл тэвчих байдлыг өдөөхгүйгээр дижитал харилцааг хөгжүүлэх боломжтой. Ихэнх сошиал медиа сайтууд маш хортой мэт санагддагийн шалтгаан нь тэдгээр нь агуулга, нарийвчлал гэхээсээ илүү хурд, вируст байдал, анхаарал хандуулах зорилгоор бүтээгдсэнтэй холбоотой юм.
Хэдэн арван жилийн дотор олон нийтийн мэдээллийн хэрэгсэлд үлдээсэн цорын ганц өв бол олон нийтийн ярианы өнгө аяс, зохимжтой байдлын элэгдэл байсан бол үнэхээр харамсалтай байх болно.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com