ძვირფასო Google Cloud, უკუთავსებადობა გკლავს.

ჯანდაბა გუგლი, ბლოგის გამეორება არ მინდოდა. იმდენი საქმე მაქვს. ბლოგინგს დრო, ენერგია და კრეატიულობა სჭირდება, რაც შემიძლია გამოვიყენო: ჩემი წიგნები, музыка, ჩემი თამაში და ასე შემდეგ. მაგრამ შენ საკმარისად გამაბრაზე, რომ ეს უნდა დავწერო.

ასე რომ, მოდით, ეს დავასრულოთ.

ნება მომეცით დავიწყოთ მოკლე, მაგრამ სასწავლო ისტორიით, როდესაც პირველად დავიწყე მუშაობა Google-ში. ვიცი, რომ ბოლო დროს ბევრ ცუდს ვამბობ Google-ზე, მაგრამ მაწუხებს, როდესაც ჩემი კომპანია რეგულარულად იღებს არაკომპეტენტურ ბიზნეს გადაწყვეტილებებს. ამავდროულად, ჩვენ უნდა მივცეთ მას თავისი დამსახურება: Google-ის შიდა ინფრასტრუქტურა მართლაც არაჩვეულებრივია, თამამად შეიძლება ითქვას, რომ დღეს უკეთესი არაფერია. Google-ის დამფუძნებლები ბევრად უკეთესი ინჟინრები იყვნენ, ვიდრე ოდესმე ვიქნები და ეს ამბავი მხოლოდ ამ ფაქტს ადასტურებს.

პირველი, მცირე ფონი: Google-ს აქვს მონაცემთა შენახვის ტექნოლოგია ე.წ დიდი მაგიდა. ეს იყო შესანიშნავი ტექნიკური მიღწევა, ერთ-ერთი პირველი (თუ არა პირველი) „უსასრულოდ მასშტაბირებადი“ გასაღების ღირებულების მაღაზია (K/V): არსებითად NoSQL-ის დასაწყისი. ამ დღეებში Bigtable კვლავ კარგად მუშაობს საკმაოდ ხალხმრავალ K/V საცავში, მაგრამ იმ დროს (2005) ის საოცრად მაგარი იყო.

Bigtable-ის ერთი სასაცილო რამ არის ის, რომ მათ ჰქონდათ შიდა კონტროლის თვითმფრინავის ობიექტები (როგორც განხორციელების ნაწილი), სახელწოდებით ტაბლეტის სერვერები, დიდი ინდექსებით, და რაღაც მომენტში ისინი გახდნენ ბოთლი სისტემის მასშტაბირებისას. Bigtable-ის ინჟინრები საგონებელში იყვნენ, როგორ განეხორციელებინათ მასშტაბურობა და უცებ მიხვდნენ, რომ მათ შეეძლოთ ტაბლეტის სერვერების შეცვლა სხვა Bigtable მეხსიერებით. ასე რომ, Bigtable არის Bigtable განხორციელების ნაწილი. ეს საცავი არის ყველა დონეზე.

კიდევ ერთი საინტერესო დეტალი არის ის, რომ გარკვეული პერიოდის განმავლობაში Bigtable გახდა პოპულარული და ყველგან გავრცელებული Google-ში, თითოეულ გუნდს ჰქონდა საკუთარი საცავი. ასე რომ, პარასკევის ერთ-ერთ შეხვედრაზე, ლარი პეიჯმა შემთხვევით ჰკითხა: „რატომ გვაქვს ერთზე მეტი Bigtable? რატომ არა მხოლოდ ერთი?” თეორიულად, ერთი საცავი საკმარისი უნდა იყოს Google-ის მეხსიერების ყველა საჭიროებისთვის. რა თქმა უნდა, ისინი არასოდეს მიდიოდნენ მხოლოდ ერთზე პრაქტიკული განვითარების მიზეზების გამო (როგორც პოტენციური წარუმატებლობის შედეგები), მაგრამ თეორია საინტერესო იყო. ერთი საცავი მთელი სამყაროსთვის (სხვათა შორის, ვინმემ იცის, გააკეთა თუ არა ამაზონმა ეს თავისი Sable-ით?)

ყოველ შემთხვევაში, აქ არის ჩემი ამბავი.

იმ დროს გუგლში სულ რაღაც ორ წელზე მეტი ხნის განმავლობაში ვმუშაობდი და ერთ დღეს მივიღე ელფოსტა Bigtable ინჟინერიის გუნდისგან, რომელიც ასე იყო:

ძვირფასო სტივ,

გამარჯობა Bigtable გუნდიდან. გვსურს გაცნობოთ, რომ [data center name]-ში იყენებთ ძალიან, ძალიან ძველ Bigtable ბინარს. ეს ვერსია აღარ არის მხარდაჭერილი და გვინდა დაგეხმაროთ უახლეს ვერსიაზე განახლებაში.

გთხოვთ, შემატყობინოთ, თუ შეგიძლიათ დანიშნოთ გარკვეული დრო ამ საკითხზე ერთად მუშაობისთვის.

Ყველაფერი საუკეთესო,
Bigtable გუნდი

Google-ში თქვენ იღებთ უამრავ წერილს, ასე რომ, ერთი შეხედვით წავიკითხე მსგავსი რამ:

