Эскертүү. котормо.: Medium хитине айланган бул макала программалоо тилдеринин дүйнөсүндөгү негизги (2010-2019) өзгөрүүлөргө жана аны менен байланышкан технологиялык экосистемага сереп салуу болуп саналат (Docker жана Kubernetesке өзгөчө көңүл буруу менен). Анын оригиналдуу автору Синди Сридхаран, ал иштеп чыгуучу куралдар жана бөлүштүрүлгөн системалар боюнча адистешкен, атап айтканда, ал "Бөлүштүрүлгөн системалардын байкоосу" китебин жазган жана интернет мейкиндигинде IT адистеринин арасында абдан популярдуу, айрыкча булуттун жергиликтүү темасына кызыккан.
2019-жыл аяктап бараткандыктан, мен акыркы он жылдагы эң маанилүү технологиялык жетишкендиктер жана инновациялар тууралуу өз оюм менен бөлүшкүм келди. Мындан тышкары, мен келечекке бир аз карап, алдыдагы он жылдыктын негизги көйгөйлөрүн жана мүмкүнчүлүктөрүн белгилегенге аракет кылам.
Мен бул макалада маалымат илими сыяктуу тармактардагы өзгөрүүлөрдү камтыбай турганымды ачык айткым келет (маалымат илими), жасалма интеллект, алдыңкы инженерия ж.б., анткени менде аларда жетиштүү тажрыйба жок.
Typification Strikes Back
2010-жылдардын эң позитивдүү тенденцияларынын бири статикалык типтелген тилдердин кайра жаралышы болду. Бирок, мындай тилдер эч качан жок болгон эмес (C++ жана Java бүгүнкү күндө суроо-талапка ээ; алар он жыл мурун үстөмдүк кылышкан), бирок динамикалык түрдө терилген тилдер (динамика) 2005-жылы Ruby on Rails кыймылы пайда болгондон кийин популярдуулуктун олуттуу өсүшүн байкаган. . Бул өсүш 2009-жылы Node.js ачык булагы менен эң жогорку чегине жетти, бул Javascript-on-the-server-ди реалдуулукка айлантты.
Убакыттын өтүшү менен динамикалык тилдер сервердик программалык камсыздоону түзүү жаатында өзүнүн жагымдуулугун жоготту. Контейнердик революция учурунда популярдуу болгон Go тили параллелдүү иштетүү менен жогорку натыйжалуу, ресурсту үнөмдөөчү серверлерди түзүүгө ылайыктуу көрүнгөн. Node.js түзүүчүсү).
Rust, 2010-жылы киргизилген, жылы жетишкендиктерди камтыган коопсуз жана терилген тил болуу аракетинде. Он жылдыктын биринчи жарымында өнөр жайдын Rustту кабыл алуусу кыйла жылуу болгон, бирок экинчи жарымында анын популярдуулугу бир кыйла өстү. Rust үчүн колдонуунун көрүнүктүү учурлары анын колдонулушун камтыйт , (Биз бул жөнүндө сүйлөшкөнбүз — болжол менен. котормо.), алгачкы WebAssembly компилятору Fastly (азыр bytecodealliance бөлүгү) ж.б. Microsoft корпорациясы Windows OSтин кээ бир бөлүктөрүн Rustто кайра жазуу мүмкүнчүлүгүн эске алуу менен, бул тилдин 2020-жылдары жаркын келечеги бар деп ишенимдүү айтууга болот.
Ал тургай, динамикалык тилдер сыяктуу жаңы өзгөчөлүктөргө ээ (милдеттүү эмес түрлөрү). Алар алгач терилген кодду түзүүгө жана аны JavaScriptге компиляциялоого мүмкүндүк берген TypeScript тилинде ишке ашырылган. PHP, Ruby жана Python өздөрүнүн кошумча терүү системалары бар (, ), алар ийгиликтүү колдонулат .
SQLди NoSQLге кайтаруу
NoSQL - он жылдыктын башында акырына караганда алда канча популярдуу болгон дагы бир технология. Мунун эки себеби бар деп ойлойм.
Биринчиден, SQL моделине караганда схемасы, транзакциялары жана ырааттуулугунун кепилдиктери начар болгон NoSQL моделин ишке ашыруу кыйыныраак болуп чыкты. IN "Эмне үчүн мүмкүн болушунча күчтүү ырааттуулукка артыкчылык беришиңиз керек" деген аталыш менен (Эмне үчүн мүмкүн болушунча күчтүү ырааттуулукту тандап алышыңыз керек) Google мындай деп жазат:
Google'да биз үйрөнгөн нерселердин бири - инженерлер татаал транзакцияларды жүргүзүү жана маалыматтарды иретке келтирүү үчүн учурдагы сактагычка таяна алганда, колдонмо коду жөнөкөй жана иштеп чыгуу убактысы кыскараак болот. Спаннердин түпнуска документтеринен цитата келтире турган болсок, "Биз программисттер транзакциялардын жоктугун дайыма эстен чыгарбай, транзакцияларды кыянаттык менен пайдалануудан улам тиркемелерди аткаруу көйгөйлөрүн чечкени жакшы деп эсептейбиз".
Экинчи себеп, "масштабды кеңейтүү" бөлүштүрүлгөн SQL маалымат базаларынын өсүшүнө байланыштуу (мисалы и ) коомдук булут мейкиндигинде, ошондой эле CockroachDB сыяктуу Open Source альтернативалары (Биз ал жөнүндө да айтып жатабыз — болжол менен. котормо.), бул салттуу SQL маалымат базаларынын "масштабына" алып келген көптөгөн техникалык көйгөйлөрдү чечет. Ал тургай MongoDB, бир кездеги NoSQL кыймылынын үлгүсү болгон, азыр бөлүштүрүлгөн транзакциялар.
Атомдук окууну жана бир нече документтер боюнча жазууну талап кылган жагдайлар үчүн (бир же бир нече коллекциялар боюнча), MongoDB көп документ транзакцияларын колдойт. Бөлүштүрүлгөн транзакцияларда транзакциялар бир нече операцияларда, коллекцияларда, маалымат базаларында, документтерде жана сыныктарда колдонулушу мүмкүн.
Жалпы агым
Апачи Кафка акыркы он жылдагы эң маанилүү ойлоп табуулардын бири экендиги талашсыз. Анын баштапкы коду 2011-жылдын январында ачылган жана бул жылдар аралыгында Кафка бизнестин маалыматтар менен иштөө ыкмасын өзгөрттү. Кафканы мен иштеген бардык компанияларда, стартаптардан баштап ири корпорацияларга чейин колдонушкан. Ал камсыз кылган кепилдиктер жана колдонуу учурлары (паб-суб, агымдар, окуяга негизделген архитектуралар) маалыматты сактоодон баштап мониторинг жана агымдык аналитикага чейин ар кандай тапшырмаларда колдонулат, мисалы, каржы, саламаттыкты сактоо, мамлекеттик сектор, чекене жана башкалар.
Үзгүлтүксүз интеграция (жана азыраак деңгээлде Үзгүлтүксүз жайылтуу)
Үзгүлтүксүз интеграция акыркы 10 жылда эмес, акыркы он жылда пайда болгон ушунчалык даражага чейин тарады, стандарттык иш процессинин бир бөлүгү болуп калды (бардык тартуу сурамдары боюнча тесттерди жүргүзүү). GitHub кодду иштеп чыгуу жана сактоо үчүн платформа катары түзүү жана андан да маанилүүсү, иштөө процессин иштеп чыгуу мастерге тартуу өтүнүчүн кабыл алуудан мурун тесттерди жүргүзүү дегенди билдирет гана акыркы он жылда эмгек жолун баштаган инженерлерге тааныш иштеп чыгуудагы иш процесси.
Үзгүлтүксүз жайылтуу (ар бир тапшырманы кожоюнга тийгенде жана качан жайылтуу) үзгүлтүксүз интеграция сыяктуу кеңири таралган эмес. Бирок, жайылтуу үчүн ар кандай булут API'леринин көптүгү менен, Kubernetes сыяктуу платформалардын популярдуулугу (орнотуулар үчүн стандартташтырылган API камсыз кылат) жана Spinnaker (стандартташтырылгандардын үстүнө курулган) сыяктуу көп платформалуу, көп булуттуу куралдардын пайда болушу. API), жайылтуу процесстери автоматташтырылган, жөнөкөйлөштүрүлгөн жана жалпысынан коопсузураак болуп калды.
Контейнерлер
Контейнерлер, балким, 2010-жылдардын эң кызганган, талкууланган, жарнамаланган жана туура эмес түшүнүлгөн технологиясы. Экинчи жагынан, бул өткөн он жылдыктын эң маанилүү инновацияларынын бири. Бул какофониянын себептеринин бир бөлүгү биз дээрлик бардык жерден алган аралаш сигналдарда жатат. Азыр бир аз басаңдагандан кийин, кээ бир нерселер курчуду.
Контейнерлер дүйнөлүк иштеп чыгуучулардын коомчулугунун керектөөлөрүн канааттандырган тиркемени иштетүүнүн эң мыкты жолу болгондуктан эмес, популярдуу болуп калды. Контейнерлер популярдуу болуп калды, анткени алар такыр башка маселени чечүүчү белгилүү бир инструментке маркетинг суроо-талабына ийгиликтүү туура келет. Докер болуп чыкты фантастикалык актуалдуу шайкештик маселесин чечүүчү иштеп чыгуу куралы ("менин машинамда иштейт").
Тагыраак айтканда, революция жасалган Докер сүрөтү, анткени ал чөйрөлөр ортосундагы паритет маселесин чечип, колдонмо файлынын гана эмес, ошондой эле анын бардык программалык камсыздоо жана операциялык көз карандылыктарынын чыныгы көчмөлүгүн камсыз кылды. Бул курал кандайдыр бир жол менен "контейнерлердин" популярдуулугуна түрткү бергени, бул өтө төмөн деңгээлдеги ишке ашыруу деталдары, мен үчүн акыркы он жылдыктын негизги сыры бойдон калууда.
Серверсиз
Мен "серверсиз" эсептөөлөрдүн пайда болушу контейнерлерге караганда маанилүүрөөк экенине ишенем, анткени ал чындап эле талап боюнча эсептөө кыялын ишке ашырат. (суроо-талап боюнча). Акыркы беш жылдын ичинде мен серверсиз ыкма акырындык менен жаңы тилдерге жана иштөө убакыттарына колдоо кошуу менен масштабы кеңейип жатканын көрдүм. Azure Durable Functions сыяктуу өнүмдөрдүн пайда болушу мамлекеттик функцияларды ишке ашырууга карата туура кадам болуп көрүнөт (ошол эле учурда чечүүчү FaaS чектөөлөрүнө байланыштуу). Мен бул жаңы парадигма жакынкы жылдарда кандай өнүгүп жатканын кызыгуу менен байкайм.
автоматизация
Балким, бул тенденциянын эң чоң бенефициары операциялык инженердик коомчулук болуп саналат, анткени ал инфраструктура сыяктуу концепцияларды код катары (IaC) ишке ашырууга мүмкүндүк берген. Кошумчалай кетсек, автоматташтырууга болгон ынтызарлык операцияларга программалык камсыздоого багытталган мамилени көздөгөн “SRE маданиятынын” өсүшү менен дал келди.
Универсалдуу API-фикациясы
Акыркы он жылдыктын дагы бир кызыктуу өзгөчөлүгү ар кандай иштеп чыгуу тапшырмаларынын API-фикациясы болду. Жакшы, ийкемдүү API'лер иштеп чыгуучуга инновациялык иш процесстерин жана куралдарын түзүүгө мүмкүндүк берет, бул өз кезегинде тейлөөгө жана колдонуучу тажрыйбасын жакшыртууга жардам берет.
Кошумчалай кетсек, API-fication - бул кандайдыр бир функциянын же куралдын SaaS-фикациясына карай биринчи кадам. Бул тенденция микросервистердин популярдуулугунун өсүшү менен дал келди: SaaS API аркылуу кирүүгө мүмкүн болгон дагы бир кызмат болуп калды. Азыр көптөгөн SaaS жана FOSS куралдары бар, мисалы, мониторинг, төлөмдөр, жүк балансы, үзгүлтүксүз интеграция, эскертүүлөр, функцияларды алмаштыруу (функцияны белгилөө), CDN, трафик инженериясы (мисалы, DNS) ж.б.
Байкоочулук
Айта кетсек, бүгүнкү күндө бизде мүмкүнчүлүк бар алда канча өнүккөн мурда болуп көрбөгөндөй колдонмо жүрүм-турумун көзөмөлдөө жана диагностикалоо үчүн куралдар. 2015-жылы Open Source статусун алган Prometheus мониторинг системасы, балким, деп атоого болот мыкты Мен иштеген адамдардан мониторинг системасы. Бул кемчиликсиз эмес, бирок көп нерселер туура жол менен ишке ашырылган (мисалы, өлчөөлөрдү колдоо [өлчөмдүүлүк] метрикалык учурда).
Бөлүштүрүлгөн көзөмөлдөө OpenTracing (жана анын мураскери OpenTelemetry) сыяктуу демилгелердин аркасында 2010-жылдары негизги агымга кирген дагы бир технология болгон. Издөө дагы деле кыйын болсо да, акыркы окуялардын айрымдары 2020-жылдары анын чыныгы потенциалын ачабыз деп үмүттөнөт. (Эскертүү: макаланын котормосун биздин блогдон да окуңуз ""ошол эле автор тарабынан.)
Келечекке карап
Тилекке каршы, жакынкы он жылдыкта чечилишин күтүп жаткан көптөгөн көйгөйлөр бар. Бул жерде менин алар жөнүндө ойлорум жана алардан кантип кутулуу боюнча кээ бир потенциалдуу идеяларым бар.
Мур мыйзамы маселесин чечүү
Деннардын масштабдуу мыйзамынын аягы жана Мурдун мыйзамынан артта калуу жаңы инновацияларды талап кылат. Джон Хеннесси кирди көйгөйгө көз каранды эмне үчүн түшүндүрөт (доменге тиешелүү) TPU сыяктуу архитектуралар Мур мыйзамынан артта калуу маселесин чечүүнүн бири болушу мүмкүн. сыяктуу куралдар Google бул багытта жакшы кадам болуп калды окшойт:
Компиляторлор жаңы тиркемелерди колдоого алышы керек, жаңы аппараттык жабдыктарга оңой көчүрүлүшү керек, динамикалык, башкарылуучу тилдерден вектордук тездеткичтерге жана программалык камсыздоо менен башкарылуучу сактагыч түзүлүштөргө чейин абстракциянын бир нече катмарын байланыштырышы керек. функционалдуулукта -убакыт, диагностика жана системалардын иштеши жана иштеши жөнүндө мүчүлүштүктөрдү оңдоо маалыматын стек боюнча бөлүштүрүү, ошол эле учурда көпчүлүк учурларда кол менен жазылган ассемблерге жакын болгон аткарууну камсыз кылуу. Биз мындай компиляция инфраструктурасын өнүктүрүү жана коомчулукка жеткиликтүү кылуу боюнча көз карашыбыз, прогресс жана пландарыбыз менен бөлүшүүгө ниеттенип жатабыз.
CI / CD
CIнин өсүшү 2010-жылдардагы эң чоң тенденциялардын бири болуп калса да, Дженкинс дагы эле CI үчүн алтын стандарт болуп саналат.
Бул мейкиндик төмөнкү багыттар боюнча инновацияларга абдан муктаж:
- колдонуучу интерфейси (тест спецификацияларын коддоо үчүн DSL);
- аны чындап масштабдуу жана тез кыла турган ишке ашыруу деталдары;
- тестирлөөнүн өркүндөтүлгөн формаларын ишке ашыруу үчүн ар кандай чөйрөлөр менен интеграциялоо (сценировка, өндүрүш ж.б.);
- үзгүлтүксүз сыноо жана жайылтуу.
Иштеп чыгуучу куралдары
Тармак катары биз барган сайын татаал жана таасирдүү программалык камсыздоону түзө баштадык. Бирок, өзүбүздүн куралдарыбызга келгенде, абал бир топ жакшыраак болушу мүмкүн.
Биргелешип жана алыстан (ssh аркылуу) редакциялоо белгилүү бир популярдуулукка ээ болду, бирок эч качан өнүгүүнүн жаңы стандарттуу жолу болгон эмес. Эгер сиз мага окшоп идеяны четке кагсаңыз муктаждык жөн гана программалоо жүргүзүү үчүн Интернетке туруктуу туташуу, андан кийин алыскы машинада ssh аркылуу иштөө сизге ылайыктуу эмес.
Жергиликтүү өнүгүү чөйрөлөрү, айрыкча чоң кызмат көрсөтүүгө багытталган архитектурада иштеген инженерлер үчүн дагы эле кыйынчылык жаратууда. Кээ бир долбоорлор муну чечүүгө аракет кылып жатышат, жана мен эң эргономикалык UX берилген колдонуу учуру үчүн кандай болорун билгим келет.
Ошондой эле "көчмө чөйрөлөр" түшүнүгүн өнүктүрүүнүн башка тармактарына, мисалы, мүчүлүштүктөрдү көбөйтүү (же) кызыктуу болмок. ) белгилүү шарттарда же орнотууларда пайда болгон.
Мен ошондой эле семантикалык жана контекстти сезгич код издөө, өндүрүш инциденттерин код базасынын белгилүү бөлүктөрү менен салыштыруу куралдары сыяктуу тармактарда көбүрөөк инновацияларды көргүм келет.
Эсептөө (PaaS келечеги)
2010-жылдардагы контейнерлердин жана серверсиздердин айланасындагы ызы-чуулардан кийин, акыркы бир нече жылда коомдук булут мейкиндигинде чечимдердин спектри кыйла кеңейди.
Бул бир нече кызыктуу суроолорду жаратат. Биринчиден, коомдук булуттагы жеткиликтүү варианттардын тизмеси тынымсыз өсүп жатат. Булут кызмат көрсөтүүчүлөрүндө Ачык Булак дүйнөсүндөгү акыркы окуялардан оңой кабардар болуу жана "серверсиз подколор" сыяктуу өнүмдөрдү чыгаруу (жөн гана өздөрүнүн FaaS иштөө убакыттарын OCI менен шайкеш келтирүү аркылуу деп ойлойм) же башка ушул сыяктуу кооз нерселерди чыгаруу үчүн кызматкерлер жана ресурстар бар.
Бул булут чечимдерин колдонгондорго гана ичи тар болот. Теорияда, Kubernetes булут сунуштары (GKE, EKS, Fargate боюнча EKS ж.б.) жумуш жүктөмдөрүн иштетүү үчүн булут провайдеринен көз карандысыз API'лерди камсыз кылат. Эгер сиз окшош өнүмдөрдү (ECS, Fargate, Google Cloud Run ж.б.) колдонсоңуз, анда сиз кызмат көрсөтүүчү сунуштаган эң кызыктуу функциялардын көбүн пайдаланып жаткандырсыз. Кошумчалай кетсек, жаңы өнүмдөр же компьютердик парадигмалар пайда болгондон кийин, миграция жөнөкөй жана стресссиз болот.
Мындай чечимдердин диапазону канчалык тез өнүгүп жатканын эске алуу менен (жакынкы келечекте бир нече жаңы варианттар пайда болбосо, мен абдан таң калам), кичинекей "платформа" командалары (инфраструктура менен байланышкан жана жергиликтүү платформаларды түзүүгө жооптуу командалар). иштеп жаткан жүк ташуучу компаниялар) функционалдык, колдонуунун жөнөкөйлүгү жана жалпы ишенимдүүлүк жагынан атаандашуу абдан кыйын болот. 2010-жылдары Kubernetes PaaS (платформа катары кызмат көрсөтүү) куруунун куралы катары көрүлгөн, ошондуктан мен үчүн Kubernetesтин үстүнө ички платформаны куруу таптакыр бекер окшойт, ал жалпыга жеткиликтүү бирдей тандоону, жөнөкөйлүктү жана эркиндикти сунуш кылат. булут мейкиндиги. Контейнерге негизделген PaaSти “Кубернетес стратегиясы” катары рамкалоо булуттун эң инновациялык мүмкүнчүлүктөрүнөн атайылап качууга барабар.
Эгер жеткиликтүү карап көрсөк бүгүн Эсептөө мүмкүнчүлүктөрүн эске алганда, Кубернетеске гана негизделген өзүңүздүн PaaSиңизди түзүү өзүңүздү бурчка сүрөттөө менен барабар экени айкын болуп калат (өтө келечекти ойлогон мамиле эмес, ыя?). Бүгүн кимдир бирөө Кубернетеске контейнердик PaaS курууну чечсе да, бир нече жылдан кийин булуттун мүмкүнчүлүктөрүнө салыштырмалуу эскирип калат. Kubernetes ачык булактуу долбоор катары башталганына карабастан, анын түпкү атасы жана илхамы ички Google куралы болуп саналат. Бирок, ал адегенде 2000-жылдардын башында / орто ченинде, эсептөө пейзажы такыр башкача болгондо иштелип чыккан.
Ошондой эле, кеңири мааниде, компаниялар Kubernetes кластерин иштетүү боюнча эксперт болбошу керек, ошондой эле алар өздөрүнүн маалымат борборлорун куруп жана тейлешпейт. Ишенимдүү эсептөө пайдубалын камсыз кылуу негизги маселе болуп саналат булут кызмат көрсөтүүчүлөрү.
Акыр-аягы, мен тармак катары бир аз артка кеттик деп ойлойм өз ара аракеттенүү тажрыйбасы (). Heroku 2007-жылы ишке киргизилген жана дагы эле алардын бири болуп саналат колдонууга жеңил платформалар. Kubernetes алда канча күчтүү, кеңейтилүүчү жана программалануучу экенин танууга болбойт, бирок мен Херокуга баштоо жана жайылтуу канчалык оңой экенин сагындым. Бул платформаны колдонуу үчүн сиз Gitти билишиңиз керек.
Мунун баары мени төмөнкү жыйынтыкка алып келет: иштөө үчүн бизге жакшыраак, жогорку деңгээлдеги абстракциялар керек (бул өзгөчө эң жогорку деңгээлдеги абстракциялар).
Эң жогорку деңгээлдеги туура API
Докер ошол эле учурда тынчсызданууларды жакшыраак бөлүү зарылдыгынын сонун мисалы эң жогорку деңгээлдеги APIди туура ишке ашыруу.
Докердин көйгөйү, (жок дегенде) алгач долбоордун өтө кеңири максаттары болгон: бардыгы шайкештик маселесин чечүү үчүн («менин машинамда иштейт») контейнер технологиясын колдонуу менен. Docker бул сүрөт форматы, өзүнүн виртуалдык тармагы менен иштөө убактысы, CLI куралы, тамыр катары иштеген демон жана башкалар. Кандай болгон күндө да, билдирүүлөр алмашуу болду дагы "жеңил VM'лерди", топторду, аттар мейкиндиктерин, көптөгөн коопсуздук маселелерин жана "каалаган жерде каалаган тиркемени куруу, жеткирүү, иштетүү" маркетинг чакырыгы менен аралашкан чаташкан.
Бардык жакшы абстракциялар сыяктуу эле, ар кандай көйгөйлөрдү бири-бири менен айкалыштыра турган логикалык катмарларга бөлүү үчүн убакыт (жана тажрыйба жана оору) талап кылынат. Тилекке каршы, Докер ушундай жетилгендикке жете электе, Кубернетес күрөшкө кирди. Ал хайп циклин ушунчалык монополиялаштыргандыктан, азыр бардыгы Kubernetes экосистемасындагы өзгөрүүлөргө туруштук берүүгө аракет кылып жатышты жана контейнер экосистемасы экинчи даражадагы статуска ээ болду.
Kubernetes 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 гезитинин мурдагы редактору Алан Русбриджер, :
Негизгиси, көп жылдар бою америкалык гезиттерди карап, ал жактагы кесиптештериме боорум ооруду, алар жаңылыктар үчүн жалгыз жоопкер болуп, комментарийди таптакыр башка адамдарга тапшырып коюшту. Бирок, убакыттын өтүшү менен боорукердик көрө албастыкка айланды. Мен азыр бардык британиялык улуттук гезиттер жаңылыктар үчүн өз жоопкерчилигин комментарийлөө жоопкерчилигинен ажыратышы керек деп ойлойм. Тилекке каршы, жөнөкөй окурман үчүн, өзгөчө онлайн окурмандар үчүн айырманы түшүнүү өтө кыйын.
Силикон өрөөнүнүн этикага келгенде өтө эле күмөндүү репутациясын эске алганда, мен эч качан технология журналистиканы “революциялашат” деп ишенбейм. Айтор, мен (жана менин көптөгөн досторум) калыс, кызыкдар эмес жана ишенимдүү маалымат булагы болсо кубанмакмын. Мындай аянтча кандай болорун билбейм, бирок чындыкты аныктоо барган сайын кыйындап бараткан заманда чынчыл журналистикага болгон муктаждык болуп көрбөгөндөй күчөгөнүнө ишенем.
Социалдык тармак
Социалдык медиа жана коомчулуктун жаңылык платформалары дүйнө жүзү боюнча көптөгөн адамдар үчүн маалыматтын негизги булагы болуп саналат жана кээ бир платформалардын тактыгынын жоктугу жана ал тургай негизги фактыларды текшерүүнү каалабагандыгы геноцид, шайлоого кийлигишүү жана башкалар сыяктуу каргашалуу кесепеттерге алып келди. .
Социалдык медиа да буга чейин болгон эң күчтүү медиа куралы болуп саналат. Алар саясий практиканы туп-тамырынан бери езгертушту. Алар жарнаманы өзгөртүштү. Алар поп-маданиятты өзгөртүштү (мисалы, жокко чыгаруу маданиятынын өнүгүшүнө негизги салым [остракизм маданияттары - болжол менен. котормо] коомдук тармактар салым кошот). Сынчылар социалдык медиа адеп-ахлактык баалуулуктарды тез жана каприздуу өзгөртүүгө ыңгайлуу шарт экенин далилдеп, бирок ал маргиналдуу топтордун мүчөлөрүнө мурда болуп көрбөгөндөй уюштуруу мүмкүнчүлүгүн бергенин айтышат. Негизи, социалдык медиа 21-кылымда адамдардын баарлашуу жана оюн билдирүү ыкмасын өзгөрттү.
Бирок, мен дагы социалдык медиа адамдын эң жаман импульстарын чыгарат деп ишенем. Популярдуулуктун пайдасына көп учурда ойлонуу жана ойлонуу этибарга алынбай калат жана айрым пикирлер жана позициялар менен жүйөлүү пикир келишпестиктерди билдирүү дээрлик мүмкүн эмес болуп калат. Поляризация көбүнчө көзөмөлдөн чыгып кетет, натыйжада коомчулук жеке пикирлерди укпай калат, ал эми абсолютисттер онлайн этикеттин жана алгылыктуулугун көзөмөлдөйт.
Кызык, сапаттуу талкууларды өткөрө турган “жакшы” аянтчаны түзүүгө болобу? Анткени, дал ушул платформаларга көбүнчө негизги киреше алып келген "кыйышууга" түрткү болгон нерсе. Кантип Кара Свишер New York Times гезитинде:
Санариптик өз ара аракеттенүүнү жек көрүүнү жана сабырсыздыкты жаратпастан өнүктүрүүгө болот. Көпчүлүк социалдык медиа сайттарынын ушунчалык уулуу көрүнгөнүнүн себеби, алар мазмун жана тактык үчүн эмес, ылдамдык, вирустуулук жана көңүл буруу үчүн курулган.
Эгерде бир нече ондогон жылдардан кийин социалдык медианын жалгыз мурасы коомдук талкууда нюанстын жана ылайыктуулугунун эрозиясы болуп калса, чындап эле өкүнүчтүү болмок.
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com