Անիծյալ Google-ը, ես չէի ուզում նորից բլոգ գրել: Ես այնքան բան ունեմ անելու: Բլոգավարությունը պահանջում է ժամանակ, էներգիա և ստեղծագործական ունակություններ, որոնք ես կարող եմ լավ օգտագործել. իմ գրքերը, , իմ խաղը և այլն։ Բայց դու ինձ բավականաչափ բարկացրել ես, որ ես պետք է սա գրեմ:
Այսպիսով, եկեք ավարտենք այս հարցը:
Սկսեմ մի կարճ, բայց ուսանելի պատմությունից, երբ ես առաջին անգամ սկսեցի աշխատել Google-ում: Ես գիտեմ, որ վերջերս շատ վատ բաներ եմ ասում Google-ի մասին, բայց դա ինձ վրդովեցնում է, երբ իմ սեփական ընկերությունը պարբերաբար ոչ կոմպետենտ բիզնես որոշումներ է կայացնում: Միևնույն ժամանակ, մենք պետք է դրան արժանին մատուցենք. Google-ի ներքին ենթակառուցվածքն իսկապես արտասովոր է, կարելի է վստահորեն ասել, որ այսօր ավելի լավ բան չկա: Google-ի հիմնադիրները շատ ավելի լավ ինժեներներ էին, քան ես երբևէ կլինեմ, և այս պատմությունը միայն հաստատում է այդ փաստը։
Նախ, մի փոքր նախապատմություն. Google-ն ունի տվյալների պահպանման տեխնոլոգիա, որը կոչվում է . Դա ուշագրավ տեխնիկական ձեռքբերում էր, առաջիններից մեկը (եթե ոչ առաջինը) «անսահման մասշտաբային» բանալի-արժեքի խանութներից մեկը (K/V). ըստ էության NoSQL-ի սկիզբը: Այս օրերին Bigtable-ը դեռ լավ է աշխատում բավականին մարդաշատ K/V պահեստային տարածքում, բայց այն ժամանակ (2005 թ.) այն զարմանալիորեն զով էր:
Bigtable-ի հետ կապված մի զվարճալի բան այն է, որ նրանք ունեին ներքին կառավարման ինքնաթիռի օբյեկտներ (որպես իրագործման մաս), որոնք կոչվում էին պլանշետային սերվերներ, մեծ ինդեքսներով, և ինչ-որ պահի դրանք դարձան խցան, երբ համակարգը մեծացնում էր: Bigtable-ի ինժեներները տարակուսում էին, թե ինչպես կիրառել ընդլայնելիությունը, և հանկարծ հասկացան, որ նրանք կարող են փոխարինել պլանշետային սերվերները այլ Bigtable պահեստով: Այսպիսով, Bigtable-ը Bigtable-ի իրականացման մի մասն է: Այս պահեստարանները կան բոլոր մակարդակներում:
Մեկ այլ հետաքրքիր մանրամասն այն է, որ որոշ ժամանակ Bigtable-ը դարձավ հանրաճանաչ և ամենուր տարածված Google-ում, և յուրաքանչյուր թիմ ուներ իր սեփական պահեստը: Ուստի ուրբաթ օրվա հանդիպումներից մեկում Լարի Փեյջը պատահաբար հարցրեց. «Ինչո՞ւ մենք ունենք մեկից ավելի Bigtable: Ինչու ոչ միայն մեկը»: Տեսականորեն, մեկ պահեստը պետք է բավարար լինի Google-ի պահեստավորման բոլոր կարիքների համար: Իհարկե, նրանք երբեք չեն գնացել միայն մեկին գործնական զարգացման պատճառներով (ինչպես պոտենցիալ ձախողման հետևանքները), բայց տեսությունը հետաքրքիր էր: Մեկ պահեստ ամբողջ Տիեզերքի համար (Ի դեպ, որևէ մեկը գիտի՞ արդյոք Amazon-ը դա արել է իր Sable-ի հետ:)
Ինչևէ, ահա իմ պատմությունը.
Այդ ժամանակ ես աշխատում էի Google-ում ընդամենը երկու տարի, և մի օր ես նամակ ստացա Bigtable-ի ինժեներական թիմից, որն այսպիսին էր.
Հարգելի Սթիվ,
Բարև Bigtable թիմից: Մենք ցանկանում ենք ձեզ տեղեկացնել, որ [data center name]-ում դուք օգտագործում եք շատ, շատ հին Bigtable երկուական տարբերակ: Այս տարբերակն այլևս չի աջակցվում, և մենք ցանկանում ենք օգնել ձեզ թարմացնել վերջին տարբերակը:
Խնդրում եմ ինձ տեղյակ պահեք, եթե կարող եք որոշ ժամանակ պլանավորել այս հարցի շուրջ միասին աշխատելու համար:
Ամենայն բարիք,
Bigtable թիմ
Google-ում դուք ստանում եք շատ նամակներ, ուստի առաջին հայացքից ես կարդացի այսպիսի բան.
Հարգելի Ստացող,
Բարև մի թիմից: Մենք ուզում ենք այդ բլա բլա բլա բլա բլա հաղորդել: Բլա բլա բլա բլա բլա բլա, ու բլա բլա բլա անմիջապես։
Խնդրում ենք տեղեկացնել մեզ, արդյոք կարող եք պլանավորել ձեր թանկարժեք ժամանակի մի մասը բլա բլա բլա:
Ամենայն բարիք,
Ինչ-որ հրաման
Ես գրեթե անմիջապես ջնջեցի այն, բայց իմ գիտակցության եզրին ես զգացի ցավոտ, տխուր զգացում, որ դա ոչ իրականում կարծես թե պաշտոնական նամակ է ակնհայտորեն, որ ստացողը սխալվել է, քանի որ ես չեմ օգտագործել Bigtable:
Բայց տարօրինակ էր։
Օրվա մնացած մասը հերթափոխով անցկացրեցի աշխատանքի մասին մտածելով, թե ինչ տեսակի շնաձկան միս փորձեմ միկրոխոհանոցում, որից առնվազն երեքը բավական մոտ էին, որպեսզի տեղիցս թխվածքաբլիթի լավ նպատակաուղղված նետումով հարվածեի, բայց Գրելու միտքը երբեք ինձ չթողեց աճող մեղմ անհանգստության զգացումով:
Նրանք հստակ ասացին իմ անունը։ Եվ նամակն ուղարկվել է իմ էլեկտրոնային հասցեին, ոչ թե ուրիշի, և դա cc: կամ bcc: չէ: Տոնը շատ անհատական է և հստակ: Միգուցե սա ինչ-որ սխալ է:
Ի վերջո, հետաքրքրասիրությունը հաղթահարեց ինձ, և ես գնացի նայելու Borg վահանակը տվյալների կենտրոնում, որը նրանք նշեցին:
Եվ իհարկե, ես կառավարման տակ ունեի BigTable պահեստավորում: Կներես, ի՞նչ։ Ես նայեցի դրա բովանդակությանը և վա՜յ։ Դա Codelab-ի ինկուբատորից էր, որտեղ ես նստեցի Google-ում իմ առաջին շաբաթվա ընթացքում 2005 թվականի հունիսին: Codelab-ը ձեզ ստիպեց գործարկել Bigtable-ը՝ այնտեղ որոշ արժեքներ գրելու համար, և ես, ըստ երևույթին, դրանից հետո երբեք չեմ փակել պահեստը: Այն դեռ աշխատում էր, թեև ավելի քան երկու տարի էր անցել։
Այս պատմության մեջ կան մի քանի ուշագրավ կողմեր. Նախ, Bigtable-ի աշխատանքն այնքան աննշան էր Google-ի մասշտաբով, որ միայն երկու տարի անց որևէ մեկը նկատեց լրացուցիչ պահեստը, և միայն այն պատճառով, որ երկուականի տարբերակը հնացել էր: Համեմատության համար մի անգամ մտածեցի օգտագործել իմ առցանց խաղի համար: Այն ժամանակ այս ծառայությունն արժեր մոտավորապես $16 տարեկան: դատարկ Bigtable-ը GCP-ում: Չեմ ասում, որ քեզ խաբում են, բայց իմ անձնական կարծիքով, դա մեծ գումար է դատարկ խարխափած տվյալների բազայի համար:
Մեկ այլ ուշագրավ կողմն այն է, որ պահեստավորումը դեռ աշխատում է երկու տարի անց. WTF? Տվյալների կենտրոնները գալիս և գնում են. նրանք ունենում են անջատումներ, անցնում են պլանային սպասարկում, անընդհատ փոխվում են։ Սարքավորումները թարմացվում են, անջատիչները փոխվում են, ամեն ինչ անընդհատ բարելավվում է: Ինչպե՞ս կարողացան այս բոլոր փոփոխություններով իմ ծրագիրը երկու տարի շարունակ պահել: Սա կարող է թվալ համեստ ձեռքբերում 2020 թվականին, սակայն 2005-2007 թվականներին այն բավականին տպավորիչ էր։
Եվ ամենահրաշալի կողմն այն է, որ արտաքին ինժեներական թիմը ինչ-որ այլ նահանգում մոտենում է ինձ՝ Bigtable-ի ինչ-որ փոքրիկ, գրեթե դատարկ օրինակի սեփականատեր, ով ունի. զրոյական երթևեկություն վերջին երկու տարիների ընթացքում և առաջարկում են օգնություն այն թարմացնելու համար:
Ես շնորհակալություն հայտնեցի նրանց, ջնջեցի պահեստը, և կյանքը շարունակվեց սովորականի պես: Բայց տասներեք տարի անց ես դեռ մտածում եմ այդ նամակի մասին։ Քանի որ երբեմն ես նմանատիպ նամակներ եմ ստանում Google Cloud-ից: Նրանք այսպիսի տեսք ունեն.
Հարգելի Google Cloud օգտվող,
Որպես հիշեցում, մենք կդադարեցնենք [հիմնական ծառայությունը, որն օգտագործում եք] ծառայությունը 2020 թվականի օգոստոսից, որից հետո դուք չեք կարողանա թարմացնել ձեր օրինակները: Մենք խորհուրդ ենք տալիս թարմացնել վերջին տարբերակը, որը գտնվում է բետա թեստավորման փուլում, չունի փաստաթղթեր, չունի միգրացիոն ուղի և նախկինում հնացած է մեր բարի օգնությամբ:
Մենք պարտավորվում ենք ապահովել, որ այս փոփոխությունը նվազագույն ազդեցություն ունենա Google Cloud հարթակի բոլոր օգտատերերի վրա:
Ընդմիշտ լավագույն ընկերներ,
Google Cloud Platform
Բայց ես գրեթե երբեք չեմ կարդացել նման նամակներ, քանի որ իրականում ասում են.
Հարգելի Ստացող,
Գնա գրողի ծոցը. Քեզ, բա՛ց քեզ, բա՛ց քեզ: Բաց թողեք այն ամենը, ինչ անում եք, քանի որ դա նշանակություն չունի: Կարևորը մեր ժամանակն է։ Մենք ժամանակ և գումար ենք վատնում մեր խեղկատակությունը պահպանելու համար, և մենք հոգնել ենք դրանից, ուստի այլևս չենք աջակցի դրան: Ուրեմն, թողեք ձեր պիղծ ծրագրերը և սկսեք փորփրել մեր պիղծ փաստաթղթերը, մուրալ ֆորումներում գրություններ, և, ի դեպ, մեր նոր խայտառակությունը բոլորովին տարբերվում է հինից, որովհետև մենք այս դիզայնը շատ վատ ենք քանդել, հա, բայց դա ձերն է։ խնդիրը, ոչ թե մերը:
Մենք շարունակում ենք ջանքեր գործադրել, որպեսզի ձեր բոլոր մշակումները դառնան անօգտագործելի մեկ տարվա ընթացքում:
Խնդրում եմ, հեռացիր
Google Cloud Platform
Եվ փաստն այն է, որ նման նամակներ ստանում եմ ամիսը մեկ անգամ։ Դա տեղի է ունենում այնքան հաճախ և այնքան անընդհատ, որ նրանք անխուսափելիորեն հրել հեռու ինձ GCP-ից մինչև հակաամպային ճամբար: Ես այլևս համաձայն չեմ կախված լինել նրանց սեփականության զարգացումներից, քանի որ իրականում devops-ի համար ավելի հեշտ է բաց կոդով համակարգը բաց վիրտուալ մեքենայի վրա պահել, քան փորձել Google-ից հետ մնալ «հնացած» արտադրանքները փակելու իր քաղաքականությամբ:
Նախքան վերադառնալ Google Cloud, քանի որ ես նույնիսկ մոտ չէ չի ավարտվել նրանց քննադատելը, եկեք նայենք ընկերության գործունեությանը մի քանի այլ ոլորտներում: Google-ի ինժեներները հպարտանում են իրենց ծրագրային ապահովման ինժեներական կարգապահությամբ, և դա իրականում խնդիրներ է առաջացնում: Հպարտությունը ծուղակ է անզգույշների համար, և այն ստիպել է Google-ի շատ աշխատակիցների մտածել, որ իրենց որոշումները միշտ ճիշտ են, և որ ճիշտ լինելը (որոշ անորոշ որոշմամբ) ավելի կարևոր է, քան հաճախորդների մասին հոգալը:
Ես մի քանի պատահական օրինակներ կտամ Google-ից դուրս այլ խոշոր նախագծերից, բայց հուսով եմ, որ դուք կտեսնեք այս օրինաչափությունը ամենուր: Այն հետևյալն է. հետամնաց համատեղելիությունը համակարգերը կենդանի և արդիական է պահում տասնամյակների ընթացքում.
Հետընթաց համատեղելիությունը բոլոր հաջողակ համակարգերի նախագծման նպատակն է, որոնց համար նախատեսված են բացել օգտագործել, այսինքն՝ իրականացվել բաց կոդով և/կամ բաց ստանդարտներով։ Ինձ թվում է, որ ես չափազանց ակնհայտ բան եմ ասում, որ բոլորը նույնիսկ անհարմար են, բայց ոչ: Սա քաղաքական խնդիր է, ուստի օրինակներ են պետք։
Առաջին համակարգը, որը ես կընտրեմ, ամենահինն է՝ GNU Emacs-ը, որը մի տեսակ հիբրիդ է Windows Notepad-ի, OS միջուկի և Միջազգային տիեզերակայանի միջև: Դա մի փոքր դժվար է բացատրել, բայց մի խոսքով, Emacs-ը 1976 թվականին (այո, գրեթե կես դար առաջ) ստեղծված հարթակ է ծրագրավորման համար՝ ձեզ ավելի արդյունավետ դարձնելու, բայց դիմակավորված որպես տեքստային խմբագրիչ:
Ես օգտագործում եմ Emacs ամեն օր: Այո, ես նույնպես օգտագործում եմ IntelliJ-ն ամեն օր, այն ինքնին վերածվել է հզոր գործիքակազմի: Սակայն IntelliJ-ի համար ընդլայնումներ գրելը շատ ավելի հավակնոտ և բարդ խնդիր է, քան Emacs-ի համար ընդլայնումներ գրելը: Եվ ավելի կարևոր է, որ Emacs-ի համար գրված ամեն ինչ պահպանվում է ընդմիշտ.
Ես դեռ օգտագործում եմ այն ծրագրաշարը, որը գրել էի Emacs-ի համար դեռևս 1995 թվականին: Եվ ես վստահ եմ, որ ինչ-որ մեկը օգտագործում է Emacs-ի համար գրված մոդուլներ 80-ականների կեսերին, եթե ոչ ավելի վաղ: Նրանք կարող են ժամանակ առ ժամանակ պահանջել մի փոքր ճշգրտում, բայց դա իսկապես բավականին հազվադեպ է: Ես չգիտեմ որևէ բան, որ ես երբևէ գրել եմ Emacs-ի համար (և ես շատ եմ գրել), որը պահանջում է վերաճարտարապետություն:
Emacs-ն ունի ֆունկցիա, որը կոչվում է make-obsolete հնացած անձանց համար: Համակարգչային հիմնարար հասկացությունների Emacs տերմինաբանությունը (օրինակ, թե ինչ է «պատուհանը») հաճախ տարբերվում է ոլորտի կոնվենցիաներից, քանի որ Emacs-ը դրանք ներկայացրել է շատ վաղուց: Սա բնորոշ վտանգ է նրանց համար, ովքեր իրենց ժամանակից առաջ են անցել. ձեր բոլոր պայմանները սխալ են: Բայց Emacs-ը իսկապես ունի նսեմացման հայեցակարգ, որն իրենց ժարգոնում կոչվում է հնացում.
Բայց Emacs-ի աշխարհում, կարծես, այլ աշխատանքային սահմանում կա: Այլ հիմքում ընկած փիլիսոփայություն, եթե կուզեք:
Emacs-ի աշխարհում (և շատ այլ ոլորտներում, որոնց մենք կանդրադառնանք ստորև), API-ի հնացած կարգավիճակը հիմնականում նշանակում է. ցուցակն այստեղ: Բայց վերջիվերջո դա քո ընտրությունն է»:
Google-ի աշխարհում հնացած լինելը նշանակում է՝ «Մենք խախտում ենք ձեր հանդեպ ունեցած մեր պարտավորությունները»: Սա ճիշտ է։ Սա այն է, ինչ այն ըստ էության նշանակում է: Սա նշանակում է, որ նրանք կստիպեն ձեզ պարբերաբար ինչ-որ աշխատանք կատարել, գուցե շատ աշխատանք, որպես պատիժ նրանց հավատալու համար Մենք ունենք լավագույն ծրագրաշարը: Ամենաարագը! Դուք ամեն ինչ անում եք հրահանգների համաձայն, գործարկում եք ձեր հավելվածը կամ ծառայությունը, իսկ հետո բամ, մեկ-երկու տարի հետո այն կոտրվում է:
Ոնց որ օգտագործած մեքենա վաճառես, որը 1500 կմ անցնելուց հետո հաստատ կփչանա։
Սրանք «հնության» երկու բոլորովին տարբեր փիլիսոփայական սահմանումներ են։ Google-ի հոտի սահմանումը . Ես սրան չեմ հավատում փաստորեն պլանավորված հնացում նույն իմաստով, ինչ Apple-ը: Բայց Google-ը, անկասկած, ծրագրում է կոտրել ձեր ծրագրերը՝ շրջանաձև ճանապարհով: Ես դա գիտեմ, քանի որ այնտեղ աշխատել եմ որպես ծրագրային ապահովման ինժեներ ավելի քան 12 տարի: Նրանք ունեն անորոշ ներքին ուղեցույցներ, թե որքանով պետք է հետևել հետընթաց համատեղելիությանը, բայց ի վերջո դա կախված է յուրաքանչյուր առանձին թիմից կամ ծառայությունից: Չկան ձեռնարկությունների կամ ինժեներական մակարդակի առաջարկություններ, և հնացման ցիկլերի առումով ամենահամարձակ առաջարկությունն է՝ «փորձեք հաճախորդներին տալ 6-12 ամիս թարմացման համար՝ նախքան իրենց ամբողջ համակարգը կոտրելը»:
Խնդիրը շատ ավելի մեծ է, քան նրանք կարծում են, և այն կպահպանվի տարիներ շարունակ, քանի որ հաճախորդների խնամքը նրանց ԴՆԹ-ում չէ: Այս մասին ավելին ստորև:
Այս պահին ես պատրաստվում եմ համարձակ հայտարարություն անել, որ Emacs-ը մեծ չափով և նույնիսկ հաջողակ է հիմնականում քանի որ նրանք այդքան լուրջ են վերաբերվում հետընթաց համատեղելիությանը: Իրականում սա մեր հոդվածի թեզն է։ Հաջողակ, երկարակյաց բաց համակարգերն իրենց հաջողության համար պարտական են այն միկրոհամայնքներին, որոնք ապրել են իրենց շուրջը տասնամյակներ շարունակ: ընդարձակումներ/պլագիններ. Սա էկոհամակարգն է։ Ես արդեն խոսել եմ հարթակների բնույթի և դրանց կարևորության մասին, և ինչպես Google-ն իր ամբողջ կորպորատիվ պատմության ընթացքում երբեք չի հասկացել, թե ինչ է նշանակում ստեղծել հաջողակ բաց հարթակ Android-ից կամ Chrome-ից դուրս:
Իրականում, ես պետք է հակիրճ նշեմ Android-ը, քանի որ դուք հավանաբար մտածում եք դրա մասին:
Առաջին, Android-ը Google-ը չէ. Նրանք գրեթե ոչ մի ընդհանուր բան չունեն միմյանց հետ։ Android-ը մի ընկերություն է, որը գնվել է Google-ի կողմից 2005թ. հուլիսին, ընկերությանը թույլատրվել է աշխատել քիչ թե շատ ինքնավար և, փաստորեն, մնացել է հիմնականում անձեռնմխելի միջանկյալ տարիներին: Android-ը տխրահռչակ տեխնոլոգիական փաթեթ է և նույնքան տխրահռչակ փշոտ կազմակերպություն: Ինչպես Google-ի աշխատակիցներից մեկն ասաց, «Դուք պարզապես չեք կարող մուտք գործել Android»:
Նախորդ հոդվածում ես քննարկեցի, թե որքան վատ էին Android-ի որոշ վաղ դիզայնի որոշումներ: Դժբախտաբար, երբ ես գրեցի այդ հոդվածը, նրանք «ակնթարթային հավելվածներ» էին անվանում, որոնք այժմ (անակնկալ!) , և ես կարեկցում եմ, եթե դուք բավական հիմար էիք լսել Google-ին և ձեր բովանդակությունը տեղափոխել այս ակնթարթային հավելվածներ:
Բայց այստեղ կա մի տարբերություն, էական տարբերություն, այն է, որ Android-ի մարդիկ իսկապես հասկանում են, թե որքան կարևոր են հարթակները, նրանք փորձում են ամեն ինչ անել, որպեսզի հին Android հավելվածները աշխատեն: Իրականում, հետադարձ համատեղելիությունը պահպանելու նրանց ջանքերն այնքան ծայրահեղ են, որ նույնիսկ ես, մի քանի տարի առաջ Android-ի բաժանմունքում իմ կարճատև աշխատանքի ընթացքում, համոզեցի նրանց համոզել հրաժարվել հնագույն սարքերից և API-ներից մի քանիսի աջակցությունից (ես սխալվում էի: , ինչպես նախկինում և ներկայում շատ այլ բաներում: Ներողություն Android-ի տղաներ: Այժմ, երբ ես եղել եմ Ինդոնեզիայում, ես հասկանում եմ, թե ինչու են դրանք մեզ անհրաժեշտ):
Android-ի մարդիկ հետ են մղում համատեղելիությունը գրեթե աներևակայելի ծայրահեղությունների՝ կուտակելով հսկայական քանակությամբ ժառանգական տեխնիկական պարտք իրենց համակարգերում և գործիքների շղթաներում: Օ, աստված իմ, դուք պետք է տեսնեք որոշ խելահեղ բաներ, որոնք նրանք պետք է անեն իրենց կառուցման համակարգում, բոլորը համատեղելիության անվան տակ:
Դրա համար ես Android-ին շնորհում եմ բաղձալի «Դու Google-ը չես» մրցանակը: Նրանք իսկապես չեն ուզում դառնալ Google-ը, որը ոչ թե դիմացկուն հարթակներ ստեղծել, այլ Android գիտի գիտի, ինչպես դա անել: Եվ այսպես, Google-ը շատ խելացի է մի առումով. թույլ է տալիս մարդկանց անել ամեն ինչ իրենց ձևով Android-ում:
Այնուամենայնիվ, Android-ի համար ակնթարթային հավելվածները բավականին հիմար գաղափար էին: Իսկ գիտե՞ք ինչու։ Որովհետև պահանջում էին վերաշարադրեք և ձևավորեք ձեր դիմումը! Ոնց որ մարդիկ ուղղակի վերաշարադրեն երկու միլիոն դիմում։ Կարծում եմ, որ Instant Apps-ը Google-ի աշխատողի գաղափարն էր:
Բայց կա մի տարբերություն. Հետադարձ համատեղելիությունը բարձր գնով է: Android-ն ինքն է կրում այդ ծախսերի բեռը, մինչդեռ Google-ը պնդում է, որ այդ բեռը կրի դուք, վճարող հաճախորդ.
Դուք կարող եք տեսնել Android-ի հետամնաց համատեղելիության պարտավորությունը իր API-ներում: Երբ դուք ունեք չորս կամ հինգ տարբեր ենթահամակարգեր, որոնք բառացիորեն նույն բանն են անում, դա հաստատ նշան է, որ հիմքում կա հետընթաց համատեղելիության պարտավորություն: Ինչը հարթակների աշխարհում հոմանիշ է ձեր հաճախորդների և ձեր շուկայի հանդեպ նվիրվածության հետ:
Google-ի հիմնական խնդիրն այստեղ նրանց հպարտությունն է ինժեներական հիգիենայի համար: Նրանց դուր չի գալիս, երբ կան միևնույն բան անելու շատ տարբեր եղանակներ՝ հին, ոչ այնքան ցանկալի ձևերով, որոնք նստած են նոր, ավելի հմայիչ ձևերի կողքին: Այն մեծացնում է ուսուցման կորը համակարգում նորեկների համար, մեծացնում է ժառանգական API-ների պահպանման բեռը, դանդաղեցնում է նոր գործառույթների արագությունը, և հիմնական մեղքն այն է, որ դա գեղեցիկ չէ: Google-ը, ինչպես Լեդի Ասքոթը Թիմ Բարթոնի «Ալիսը հրաշքների աշխարհում» ֆիլմից.
Լեդի Ասկոտ.
- Ալիս, գիտե՞ս, թե ինչից եմ ես ամենից շատ վախենում:
- Արիստոկրատիայի անկո՞ւմը։
-Վախենում էի, որ կունենամ տգեղ թոռներ.
Գեղեցիկի և գործնականի միջև փոխզիջումը հասկանալու համար եկեք նայենք երրորդ հաջողված հարթակին (Emacs-ից և Android-ից հետո) և տեսնենք, թե ինչպես է այն աշխատում՝ հենց Java-ն:
Java-ն ունի շատ հնացած API-ներ: Անվանումը շատ տարածված է Java ծրագրավորողների շրջանում, նույնիսկ ավելի տարածված, քան ծրագրավորման լեզուների մեծ մասում: Ինքը՝ Java-ն՝ հիմնական լեզուն, և գրադարանները մշտապես հնազանդում են API-ները:
Բերենք հազարավոր օրինակներից միայն մեկը, համարվում է հնացած: Այն հնացել է 1.2 թվականի դեկտեմբերին Java 1998-ի թողարկումից հետո։ Արդեն 22 տարի է, ինչ այն հնացել է:
Բայց արտադրության մեջ իմ իրական կոդը դեռ սպանում է թելերը ամեն օր. Իսկապե՞ս կարծում եք, որ դա լավ է: Բացարձակապես! Նկատի ունեմ, իհարկե, եթե ես այսօր վերաշարադրեի կոդը, ես այն այլ կերպ կկիրառեի: Բայց իմ խաղի կոդը, որը երջանկացրել է հարյուր հազարավոր մարդկանց վերջին երկու տասնամյակների ընթացքում, գրված է չափազանց երկար կախված թելերը փակելու գործառույթով, և ես երբեք ստիպված չի եղել փոխել այն. Ես իմ համակարգը բոլորից լավ գիտեմ, ես դրա հետ աշխատելու տառացիորեն 25 տարվա փորձ ունեմ արտադրության մեջ, և կարող եմ վստահ ասել. անվնաս. Չարժե ժամանակ և ջանք ծախսել այս կոդը վերաշարադրելու համար, և շնորհակալություն Լարի Էլիսոնին (հավանաբար), որ Oracle-ը ինձ չստիպեց վերաշարադրել այն:
Oracle-ը հավանաբար հասկանում է նաև հարթակներ: Ով գիտի.
Ապացույցները կարելի է գտնել Java-ի հիմնական API-ներում, որոնք լի են հնության ալիքներով, ինչպես կիրճում գտնվող սառցադաշտի գծերը: Java Swing գրադարանում հեշտությամբ կարող եք գտնել ստեղնաշարի նավիգացիայի հինգ կամ վեց տարբեր կառավարիչներ (KeyboardFocusManager): Իրականում դժվար է գտնել Java API, որը հնացած չէ: Բայց նրանք դեռ աշխատում են: Կարծում եմ, որ Java-ի թիմը իսկապես կհեռացնի API-ն միայն այն դեպքում, եթե ինտերֆեյսը անվտանգության ակնհայտ խնդիր առաջացնի:
Ահա բանը, ժողովուրդ. Մենք՝ ծրագրակազմ մշակողներս, բոլորս շատ զբաղված ենք, և ծրագրային ապահովման յուրաքանչյուր ոլորտում մենք բախվում ենք մրցակցող այլընտրանքների հետ: Ցանկացած ժամանակ X լեզվով ծրագրավորողները դիտարկում են Y լեզուն որպես հնարավոր փոխարինող: Օ, դու ինձ չե՞ս հավատում: Ցանկանու՞մ եք այն անվանել Սվիֆթ: Ինչպես, բոլորը գաղթում են Swift, և ոչ ոք չի թողնում այն, այնպես չէ՞: Վայ, որքան քիչ գիտես: Ընկերությունները հաշվում են երկկողմանի բջջային ծրագրավորման թիմերի (iOS և Android) ծախսերը, և նրանք սկսում են հասկանալ, որ այդ միջպլատֆորմային զարգացման համակարգերը զվարճալի անուններով, ինչպիսիք են Flutter-ը և React Native-ը, իրականում աշխատում են և կարող են օգտագործվել՝ նվազեցնելու դրանց չափը: շարժական թիմերը երկու անգամ կամ, ընդհակառակը, նրանց երկու անգամ ավելի արդյունավետ դարձնել: Վտանգված է իրական փողեր: Այո՛, փոխզիջումներ կան, բայց, մյուս կողմից՝ փող։
Եկե՛ք հիպոթետիկորեն ենթադրենք, որ Apple-ը հիմարաբար նշան է վերցրել Գվիդո վան Ռոսումից և հայտարարել, որ Swift 6.0-ը հետընթաց անհամատեղելի է Swift 5.0-ի հետ, ինչպես Python 3-ն անհամատեղելի է Python 2-ի հետ:
Ես, հավանաբար, պատմել եմ այս պատմությունը մոտ տասը տարի առաջ, բայց մոտ տասնհինգ տարի առաջ ես Գուիդոյի հետ գնացի Օ'Ռեյլի Ֆու Քեմփ, նստեցի վրան Փոլ Գրեհեմի հետ և մի փունջ մեծ կրակոցներ: Մենք նստած էինք սաստիկ շոգի մեջ՝ սպասելով, որ Լարի Փեյջը դուրս թռչի իր անձնական ուղղաթիռով, մինչ Գուիդոն անօդաչու թռչում էր «Python 3000»-ի վրա, որը նա անվանեց այն տարիների թվով, որ բոլորը կպահանջվեին այնտեղ գաղթելու համար: Մենք անընդհատ հարցնում էինք, թե ինչու է խախտում համատեղելիությունը, և նա պատասխանեց. «Յունիկոդ»: Եվ մենք հարցրինք՝ եթե մենք ստիպված լինենք վերաշարադրել մեր կոդը, էլ ի՞նչ օգուտներ կտեսնենք։ Եվ նա պատասխանեց.
Եթե տեղադրեք Google Cloud Platform SDK («gcloud»), դուք կստանաք հետևյալ ծանուցումը.
Հարգելի Ստացող,
Ուզում ենք հիշեցնել, որ Python 2-ի աջակցությունը հնացել է, այնպես որ ջախջախեք ձեզ
… և այլն: Կյանքի շրջան.
Բայց հարցն այն է, որ յուրաքանչյուր մշակող ունի ընտրություն: Եվ եթե ստիպեք նրանց բավական հաճախ վերագրել կոդը, նրանք կարող են մտածել դրա մասին այլ տարբերակները. Նրանք ձեր պատանդը չեն, որքան էլ դուք ցանկանաք, որ նրանք լինեն: Նրանք ձեր հյուրերն են: Python-ը դեռևս շատ տարածված ծրագրավորման լեզու է, բայց անիծյալ, Python 3(000)-ն ինքնին այնպիսի խառնաշփոթ ստեղծեց իր համայնքներում և իր համայնքների օգտատերերի շրջանում, որ հետևանքները չեն պարզվել արդեն տասնհինգ տարի:
Քանի՞ Python ծրագիր է վերաշարադրվել Go-ում (կամ Ruby-ում կամ որևէ այլ այլընտրանքային տարբերակում) այս հետընթաց անհամատեղելիության պատճառով: Որքան նոր ծրագրակազմ է գրվել Python-ից բացի այլ բանում, չնայած դա կարող է լինել գրված է Python-ով, եթե Գվիդոն ամբողջ գյուղը չայրե՞ր։ Դժվար է ասել, բայց Python-ը ակնհայտորեն տուժել է: Դա հսկայական խառնաշփոթ է, և բոլորը պարտվում են:
Այսպիսով, ենթադրենք, որ Apple-ը հուշում է Guido-ից և խախտում է համատեղելիությունը: Ի՞նչ եք կարծում, ի՞նչ կլինի հետո։ Դե, միգուցե մշակողների 80-90%-ը հնարավորության դեպքում վերաշարադրի իր ծրագրաշարը: Այսինքն՝ օգտատերերի բազայի 10-20%-ն ավտոմատ կերպով անցնում է ինչ-որ մրցակցող լեզվի, ինչպիսին է Flutter-ը։
Դա արեք մի քանի անգամ, և դուք կկորցնեք ձեր օգտագործողների բազայի կեսը: Ինչպես սպորտում, այնպես էլ ծրագրավորման աշխարհում, ներկայիս ձևը նույնպես կարևոր է: ամեն ինչ. Յուրաքանչյուր ոք, ով հինգ տարում կկորցնի իր օգտատերերի կեսը, կհամարվի մեծ ճարպ կորցնող: Դուք պետք է թրենդային լինեք հարթակների աշխարհում: Բայց սա այն վայրն է, որտեղ ավելի հին տարբերակները չաջակցելը ձեզ ժամանակի ընթացքում կկործանի: Քանի որ ամեն անգամ, երբ դուք ազատվում եք որոշ ծրագրավորողներից, դուք (ա) կորցնում եք նրանց ընդմիշտ, քանի որ նրանք բարկանում են ձեզ վրա պայմանագիրը խախտելու համար, և (բ) տալիս եք դրանք ձեր մրցակիցներին:
Ճակատագրի հեգնանքով, ես նաև օգնեցի Google-ին դառնալ այնպիսի պրիմադոննա, որն անտեսում է հետընթաց համատեղելիությունը, երբ ես ստեղծեցի Grok-ը, աղբյուր կոդի վերլուծության և ըմբռնման համակարգ, որը հեշտացնում է ինքնին կոդը ավտոմատացնելն ու գործիքավորելը. նման է IDE-ին, բայց այստեղ ամպային ծառայությունը պահպանում է: Google-ի աղբյուրի կոդի բոլոր միլիարդավոր տողերի նյութականացված ներկայացումները տվյալների մեծ պահեստում:
Grok-ը Google-ի աշխատողներին տրամադրեց հզոր շրջանակ՝ ավտոմատացված վերամշակումներ կատարելու իրենց ամբողջ կոդերի բազայում (բառացիորեն ողջ Google-ում): Համակարգը հաշվարկում է ոչ միայն ձեր կախվածությունը (որից դուք կախված եք), այլ նաև իջնող (որոնք կախված են ձեզանից), այնպես որ, երբ փոխում եք API-ները, դուք գիտեք բոլորին, ում կոտրում եք: Այս կերպ, երբ փոփոխություններ եք կատարում, կարող եք ստուգել, որ ձեր API-ի յուրաքանչյուր սպառող թարմացվել է նոր տարբերակին, և իրականում, հաճախ իրենց գրած Rosie գործիքի միջոցով, կարող եք ամբողջությամբ ավտոմատացնել գործընթացը:
Սա թույլ է տալիս Google-ի կոդերի բազան ներսից գրեթե գերբնական մաքուր լինել, քանի որ այս ռոբոտ ծառայողները պտտվում են տան շուրջը և ավտոմատ կերպով մաքրում ամեն ինչ, եթե նրանք վերանվանեն SomeDespicablyLongFunctionName-ը SomeDespicablyLongMethodName, քանի որ ինչ-որ մեկը որոշել է, որ դա տգեղ թոռ է, և նրան պետք է քնեցնել:
Եվ անկեղծ ասած, այն բավականին լավ է աշխատում Google-ի համար... ներքին: Ես նկատի ունեմ, որ այո, Google-ի Go համայնքը լավ ծիծաղում է Google-ի Java համայնքի հետ՝ շարունակական վերամշակման իրենց սովորության պատճառով: Եթե ինչ-որ բան վերագործարկեք N անգամ, դա նշանակում է, որ դուք ոչ միայն պտտել եք այն N-1 անգամ, այլև որոշ ժամանակ անց պարզ է դառնում, որ դուք հավանաբար պտտել եք այն նաև n-րդ փորձի ժամանակ: Բայց, մեծ հաշվով, նրանք վեր են մնում այս աղմուկից և «մաքուր» են պահում ծածկագիրը։
Խնդիրը սկսվում է, երբ նրանք փորձում են այս վերաբերմունքը պարտադրել իրենց ամպային հաճախորդների և այլ API-ների օգտագործողների վրա:
Ես ձեզ մի փոքր ծանոթացրել եմ Emacs-ի, Android-ի և Java-ի հետ; եկեք նայենք վերջին հաջողակ երկարակյաց հարթակին՝ ինքնին համացանցին: Պատկերացնու՞մ եք, թե HTTP-ի քանի կրկնություններ է անցել 1995 թվականից ի վեր, երբ մենք օգտագործեցինք թարթող պիտակներ: և «Կառուցման փուլում» պատկերակները վեբ էջերում:
Բայց դա դեռ աշխատում է! Եվ այս էջերը դեռ աշխատում են: Այո, տղերք, բրաուզերներն աշխարհի չեմպիոններն են հետամնաց համատեղելիության մեջ: Chrome-ը Google-ի հազվագյուտ պլատֆորմի ևս մեկ օրինակ է, որի գլուխները ճիշտ են պտտվում, և ինչպես կարող էիք կռահել, Chrome-ն արդյունավետորեն գործում է որպես Google-ի մնացած ընկերություններից անջատված ավազի արկղով:
Ես նաև ուզում եմ շնորհակալություն հայտնել օպերացիոն համակարգերի մշակողների մեր ընկերներին՝ Windows-ին, Linux-ին, NOT APPLE FUCK YOU APPLE-ին, FreeBSD-ին և այլն, իրենց հաջողակ հարթակներում հետադարձ համատեղելիության նման հիանալի աշխատանք կատարելու համար (Apple-ը լավագույն դեպքում ստանում է C-ը The-ի միջոցով: բացասական կողմն այն է, որ նրանք անընդհատ կոտրում են ամեն ինչ առանց որևէ հիմնավոր պատճառի, բայց ինչ-որ կերպ համայնքը շրջանցում է ամեն ինչ, և OS X-ի բեռնարկղերը դեռևս ամբողջովին հնացած չեն...
Բայց սպասիր, դու ասում ես։ Արդյո՞ք մենք չենք համեմատում խնձորները նարնջի հետ՝ առանձին ծրագրային համակարգեր մեկ մեքենայի վրա, ինչպիսին է Emacs/JDK/Android/Chrome-ը ընդդեմ բազմասերվերային համակարգերի և API-ների, ինչպիսիք են ամպային ծառայությունները:
Դե, ես երեկ թվիթեցի այս մասին, բայց Լարի Ուոլի ոճով (Պերլ ծրագրավորման լեզվի ստեղծող - մոտ. per.) «ծծում/կանոններ» սկզբունքով փնտրեցի բառը. արգելված է Google-ի և Amazon-ի մշակողների կայքերում: Եվ չնայած AWS-ն ունի հարյուրավոր Google-ի ծրագրավորողների փաստաթղթերում մոտ յոթ անգամ ավելի հաճախ նշվում են ծառայությունների մատուցման ավելի շատ առաջարկներ, քան GCP-ն:
Եթե Google-ում որևէ մեկը կարդում է սա, նա հավանաբար պատրաստ է դուրս բերել Դոնալդ Թրամփի ոճի գծապատկերները, որոնք ցույց են տալիս, որ նրանք իրականում ամեն ինչ ճիշտ են անում, և որ ես չպետք է անարդար համեմատություններ կատարեմ, ինչպիսիք են «հնացած բառի հիշատակումների թիվը ընդդեմ ծառայությունների քանակը»
Բայց այսքան տարի անց Google Cloud-ը շարունակում է մնալ 3-րդ ծառայությունը (ես երբեք հոդված չեմ գրել թիվ 2 դառնալու անհաջող փորձի մասին), բայց եթե հավատալ ինսայդերներին, կան որոշ մտահոգություններ, որ նրանք շուտով կարող են հայտնվել: Թիվ 4.
Ես չունեմ ոչ մի համոզիչ փաստարկ՝ իմ թեզը «ապացուցելու»։ Այն ամենը, ինչ ես ունեմ, գունագեղ օրինակներ են, որոնք ես կուտակել եմ 30 տարվա ընթացքում որպես ծրագրավորող: Ես արդեն նշեցի այս խնդրի խորը փիլիսոփայական բնույթը. որոշ առումներով այն քաղաքականացված է կառուցապատող համայնքներում: Ոմանք կարծում են, որ ստեղծագործողներ հարթակները պետք է հոգ տանեն համատեղելիության մասին, մինչդեռ մյուսները կարծում են, որ դա մտահոգիչ է օգտվողները (իրենք մշակողները): Երկուսից մեկը։ Իսկապես, քաղաքական խնդիր չէ՞, երբ մենք որոշում ենք, թե ով պետք է կրի ընդհանուր խնդիրների ծախսերը։
Այսպիսով, սա քաղաքականություն է: Եվ իմ ելույթին հավանաբար զայրույթով արձագանքներ կլինեն։
Ինչպես օգտագործողը Google Cloud Platform-ը և որպես AWS օգտատեր երկու տարի (Գրաբում աշխատելիս), կարող եմ ասել, որ հսկայական տարբերություն կա 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-ի սխալը երբեք չի շտկվի: Ի՞նչ եզրակացություն կարելի է անել: Դուք կարող եք օգնություն ստանալ եթե աշխատում եք ընկերությունում. Ես, հավանաբար, միակն եմ, ով օգտագործում է Firebase-ը GAE-ում, քանի որ ես գրանցել եմ 100-ից քիչ բանալի 100% բնիկ հավելվածում, և այն դադարում է աշխատել ամեն երկու օրը մեկ՝ հայտնի սխալի պատճառով: Ինչ կարող եմ ասել, քան այն օգտագործել ձեր սեփական ռիսկով: Ես անցնում եմ Redis-ին:
Ես նաև տեսել եմ, որ AWS-ի որոշ ավելի փորձառու օգտատերեր ասում են, որ AWS-ը սովորաբար երբեք չի դադարում աջակցել որևէ ծառայությունների, և SimpleDB-ն հիանալի օրինակ է: Իմ ենթադրությունները, որ AWS-ը չունի աջակցության նույն ավարտը, ինչ Google-ը, կարծես թե արդարացված են:
Բացի այդ, ես նկատեցի, որ 20 օր առաջ Google App Engine-ի թիմը կոտրել է կարևոր Go գրադարանի հոսթինգը՝ անջատելով հիմնական Go մշակողներից մեկի GAE հավելվածը: Դա իսկապես հիմարություն էր:
Վերջապես, ես լսել եմ, որ Google-ի աշխատակիցներն արդեն քննարկում են այս հարցը և ընդհանուր առմամբ համաձայնում են ինձ հետ (սիրում եմ ձեզ, տղաներ): Բայց նրանք կարծես թե կարծում են, որ խնդիրն անլուծելի է, քանի որ Google-ի մշակույթը երբեք չի ունեցել ճիշտ խրախուսական կառուցվածք: Ես մտածեցի, որ լավ կլինի որոշ ժամանակ տրամադրել՝ քննարկելու այն բացարձակապես զարմանալի փորձը, որը ես ունեցել եմ Grab-ում աշխատելիս AWS ինժեներների հետ աշխատելիս: Մի օր ապագայում, հուսով եմ:
Եվ այո, 2005 թվականին նրանք ունեին տարբեր տեսակի շնաձկան միս թիվ 43 շենքի հսկա բուֆետում, և իմ սիրելին շնաձկան միսն էր: Այնուամենայնիվ, մինչև 2006 թվականը Լարին և Սերգեյը ազատվեցին բոլոր անառողջ նախուտեստներից: Այսպիսով, 2007 թվականին Bigtable-ի պատմության ընթացքում իսկապես շնաձկներ չկային, և ես խաբեցի ձեզ:
Երբ ես չորս տարի առաջ նայեցի cloud Bigtable-ին (տուր կամ վերցրու), հենց այստեղ էր արժեքը: Թվում է, թե հիմա մի փոքր նվազել է, բայց դա դեռ սարսափելի է դատարկ տվյալների պահեստի համար, հատկապես որ իմ առաջին պատմությունը ցույց է տալիս, թե որքան անհետևանք է դատարկ մեծ աղյուսակը իրենց մասշտաբով:
Կներեք Apple-ի համայնքին վիրավորելու և Microsoft-ի մասին ոչ մի լավ բան չասելու համար: Դուք ամեն ինչ կարգին եք, ես իսկապես գնահատում եմ այս հոդվածի ստեղծած բոլոր քննարկումները: Բայց երբեմն պետք է մի փոքր ալեկոծել՝ քննարկում սկսելու համար, գիտե՞ք:
Շնորհակալություն կարդալու համար:
Թարմացում 2, 19.08.2020/XNUMX/XNUMX: Շերտագիծ !
Թարմացում 3, 31.08.2020/2/2: Ինձ հետ կապվեց Google-ի մի ինժեներ Cloud Marketplace-ում, ով պարզվեց, որ իմ վաղեմի ընկերն է: Նա ուզում էր պարզել, թե ինչու չի աշխատում CXNUMXD-ը, և մենք ի վերջո պարզեցինք, որ դա այն պատճառով էր, որ ես ստեղծել եմ իմ ցանցը տարիներ առաջ, իսկ CXNUMXD-ը չէր աշխատում հին ցանցերի վրա, քանի որ ենթացանցային պարամետրը բացակայում էր նրանց կաղապարներում: Կարծում եմ՝ լավագույնն է GCP-ի պոտենցիալ օգտվողների համար, որպեսզի համոզվեն, որ Google-ում բավականաչափ ինժեներներ գիտեն...
Source: www.habr.com