ძვირფასო მიმღებ,

გამარჯობა რომელიმე გუნდიდან. ჩვენ გვინდა კომუნიკაცია, რომ ბლა ბლა ბლა ბლა ბლა. ბლა ბლა ბლა ბლა ბლა ბლა და ბლა ბლა ბლა მაშინვე.

გთხოვთ შეგვატყობინოთ, შეგიძლიათ თუ არა დაგეგმოთ თქვენი ძვირფასი დრო ბლა ბლა ბლასთვის.

Ყველაფერი საუკეთესო,
ერთგვარი ბრძანება

კინაღამ მაშინვე წავშალე, მაგრამ ცნობიერების ზღვარზე ვიგრძენი მტკივნეული, მტკივნეული შეგრძნება, რომ ის არა საკმაოდ თუმცა ფორმალურ წერილს ჰგავს აშკარად, რომ მიმღები შეცდა, რადგან მე არ გამოვიყენე Bigtable.

მაგრამ უცნაური იყო.

მთელი დღის განმავლობაში მონაცვლეობით ვფიქრობდი სამუშაოზე და იმაზე, თუ როგორი ზვიგენის ხორცი მესინჯა მიკრო-სამზარეულოში, რომელთაგან სამი მაინც საკმარისად ახლოს იყო, რომ ჩემი ადგილიდან ბისკვიტის კარგად გასროლით დამეჯახა, მაგრამ წერაზე ფიქრმა არასოდეს დამტოვა მზარდი ზომიერი შფოთვა.

მათ აშკარად თქვეს ჩემი სახელი. და ელ.წერილი გაიგზავნა ჩემს ელფოსტის მისამართზე და არა სხვისი, და ეს არ არის cc: ან bcc:. ტონი ძალიან პირადი და ნათელია. იქნებ ეს რაღაც შეცდომაა?

დაბოლოს, ცნობისმოყვარეობამ დამამარცხა და წავედი Borg-ის კონსოლის დასათვალიერებლად მათ მიერ ნახსენები მონაცემთა ცენტრში.

და რა თქმა უნდა, მე მქონდა BigTable საცავი მენეჯმენტის ქვეშ. Უკაცრავად, რა? შევხედე მის შინაარსს და ვაი! ეს იყო Codelab-ის ინკუბატორიდან, რომელშიც ვიჯექი Google-ში ჩემი პირველი კვირის განმავლობაში, 2005 წლის ივნისში. Codelab-მა გაიძულებდა გაუშვათ Bigtable, რომ დაგეწერათ გარკვეული მნიშვნელობები და, როგორც ჩანს, ამის შემდეგ მეხსიერება არ დავხურე. ის მაინც მუშაობდა, მიუხედავად იმისა, რომ ორ წელზე მეტი იყო გასული.

ამ ამბავს რამდენიმე საყურადღებო ასპექტი აქვს. ჯერ ერთი, Bigtable-ის მუშაობა იმდენად უმნიშვნელო იყო Google-ის მასშტაბით, რომ მხოლოდ ორი წლის შემდეგ ვინმემ შეამჩნია დამატებითი საცავი და მხოლოდ იმიტომ, რომ ბინარის ვერსია მოძველებული იყო. შედარებისთვის, ერთხელ განვიხილე გამოყენება Bigtable Google Cloud-ზე ჩემი ონლაინ თამაშისთვის. იმ დროს, ეს სერვისი წელიწადში დაახლოებით $16 ღირდა. ცარიელია Bigtable GCP-ზე. მე არ ვამბობ, რომ ისინი თაღლითობენ, მაგრამ ჩემი პირადი აზრით, ეს არის დიდი ფული ცარიელი მონაცემთა ბაზისთვის.

კიდევ ერთი საყურადღებო ასპექტი არის შენახვა ორი წლის შემდეგ ისევ მუშაობს. WTF? მონაცემთა ცენტრები მოდიან და მიდიან; განიცდიან გათიშვას, გადიან გეგმიურ მოვლა-პატრონობას, მუდმივად იცვლებიან. აპარატურა განახლებულია, კონცენტრატორები იცვლება, ყველაფერი მუდმივად იხვეწება. როგორ შეძლეს მათ ჩემი პროგრამის გაშვება ორი წლის განმავლობაში ყველა ამ ცვლილებებით? ეს შეიძლება მოკრძალებულ მიღწევად ჩანდეს 2020 წელს, მაგრამ 2005-2007 წლებში საკმაოდ შთამბეჭდავი იყო.

და ყველაზე მშვენიერი ასპექტი ის არის, რომ გარე საინჟინრო გუნდი სხვა შტატში მომიახლოვდება, Bigtable-ის რაღაც პატარა, თითქმის ცარიელი ინსტანციის მფლობელს, რომელსაც აქვს ნულოვანი მოძრაობა ბოლო ორი წლის განმავლობაში - და გვთავაზობენ დახმარებას მის განახლებაში.

მადლობა გადავუხადე, საცავი წავშალე და ცხოვრება ჩვეულებრივად გაგრძელდა. მაგრამ ცამეტი წლის შემდეგ ისევ იმ წერილზე ვფიქრობ. რადგან ზოგჯერ მე ვიღებ მსგავს წერილებს Google Cloud-დან. ისინი ასე გამოიყურებიან:

