Хараал ид Google, би дахиж блог бичихийг хүсээгүй. Надад хийх зүйл маш их байна. Блог бичих нь цаг хугацаа, эрч хүч, бүтээлч сэтгэлгээ шаарддаг бөгөөд үүнийг би сайн ашиглаж болох юм: миний номууд, , миний тоглоом гэх мэт. Гэхдээ та намайг хангалттай уурлууллаа, би үүнийг бичихээс өөр аргагүй боллоо.
Ингээд энэ бүхнийг дуусгая.
Би Google-д анх ажиллаж эхэлсэн үеийн товчхон боловч сургамжтай түүхээс эхэлье. Би сүүлийн үед Google-ийн талаар маш их муу зүйл ярьж байгаагаа мэдэж байна, гэхдээ миний компани бизнесийн чадваргүй шийдвэрүүдийг байнга гаргадаг нь намайг бухимдуулдаг. Үүний зэрэгцээ бид зохих ёсоороо өгөх ёстой: Google-ийн дотоод дэд бүтэц үнэхээр гайхалтай, өнөөдөр үүнээс илүү зүйл байхгүй гэж хэлж болно. Google-ийн үүсгэн байгуулагчид надаас хамаагүй илүү сайн инженерүүд байсан бөгөөд энэ түүх зөвхөн үүнийг баталж байна.
Нэгдүгээрт, бага зэрэг мэдээлэл: Google-д өгөгдөл хадгалах технологи байдаг . Энэ бол техникийн гайхалтай ололт байсан бөгөөд анхны (хэрэв анхны биш бол) "хязгааргүй өргөтгөх боломжтой" түлхүүр үнэ цэнийн хадгалалтын нэг (K/V): үндсэндээ NoSQL-ийн эхлэл байв. Эдгээр өдрүүдэд Bigtable нь нэлээн хөл хөдөлгөөн ихтэй K/V хадгалах санд сайн ажиллаж байгаа ч тухайн үед (2005) үнэхээр гайхалтай байсан.
Bigtable-ийн нэг инээдтэй зүйл бол тэд таблет сервер гэж нэрлэгддэг дотоод хяналтын хавтгай объектуудтай (хэрэгжилтийн нэг хэсэг болгон) том индексүүдтэй байсан бөгөөд хэзээ нэгэн цагт системийг өргөтгөхөд саад болж байсан. Bigtable-ийн инженерүүд өргөтгөх чадварыг хэрхэн хэрэгжүүлэх талаар толгойгоо гашилгаж байсан бөгөөд гэнэт таблет серверүүдийг өөр Bigtable санах ойгоор сольж болохыг ойлгосон. Тиймээс Bigtable бол Bigtable хэрэгжилтийн нэг хэсэг юм. Эдгээр агуулахууд бүх түвшинд байдаг.
Өөр нэг сонирхолтой зүйл бол хэсэг хугацаанд Bigtable нь Google-д түгээмэл болж, хаа сайгүй тархаж, баг бүр өөрийн гэсэн репозитортой болсон. Баасан гарагийн нэгэн уулзалтын үеэр Ларри Пэйж санамсаргүй байдлаар асуув: "Яагаад бидэнд нэгээс олон Bigtable байдаг вэ? Яагаад ганцхан биш гэж?" Онолын хувьд нэг хадгалах сан нь Google-ийн бүх хадгалах сангийн хэрэгцээнд хангалттай байх ёстой. Мэдээжийн хэрэг, тэд хэзээ ч практик хөгжлийн шалтгаанаар (болзошгүй бүтэлгүйтлийн үр дагавар гэх мэт) зөвхөн нэг рүү очоогүй ч онол нь сонирхолтой байсан. Бүх ертөнцийн нэг агуулах (Дашрамд хэлэхэд, Амазон үүнийг Sable-тай хийсэн эсэхийг мэдэх хүн байна уу?)
Ямар ч байсан миний түүх энд байна.
Тухайн үед би Google-д хоёр жил гаруй ажиллаж байсан бөгөөд нэг өдөр би Bigtable-ийн инженерийн багаас дараах имэйлийг хүлээн авсан.
Эрхэм Стив,
Bigtable-ийн хамт олноос мэндчилж байна. Та [өгөгдлийн төвийн нэр] дээр маш хуучин Bigtable хоёртын файлыг ашиглаж байгааг бид танд мэдэгдье. Энэ хувилбарыг дэмжихээ больсон бөгөөд бид танд хамгийн сүүлийн хувилбар руу шинэчлэхэд туслахыг хүсэж байна.
Та энэ асуудлаар хамтран ажиллах цагаа товлох боломжтой бол надад мэдэгдээрэй.
Хамгийн сайн сайхныг хүсье
Том ширээний баг
Google дээр та маш их захидал хүлээн авдаг тул эхлээд харахад би иймэрхүү зүйлийг уншсан:
Эрхэм хүлээн авагч,
Зарим багаас мэндчилж байна. Бид тэр бла бла бла бла бла харилцахыг хүсэж байна. бла бла бла бла бла бла, тэгээд бла бла бла.
Хэрэв та өөрийн үнэт цагаа бла бла бла гэж төлөвлөх боломжтой бол бидэнд мэдэгдээрэй.
Хамгийн сайн сайхныг хүсье
Ямар нэгэн тушаал
Би тэр дороо бараг л устгасан ч ухамсрынхоо ирмэг дээр ийм зовиуртай, уйтгартай мэдрэмжийг мэдэрсэн. тийм биш албан ёсны захидал шиг харагдаж байна мэдээжийн хэрэг, би Bigtable ашиглаагүй учраас хүлээн авагч андуурсан.
Гэхдээ хачирхалтай байсан.
Би өдрийн цагаар ээлжлэн ажил хийх, ямар төрлийн акулын махыг бичил гал тогоонд хийж үзэх талаар бодож өнгөрөөсөн бөгөөд үүний гурваас доошгүй нь жигнэмэгийг сайн онож шидэхэд миний суудлаас цохиход хангалттай байв. бичих тухай бодол надад өсөн нэмэгдэж буй бага зэргийн түгшүүртэй мэдрэмжийг хэзээ ч үлдээгээгүй.
Тэд миний нэрийг тодорхой хэлсэн. Мөн энэ имэйлийг хэн нэгнийх биш миний имэйл хаяг руу илгээсэн бөгөөд энэ нь cc: эсвэл bcc: биш юм. Өнгө аяс нь маш хувийн бөгөөд тодорхой юм. Магадгүй энэ нь ямар нэгэн алдаа юм болов уу?
Эцэст нь сониуч зан намайг давж, би тэдний дурдсан дата төв дэх Борг консолыг үзэхээр явлаа.
Мэдээжийн хэрэг, миний удирдлага дор BigTable хадгалах сан байсан. Уучлаарай, юу вэ? Би түүний агуулгыг харлаа, хөөе! Энэ нь 2005 оны XNUMX-р сард Google-д ажилласан эхний долоо хоногт миний сууж байсан Codelab инкубаторынх байсан. Codelab танд зарим утгыг бичихийн тулд Bigtable програмыг ажиллуулахыг албадсан бөгөөд үүний дараа би хадгалах санг хэзээ ч хаагаагүй бололтой. Хоёр жил гаруйн хугацаа өнгөрсөн ч ажилласаар л байсан.
Энэ түүхэнд анхаарал татахуйц хэд хэдэн зүйл бий. Нэгдүгээрт, Bigtable-ийн ажил Google-ийн хэмжээнд тийм ч ач холбогдолгүй байсан тул ердөө хоёр жилийн дараа хэн ч нэмэлт хадгалах санг анзаарсан бөгөөд зөвхөн хоёртын хувилбар нь хуучирсан байсан. Харьцуулахын тулд би нэг удаа ашиглах талаар бодож байсан миний онлайн тоглоомын хувьд. Тухайн үед энэ үйлчилгээ жилд ойролцоогоор 16 долларын үнэтэй байв. хоосон GCP дээрх Bigtable. Би чамайг хуурч байна гэж хэлэхгүй, гэхдээ миний хувийн бодлоор энэ бол хоосон мэдээллийн санд маш их мөнгө юм.
Өөр нэг анхаарал татахуйц зүйл бол хадгалалт юм хоёр жилийн дараа ч ажиллаж байна. WTF? Мэдээллийн төвүүд орж ирдэг; Тэд тасалддаг, хуваарьт засвар үйлчилгээ хийдэг, байнга өөрчлөгддөг. Техник хангамж шинэчлэгдэж, унтраалга солигдож, бүх зүйл байнга сайжирч байна. Энэ бүх өөрчлөлтийн хажуугаар тэд яаж миний хөтөлбөрийг хоёр жилийн турш ажиллуулж чадав аа? Энэ нь 2020 онд даруухан амжилт мэт санагдаж болох ч 2005-2007 онд үнэхээр гайхалтай байсан.
Хамгийн гайхалтай нь өөр мужид байдаг гадны инженерийн баг Bigtable-ийн өчүүхэн, хоосон шахуу жишээний эзэн над руу ойртож байгаа явдал юм. замын хөдөлгөөн тэг Сүүлийн хоёр жилийн турш - мөн үүнийг шинэчлэхэд тусламж санал болгож байна.
Би тэдэнд талархаж, хадгалах санг устгаж, амьдрал ердийнхөөрөө үргэлжилсэн. Гэвч арван гурван жил өнгөрсөн ч би тэр захидлыг одоо хүртэл боддог. Учир нь заримдаа би Google Cloud-аас ижил төстэй имэйл хүлээн авдаг. Тэд дараах байдлаар харагдаж байна.
Эрхэм Google Cloud хэрэглэгч,
Сануулахад, бид 2020 оны XNUMX-р сараас эхлэн [таны ашигладаг үндсэн үйлчилгээ] үйлчилгээг зогсоох бөгөөд үүний дараа та инстанцуудаа шинэчлэх боломжгүй болно. Бид бета туршилтанд орсон, баримт бичиггүй, шилжих замгүй, бидний эелдэг тусламжаар урьд өмнө нь хуучирсан хувилбарыг шинэчлэхийг зөвлөж байна.
Энэхүү өөрчлөлт нь Google Cloud платформын бүх хэрэглэгчдэд хамгийн бага нөлөө үзүүлэхийг бид зорьж байна.
Үүрдийн сайн найзууд,
Google Cloud платформ
Гэхдээ би ийм захидлуудыг бараг хэзээ ч уншдаггүй, учир нь тэдний бичсэн зүйл бол:
Эрхэм хүлээн авагч,
Там руугаа тонил. Новш, новш, новш. Хийж байгаа бүхнээ орхи, учир нь энэ нь хамаагүй. Бидний цаг хугацаа чухал. Бид дэмий хоосон зүйлээ хадгалахын тулд цаг хугацаа, мөнгөө үрдэг бөгөөд үүнээс залхсан тул цаашид дэмжихгүй. Тиймээс новшийн төлөвлөгөөнөөсөө татгалзаж, манай новшийн баримт бичгийг ухаж, форум дээр хаягдал гуйж эхлээрэй, дашрамд хэлэхэд, бидний шинэ новш хуучин новшоос тэс өөр юм, учир нь бид энэ дизайныг маш муу хийсэн, хэхэ, гэхдээ энэ бол чинийх. асуудал, бидний биш.
Бид таны бүх бүтээн байгуулалтыг нэг жилийн дотор ашиглах боломжгүй болгохын тулд хүчин чармайлт гаргасаар байна.
Новш чинь зайлуул
Google Cloud платформ
Үнэндээ би сард нэг удаа ийм захидал авдаг. Энэ нь маш олон удаа, байнга тохиолддог тул зайлшгүй тохиолддог холдуулсан намайг GCP-ээс үүлний эсрэг хуаран руу. Би тэдний өмчийн бүтээн байгуулалтаас хамааралтай байхыг зөвшөөрөхөө больсон, учир нь үнэндээ хөгжүүлэгчид Google-ийн "хуучирсан" бүтээгдэхүүнийг хаах бодлогыг дагаж мөрдөхөөс илүүтэйгээр нүцгэн виртуал машин дээр нээлттэй эхийн системийг хадгалах нь илүү хялбар байдаг.
Би Google Cloud руу буцахаасаа өмнө учир нь би ойрхон ч биш Тэднийг шүүмжилж дуусаагүй байгаа тул бусад чиглэлээр компанийн гүйцэтгэлийг харцгаая. Google-ийн инженерүүд програм хангамжийн инженерчлэлийн чиглэлээрээ бахархдаг бөгөөд энэ нь үнэндээ асуудал үүсгэдэг. Бардамнал бол болгоомжгүй хүмүүсийн урхи бөгөөд энэ нь Google-ийн олон ажилчдыг шийдвэрүүд нь үргэлж зөв байдаг бөгөөд зөв байх нь (зарим тодорхойгүй бүдүүлэг тодорхойлолтоор) үйлчлүүлэгчдэд санаа тавихаас илүү чухал гэж бодоход хүргэсэн.
Би Google-ээс бусад томоохон төслүүдээс санамсаргүй жишээ өгөх болно, гэхдээ та энэ загварыг хаа сайгүй харна гэж найдаж байна. Энэ нь дараах байдалтай байна. Хоцрогдсон нийцтэй байдал нь системийг хэдэн арван жилийн турш амьд, шинэчлэгддэг.
Хоцрогдсон нийцтэй байдал нь зориулагдсан бүх амжилттай системүүдийн дизайны зорилго юм нээлттэй ашиглах, өөрөөр хэлбэл, нээлттэй эх код болон/эсвэл нээлттэй стандартаар хэрэгждэг. Хэтэрхий илэрхий зүйл хэлж байгаа юм шиг санагдаж байна, хүн бүр бүр эвгүй байдаг, гэхдээ үгүй. Энэ бол улс төрийн асуудал учраас жишээ татах хэрэгтэй.
Миний сонгох хамгийн эхний систем бол хамгийн эртний нь: GNU Emacs бөгөөд энэ нь Windows Notepad, үйлдлийн системийн цөм болон Олон улсын сансрын станцын хоорондох эрлийз юм. Үүнийг тайлбарлахад бага зэрэг хэцүү ч товчхондоо Emacs бол 1976 онд (тиймээ бараг хагас зуун жилийн өмнө) таныг илүү бүтээмжтэй болгохын тулд программчлах зорилгоор бүтээгдсэн, гэхдээ текст засварлагчийн дүрд хувирсан платформ юм.
Би өдөр бүр Emacs ашигладаг. Тийм ээ, би IntelliJ-ийг өдөр бүр ашигладаг, энэ нь өөрөө хүчирхэг багаж хэрэгслийн платформ болж өссөн. Гэхдээ IntelliJ-д зориулж өргөтгөл бичих нь Emacs-д өргөтгөл бичихээс хамаагүй илүү амбицтай, төвөгтэй ажил юм. Хамгийн гол нь Emacs-д зориулж бичсэн бүх зүйл хадгалагдан үлджээ үүрд.
Би одоо хүртэл 1995 онд Emacs-д зориулж бичсэн программ хангамжаа ашигладаг. Өмнө нь биш юмаа гэхэд 80-аад оны дундуур Emacs-д зориулж бичсэн модулиудыг хэн нэгэн ашиглаж байгаа гэдэгт би итгэлтэй байна. Тэд үе үе бага зэрэг засах шаардлагатай байж болох ч энэ нь үнэхээр ховор тохиолддог. Би Emacs-д зориулж бичсэн (мөн би маш их бичсэн) архитектурыг дахин хийх шаардлагатай юу ч мэдэхгүй байна.
Emacs нь хуучирсан аж ахуйн нэгжүүдэд зориулсан make-ussolete гэсэн функцтэй. Компьютерийн үндсэн ойлголтуудын ("цонх" гэж юу болох гэх мэт) Emacs нэр томьёо нь салбарын конвенцуудаас ихэвчлэн ялгаатай байдаг, учир нь Emacs үүнийг эртнээс нэвтрүүлсэн. Энэ нь цаг хугацаанаасаа түрүүлж байгаа хүмүүсийн хувьд ердийн аюул юм: таны бүх нөхцөл буруу байна. Гэхдээ Emacs-д элэгдлийн тухай ойлголт байдаг бөгөөд үүнийг тэдний хэллэгээр нэрлэдэг хуучирсан.
Гэхдээ Emacs ертөнцөд өөр ажлын тодорхойлолт байдаг бололтой. Хэрэв хүсвэл өөр өөр гүн ухаан.
Emacs-ийн ертөнцөд (мөн бид доор авч үзэх бусад олон салбарт) хуучирсан API статус нь үндсэндээ: "Та энэ аргыг ашиглах ёсгүй, учир нь энэ нь ажиллаж байх хугацаандаа янз бүрийн дутагдалтай байдаг. энд жагсаана уу. Гэхдээ эцсийн эцэст энэ бол таны сонголт."
Google-ийн ертөнцөд хуучирсан гэдэг нь "Бид таны өмнө хүлээсэн амлалтаа зөрчиж байна" гэсэн үг юм. Энэ бол үнэн. Энэ нь үндсэндээ юу гэсэн үг юм. Энэ нь тэд чамайг албадах болно гэсэн үг юм байнга тэдэнд итгэсний шийтгэл болгон зарим ажил, магадгүй маш их ажил хийх : Бидэнд хамгийн сайн програм хангамж бий. Хамгийн хурдан! Та зааврын дагуу бүх зүйлийг хийж, програм эсвэл үйлчилгээгээ эхлүүлж, дараа нь нэг юмуу хоёр жилийн дараа энэ нь эвдэрдэг.
1500 км яваад гарцаагүй эвдэрдэг хуучин машин зарах шиг.
Эдгээр нь "хуучирсан" гэсэн хоёр огт өөр философийн тодорхойлолт юм. Google-ийн үнэрийн тодорхойлолт . Би үүнд итгэхгүй байна Үнэндээ Apple-тай ижил утгаараа төлөвлөсөн хуучирсан . Гэхдээ Google таны хөтөлбөрүүдийг тойрсон байдлаар эвдэх төлөвлөгөөтэй байгаа нь гарцаагүй. Би тэнд 12 гаруй жил программ хангамжийн инженерээр ажилласан болохоор үүнийг мэднэ. Тэд хоцрогдсон нийцтэй байдлыг хэр зэрэг дагаж мөрдөх талаар тодорхойгүй дотоод удирдамжтай байдаг ч эцсийн дүндээ баг эсвэл үйлчилгээ тус бүрээс хамаарна. Аж ахуйн нэгж, инженерийн түвшний зөвлөмж байхгүй бөгөөд хуучирсан мөчлөгийн талаархи хамгийн зоригтой зөвлөмж бол "хэрэглэгчид системээ бүхэлд нь эвдэхээс өмнө шинэчлэхийн тулд 6-12 сарын хугацаа өгөхийг хичээ".
Асуудал нь тэдний бодож байгаагаас хамаагүй том бөгөөд үйлчлүүлэгчийн тусламж үйлчилгээ нь тэдний ДНХ-д байдаггүй тул олон жилийн турш үргэлжлэх болно. Энэ талаар доор дэлгэрэнгүй үзнэ үү.
Энэ үед би Emacs их хэмжээгээр, тэр ч байтугай амжилтанд хүрсэн гэж зоримог мэдэгдэл хийх гэж байна ихэнхдээ Учир нь тэд хоцрогдсон нийцтэй байдлыг маш нухацтай авч үздэг. Үнэндээ энэ бол бидний нийтлэлийн сэдэв юм. Амжилттай, урт наслалттай нээлттэй системүүд нь тэдний эргэн тойронд хэдэн арван жилийн турш амьдарч ирсэн бичил нийгэмлэгүүдэд амжилтанд хүрдэг. өргөтгөлүүд / залгаасууд. Энэ бол экосистем юм. Платформуудын мөн чанар, тэдгээр нь хэр чухал болохыг, мөн Google корпорацийн түүхэнд Android эсвэл Chrome-ээс бусад амжилттай нээлттэй платформыг бий болгоход юу нөлөөлдөг болохыг хэзээ ч ойлгож байгаагүй талаар би аль хэдийн ярьсан.
Үнэндээ Android-ийн талаар товч дурдах хэрэгтэй, учир нь та энэ талаар бодож байгаа байх.
Юуны өмнө, Android бол Google биш. Тэд хоорондоо бараг ижил төстэй зүйл байдаггүй. Android бол 2005 оны XNUMX-р сард Google-ээс худалдаж авсан компани бөгөөд тус компани нь бие даасан байдлаар ажиллахыг зөвшөөрсөн бөгөөд сүүлийн жилүүдэд бараг хөндөгдөөгүй хэвээр байна. Андройд бол алдартай технологийн стек бөгөөд адилхан зартай өргөст байгууллага юм. Нэг Google-ийн хэлснээр "Та зүгээр л Android руу нэвтэрч чадахгүй."
Өмнөх нийтлэлдээ би Android-ийн дизайны анхны шийдвэрүүд хэр муу байсныг авч үзсэн. Би тэр нийтлэлийг бичихэд тэд "шуурхай програмууд" гэж нэрлэдэг балиар гаргаж байсан бөгөөд одоо (гайхшралтай!) , мөн та Google-ийг сонсож, контентоо эдгээр шуурхай апп-ууд руу шилжүүлэх хангалттай тэнэг байсан бол би өрөвдөж байна.
Гэхдээ энд нэг ялгаа бий, мэдэгдэхүйц ялгаа нь Андройдын хүмүүс платформууд ямар чухал болохыг үнэхээр ойлгодог, хуучин Android програмуудыг ажиллуулахын тулд чадах бүхнээ хичээдэг. Үнэн хэрэгтээ, тэдний хоцрогдсон нийцтэй байдлыг хадгалахын тулд хийсэн хүчин чармайлт нь маш их байсан тул би хэдэн жилийн өмнө Android хэлтэст богино хугацаанд ажиллаж байхдаа хамгийн эртний төхөөрөмжүүд болон API-уудын дэмжлэгийг зогсоохыг тэдэнд итгүүлэхийг оролдсон (би буруу байсан. , өмнөх болон одоогийн бусад олон зүйлсийн нэгэн адил. Уучлаарай Android залуусаа! Би Индонезид очсон болохоор бидэнд яагаад хэрэгтэй байгааг ойлгож байна).
Андройдын хүмүүс өөрсдийн систем, багаж хэрэгсэлд асар их хэмжээний хуучин техникийн өрийг хуримтлуулж, нийцтэй байдлыг бараг төсөөлшгүй хэмжээнд хүргэж байна. Ээ бурхан минь, та тэдний бүтээх системд нийцтэй байх нэрээр хийх ёстой галзуу зүйлсийг харах ёстой.
Үүнийхээ төлөө би Android-д "Та Google биш" шагналыг өгдөг. Тэд удаан эдэлгээтэй платформуудыг хэрхэн бүтээхийг мэдэхгүй Google болохыг үнэхээр хүсэхгүй байгаа ч Android мэдэж байгаа, үүнийг хэрхэн хийх вэ. Тиймээс Google нь нэг талаараа маш ухаалаг юм: хүмүүст Android дээр өөрийнхөөрөө зүйлийг хийх боломжийг олгодог.
Гэсэн хэдий ч Android-д зориулсан шуурхай програмууд нь үнэхээр тэнэг санаа байсан. Тэгээд яагаад гэдгийг мэдэх үү? Учир нь тэд шаардсан програмаа дахин бичиж, дахин загварчлаарай! Хүмүүс зүгээр л хоёр сая өргөдлөө дахин бичих юм шиг. Instant Apps нь зарим Google-ийн санаа байсан гэж би таамаглаж байна.
Гэхдээ ялгаа бий. Хоцрогдсон нийцтэй байдал нь өндөр өртөгтэй байдаг. Эдгээр зардлын ачааг Андройд өөрөө хариуцдаг бол Google ачааг үүрэхийг шаарддаг чи байна, төлбөр төлж буй үйлчлүүлэгч.
Та Android-ын API-уудаас буцаж нийцтэй байх амлалтыг харж болно. Хэрэв та дөрвөөс таван өөр дэд системтэй бол яг ижил зүйлийг хийж байгаа бол энэ нь үндсэндээ хоцрогдсон нийцтэй байх амлалт байгаагийн баттай шинж тэмдэг юм. Платформын ертөнцөд энэ нь таны үйлчлүүлэгчид болон зах зээлд үнэнч байхтай ижил утгатай юм.
Энд Google-ийн гол асуудал бол инженерийн эрүүл ахуйдаа бахархах явдал юм. Хуучин, хүсээгүй арга нь шинэ, илүү сонирхолтой аргуудын хажууд сууж, ижил зүйлийг хийх олон янзын арга зам байгаа нь тэдэнд дургүй байдаг. Энэ нь системд шинээр орсон хүмүүсийн сурах муруйг нэмэгдүүлж, хуучин API-уудыг хадгалах ачааллыг нэмэгдүүлж, шинэ функцүүдийн хурдыг удаашруулж, гол нүгэл нь хөөрхөн биш юм. Google - Тим Бертоны Алис гайхамшгийн оронд киноны хатагтай Аскот шиг:
Хатагтай Аскот:
- Алис, чи миний юунаас хамгийн их айдагийг мэдэх үү?
-Язгууртны уналт?
-Тийм болно гэж айж байсан муухай ач зээ нар.
Үзэсгэлэнтэй, практик хоёрын хоорондын ялгааг ойлгохын тулд гурав дахь амжилттай платформыг (Emacs болон Android-ийн дараа) авч үзээд энэ нь хэрхэн ажилладагийг харцгаая: Java өөрөө.
Java-д маш олон хуучирсан API байдаг. Элэгдэл нь Java програмистуудын дунд маш их алдартай бөгөөд ихэнх програмчлалын хэлнүүдээс ч илүү алдартай байдаг. Жава өөрөө, үндсэн хэл, номын сангууд API-г байнга няцааж байдаг.
Мянга мянган жишээнээс нэгийг нь авч үзвэл, хуучирсан гэж үздэг. 1.2 оны 1998-р сард Java 22 хувилбар гарснаас хойш энэ нь хуучирсан. Үүнийг хэрэглээгүй болгоод XNUMX жил болж байна.
Гэхдээ миний үйлдвэрлэлийн код нь утаснуудыг устгасаар байна өдөр бүр. Та үүнийг үнэхээр сайн гэж бодож байна уу? Мэдээжийн хэрэг! Мэдээжийн хэрэг, хэрэв би кодыг өнөөдөр дахин бичих байсан бол би үүнийг өөрөөр хэрэгжүүлэх байсан. Гэвч сүүлийн хорин жилийн хугацаанд олон зуун мянган хүнийг баярлуулсан миний тоглоомын код нь хэтэрхий урт гацсан хэлхээг хаах функцээр бичигдсэн бөгөөд би хэзээ ч өөрчлөх шаардлагагүй байсан. Би өөрийн системийг хэнээс ч илүү мэддэг, би үүнтэй үйлдвэрлэлд 25 жил ажилласан туршлагатай бөгөөд би баттай хэлж чадна: миний хувьд эдгээр тодорхой ажилчдын утаснуудыг хаах нь бүрэн хэрэг болно. хор хөнөөлгүй. Энэ кодыг дахин бичихэд цаг хугацаа, хүчин чармайлт гаргах нь үнэ цэнэтэй зүйл биш бөгөөд Оракл намайг дахин бичихийг албадаагүйд Ларри Эллисонд (магадгүй) баярлалаа.
Oracle бас платформыг ойлгодог байх. Хэн мэдэх вэ.
Хавцал дахь мөсөн голын шугам шиг хуучирсан долгионоор дүүрэн байдаг үндсэн Java API-уудаас нотлох баримтыг олж болно. Та Java Swing номын сангаас тав, зургаан өөр гарын навигацийн менежерийг (KeyboardFocusManager) хялбархан олох боломжтой. Хэрэглээгүй Java API олох нь үнэндээ хэцүү байдаг. Гэхдээ тэд ажиллаж байна! Интерфэйс нь аюулгүй байдлын ноцтой асуудал үүсгэсэн тохиолдолд Java багийнхан API-г үнэхээр устгах болно гэж би бодож байна.
Энд нэг зүйл байна, хүмүүсээ: Бид програм хангамж хөгжүүлэгчид маш завгүй байдаг бөгөөд програм хангамжийн аль ч салбарт бид өрсөлдөх өөр хувилбаруудтай тулгардаг. Ямар ч үед X хэлний програмистууд Y хэлийг орлуулах боломжтой гэж үздэг. Өө, чи надад итгэхгүй байна уу? Та үүнийг Свифт гэж нэрлэмээр байна уу? Хүн бүр Свифт рүү шилжиж байгаа ч хэн ч үүнийг орхихгүй, тийм ээ? Хөөх, чи ямар бага юм мэддэг. Компаниуд хос гар утасны хөгжүүлэлтийн багуудын (iOS болон Android) зардлыг тооцож байгаа бөгөөд Flutter, React Native гэх мэт инээдтэй нэртэй платформ хоорондын хөгжүүлэлтийн системүүд үнэхээр ажилладаг бөгөөд тэдгээрийн хэмжээг багасгахад ашиглаж болохыг тэд ойлгож эхэлж байна. хөдөлгөөнт багийг хоёр дахин эсвэл эсрэгээр нь хоёр дахин бүтээмжтэй болгоно. Бодит мөнгө эрсдэлд байна. Тийм ээ, буулт хийх боломжтой, гэхдээ нөгөө талаас мөнгө.
Apple-ийн тэнэглэлээр Гуидо ван Россумаас санаа авч, Python 6.0 нь Python 5.0-той нийцэхгүй байгаатай адил Swift 3 нь Swift 2-тэй таарахгүй гэж мэдэгдсэн гэж таамаглаж үзье.
Би энэ түүхийг арав орчим жилийн өмнө ярьж байсан байх, гэхдээ арван таван жилийн өмнө би Гуидотой хамт О'Рейлигийн Фүү бааз руу явж, Пол Грахамтай майханд сууж, олон том зураг авалт хийсэн. Бид бүгчим халуунд Ларри Пэйжийг хувийн нисдэг тэргээрээ нисэхийг хүлээж суугаад Гуидо "Python 3000"-ын талаар нисгэгчгүй нисч, хүн бүр тийшээ нүүж ирэхэд хэдэн жилийн дараа үүнийгээ нэрлэжээ. Бид түүнээс яагаад нийцтэй байдлыг эвдэж байгааг байнга асуухад тэр: "Юникод" гэж хариулсан. Хэрэв бид кодоо дахин бичих шаардлагатай бол өөр ямар давуу талыг олж харах вэ? Тэгээд тэр "Ёооооооооооооооууууууиииииииииииээээээээ" гэж хариулав.
Хэрэв та Google Cloud Platform SDK (“gcloud”) суулгавал дараах мэдэгдлийг хүлээн авна:
Эрхэм хүлээн авагч,
Python 2-ын дэмжлэгийг зогсоосныг бид танд сануулахыг хүсч байна, тиймээс та новш
... гэх мэт. Амьдралын тойрог.
Гэхдээ гол зүйл бол хөгжүүлэгч бүр сонголттой байдаг. Хэрэв та тэднийг кодыг хангалттай дахин бичихийг албадах юм бол тэд бодож магадгүй юм бусад сонголтууд. Та тэднийг хичнээн хүсч байсан ч тэд чиний барьцаанд байгаа хүмүүс биш. Тэд таны зочид. Python бол маш алдартай програмчлалын хэл хэвээр байгаа боловч хараал идсэн Python 3(000) нь өөрөө, нийгэмдээ болон олон нийтийн хэрэглэгчдийн дунд ийм эмх замбараагүй байдлыг бий болгож, үр дагавар нь арван таван жилийн турш арилаагүй байна.
Энэ арагшаа нийцэхгүйн улмаас Go (эсвэл Ruby эсвэл өөр хувилбар) дээр хичнээн Python программыг дахин бичсэн бэ? Хэдийгээр Python-оос өөр зүйл дээр хичнээн шинэ программ бичигдсэн бол байж болох юм Хэрэв Гуидо тосгоныг бүхэлд нь шатаагаагүй бол Python хэл дээр бичигдсэн үү? Үүнийг хэлэхэд хэцүү ч Python тодорхой хохирол амссан. Энэ бол маш том эмх замбараагүй байдал бөгөөд хүн бүр алддаг.
Тиймээс Apple нь Guido-ээс санаа авч, нийцтэй байдлыг эвдсэн гэж бодъё. Цаашид юу болно гэж та бодож байна вэ? Боломжтой бол хөгжүүлэгчдийн 80-90% нь программ хангамжаа дахин бичих байх. Өөрөөр хэлбэл, хэрэглэгчийн 10-20% нь Flutter гэх мэт өрсөлдөгч хэл рүү автоматаар ордог.
Үүнийг олон удаа хийвэл та хэрэглэгчийн баазынхаа талыг алдах болно. Спортын нэгэн адил програмчлалын ертөнцөд одоогийн хэлбэр нь бас чухал юм. бүгд. Таван жилийн дотор хэрэглэгчдийнхээ талыг алдсан хүн бүр том өөх тос алдсанд тооцогдох болно. Та платформуудын ертөнцөд загварлаг байх ёстой. Гэхдээ энэ нь хуучин хувилбаруудыг дэмжихгүй байх нь таныг цаг хугацааны явцад сүйрүүлэх болно. Учир нь та зарим хөгжүүлэгчдээс салах болгондоо (а) гэрээгээ зөрчсөнийхөө төлөө чамайг уурлаж байгаа учраас тэднийг үүрд алдаж, (б) өрсөлдөгчиддөө өгөх болно.
Хачирхалтай нь, би IDE-тэй төстэй кодыг өөрөө автоматжуулах, хэмжихэд хялбар болгодог эх кодын дүн шинжилгээ, ойлголтын систем болох Grok-ийг бүтээхдээ Google-д буцаад нийцтэй байдлыг үл тоомсорлодог тийм prima donna болоход тусалсан. том өгөгдлийн агуулах дахь Google-ийн эх кодын олон тэрбум мөрийн материаллаг дүрслэл.
Grok Google-н ажилтнуудад бүхэл бүтэн кодын (Google даяар) автоматжуулсан рефакторинг хийх хүчирхэг тогтолцоогоор хангасан. Систем нь зөвхөн таны дээд талын хамаарлыг (таны хамааралтай) тооцоолдог уруудаж байна (энэ нь чамаас шалтгаална) тиймээс та API-г өөрчлөхдөө эвдэж буй хүн бүрийг мэддэг болно! Ингэснээр та өөрчлөлт хийхдээ өөрийн API-ийн хэрэглэгч бүр шинэ хувилбарт шинэчлэгдсэн эсэхийг шалгах боломжтой бөгөөд бодит байдал дээр тэдний бичсэн Rosie хэрэглүүрийг ашигласнаар та үйл явцыг бүрэн автоматжуулж чадна.
Энэ нь Google-ийн кодын баазыг дотооддоо бараг ер бусын цэвэр байлгах боломжийг олгодог, учир нь тэдгээр робот үйлчлэгч нар байшинг тойрон гүйлдэж, хэрэв хэн нэгэн нь үүнийг муухай ач гэж шийдсэн тул түүнийг унтуулах шаардлагатай болсон тул SomeDespicablyLongFunctionName-ийн нэрийг SomeDespicablyLongMethodName болгон өөрчилсөн тохиолдолд автоматаар бүх зүйлийг цэвэрлэдэг.
Үнэнийг хэлэхэд, энэ нь Google-д маш сайн ажилладаг ... дотооддоо. Тиймээ, Google-ийн Go нийгэмлэг нь Google-ийн Java нийгэмлэгийн хамт олонд байнга рефакторинг хийдэг зуршлаасаа болж инээдэг. Хэрэв та ямар нэг зүйлийг N удаа дахин эхлүүлбэл, энэ нь зөвхөн N-1 удаа алдаад зогсохгүй хэсэг хугацааны дараа N-р оролдлого дээр ч гэсэн үүнийг эвдсэн байх нь тодорхой болно. Гэхдээ ерөнхийдөө тэд энэ бүх шуугианаас дээгүүр үлдэж, кодыг "цэвэр" байлгадаг.
Асуудал нь тэд өөрсдийн үүлэн үйлчлүүлэгчид болон бусад API хэрэглэгчдэд энэ хандлагыг ногдуулахыг оролдох үед эхэлдэг.
Би танд Emacs, Android болон Java-г бага зэрэг танилцуулсан; Хамгийн сүүлийн үеийн амжилттай урт хугацааны платформыг харцгаая: Вэб өөрөө. 1995 оноос хойш бид анивчдаг хаягуудыг ашигласнаас хойш HTTP хэдэн удаа давтагдсаныг та төсөөлж байна уу? вэб хуудсууд дээрх "Барьж байгаа" дүрсүүд.
Гэхдээ энэ нь ажилладаг хэвээр байна! Мөн эдгээр хуудаснууд ажиллаж байна! Тийм ээ, залуус аа, хөтчүүд бол хоцрогдсон нийцтэй байдлын дэлхийн аварга юм. Chrome бол Google-ийн ховор платформын өөр нэг жишээ бөгөөд таны таамаглаж байсанчлан Chrome нь бусад Google-ээс тусдаа хамгаалагдсан хязгаарлагдмал орчинд ажилладаг компани юм.
Би бас үйлдлийн систем хөгжүүлэгч найзууддаа: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD гэх мэт амжилттай платформууд дээрээ буцаад нийцтэй байх ажлыг маш сайн хийж байгаад талархаж байгаагаа хэлмээр байна (Apple нь The Сул тал нь тэд ямар ч шалтгаангүйгээр бүх зүйлийг эвддэг, гэхдээ ямар нэгэн байдлаар олон нийт гарах болгондоо үүнийг тойрч гардаг бөгөөд OS X контейнерууд бүрэн хуучираагүй байна ...).
Гэхдээ хүлээгээрэй гэж та хэлж байна. Бид алимыг жүржтэй харьцуулж байгаа юм биш үү? Emacs/JDK/Android/Chrome зэрэг нэг машин дээрх бие даасан програм хангамжийн системийг олон серверийн системүүд болон үүлэн үйлчилгээ гэх мэт API-уудтай харьцуулж байгаа юм биш үү?
Өчигдөр би энэ тухай жиргэсэн боловч Ларри Уолл (Перл програмчлалын хэлийг бүтээгч - ойролцоогоор XNUMX.) -ийн хэв маягаар "сохрох/дүрэм" гэсэн зарчмаар энэ үгийг хайлаа. хуучирсан Google болон Amazon хөгжүүлэгчийн сайтууд дээр. Хэдийгээр AWS-д байдаг зуу зуун GCP-ээс хэд дахин илүү үйлчилгээний санал болгож буй Google-ийн хөгжүүлэгчийн баримт бичигт хуучирсан тухай долоо дахин олон удаа дурдсан байдаг.
Хэрэв Google дээрх хэн нэгэн үүнийг уншиж байгаа бол тэд үнэхээр бүх зүйлийг зөв хийж байгаа гэдгээ харуулсан Дональд Трамп маягийн графикуудыг гаргаж авахад бэлэн байж магадгүй бөгөөд би "хуучирсан үгийн тоог дурьдсан үгтэй харьцуулах" зэрэг шударга бус харьцуулалт хийх ёсгүй. үйлчилгээний тоо" "
Гэвч энэ олон жилийн дараа Google Cloud нь 3-р үйлчилгээ хэвээр байгаа (Би 2-р байранд орох оролдлого бүтэлгүйтсэн тухай нийтлэл бичиж байгаагүй), гэхдээ хэрэв дотоод хүмүүст итгэх юм бол тэд удахгүй буурах вий гэсэн болгоомжлол бий. №4.
Би дипломын ажлаа "нотлох" ямар ч үндэслэлтэй үндэслэл байхгүй. Надад байгаа бүх зүйл бол хөгжүүлэгчийн хувьд 30 гаруй жил цуглуулсан өнгөлөг жишээнүүд юм. Энэ асуудлын гүн гүнзгий гүн ухааны мөн чанарыг би аль хэдийн дурдсан; Энэ нь зарим талаараа хөгжүүлэгчдийн нийгэмлэгт улстөрждөг. Зарим нь үүнд итгэдэг бүтээгчид платформууд нийцтэй байдалд санаа тавих ёстой бол бусад нь үүнийг санаа зовоосон асуудал гэж үздэг хэрэглэгчид (хөгжүүлэгчид өөрсдөө). Хоёрын нэг. Үнэхээр нийтлэг асуудлын зардлыг хэн даах вэ гэдэг нь улс төрийн асуудал биш гэж үү?
Тэгэхээр энэ бол улс төр. Мөн миний хэлсэн үгэнд ууртай хариу ирэх байх.
Хэрхэн хэрэглэгч Google Cloud Platform, мөн хоёр жилийн турш AWS хэрэглэгчийн хувьд (Grab-д ажиллаж байхдаа) тэргүүлэх чиглэлийн тухайд Amazon болон Google-ийн философийн хооронд асар их ялгаа байгааг хэлж чадна. Би AWS дээр идэвхтэй хөгжүүлдэггүй тул хуучин API-г хэр олон удаа устгадгийг сайн мэдэхгүй байна. Гэхдээ энэ нь Google-д тохиолддог шиг тийм ч олон тохиолддоггүй гэсэн хардлага байдаг. GCP-ийн байнгын маргаан, бухимдлын эх үүсвэр нь платформыг хөгжүүлэхэд саад болж буй хамгийн том хүчин зүйлүүдийн нэг гэдэгт би үнэхээр итгэдэг.
Дэмжихээ больсон GCP системийн тодорхой жишээг би нэрлээгүй гэдгээ мэдэж байна. Сүлжээнээс (хамгийн эртнийхээс VPC хүртэл) хадгалах (Cloud SQL v1-v2), Firebase (одоо Firestore, огт өөр API-тай), App Engine (эхлэхгүй байя) гээд миний ашигласан бараг бүх зүйл гэж би хэлж чадна. , үүлэн төгсгөлийн цэгүүд Cloud Endpoint ба хүртэл... Би мэдэхгүй - үнэхээр энэ бүгд хамгийн ихдээ 2-3 жилийн дараа кодыг дахин бичихийг албадсан бөгөөд тэд таны шилжилтийг хэзээ ч автоматжуулж байгаагүй бөгөөд ихэнхдээ . Тийм байх ёстой юм шиг.
Тэгээд AWS-г харах болгондоо би яагаад GCP дээр байгаа юм бэ гэж өөрөөсөө асуудаг. Тэдэнд үйлчлүүлэгч хэрэггүй нь тодорхой. Тэдэнд хэрэгтэй худалдан авагчид. Та ялгааг ойлгож байна уу? Би тайлбарлая.
Google Cloud-д байдаг , хүмүүс өөрсдийн програм хангамжийн шийдлүүдийг санал болгодог бөгөөд рестораны хоосон нөлөөллөөс зайлсхийхийн тулд зарим саналуудыг бөглөх шаардлагатай байсан тул Bitnami хэмээх компанитай гэрээ байгуулж, "нэг товшилтоор" олон тооны шийдлүүдийг бий болгох хэрэгтэй. Би үүнийг өөрөө "шийдэл" гэж бичдэг, учир нь эдгээр нь ямар ч зүйлийг шийдэж чадахгүй. Эдгээр нь зүгээр л шалгах хайрцаг, маркетингийн дүүргэгч хэлбэрээр байдаг бөгөөд Google-ийн аль нэг хэрэгсэл нь үнэхээр ажиллаж байгаа эсэхийг хэзээ ч тоодоггүй. Жолоочийн суудалд сууж байсан бүтээгдэхүүний менежерүүдийг би мэддэг бөгөөд эдгээр хүмүүст хамаагүй гэдгийг би баттай хэлж чадна.
Жишээлбэл, "нэг товшилтоор" байршуулах шийдлийг авч үзье. . Би Google Cloud SQL-ийн хов живээс болж үхтлээ өвдөж байсан тул өөр хувилбар болгон өөрийн Percona кластер бүтээхээр хайж эхэлсэн. Мөн энэ удаад Google сайн ажил хийсэн бололтой, тэд нэг товчлуур дээр дарснаар миний цаг хугацаа, хүчин чармайлтыг хэмнэх болно!
За сайн байна, явцгаая. Холбоосыг дагаж энэ товчийг дарцгаая. Бүх өгөгдмөл тохиргоог зөвшөөрөхийн тулд "Тийм" гэснийг сонгоод Google клоуд төсөлдөө кластер байрлуулна уу. Хаха, болохгүй байна. Энэ новшийн аль нь ч бүтдэггүй. Энэ хэрэгслийг хэзээ ч туршиж үзээгүй бөгөөд эхний минутаас ялзарч эхэлсэн бөгөөд "шийдлийн" талаас илүү хувь нь нэг товшилтоор суулгагдсан бол намайг гайхшруулахгүй (одоо бид яагаад ишлэл хийснийг ойлгож байна) ерөнхийдөө Ажиллахгүй байна. Энэ бол үнэхээр найдваргүй харанхуй бөгөөд орохгүй байх нь дээр.
Гэхдээ Google-ийн зөв урамшуулал Та тэдгээрийг ашиглах. Тэд чамайг хүсч байна худалдаж авсан. Тэдний хувьд энэ бол гүйлгээ юм. Тэд юу ч хүсэхгүй байна дэмжлэг. Энэ нь Google-ийн ДНХ-ийн нэг хэсэг биш юм. Тийм ээ, инженерүүд бие биенээ дэмждэг нь Bigtable-тэй хийсэн түүх маань нотлогдсон. Харин жирийн хүмүүст зориулсан бүтээгдэхүүн, үйлчилгээнд тэд үргэлж харгис хэрцгий байсан , энэ нь сая сая хэрэглэгчтэй байсан ч ашиг олох шалгуурыг хангадаггүй.
Энэ нь GCP-ийн хувьд жинхэнэ сорилт болж байна, учир нь энэ бол бүх үүлэн саналын ард байгаа ДНХ юм. Тэд юуг ч дэмжихийг оролддоггүй; Тэд аливаа гуравдагч талын програм хангамжийг (удирдлагатай үйлчилгээ болгон) байршуулахаас татгалздаг нь мэдэгдэж байна хүртэл, AWS ижил зүйлийг хийж, эргэн тойронд нь амжилттай бизнесийг бий болгох хүртэл, мөн үйлчлүүлэгчид шууд утгаараа үүнийг шаардах хүртэл. Гэсэн хэдий ч Google-г ямар нэг зүйлийг дэмжихийн тулд бага зэрэг хүчин чармайлт гаргах шаардлагатай.
Энэхүү дэмжлэгийн соёлгүй байдал, “ямар ч гоё болгоё” гэсэн сэтгэлгээтэй нийлээд хөгжүүлэгчдийг холдуулж байна.
Хэрэв та урт хугацааны платформ барихыг хүсч байвал энэ нь тийм ч сайн зүйл биш юм.
Google, сэрээрэй, хараал идээрэй. Одоо 2020 он боллоо. Та алдсаар л байна. Толинд сайн харж, үүлэн бизнест үлдэхийг үнэхээр хүсч байгаа эсэхдээ хариулах цаг болжээ.
Хэрэв та үлдэхийг хүсч байвал бүгдийг эвдэхээ боль. Залуус аа, та баян. Хөгжүүлэгчид бид тэгдэггүй. Тиймээс нийцтэй байдлын ачааг хэн үүрэх вэ гэхээр та үүнийг өөртөө үүрэх хэрэгтэй. Бидний хувьд биш.
Учир нь дор хаяж гурван үнэхээр сайн үүл бий. Тэд дуудаж байна.
Одоо би бүх эвдэрсэн системээ засах болно. Өө.
Дараагийн удаа хүртэл!
Жич Энэ нийтлэлийн зарим хэлэлцүүлгийг уншсаны дараа шинэчлээрэй (хэлэлцүүлэг маш сайн байна, btw). Firebase-ийн дэмжлэгийг зогсоогоогүй бөгөөд миний мэдэж байгаа төлөвлөгөө байхгүй байна. Гэсэн хэдий ч, тэд Java клиентийг App Engine дээр зогсоход хүргэдэг муу урсгалтай алдаатай байдаг. Тэдний нэг инженер надад энэ асуудлыг шийдвэрлэхэд тусалсан. намайг Google-д ажиллаж байхдаа, гэхдээ тэд алдааг хэзээ ч засч чадаагүй тул надад GAE програмыг өдөр бүр дахин эхлүүлэх хэрэгтэй болж байна. Ингээд дөрвөн жил өнгөрчээ! Тэд одоо Firestore-тэй болсон. Энэ нь огт өөр систем бөгөөд Firebase-ийн алдаа хэзээ ч засагдахгүй тул үүн рүү шилжихэд маш их ажил шаардагдана. Ямар дүгнэлт хийж болох вэ? Та тусламж авч болно хэрэв та компанид ажилладаг бол. Би GAE дээр Firebase ашиглаж байгаа цорын ганц хүн байж магадгүй, учир нь би 100% уугуул програмд 100-аас бага түлхүүр нэвтэрсэн бөгөөд мэдэгдэж буй алдааны улмаас энэ нь хоёр өдөр тутамд ажиллахаа больдог. Эрсдлээрээ ашиглахаас өөр юу хэлэх вэ дээ. Би Redis руу шилжиж байна.
AWS нь ихэвчлэн ямар ч үйлчилгээг дэмжихээ зогсоодоггүй бөгөөд SimpleDB бол гайхалтай жишээ юм гэж илүү туршлагатай AWS хэрэглэгчид хэлэхийг би бас харсан. AWS нь Google-тэй адил дэмжлэг үзүүлэх өвчний төгсгөлгүй гэсэн миний таамаглал үндэслэлтэй юм шиг санагдаж байна.
Нэмж дурдахад, Google App Engine баг 20 хоногийн өмнө Go-н чухал номын сангийн хостинг эвдэж, Go програмыг гол хөгжүүлэгчдийн нэгээс GAE програмыг хаасныг би анзаарсан. Энэ үнэхээр тэнэг байсан.
Эцэст нь би Google-ийн ажилтнууд энэ асуудлыг аль хэдийн хэлэлцэж, надтай ерөнхийдөө санал нийлж байгааг сонссон (та нарт хайртай!). Гэхдээ тэд Google-ийн соёл нь урамшууллын зөв бүтэцтэй байгаагүй тул асуудлыг шийдэх боломжгүй гэж боддог бололтой. Би Grab-д ажиллаж байхдаа AWS-ийн инженерүүдтэй ажиллаж байсан гайхалтай туршлагынхаа талаар ярилцах цаг гаргавал зүгээр гэж бодлоо. Ирээдүйд хэзээ нэгэн цагт би найдаж байна!
Тийм ээ, 2005 онд тэд 43-р байрны аварга буфет дээр янз бүрийн төрлийн акулын махтай байсан бөгөөд миний дуртай зүйл бол алх толгойтой акулын мах байсан. Гэсэн хэдий ч 2006 он гэхэд Ларри, Сергей хоёр эрүүл бус бүх зуушнаас салжээ. Тиймээс 2007 онд Bigtable түүхийн үеэр акулууд үнэхээр байгаагүй бөгөөд би чамайг хуурсан.
Дөрвөн жилийн өмнө би cloud Bigtable-г харахад (өгөх эсвэл авах) зардал нь энд байсан. Энэ нь одоо бага зэрэг буурсан юм шиг санагдаж байна, гэхдээ энэ нь хоосон мэдээллийн агуулахын хувьд маш их зүйл хэвээр байна, ялангуяа миний анхны түүх хоосон том хүснэгт нь тэдний хэмжээнд ямар ач холбогдолгүй болохыг харуулсан тул.
Apple-ийн нийгэмлэгийг гомдоож, Майкрософт гэх мэтийн талаар сайхан үг хэлээгүйд уучлаарай. Та зүгээр, энэ нийтлэлийн үүсгэсэн бүх хэлэлцүүлэгт би үнэхээр талархаж байна! Гэхдээ заримдаа яриа өрнүүлэхийн тулд бага зэрэг давалгаа хийх хэрэгтэй болдог шүү дээ?
Уншсанд баярлалаа.
Шинэчлэлт 2, 19.08.2020/XNUMX/XNUMX. Судал !
Шинэчлэлт 3, 31.08.2020/2/2. Cloud Marketplace-ийн Google-ийн инженер надтай холбогдож, миний хуучин найз болсон. Тэр яагаад CXNUMXD ажиллахгүй байгааг олж мэдэхийг хүссэн ба эцэст нь би сүлжээгээ олон жилийн өмнө байгуулсан, мөн CXNUMXD нь хуучин сүлжээн дээр ажиллахгүй байгаа, учир нь тэдний загварт дэд сүлжээний параметр байхгүй байсан гэдгийг бид ойлгосон. GCP-ийн боломжит хэрэглэгчид Google-д хангалттай инженерүүдийг мэддэг байх нь дээр гэж би бодож байна...
Эх сурвалж: www.habr.com