Google қарғыс атсын, мен қайтадан блог жасағым келмеді. Менде көп нәрсе бар. Блог жазу уақытты, күш пен шығармашылықты қажет етеді, мен оны тиімді пайдалана аламын: менің кітаптарым, , менің ойыным және т.б. Бірақ сіз мені қатты ашуландырдыңыз, мен мұны жазуға мәжбүр болдым.
Ендеше осымен бітейік.
Google-де алғаш жұмыс істей бастаған кездегі қысқа, бірақ тағылымды әңгімеден бастайын. Мен соңғы уақытта Google туралы көп жаман сөздер айтқанымды білемін, бірақ менің жеке компаниям үнемі сауатсыз бизнес шешімдерін қабылдайтын кезде бұл мені ренжітеді. Сонымен қатар, біз оған лайықты бағасын беруіміз керек: Google-дың ішкі инфрақұрылымы шынымен де ерекше, бүгінгі күні бұдан жақсы ештеңе жоқ деп айтуға болады. Google негізін қалаушылар мен бұрын-соңды болмағаннан әлдеқайда жақсы инженерлер болды және бұл оқиға тек осы фактіні растайды.
Біріншіден, кішкене фон: Google-де деректерді сақтау технологиясы бар . Бұл тамаша техникалық жетістік, алғашқылардың бірі (бірінші болмаса) «шексіз масштабталатын» кілт-мәндер қоймасы (K/V): негізінен NoSQL-тің басы. Бұл күндері Bigtable әлі де толып жатқан K/V сақтау кеңістігінде жақсы жұмыс істейді, бірақ ол кезде (2005) ол таңқаларлық керемет болды.
Bigtable туралы бір күлкілі нәрсе, оларда үлкен индекстері бар планшет серверлері деп аталатын ішкі бақылау жазықтығы объектілері (іске асыру бөлігі ретінде) болды және олар жүйені масштабтау кезінде бір сәтте тығырыққа тіреледі. Bigtable инженерлері ауқымдылықты қалай жүзеге асыруға болатынын білмей жатып, кенеттен планшет серверлерін басқа Bigtable жадымен алмастыра алатынын түсінді. Сондықтан Bigtable Bigtable іске асыру бөлігі болып табылады. Бұл қоймалар барлық деңгейде бар.
Тағы бір қызық жайт, Bigtable біраз уақыт бойы Google ішінде танымал болды және әр команданың өз репозиторийі бар. Жұма күнгі кездесулердің бірінде Ларри Пейдж кездейсоқ: «Неге бізде бірнеше үлкен үстел бар? Неге бір ғана емес?» Теориялық тұрғыдан бір жад Google-дың барлық сақтау қажеттіліктеріне жеткілікті болуы керек. Әрине, олар ешқашан практикалық даму себептері бойынша (әлеуетті сәтсіздіктің салдары сияқты) тек біреуіне барған жоқ, бірақ теория қызықты болды. Бүкіл ғаламға арналған бір репозиторий (Айтпақшы, Amazon мұны өздерінің Sable-мен жасағанын біледі ме?)
Қалай болғанда да, міне менің оқиғам.
Ол кезде мен Google-да екі жылдан астам жұмыс істедім және бір күні маған Bigtable инженерлік командасынан келесідей болатын электрондық хат келді:
Құрметті Стив,
Bigtable командасынан сәлем. Сізге [деректер орталығының атауы] өте ескі Bigtable екілік файлын пайдаланып жатқаныңызды хабарлаймыз. Бұл нұсқаға енді қолдау көрсетілмейді және біз сізге соңғы нұсқаға жаңартуға көмектескіміз келеді.
Осы мәселе бойынша бірлесіп жұмыс істеуге уақыт бөлуге болатынын маған хабарлаңыз.
Барлық жақсылық,
Үлкен үстел командасы
Google-де сіз көп хат аласыз, сондықтан мен бір қарағанда мынаны оқыдым:
Құрметті алушы,
Бір командадан сәлем. Біз бұл бла-бла-бла-бла-бла туралы хабарлағымыз келеді. Бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла.
Қымбат уақытыңызды бля бла блаға жоспарлауға болатынын бізге хабарлаңыз.
Барлық жақсылық,
Қандай да бір бұйрық
Мен оны бірден жойып жібере жаздадым, бірақ санамның шетінде менде ауыр, ауыр сезім болды. шынымен де емес ресми хатқа ұқсайды анық, алушы қателесті, себебі мен Bigtable қолданбадым.
Бірақ бұл біртүрлі болды.
Мен күннің қалған бөлігін кезектесіп жұмыс туралы және шағын асүйде қандай акуланың етін жеу керектігі туралы ойладым, оның кем дегенде үшеуі бисквитті дұрыс лақтыру арқылы орнымнан тиіп кетуге жеткілікті болды, бірақ Жазу туралы ой мені ешқашан өсіп келе жатқан жұмсақ алаңдаушылық сезімімен қалдырмады.
Олар менің атымды анық айтты. Және электрондық пошта басқа біреудің емес, менің электрондық пошта мекенжайыма жіберілді және ол cc: немесе bcc: емес. Тон өте жеке және анық. Мүмкін бұл қандай да бір қателік шығар?
Ақырында, қызығушылығым басым болды және мен олар айтқан деректер орталығындағы Borg консолін қарауға бардым.
Әрине, менде BigTable қоймасы болды. Кешіріңіз, не? Мен оның мазмұнына қарадым, және уау! Бұл 2005 жылдың маусымында Google-дағы бірінші аптасында мен жұмыс істеген Codelab инкубаторынан болды. Codelab сізге кейбір мәндерді жазу үшін Bigtable бағдарламасын іске қосуға мәжбүр етті, мен одан кейін жадты ешқашан жаппаған сияқтымын. Арада екі жылдан астам уақыт өтсе де жұмыс істеп тұрды.
Бұл оқиғаның бірнеше назар аударарлық тұстары бар. Біріншіден, Bigtable жұмысы Google масштабында соншалықты елеусіз болды, тек екі жылдан кейін ешкім қосымша жадты байқады және тек екілік нұсқасы ескіргендіктен ғана. Салыстыру үшін мен бір рет пайдалануды қарастырдым менің онлайн ойыным үшін. Сол кезде бұл қызмет жылына шамамен $16 000 тұрады. бос GCP бойынша үлкен кесте. Мен сізді алдап жатыр деп айтпаймын, бірақ менің жеке пікірімше, бұл бос деректер базасы үшін көп ақша.
Тағы бір назар аударарлық аспект - сақтау екі жылдан кейін де жұмыс істейді. WTF? Деректер орталықтары келеді және кетеді; олар үзілістерге ұшырайды, олар жоспарлы жөндеуден өтеді, олар үнемі өзгереді. Аппараттық құралдар жаңартылды, қосқыштар ауыстырылады, бәрі үнемі жетілдірілуде. Қалайша олар менің бағдарламамды екі жыл бойы барлық осы өзгерістермен жұмыс істей алды? Бұл 2020 жылғы қарапайым жетістік сияқты көрінуі мүмкін, бірақ 2005-2007 жылдары бұл өте әсерлі болды.
Ең кереметі, басқа штаттағы сырттан инженерлік топ маған жақындайды, Bigtable бағдарламасының кішкентай, бос дерлік данасы иесі. нөлдік трафик соңғы екі жылда - және оны жаңартуға көмектесуде.
Мен оларға рахметімді айттым, қойманы өшірдім, өмір әдеттегідей өтті. Бірақ он үш жыл өтсе де, сол хатты әлі де ойлаймын. Өйткені кейде Google Cloud-тан ұқсас хаттар аламын. Олар келесідей көрінеді:
Құрметті Google Cloud пайдаланушысы,
Еске сала кетейік, біз [сіз пайдаланатын негізгі қызмет] қызметін 2020 жылдың тамызынан бастап тоқтатамыз, содан кейін даналарды жаңарта алмайсыз. Бета тестілеуде, құжаттамасы жоқ, тасымалдау жолы жоқ және біздің көмектің арқасында бұрын ескірген соңғы нұсқаға жаңартуды ұсынамыз.
Біз бұл өзгерістің Google Cloud платформасының барлық пайдаланушыларына ең аз әсер етуін қамтамасыз етуге міндеттенеміз.
Мәңгілік ең жақсы достар,
Google бұлттық платформасы
Бірақ мен мұндай хаттарды ешқашан оқымаймын, өйткені олар шын мәнінде былай дейді:
Құрметті алушы,
Тозаққа кет. Білесің бе, блять сені, блять сені. Барлығын тастаңыз, себебі бұл маңызды емес. Маңыздысы біздің уақытымыз. Біз ақымақтықты сақтау үшін уақыт пен ақшаны ысырап етеміз және біз одан шаршадық, сондықтан оны енді қолдамаймыз. Ендеше, өз жоспарларыңыздан бас тартыңыз және форумдардағы сынықтарды сұрап, біздің сұмдық құжаттамаларды қазып бастаңыз, және айтпақшы, біздің жаңа былғарымыз бұрынғы ақымақтан мүлдем өзгеше, өйткені біз бұл дизайнды өте нашар бұздық, хе, бірақ бұл сіздің мәселе біздің емес.
Біз сіздің барлық әзірлемелеріңіз бір жыл ішінде жарамсыз болып қалуы үшін күш салуды жалғастырамыз.
Өтінемін, кетіңіз
Google бұлттық платформасы
Ал шындығында, мұндай хаттар айына бір рет келеді. Бұл жиі және үнемі болып тұрады, олар сөзсіз итеріп жіберді Мен GCP-тен бұлтқа қарсы лагерьге. Мен енді олардың меншікті әзірлемелеріне тәуелді болуға келіспеймін, өйткені іс жүзінде әзірлеушілерге Google компаниясының «ескірген» өнімдерді жабу саясатын ұстануға тырысқаннан гөрі ашық бастапқы жүйені жалаң виртуалды машинада ұстау оңайырақ.
Мен Google Cloud қызметіне қайта оралмас бұрын, өйткені мен тіпті жақын емес оларды сынаған жоқпыз, компанияның кейбір басқа салалардағы көрсеткіштерін қарастырайық. Google инженерлері өздерінің бағдарламалық жасақтама инженериясы пәнімен мақтанады және бұл шын мәнінде проблемаларды тудырады. Тәкаппарлық – абайсыздардың тұзағы және бұл көптеген Google қызметкерлерін олардың шешімдері әрқашан дұрыс және дұрыс болу (кейбір анық емес анықтама бойынша) тұтынушыларға қамқорлық жасаудан маңыздырақ деп ойлауға итермеледі.
Мен Google-дан тыс басқа ірі жобалардан кездейсоқ мысалдар келтіремін, бірақ бұл үлгіні барлық жерде көресіз деп үміттенемін. Ол келесідей: кері үйлесімділік жүйелерді ондаған жылдар бойы тірі және жаңартылған күйде сақтайды.
Артқа үйлесімділік - бұл үшін әзірленген барлық сәтті жүйелердің жобалық мақсаты ашық пайдалану, яғни ашық бастапқы кодпен және/немесе ашық стандарттармен жүзеге асырылады. Мен тым айқын бірдеңені айтып тұрғандай сезінемін, бәрі тіпті ыңғайсыз, бірақ жоқ. Бұл саяси мәселе, сондықтан мысалдар қажет.
Мен таңдайтын бірінші жүйе - ең ескісі: GNU Emacs, ол Windows блокнот, ОЖ ядросы және Халықаралық ғарыш станциясы арасындағы гибридтің бір түрі болып табылады. Түсіндіру біршама қиын, бірақ қысқаша айтқанда, Emacs 1976 жылы (иә, жарты ғасырға жуық бұрын) сізді өнімдірек ету үшін бағдарламалауға арналған, бірақ мәтіндік редактор ретінде жасалған платформа.
Мен күн сайын Emacs қолданамын. Иә, мен IntelliJ-ті күнде қолданамын, ол өз алдына қуатты құрал платформасына айналды. Бірақ IntelliJ үшін кеңейтімдерді жазу Emacs кеңейтімдерін жазуға қарағанда әлдеқайда өршіл және күрделі тапсырма. Ең бастысы, Emacs үшін жазылғанның бәрі сақталады мәңгі.
Мен әлі күнге дейін 1995 жылы Emacs үшін жазған бағдарламалық құралды қолданамын. Біреу бұрын болмаса, 80-ші жылдардың ортасында Emacs үшін жазылған модульдерді пайдаланып жатқанына сенімдімін. Олар мезгіл-мезгіл аздап түзетуді қажет етуі мүмкін, бірақ бұл өте сирек. Мен Emacs үшін жазған кез келген нәрсені білмеймін (және мен көп жаздым), бұл қайта архитектураны қажет етеді.
Emacs-те ескірген нысандар үшін ескіру деп аталатын функция бар. Негізгі компьютерлік тұжырымдамаларға арналған 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 ауыртпалықты көтеруді талап етеді сіз болсаңыз, төлеуші клиент.
Сіз оның API интерфейстерінде Android жүйесінің кері үйлесімділікке деген міндеттемесін көре аласыз. Сізде бірдей нәрсені жасайтын төрт немесе бес түрлі ішкі жүйе болған кезде, бұл өзегінде кері үйлесімділікке деген міндеттеменің бар екендігінің сенімді белгісі. Платформалар әлемінде бұл сіздің тұтынушыларыңыз бен нарықтарыңызға адалдықпен синоним болып табылады.
Мұнда 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 ақымақтықпен Гвидо ван Россумнан үлгі алып, 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 компаниясы Гуидодан үлгі алып, үйлесімділікті бұзады делік. Бұдан әрі не болады деп ойлайсыз? Мүмкін, әзірлеушілердің 80-90% мүмкіндігінше бағдарламалық жасақтамасын қайта жазады. Басқаша айтқанда, пайдаланушы базасының 10-20% автоматты түрде Flutter сияқты бәсекелес тілге ауысады.
Мұны бірнеше рет жасаңыз, сонда сіз пайдаланушы базасының жартысын жоғалтасыз. Спорттағы сияқты, бағдарламалау әлемінде де қазіргі форма маңызды. барлығы. Бес жыл ішінде пайдаланушыларының жартысын жоғалтқан кез келген адам үлкен май жоғалтушы болып саналады. Сіз платформалар әлемінде сәнді болуыңыз керек. Бірақ бұл жерде ескі нұсқаларды қолдамау уақыт өте келе сізді бұзады. Өйткені кейбір әзірлеушілерден құтылған сайын, сіз оларды (а) олар сізге келісім-шартты бұзғаныңыз үшін ашуланғандықтан мәңгілікке жоғалтасыз және (б) оларды бәсекелестеріңізге бересіз.
Бір қызығы, мен Google-ға IDE-ге ұқсас кодтың өзін автоматтандыруды және өлшеуді жеңілдететін бастапқы кодты талдау және түсіну жүйесі Grok жасаған кезде кері үйлесімділікті елемейтін примадонна болуға көмектестім, бірақ бұл жерде бұлттық қызмет сақтайды. үлкен деректер қоймасындағы 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 ең жақсы жағдайда C дәрежесін алады. Кемшілігі - олар барлық уақытта ешбір себепсіз бұзады, бірақ әйтеуір қауымдастық оны әрбір шығарылыммен айналып өтеді, ал OS X контейнерлері әлі де толығымен ескірген емес...).
Бірақ күтіңіз, айтасыз. Біз алмаларды апельсиндермен - Emacs/JDK/Android/Chrome сияқты бір құрылғыдағы дербес бағдарламалық жүйелерді және бұлттық қызметтер сияқты көп серверлік жүйелерді және API интерфейстерін салыстырмаймыз ба?
Кеше мен бұл туралы твиттерде жаздым, бірақ Ларри Уоллдың стилінде (Perl бағдарламалау тілін жасаушы - шамамен пер.) мен «сорғыш/ережелер» принципі бойынша сөзді іздедім. ескірген 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 (қазір мүлдем басқа API бар Firestore), 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 жыл. Сіз әлі жеңіліп жатырсыз. Айнаға мұқият қарап, бұлтты бизнесте шынымен қалғыңыз келе ме деген сұраққа жауап беретін кез келді.
Қалғың келсе бәрін бұзуды доғар. Балалар, сендер байсыңдар. Біз әзірлеушілер жоқ. Сондықтан үйлесімділік ауыртпалығын кім көтеретіні туралы сөз болғанда, сіз оны өзіңізге алуыңыз керек. Біз үшін емес.
Өйткені кем дегенде тағы үш шынымен жақсы бұлт бар. Олар шақырады.
Енді мен барлық бұзылған жүйелерімді жөндеуге көшемін. Эх.
Келесіге дейін!
PS Осы мақаладағы кейбір талқылауларды оқығаннан кейін жаңарту (талқылаулар керемет, btw). Firebase қолдауы тоқтатылған жоқ және мен білетін жоспарлар жоқ. Дегенмен, оларда Java клиентінің App Engine жүйесінде тоқтап қалуына әкелетін жағымсыз ағындық қате бар. Олардың инженерлерінің бірі маған бұл мәселені шешуге көмектесті, мен Google-да жұмыс істеген кезде, бірақ олар ешқашан қатені түзетпеді, сондықтан менде GAE қолданбасын күн сайын қайта іске қосу керек болатын күрделі шешім бар. Міне, төрт жыл болды! Қазір оларда Firestore бар. Оған көшу үшін көп жұмыс қажет, өйткені бұл мүлдем басқа жүйе және Firebase қатесі ешқашан түзетілмейді. Қандай қорытынды жасауға болады? Сіз көмек ала аласыз егер сіз компанияда жұмыс істесеңіз. Мен GAE-де Firebase-ді қолданатын жалғыз адам шығармын, себебі мен 100% жергілікті қолданбада 100-ден аз кілтті тіркедім және ол белгілі қатеге байланысты әр екі күн сайын жұмысын тоқтатады. Мен оны өз тәуекеліңізбен пайдаланудан басқа не айта аламын. Мен Redis-ке ауысамын.
Мен сондай-ақ тәжірибелі AWS пайдаланушыларының AWS әдетте кез келген қызметтерге қолдау көрсетуді тоқтатпайтынын айтқанын көрдім және SimpleDB тамаша үлгі болып табылады. AWS-тің Google сияқты қолдау ауруының соңы жоқ деген болжамдарым ақталған сияқты.
Бұған қоса, мен 20 күн бұрын Google App Engine командасының Go негізгі әзірлеушілерінің бірінің GAE қолданбасын өшіріп, маңызды Go кітапханасының хостингін бұзғанын байқадым. Бұл шынымен ақымақ болды.
Ақырында, мен Google қызметкерлері бұл мәселені талқылап, менімен келісетінін естідім (сіздерді жақсы көремін!). Бірақ олар бұл мәселені шешу мүмкін емес деп санайды, өйткені Google мәдениетінде ешқашан дұрыс ынталандыру құрылымы болмаған. Мен Grab-те жұмыс істеген кезде AWS инженерлерімен жұмыс істеген керемет тәжірибені талқылауға біраз уақыт бөлгенім дұрыс деп ойладым. Бір күні болашақта, үміттенемін!
Иә, 2005 жылы оларда 43-ші ғимараттағы алып буфетте акула етінің әртүрлі түрлері болды, ал менің сүйіктісі балға басы акула еті болды. Дегенмен, 2006 жылға қарай Ларри мен Сергей барлық зиянды тағамдардан құтылды. Сонымен, 2007 жылы «Үлкен үстел» оқиғасы кезінде акулалар шынымен де болған жоқ, мен сізді алдадым.
Төрт жыл бұрын мен Bigtable бұлтына қарағанымда (беру немесе алу), мұнда құны болды. Бұл қазір аздап төмендеген сияқты, бірақ бұл бос деректер қоймасы үшін әлі де қорқынышты, әсіресе менің бірінші әңгімем олардың масштабында бос үлкен кестенің қаншалықты мәнсіз екенін көрсететіндіктен.
Apple қауымдастығын ренжіткенім және Microsoft және т.б. туралы жақсы ештеңе айтпағаным үшін кешірім сұраймыз. Сізде бәрі дұрыс, мен осы мақаланың барлық талқылауын өте бағалаймын! Бірақ кейде талқылауды бастау үшін аздап толқын жасау керек, білесіз бе?
Оқығаныңыз үшін рахмет.
Жаңарту 2, 19.08.2020. Жолақ !
Жаңарту 3, 31.08.2020. Маған Cloud Marketplace-тегі Google инженері хабарласты, ол менің ескі досым болып шықты. Ол C2D неліктен жұмыс істемейтінін білгісі келді, және ақырында, бұл менің желімді бірнеше жыл бұрын салғандықтан және C2D бұрынғы желілерде жұмыс істемейтінін түсіндік, себебі олардың үлгілерінде ішкі желі параметрі жоқ. Менің ойымша, әлеуетті GCP пайдаланушылары Google-де жеткілікті инженерлерді білетініне көз жеткізгені дұрыс...
Ақпарат көзі: www.habr.com