ძვირფასო Google Cloud მომხმარებელო,

შეგახსენებთ, 2020 წლის აგვისტოდან ჩვენ შევწყვეტთ სერვისს [არსებითი სერვისი, რომელსაც იყენებთ], რის შემდეგაც თქვენ ვერ შეძლებთ თქვენი ეგზემპლარების განახლებას. ჩვენ გირჩევთ განაახლოთ უახლეს ვერსიაზე, რომელიც არის ბეტა ტესტირებაში, არ აქვს დოკუმენტაცია, არ აქვს მიგრაციის გზა და ადრე მოძველებულია ჩვენი კეთილი დახმარებით.

ჩვენ მზად ვართ უზრუნველვყოთ, რომ ამ ცვლილებამ მინიმალური გავლენა მოახდინოს Google Cloud პლატფორმის ყველა მომხმარებელზე.

Საუკეთესო მეგობრები სამუდამოდ,
Google Cloud Platform

მაგრამ მე თითქმის არასოდეს წამიკითხავს ასეთი წერილები, რადგან ისინი სინამდვილეში ამბობენ:

ძვირფასო მიმღებ,

Ჯოჯოხეთში წადი. ჯანდაბა შენ, ჯანდაბა, გაგიჟდი. მიატოვეთ ყველაფერი, რასაც აკეთებთ, რადგან არ აქვს მნიშვნელობა. მთავარია ჩვენი დრო. ჩვენ ვკარგავთ დროსა და ფულს ჩვენი სისულელის შესანარჩუნებლად და დავიღალეთ ამით, ამიტომ მას აღარ დავუჭერთ მხარს. ასე რომ, თავი დაანებეთ თქვენს გეგმებს და დაიწყეთ ჩვენი უაზრო დოკუმენტაციის გათხრა, ფორუმებზე ნარჩენების მათხოვრობა, და სხვათა შორის, ჩვენი ახალი ნაგავი სრულიად განსხვავდება ძველი სისულელეებისგან, რადგან ჩვენ ეს დიზაინი ძალიან ცუდად გავაფუჭეთ, ჰეჰ, მაგრამ ეს თქვენია პრობლემა და არა ჩვენი.

ჩვენ ვაგრძელებთ ძალისხმევას იმისათვის, რომ თქვენი ყველა განვითარება გამოუსადეგარი გახდეს ერთი წლის განმავლობაში.

გთხოვ, გათავისუფლდი
Google Cloud Platform

და ფაქტია, რომ დაახლოებით თვეში ერთხელ ვიღებ ასეთ წერილებს. ეს ხდება ისე ხშირად და ისე მუდმივად, რომ ისინი გარდაუვალია მოშორდა მე GCP-დან ღრუბლის საწინააღმდეგო ბანაკამდე. მე აღარ ვეთანხმები მათ საკუთრების განვითარებაზე დამოკიდებულებას, რადგან რეალურად დევოპსებისთვის უფრო ადვილია შეინარჩუნოს ღია კოდის სისტემა შიშველ ვირტუალურ მანქანაზე, ვიდრე ეცადოს 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 კმ-ის შემდეგ.

ეს არის „მოძველების“ ორი სრულიად განსხვავებული ფილოსოფიური განმარტება. გუგლის სუნის განმარტება დაგეგმილი სიბერე. მე არ მჯერა ამის სინამდვილეში დაგეგმილი მოძველება იმავე გაგებით, როგორც Apple. მაგრამ Google ნამდვილად გეგმავს თქვენი პროგრამების დაშლას, შემოვლითი გზით. ეს ვიცი, რადგან 12 წელზე მეტი ხნის განმავლობაში ვმუშაობდი იქ პროგრამული უზრუნველყოფის ინჟინრად. მათ აქვთ ბუნდოვანი შიდა მითითებები იმის შესახებ, თუ რამდენად უნდა დაიცვან უკან თავსებადობა, მაგრამ ეს საბოლოოდ დამოკიდებულია თითოეულ ინდივიდუალურ გუნდზე ან სერვისზე. არ არსებობს საწარმოს ან საინჟინრო დონის რეკომენდაციები და ყველაზე თამამი რეკომენდაცია მოძველების ციკლების თვალსაზრისით არის „შეეცადეთ მისცეთ მომხმარებელს 6-12 თვე განახლებისთვის, სანამ მათ მთლიან სისტემას დაარღვევთ“.

პრობლემა გაცილებით დიდია, ვიდრე ფიქრობენ, და ის გაგრძელდება წლების განმავლობაში, რადგან მომხმარებელთა ზრუნვა მათ დნმ-ში არ არის. მეტი ამის შესახებ ქვემოთ.

ამ ეტაპზე მე ვაპირებ თამამად განვაცხადო, რომ Emacs წარმატებულია დიდწილად და თანაბრად ძირითადად რადგან ისინი ასე სერიოზულად უყურებენ უკან თავსებადობას. სინამდვილეში, ეს არის ჩვენი სტატიის თეზისი. წარმატებული, გრძელვადიანი ღია სისტემები თავის წარმატებას ევალება მიკროსაზოგადოებებს, რომლებიც მათ გარშემო ცხოვრობდნენ ათწლეულების განმავლობაში. გაფართოებები / დანამატები. ეს არის ეკოსისტემა. მე უკვე ვისაუბრე პლატფორმების ბუნებაზე და იმაზე, თუ რამდენად მნიშვნელოვანია ისინი, და როგორ Google-ს მთელი თავისი კორპორატიული ისტორიის მანძილზე არასოდეს ესმოდა, თუ რა მოჰყვება წარმატებული ღია პლატფორმის შექმნას Android-ის ან Chrome-ის გარეთ.

სინამდვილეში, მოკლედ უნდა აღვნიშნო ანდროიდი, რადგან თქვენ ალბათ ამაზე ფიქრობთ.

პირველ რიგში, Android არ არის Google. მათ ერთმანეთთან თითქმის არაფერი აქვთ საერთო. Android არის კომპანია, რომელიც Google-მა შეიძინა 2005 წლის ივლისში, კომპანიას მიეცა უფლება ემოქმედა მეტ-ნაკლებად ავტონომიურად და ფაქტობრივად, ძირითადად ხელუხლებელი დარჩა შუალედში. Android არის ყბადაღებული ტექნიკური დასტა და თანაბრად ყბადაღებული დახუნძლული ორგანიზაცია. როგორც Google-ის ერთ-ერთმა თანამშრომელმა თქვა, "თქვენ არ შეგიძლიათ უბრალოდ შეხვიდეთ Android-ში".

წინა სტატიაში მე განვიხილეთ, თუ რამდენად ცუდი იყო Android-ის ზოგიერთი ადრეული დიზაინის გადაწყვეტილება. ჯანდაბა, როდესაც მე დავწერე ეს სტატია, ისინი ავრცელებდნენ სისულელეს, სახელწოდებით "მყისიერი აპლიკაციები", რომლებიც ახლა (სიურპრიზი!) მოძველებულიდა თანავუგრძნობ, თუ საკმარისად სულელი იყავით, რომ მოუსმინოთ Google-ს და გადაიტანოთ თქვენი შინაარსი ამ მყისიერ აპებში.

მაგრამ აქ არის განსხვავება, მნიშვნელოვანი განსხვავება, რომელიც არის ის, რომ Android-ის ხალხს ნამდვილად ესმის, რამდენად მნიშვნელოვანია პლატფორმები, ისინი მაქსიმალურად ცდილობენ გააგრძელონ ძველი Android აპლიკაციები. სინამდვილეში, მათი მცდელობები, შეენარჩუნებინათ უკან თავსებადობა იმდენად ექსტრემალურია, რომ მეც კი, რამდენიმე წლის წინ ანდროიდის განყოფილებაში ჩემი ხანმოკლე მუშაობის დროს, აღმოვჩნდი, რომ ვცდილობდი დამერწმუნებინა, რომ უარი ეთქვათ ზოგიერთი უძველესი მოწყობილობისა და API-ის მხარდაჭერაზე (მე ვცდებოდი , როგორც ბევრი სხვა რამ იყო წარსულში და აწმყოში. ბოდიშს გიხდით Android ბიჭებო! ახლა, როცა ინდონეზიაში ვიყავი, მესმის, რატომ გვჭირდება ისინი).

Android-ის მომხმარებლები თავსებადობას უკუაგდებენ თითქმის წარმოუდგენელ უკიდურესობამდე, აგროვებენ დიდი რაოდენობით ძველი ტექნიკური დავალიანებას მათ სისტემებსა და ხელსაწყოების ჯაჭვებში. ღმერთო ჩემო, თქვენ უნდა ნახოთ რამდენიმე გიჟური რამ, რაც მათ უნდა გააკეთონ თავიანთ build სისტემაში, ეს ყველაფერი თავსებადობის სახელით.

ამისთვის მე ანდროიდს ვაძლევ სასურველ ჯილდოს "შენ არ ხარ Google". მათ ნამდვილად არ სურთ გახდნენ Google, რომელმაც არ იცის როგორ შექმნას გამძლე პლატფორმები, არამედ Android იცის, როგორ გავაკეთო ეს. ასე რომ, Google არის ძალიან ჭკვიანი ერთ მხრივ: საშუალებას აძლევს ხალხს გააკეთონ საქმეები საკუთარი გზით Android-ზე.

თუმცა, Android-ისთვის მყისიერი აპლიკაციები საკმაოდ სულელური იდეა იყო. და იცი რატომ? იმიტომ რომ მოითხოვეს გადაწერეთ და გადააკეთეთ თქვენი აპლიკაცია! თითქოს ხალხი უბრალოდ გადაწერს ორ მილიონ აპლიკაციას. ვფიქრობ, მყისიერი აპები Google-ის თანამშრომლის იდეა იყო.

მაგრამ არის განსხვავება. უკანა თავსებადობა მაღალი ფასით მოდის. Android-ს თავად ეკისრება ამ ხარჯების ტვირთი, ხოლო Google დაჟინებით მოითხოვს ტვირთის ატანას შენ ხარ, გადამხდელი კლიენტი.

თქვენ შეგიძლიათ ნახოთ Android-ის ვალდებულება უკუშეთავსებადობისადმი მის API-ებში. როდესაც თქვენ გაქვთ ოთხი ან ხუთი განსხვავებული ქვესისტემა, რომლებიც აკეთებენ ფაქტიურად ერთსა და იმავეს, ეს არის დარწმუნებული ნიშანი იმისა, რომ არსებობს ერთგულება უკუღმა თავსებადობაზე. რაც პლატფორმების სამყაროში არის თქვენი მომხმარებლებისა და თქვენი ბაზრისადმი ერთგულების სინონიმი.

Google-ის მთავარი პრობლემა აქ არის მათი სიამაყე საინჟინრო ჰიგიენით. მათ არ მოსწონთ, როდესაც ერთი და იგივე საქმის გაკეთების მრავალი განსხვავებული გზა არსებობს, ძველი, ნაკლებად სასურველი გზებით, რომლებიც ახალი, უფრო ლამაზი გზების გვერდით ზის. ის ზრდის სწავლის მრუდს მათთვის, ვინც ახალ სისტემაში მუშაობს, ზრდის მემკვიდრეობითი API-ების შენარჩუნების ტვირთს, ანელებს ახალი ფუნქციების სიჩქარეს და მთავარი ცოდვა ის არის, რომ ეს არ არის ლამაზი. Google - ისევე როგორც ლედი ასკოტი ტიმ ბარტონის ალისა საოცრებათა ქვეყანაში:

ლედი ასკოტი:
-ალისა, იცი ყველაზე მეტად რისი მეშინია?
- არისტოკრატიის დაცემა?
-მეშინოდა რომ მექნებოდა მახინჯი შვილიშვილები.

ლამაზსა და პრაქტიკულს შორის ურთიერთგაგების გასაგებად, მოდით გადავხედოთ მესამე წარმატებულ პლატფორმას (Emacs-ისა და Android-ის შემდეგ) და ვნახოთ, როგორ მუშაობს ის: თავად Java.

ჯავას აქვს ბევრი მოძველებული API. გაუქმება ძალიან პოპულარულია Java პროგრამისტებს შორის, უფრო პოპულარული, ვიდრე პროგრამირების ენების უმეტესობაში. თავად Java, ძირითადი ენა და ბიბლიოთეკები მუდმივად ამცირებენ API-ებს.

ათასობით მაგალითიდან მხოლოდ ერთი ავიღოთ, ძაფების დახურვა ითვლება მოძველებულად. ის მოძველებულია Java 1.2-ის გამოსვლის შემდეგ 1998 წლის დეკემბერში. 22 წელი გავიდა მას შემდეგ, რაც ეს უარყო.

მაგრამ ჩემი ნამდვილი კოდი წარმოებაში კვლავ კლავს ძაფებს ყოველ დღე. მართლა ფიქრობ რომ კარგია? აბსოლუტურად! ვგულისხმობ, რა თქმა უნდა, დღეს რომ გადამეწერა კოდი, სხვანაირად განვახორციელებდი. მაგრამ ჩემი თამაშის კოდი, რომელმაც გაახარა ასიათასობით ადამიანი ბოლო ორი ათწლეულის განმავლობაში, დაწერილია ფუნქციით დახუროს ძაფები, რომლებიც ძალიან გრძელია, და მე არასოდეს მოუწია მისი შეცვლა. მე ჩემს სისტემას ყველაზე უკეთ ვიცნობ, მაქვს ფაქტიურად 25 წლიანი გამოცდილება წარმოებაში და შემიძლია დანამდვილებით ვთქვა: ჩემს შემთხვევაში ამ კონკრეტული მუშა ძაფების დახურვა მთლიანად არის. უვნებელი. არ ღირს ამ კოდის გადასაწერად დრო და ძალისხმევა და მადლობა ლარი ელისონს (ალბათ), რომ Oracle-მა არ მაიძულა მისი გადაწერა.

Oracle-საც ესმის პლატფორმებიც. Ვინ იცის.

მტკიცებულება შეიძლება მოიძებნოს Java-ის ბირთვულ API-ებში, რომლებიც მოძველების ტალღებითაა გაჟღენთილი, როგორც კანიონში მყინვარის ხაზები. თქვენ შეგიძლიათ მარტივად იპოვოთ ხუთი ან ექვსი სხვადასხვა კლავიატურის ნავიგაციის მენეჯერი (KeyboardFocusManager) Java Swing ბიბლიოთეკაში. სინამდვილეში ძნელია იპოვოთ Java API, რომელიც არ არის მოძველებული. მაგრამ ისინი მაინც მუშაობენ! მე ვფიქრობ, რომ ჯავის გუნდი ნამდვილად ამოიღებს API-ს მხოლოდ იმ შემთხვევაში, თუ ინტერფეისი წარმოადგენს უსაფრთხოების აშკარა პრობლემას.

აი, ხალხნო: ჩვენ, პროგრამული უზრუნველყოფის შემქმნელები, ძალიან დაკავებულები ვართ და პროგრამული უზრუნველყოფის ყველა სფეროში, კონკურენტი ალტერნატივების წინაშე ვდგავართ. ნებისმიერ დროს, პროგრამისტები X ენაზე განიხილავენ Y ენას, როგორც შესაძლო შემცვლელს. ოჰ, არ გჯერა ჩემი? გინდა დავარქვათ სვიფტი? მაგალითად, ყველა მიგრირებს სვიფტში და არავინ ტოვებს მას, არა? ვაი, რა ცოტა იცი. კომპანიები ითვლიან ორმაგი მობილური დეველოპერების გუნდების ხარჯებს (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-ის მხარდაჭერა მოძველებულია, ასე რომ გაგიჟდით

… და ასე შემდეგ. Ცხოვრების წრე.

მაგრამ საქმე იმაშია, რომ ყველა დეველოპერს აქვს არჩევანი. და თუ აიძულებთ მათ საკმარისად ხშირად გადაწერონ კოდი, შეიძლება დაფიქრდნენ სხვა პარამეტრები. ისინი არ არიან თქვენი მძევლები, რამდენიც არ უნდა გინდოდეთ რომ იყვნენ. ისინი თქვენი სტუმრები არიან. პითონი ჯერ კიდევ ძალიან პოპულარული პროგრამირების ენაა, მაგრამ ჯანდაბა, პითონმა 3(000) თავისთავად ისეთი არეულობა შექმნა თავის თემებში და მისი თემების მომხმარებლებში, რომ შედეგები თხუთმეტი წლის განმავლობაში არ გაურკვეველია.

რამდენი პითონის პროგრამაა გადაწერილი Go-ში (ან Ruby, ან სხვა ალტერნატივაში) ამ უკანა შეუთავსებლობის გამო? რამდენი ახალი პროგრამა დაიწერა პითონის გარდა სხვა რამეში, თუმცა შეიძლება იყოს პითონში დაწერილი, გვიდოს მთელი სოფელი რომ არ დაეწვა? ძნელი სათქმელია, მაგრამ პითონი აშკარად დაზარალდა. დიდი არეულობაა და ყველა წააგებს.

მოდით ვთქვათ, Apple იღებს მინიშნებას Guido-სგან და არღვევს თავსებადობას. როგორ ფიქრობთ, რა მოხდება შემდეგ? კარგად, შესაძლოა დეველოპერების 80-90% გადაწერს თავის პროგრამულ უზრუნველყოფას, თუ ეს შესაძლებელია. სხვა სიტყვებით რომ ვთქვათ, მომხმარებლის ბაზის 10-20% ავტომატურად გადადის რომელიმე კონკურენტ ენაზე, როგორიცაა Flutter.

გააკეთეთ ეს რამდენჯერმე და დაკარგავთ მომხმარებლის ბაზის ნახევარს. ისევე, როგორც სპორტში, პროგრამირების სამყაროში, აქტუალური ფორმაც მნიშვნელოვანია. всё. ვინც ხუთ წელიწადში დაკარგავს მომხმარებელთა ნახევარს, ჩაითვლება დიდი მსუქანი დამარცხებულად. თქვენ უნდა იყოთ მოდური პლატფორმების სამყაროში. მაგრამ ეს ის ადგილია, სადაც ძველი ვერსიების მხარდაჭერა დროთა განმავლობაში გაანადგურებს. რადგან ყოველ ჯერზე, როცა ათავისუფლებთ ზოგიერთ დეველოპერს, თქვენ (ა) კარგავთ მათ სამუდამოდ, რადგან ისინი გაბრაზებულები არიან თქვენზე კონტრაქტის დარღვევისთვის და (ბ) აძლევთ მათ თქვენს კონკურენტებს.

ბედის ირონიით, მე ასევე დავეხმარე Google-ს გამხდარიყო ისეთი პრიმადონა, რომელიც უგულებელყოფს უკან თავსებადობას, როდესაც შევქმენი Grok, წყარო კოდის ანალიზისა და გაგების სისტემა, რომელიც აადვილებს თავად კოდის ავტომატიზაციას და ინსტრუმენტირებას - მსგავსია IDE, მაგრამ აქ ღრუბლოვანი სერვისი ინახავს Google-ის წყაროს კოდის ყველა მილიარდი ხაზის მატერიალიზებული წარმოდგენები მონაცემთა დიდ საწყობში.

Grok-მა Google-ის თანამშრომლებს მიაწოდა ძლიერი ჩარჩო ავტომატური რეფაქტორინგის შესასრულებლად მთელ მათ კოდურ ბაზაზე (სიტყვასიტყვით მთელ Google-ში). სისტემა ითვლის არა მხოლოდ თქვენს ზედა დინების დამოკიდებულებებს (რომელზეც თქვენ ხართ დამოკიდებული), არამედ ასევე დინების მიმართულებით (რაც თქვენზეა დამოკიდებული), ასე რომ, როდესაც ცვლით API-ებს, თქვენ იცით ყველას, ვისაც არღვევთ! ამ გზით, ცვლილებების შეტანისას, შეგიძლიათ დაადასტუროთ, რომ თქვენი API-ის ყველა მომხმარებელი განახლებულია ახალ ვერსიაზე და რეალურად, ხშირად მათ მიერ დაწერილი Rosie ინსტრუმენტით, შეგიძლიათ პროცესის სრული ავტომატიზაცია.

ეს საშუალებას აძლევს Google-ის კოდების ბაზას შინაგანად თითქმის ზებუნებრივად სუფთა იყოს, რადგან მათ ჰყავთ ეს რობოტი მსახურები, რომლებიც სახლში ტრიალებენ და ავტომატურად ასუფთავებენ ყველაფერს, თუ SomeDespicablyLongFunctionName-ს დაარქმევენ SomeDespicablyLongMethodName, რადგან ვიღაცამ გადაწყვიტა, რომ ეს მახინჯი შვილიშვილი იყო და მისი დაძინება უნდა.

და გულწრფელად რომ ვთქვათ, ის საკმაოდ კარგად მუშაობს Google-ისთვის... შიდა. მე ვგულისხმობ, დიახ, Go-ს საზოგადოება Google-ში კარგად იცინის ჯავის საზოგადოებასთან Google-ში მათი უწყვეტი რეფაქტორირების ჩვევის გამო. თუ რაიმეს N-ჯერ გადატვირთავთ, ეს ნიშნავს, რომ თქვენ არა მხოლოდ გააფუჭეთ ის N-1-ჯერ, არამედ გარკვეული პერიოდის შემდეგ საკმაოდ ცხადი ხდება, რომ თქვენ ალბათ გააფუჭეთ ის მე-XNUMX ცდაზეც. მაგრამ, ზოგადად, ისინი რჩებიან ამ აურზაურზე მაღლა და ინარჩუნებენ კოდს "სუფთა".

პრობლემა იწყება მაშინ, როდესაც ისინი ცდილობენ დააწესონ ეს დამოკიდებულება თავიანთ ღრუბლოვან კლიენტებსა და სხვა 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-ებთან, როგორიცაა ღრუბლოვანი სერვისები?

აჰა, გუშინ დავწერე ამის შესახებ, მაგრამ Larry Wall-ის სტილში (პროგრამის ენის შემქმნელი Perl - დაახლოებით პერ.) პრინციპით "sucks/rules" ვეძებე სიტყვა. უარყოფილია Google-ისა და Amazon-ის დეველოპერების საიტებზე. და მიუხედავად იმისა, რომ AWS-ს აქვს ასობით ჯერ მეტი სერვისის შეთავაზება, ვიდრე GCP, Google-ის დეველოპერის დოკუმენტაციაში დაახლოებით შვიდჯერ უფრო ხშირად მოიხსენიება გაუქმება.

თუ ვინმე Google-ში კითხულობს ამას, ისინი, ალბათ, მზად არიან ამოიღონ დონალდ ტრამპის სტილის ჩარტები, რომლებიც აჩვენებს, რომ ისინი რეალურად აკეთებენ ყველაფერს სწორად და რომ მე არ უნდა გავაკეთო უსამართლო შედარება, როგორიცაა "სიტყვის ხსენებების რაოდენობა მოძველებული და სერვისების რაოდენობა" "

მაგრამ ამდენი წლის შემდეგ, Google Cloud კვლავ არის მე-3 სერვისი (მე არასოდეს დამიწერია სტატია მე-2 ნომრად გახდომის წარუმატებელი მცდელობის შესახებ), მაგრამ თუ ინსაიდერებს დავუჯერებთ, არსებობს გარკვეული შეშფოთება, რომ ისინი შესაძლოა მალე გადავიდნენ. No4.

მე არ მაქვს რაიმე დამაჯერებელი არგუმენტი ჩემი თეზისის „დასამტკიცებლად“. ყველაფერი რაც მე მაქვს არის ფერადი მაგალითები, რომლებიც დამიგროვდა 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 წელია. შენ მაინც კარგავ. დროა ჩაიხედოთ სარკეში და უპასუხოთ, ნამდვილად გსურთ თუ არა ღრუბლოვანი ბიზნესში დარჩენა.

თუ გინდა დარჩე მაშინ შეწყვიტე ყველაფრის გატეხვა. ბიჭებო, თქვენ მდიდარი ხართ. ჩვენ დეველოპერები არა. ასე რომ, როდესაც საქმე ეხება თავსებადობის ტვირთს, თქვენ უნდა აიღოთ იგი საკუთარ თავზე. ჩვენთვის არა.

იმიტომ, რომ კიდევ სამი მართლაც კარგი ღრუბელია. ისინი უხმობენ.

ახლა კი გადავალ ჩემი ყველა გატეხილი სისტემის გამოსწორებაზე. ეჰ.

მომავალ ჯერამდე!

PS განახლება ამ სტატიის ზოგიერთი დისკუსიის წაკითხვის შემდეგ (დისკუსიები შესანიშნავია, btw). Firebase-ის მხარდაჭერა არ შეწყვეტილა და არ არსებობს რაიმე გეგმები, რომლებიც მე ვიცი. თუმცა, მათ აქვთ სტრიმინგის საშინელი შეცდომა, რომელიც იწვევს Java კლიენტის შეჩერებას App Engine-ში. მათი ერთ-ერთი ინჟინერი დამეხმარა ამ პრობლემის მოგვარებაში, როცა გუგლში ვმუშაობდი, მაგრამ მათ რეალურად არასოდეს გამოასწორეს ხარვეზი, ასე რომ, მე მაქვს უაზრო გამოსავალი, რომ GAE აპი ყოველდღე გადავტვირთო. და ასე იყო უკვე ოთხი წელი! ახლა მათ აქვთ Firestor. მასში მიგრაციას დიდი შრომა დასჭირდება, რადგან ეს სრულიად განსხვავებული სისტემაა და Firebase-ის შეცდომა არასოდეს გამოსწორდება. რა დასკვნის გაკეთება შეიძლება? შეგიძლიათ მიიღოთ დახმარება თუ თქვენ მუშაობთ კომპანიაში. მე ალბათ ერთადერთი ვიყენებ Firebase-ს GAE-ზე, რადგან 100%-ზე ნაკლებ კლავიშს ვწერ 100% მშობლიურ აპლიკაციაში და ის წყვეტს მუშაობას ყოველ რამდენიმე დღეში ცნობილი ხარვეზის გამო. რა შემიძლია ვთქვა გარდა იმისა, რომ გამოიყენო საკუთარი რისკის ქვეშ. რედისზე გადავდივარ.

მე ასევე მინახავს AWS-ის უფრო გამოცდილი მომხმარებლების თქმით, რომ AWS ჩვეულებრივ არასოდეს წყვეტს რაიმე სერვისის მხარდაჭერას და SimpleDB შესანიშნავი მაგალითია. ჩემი ვარაუდები, რომ AWS-ს არ აქვს იგივე მხარდაჭერის დაავადება, როგორც Google-ს, როგორც ჩანს, გამართლებულია.

გარდა ამისა, შევამჩნიე, რომ 20 დღის წინ Google App Engine-ის გუნდმა დაარღვია კრიტიკული Go ბიბლიოთეკის ჰოსტინგი, დახურა GAE აპლიკაცია Go-ს ერთ-ერთი ძირითადი დეველოპერისგან. მართლა სისულელე იყო.

და ბოლოს, გავიგე, რომ Google-ის თანამშრომლები უკვე განიხილავდნენ ამ საკითხს და ზოგადად დამეთანხმნენ (მიყვარხართ ბიჭებო!). მაგრამ, როგორც ჩანს, ისინი ფიქრობენ, რომ პრობლემა გადაუჭრელია, რადგან Google-ის კულტურას არასოდეს ჰქონია სწორი სტიმულირების სტრუქტურა. ვფიქრობდი, რომ კარგი იქნებოდა გარკვეული დრო დამეხარჯა იმ აბსოლუტურად საოცარი გამოცდილების განსახილველად, რომელიც მივიღე AWS ინჟინრებთან Grab-ში მუშაობის დროს. ოდესმე მომავალში, იმედი მაქვს!

დიახ, 2005 წელს მათ ჰქონდათ სხვადასხვა სახის ზვიგენის ხორცი გიგანტურ ბუფეტზე 43 კორპუსში და ჩემი ფავორიტი იყო ჩაქუჩის ზვიგენის ხორცი. თუმცა, 2006 წლისთვის ლარიმ და სერგეიმ მოიშორეს ყველა არაჯანსაღი საჭმელი. ასე რომ, 2007 წლის Bigtable-ის ისტორიის დროს, ზვიგენები ნამდვილად არ იყვნენ და მე მოგატყუეთ.

როდესაც ოთხი წლის წინ ვუყურებდი Cloud Bigtable-ს (მიეცით ან აიღეთ), აქ იყო ღირებულება. როგორც ჩანს, ახლა ცოტათი დაეცა, მაგრამ ეს ჯერ კიდევ საშინელებაა ცარიელი მონაცემთა საწყობისთვის, განსაკუთრებით მას შემდეგ, რაც ჩემი პირველი ამბავი აჩვენებს, თუ რამდენად არაეფექტურია ცარიელი დიდი მაგიდა მათი მასშტაბით.

ბოდიშს გიხდით Apple-ის საზოგადოების შეურაცხყოფისთვის და ვერაფერს ამბობთ სასიამოვნო Microsoft-ზე და ა.შ. კარგად ხართ, მე ნამდვილად ვაფასებ იმ დისკუსიას, რომელიც ამ სტატიამ გამოიწვია! მაგრამ ხანდახან დისკუსიის დასაწყებად ცოტა ტალღა გჭირდებათ, გესმით?

Მადლობა წაკითხვისთვის.

განახლება 2, 19.08.2020/XNUMX/XNUMX. ზოლი აახლებს API-ს სწორად!

განახლება 3, 31.08.2020/2/2. მე დამიკავშირდა Google-ის ინჟინერი Cloud Marketplace-ში, რომელიც აღმოჩნდა, რომ ჩემი ძველი მეგობარი იყო. მას სურდა გაერკვია, რატომ არ მუშაობდა CXNUMXD და ჩვენ საბოლოოდ გავარკვიეთ, რომ ეს იმიტომ, რომ მე ავაშენე ჩემი ქსელი წლების წინ, და CXNUMXD არ მუშაობდა ძველ ქსელებზე, რადგან ქვექსელის პარამეტრი არ იყო მათ შაბლონებში. ვფიქრობ, საუკეთესოა GCP პოტენციური მომხმარებლებისთვის, რომ დარწმუნდნენ, რომ მათ იციან საკმარისი ინჟინრები Google-ში...

წყარო: www.habr.com