Google Cloud היקר, לא תאימות לאחור הורגת אותך

לעזאזל גוגל, לא רציתי לכתוב שוב בבלוג. יש לי כל כך הרבה מה לעשות. בלוגים דורשים זמן, אנרגיה ויצירתיות, שאוכל להשתמש בהם היטב: הספרים שלי, музыка, המשחק שלי וכן הלאה. אבל עצבנת אותי מספיק כדי שאני אצטרך לכתוב את זה.

אז בואו נסיים עם זה.

הרשו לי להתחיל בסיפור קצר אך מלמד מהרגע בו התחלתי לעבוד בגוגל. אני יודע שאמרתי הרבה דברים רעים על גוגל לאחרונה, אבל זה מרגיז אותי כשהחברה שלי מקבלת באופן קבוע החלטות עסקיות לא מוכשרות. יחד עם זאת, עלינו לתת לזה את המגיע: התשתית הפנימית של גוגל היא באמת יוצאת דופן, אפשר לומר בבטחה שאין היום דבר טוב יותר. המייסדים של גוגל היו מהנדסים הרבה יותר טובים ממה שאני אי פעם אהיה, והסיפור הזה רק מאשר את העובדה הזו.

ראשית, קצת רקע: לגוגל יש טכנולוגיית אחסון נתונים בשם שולחן גדול. זה היה הישג טכני יוצא דופן, אחד מחנות המפתח-ערך (K/V) הראשונים (אם לא הראשונים) "הניתנים להרחבה": בעצם ההתחלה של NoSQL. בימים אלה Bigtable עדיין מצליחה בשטח האחסון הצפוף למדי של K/V, אבל בזמנו (2005) זה היה מגניב להפליא.

דבר אחד מצחיק ב-Bigtable הוא שהיו להם אובייקטי מטוס בקרה פנימיים (כחלק מהיישום) שנקראים שרתי טאבלטים, עם אינדקסים גדולים, ובשלב מסוים הם הפכו לצוואר בקבוק בעת קנה המידה של המערכת. מהנדסי Bigtable תמהו כיצד ליישם מדרגיות, ולפתע הבינו שהם יכולים להחליף שרתי טאבלט באחסון אחר של Bigtable. אז Bigtable הוא חלק מהיישום של Bigtable. מתקני האחסון הללו נמצאים בכל הרמות.

פרט מעניין נוסף הוא שבמשך זמן מה Bigtable הפך פופולרי ונמצא בכל מקום בגוגל, כאשר לכל צוות יש מאגר משלו. אז באחת מפגישות שישי, לארי פייג' שאל כבדרך אגב: "למה יש לנו יותר מביגטבל אחד? למה לא רק אחד?" בתיאוריה, אחסון אחד אמור להספיק לכל צורכי האחסון של גוגל. כמובן, הם מעולם לא הלכו רק לאחד מסיבות פיתוח מעשיות (כמו ההשלכות של כישלון פוטנציאלי), אבל התיאוריה הייתה מעניינת. מאגר אחד לכל היקום (אגב, מישהו יודע אם אמזון עשתה את זה עם ה-Sable שלהם?)

בכל מקרה, הנה הסיפור שלי.

באותו זמן, עבדתי בגוגל קצת יותר משנתיים, ויום אחד קיבלתי אימייל מצוות ההנדסה של Bigtable שנכתב בערך כך:

סטיב היקר,

שלום מצוות Bigtable. ברצוננו להודיע ​​לך שב[שם מרכז הנתונים] אתה משתמש בבינארי מאוד מאוד ישן של Bigtable. גרסה זו אינה נתמכת עוד ואנו רוצים לעזור לך לשדרג לגרסה העדכנית ביותר.

אנא הודע לי אם תוכל לקבוע זמן לעבודה משותפת בנושא זה.

כל טוב,
צוות Bigtable

בגוגל אתה מקבל הרבה דואר, אז במבט ראשון קראתי משהו כזה:

נמען יקר,

שלום מכמה צוות. אנחנו רוצים לתקשר את זה בלה בלה בלה בלה בלה. בלה בלה בלה בלה בלה בלה, ומיד בלה בלה בלה.

אנא הודע לנו אם אתה יכול לתזמן חלק מהזמן היקר שלך לבלה בלה בלה.

כל טוב,
סוג של פקודה

כמעט מחקתי את זה מיד, אבל בקצה ההכרה שלי הרגשתי תחושה כואבת ומציקה שזה לא ממש נראה כמו מכתב רשמי כמובן, שהנמען טעה כי לא השתמשתי ב-Bigtable.

אבל זה היה מוזר.

את שארית היום ביליתי בחשיבה לסירוגין על עבודה ואיזה סוג של בשר כריש לנסות במטבח המיקרו, שלפחות שלושה מהם היו קרובים מספיק כדי להכות מהמושב שלי בזריקה מכוונת היטב של ביסקוויט, אבל המחשבה על כתיבה מעולם לא הותירה אותי עם תחושת חרדה קלה הגוברת.

הם אמרו את שמי בבירור. והמייל נשלח לכתובת המייל שלי, לא של מישהו אחר, וזה לא CC: או Bcc:. הטון מאוד אישי וברור. אולי זו טעות כלשהי?

לבסוף, הסקרנות גברה עליי והלכתי להסתכל על קונסולת Borg במרכז הנתונים שהם הזכירו.

וכמובן, היה לי אחסון BigTable בניהול. סליחה מה? הסתכלתי על התוכן שלו, ואוו! זה היה מחממת Codelab שבה ישבתי במהלך השבוע הראשון שלי בגוגל ביוני 2005. Codelab אילץ אותך להפעיל את Bigtable כדי לכתוב שם כמה ערכים, וכנראה שמעולם לא סגרתי את האחסון לאחר מכן. זה עדיין עבד למרות שחלפו יותר משנתיים.

יש כמה היבטים ראויים לציון לסיפור הזה. ראשית, העבודה של Bigtable הייתה כל כך חסרת חשיבות בקנה המידה של גוגל, שרק שנתיים לאחר מכן מישהו שם לב לאחסון הנוסף, ורק בגלל שהגרסה של הבינארי הייתה מיושנת. לשם השוואה, שקלתי פעם להשתמש 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 למחנה נגד עננים. אני כבר לא מסכים להיות תלוי בפיתוחים הקנייניים שלהם, כי למעשה קל יותר ל-devops לתחזק מערכת קוד פתוח על מכונה וירטואלית חשופה מאשר לנסות לעמוד בקצב של גוגל במדיניות שלה לסגור מוצרים "מיושנים".

לפני שאני חוזר ל-Google Cloud כי אני אפילו קרוב לא סיימת לבקר אותם, בואו נסתכל על ביצועי החברה בכמה תחומים אחרים. מהנדסי גוגל מתגאים בדיסציפלינת הנדסת התוכנה שלהם, וזה מה שבעצם גורם לבעיות. גאווה היא מלכודת לחסרי זהירות, והיא גרמה לעובדים רבים בגוגל לחשוב שההחלטות שלהם תמיד נכונות ושנכון (לפי איזו הגדרה מעורפלת) חשובה יותר מאשר אכפתיות מלקוחות.

אני אתן כמה דוגמאות אקראיות מפרויקטים גדולים אחרים מחוץ לגוגל, אבל אני מקווה שתראה את הדפוס הזה בכל מקום. זה כדלקמן: תאימות לאחור שומרת על מערכות חיים ומעודכנות במשך עשרות שנים.

תאימות לאחור היא מטרת התכנון של כל המערכות המוצלחות המיועדות להן פתוח שימוש, כלומר מיושם עם קוד מקור פתוח ו/או סטנדרטים פתוחים. אני מרגיש שאני אומר משהו ברור מדי שכולם אפילו לא בנוח, אבל לא. זה נושא פוליטי, אז צריך דוגמאות.

המערכת הראשונה שאבחר היא הוותיקה ביותר: GNU Emacs, שהיא מעין הכלאה בין Windows Notepad, ליבת מערכת ההפעלה ותחנת החלל הבינלאומית. קצת קשה להסביר את זה, אבל בקצרה, Emacs היא פלטפורמה שנוצרה ב-1976 (כן, לפני כמעט חצי מאה) לתכנות כדי להפוך אותך ליותר פרודוקטיבי, אבל מתחזה לעורך טקסט.

אני משתמש ב-Emacs כל יום. כן, אני גם משתמש ב-IntelliJ כל יום, זה גדל לפלטפורמת כלים חזקה בפני עצמה. אבל כתיבת הרחבות עבור IntelliJ היא משימה הרבה יותר שאפתנית ומורכבת מכתיבת הרחבות עבור Emacs. וחשוב מכך, כל מה שנכתב עבור Emacs נשמר לנצח.

אני עדיין משתמש בתוכנה שכתבתי עבור Emacs ב-1995. ואני בטוח שמישהו משתמש במודולים שנכתבו עבור Emacs באמצע שנות ה-80, אם לא קודם לכן. הם עשויים לדרוש מעט התאמה מעת לעת, אבל זה באמת די נדיר. אני לא יודע על משהו שאי פעם כתבתי עבור Emacs (וכתבתי הרבה) שדרש ארכיטקטורה מחדש.

ל-Emacs יש פונקציה שנקראת make-obsolete עבור ישויות מיושנות. המינוח של Emacs למושגי מחשב בסיסיים (כגון מהו "חלון") שונה לעתים קרובות מהמוסכמות בתעשייה מכיוון ש-Emacs הציגה אותם לפני זמן רב. זוהי סכנה אופיינית למי שהקדים את זמנם: כל המונחים שלך אינם נכונים. אבל ל-Emacs יש מושג של ביטול, שבז'רגון שלהם נקרא הִתיַשְׁנוּת.

אבל נראה שבעולם ה-Emacs יש הגדרת עבודה אחרת. פילוסופיה בסיס שונה, אם תרצו.

בעולם ה-Emacs (ובתחומים רבים אחרים, עליהם נעסוק בהמשך), סטטוס API שהוצא משימוש פירושו בעצם: "אתה ממש לא צריך להשתמש בגישה הזו, כי בזמן שהיא עובדת, היא סובלת מחסרונות שונים שאנחנו רשימה כאן. אבל בסופו של יום, זו הבחירה שלך".

בעולמה של גוגל, להיות מיושן פירושו, "אנחנו מפרים את המחויבות שלנו כלפיך". זה נכון. זה מה שזה אומר בעצם. זה אומר שהם יכריחו אותך באופן קבוע לעשות קצת עבודה, אולי הרבה עבודה, כעונש על האמונה בהם פרסום צבעוני: יש לנו את התוכנה הטובה ביותר. הכי מהיר! אתה עושה הכל לפי ההוראות, מפעיל את האפליקציה או השירות שלך, ואז באם, אחרי שנה או שנתיים זה נשבר.

זה כמו למכור מכונית משומשת שבהחלט יתקלקל אחרי 1500 ק"מ.

אלו שתי הגדרות פילוסופיות שונות לחלוטין של "התיישנות". ההגדרה של גוגל לריח התיישנות מתוכננת. אני לא מאמין בזה למעשה התיישנות מתוכננת באותו מובן כמו אפל. אבל גוגל בהחלט מתכננת לשבור את התוכניות שלך, באופן עוקף. אני יודע את זה כי עבדתי שם כמהנדס תוכנה למעלה מ-12 שנים. יש להם הנחיות פנימיות מעורפלות לגבי מידת התאימות לאחור שיש לעקוב אחריהם, אבל בסופו של דבר זה תלוי בכל צוות או שירות בנפרד. אין המלצות ברמת הארגון או ההנדסה, וההמלצה הנועזת ביותר מבחינת מחזורי התיישנות היא "נסה לתת ללקוחות 6-12 חודשים לשדרג לפני ששברו את כל המערכת שלהם".

הבעיה היא הרבה יותר גדולה ממה שהם חושבים, והיא תימשך עוד שנים, כי הטיפול בלקוחות אינו ב-DNA שלהם. עוד על כך בהמשך.

בשלב זה אני הולך להצהיר אמירה נועזת ש-Emacs מצליחה במידה רבה ואפילו ביסודו של דבר כי הם לוקחים תאימות לאחור כל כך ברצינות. למעשה, זו התזה של המאמר שלנו. מערכות פתוחות מצליחות וארוכות-חיים חייבות את הצלחתן למיקרו-קהילות שחיות סביבן במשך עשרות שנים תוספים/תוספים. זו המערכת האקולוגית. כבר דיברתי על מהותן של פלטפורמות ועד כמה הן חשובות, וכיצד גוגל מעולם לא הבינה בכל ההיסטוריה הארגונית שלה מה נכנס ליצירת פלטפורמה פתוחה מוצלחת מחוץ לאנדרואיד או כרום.

למעשה, אני צריך להזכיר בקצרה את אנדרואיד כי אתה כנראה חושב על זה.

ראשית, אנדרואיד זה לא גוגל. אין להם כמעט שום דבר במשותף אחד עם השני. אנדרואיד היא חברה שנרכשה על ידי גוגל ביולי 2005, החברה הורשה לפעול פחות או יותר אוטונומית ולמעשה נותרה ללא פגע בשנים שחלפו. אנדרואיד היא ערימת טכנולוגיה ידועה לשמצה וארגון עוקצני לא פחות. כפי שהגדיר זאת אחד מהגוגלים, "אי אפשר פשוט להיכנס לאנדרואיד."

במאמר קודם, דיברתי על כמה גרועות היו חלק מהחלטות העיצוב המוקדמות של אנדרואיד. לעזאזל, כשכתבתי את המאמר הזה הם פרסמו שטויות שנקראות "אפליקציות מיידיות" שהן עכשיו (הפתעה!) מְיוּשָׁן, ואני מזדהה אם היית מספיק טיפש להקשיב לגוגל ולהעביר את התוכן שלך לאפליקציות המיידיות האלה.

אבל יש כאן הבדל, הבדל משמעותי, שהוא שאנשי האנדרואיד באמת מבינים כמה חשובות הפלטפורמות, הם מנסים כמיטב יכולתם לשמור על אפליקציות אנדרואיד ישנות לעבוד. למעשה, המאמצים שלהם לשמור על תאימות לאחור הם כל כך קיצוניים שאפילו אני, במהלך הפעילות הקצרה שלי בחטיבת אנדרואיד לפני כמה שנים, מצאתי את עצמי מנסה לשכנע אותם לבטל את התמיכה בכמה מהמכשירים והממשקי API הישנים ביותר (טעיתי , כפי שהיה בהרבה דברים אחרים בעבר ובהווה. סליחה חבר'ה אנדרואיד! עכשיו, כשהייתי באינדונזיה, אני מבין למה אנחנו צריכים אותם).

אנשי אנדרואיד דוחפים את התאימות לאחור לקיצוניות כמעט בלתי נתפסת, ומגבירים כמויות אדירות של חובות טכניים מדור קודם במערכות ובשרשרת הכלים שלהם. הו אלוהים, אתה צריך לראות כמה מהדברים המטורפים שהם צריכים לעשות במערכת הבנייה שלהם, הכל בשם התאימות.

על כך אני מעניק לאנדרואיד את פרס "אתה לא גוגל" הנחשק. הם ממש לא רוצים להפוך לגוגל, שלא יודעת ליצור פלטפורמות עמידות, אלא אנדרואיד יודע, איך לעשות את זה. ולכן גוגל מאוד חכמה מבחינה אחת: מאפשרת לאנשים לעשות דברים בדרך שלהם באנדרואיד.

עם זאת, אפליקציות אינסטנט לאנדרואיד היו רעיון די טיפשי. ואתה יודע למה? כי הם דרשו לשכתב ולעצב מחדש את האפליקציה שלך! זה כאילו אנשים פשוט ישכתבו שני מיליון אפליקציות. אני מנחש שאפליקציות אינסטנט היו רעיון של איזה גוגלר.

אבל יש הבדל. תאימות לאחור גובה מחיר גבוה. אנדרואיד עצמה נושאת בנטל העלויות הללו, בעוד שגוגל מתעקשת שהנטל יישא אתה, לקוח משלם.

אתה יכול לראות את המחויבות של אנדרואיד לתאימות לאחור בממשקי ה-API שלה. כאשר יש לך ארבע או חמש תת-מערכות שונות שעושות ממש את אותו הדבר, זה סימן בטוח שיש מחויבות לתאימות לאחור בליבה. מה שבעולם הפלטפורמות הוא שם נרדף למחויבות ללקוחות שלך ולשוק שלך.

הבעיה העיקרית של גוגל כאן היא הגאווה שלהם בהיגיינה ההנדסית שלהם. הם לא אוהבים כשיש דרכים רבות ושונות לעשות את אותו הדבר, כשהדרכים הישנות והפחות נחשקות יושבות לצד הדרכים החדשות והמהודרות יותר. זה מגדיל את עקומת הלמידה עבור אלה החדשים במערכת, זה מגדיל את הנטל של תחזוקת ממשקי API מדור קודם, זה מאט את המהירות של תכונות חדשות, והחטא המרכזי הוא שזה לא יפה. גוגל - כמו ליידי אסקוט מ"אליס בארץ הפלאות" של טים ברטון:

ליידי אסקוט:
אליס, את יודעת ממה אני הכי מפחדת?
- דעיכת האצולה?
– פחדתי שאהיה נכדים מכוערים.

כדי להבין את ההחלפה בין יפה לפרקטית, בואו נסתכל על הפלטפורמה המוצלחת השלישית (אחרי Emacs ואנדרואיד) ונראה איך היא עובדת: Java עצמה.

ל-Java יש הרבה ממשקי API מיושנים. הוצאה משימוש פופולרי מאוד בקרב מתכנתי Java, אפילו יותר פופולרי מאשר ברוב שפות התכנות. Java עצמה, שפת הליבה והספריות מוציאות כל הזמן ממשקי API.

כדי לקחת רק אחת מאלפי דוגמאות, סגירת חוטים נחשב מיושן. זה הוצא משימוש מאז שחרורו של Java 1.2 בדצמבר 1998. עברו 22 שנים מאז זה הוצא משימוש.

אבל הקוד בפועל שלי בייצור עדיין הורג שרשורים כל יום. אתה באמת חושב שזה טוב? בהחלט! זאת אומרת, כמובן, אם הייתי משכתב את הקוד היום, הייתי מיישם אותו אחרת. אבל הקוד למשחק שלי, ששימח מאות אלפי אנשים בשני העשורים האחרונים, נכתב עם פונקציה לסגור שרשורים שתלויים יותר מדי זמן, ואני מעולם לא היה צריך לשנות את זה. אני מכיר את המערכת שלי יותר טוב מכולם, יש לי ממש 25 שנות ניסיון בעבודה איתה בייצור, ואני יכול לומר בוודאות: במקרה שלי, סגירת שרשורי עובדים ספציפיים אלה היא לחלוטין לֹא מַזִיק. לא שווה את הזמן והמאמץ לשכתב את הקוד הזה, ותודה ללארי אליסון (כנראה) שאורקל לא הכריחה אותי לשכתב אותו.

אורקל כנראה מבינה גם בפלטפורמות. מי יודע.

ניתן למצוא עדויות בכל הליבה של ממשקי ה-API של Java, הזרועים גלים של התיישנות, כמו קווים של קרחון בקניון. אתה יכול למצוא בקלות חמישה או שישה מנהלי ניווט שונים במקלדת (KeyboardFocusManager) בספריית Java Swing. למעשה קשה למצוא Java API שלא הוצא משימוש. אבל הם עדיין עובדים! אני חושב שצוות Java יסיר באמת API רק אם הממשק מהווה בעיית אבטחה בולטת.

הנה העניין, אנשים: כולנו מפתחי התוכנה עסוקים מאוד, ובכל תחום של תוכנה אנו עומדים בפני אלטרנטיבות מתחרות. בכל זמן נתון, מתכנתים בשפה X שוקלים את שפה Y כתחליף אפשרי. אה, אתה לא מאמין לי? אתה רוצה לקרוא לזה סוויפט? כאילו, כולם מהגרים לסוויפט ואף אחד לא נוטש את זה, נכון? וואו, כמה מעט אתה יודע. חברות סופרות את העלויות של צוותי פיתוח ניידים כפולים (iOS ואנדרואיד) - והן מתחילות להבין שאותן מערכות פיתוח חוצות-פלטפורמות עם שמות מצחיקים כמו Flutter ו-React Native אכן עובדות וניתן להשתמש בהן כדי להקטין את גודלן. צוותים ניידים פעמיים או להיפך, להפוך אותם לפרודוקטיביים פי שניים. יש כסף אמיתי על כף המאזניים. כן, יש פשרות, אבל, מצד שני, כסף.

הבה נניח באופן היפותטי שאפל לקחה רמז מגידו ואן רוסום בטיפשות והכריזה ש- Swift 6.0 אינו תואם לאחור עם Swift 5.0, בדומה ל- Python 3 אינו תואם לפייתון 2.

סביר להניח שסיפרתי את הסיפור הזה לפני כעשר שנים, אבל לפני כחמש עשרה שנה הלכתי למחנה פו של אוריילי עם גווידו, ישבתי באוהל עם פול גרהם וחבורה של שחקנים גדולים. ישבנו בחום הלוהט וחיכינו שלארי פייג' יעוף החוצה במסוק האישי שלו בזמן שגוידו רחף על "פייתון 3000", שהוא קרא לו על שם מספר השנים שייקח עד שכולם יעברו לשם. כל הזמן שאלנו אותו למה הוא שובר את התאימות, והוא ענה: "יוניקוד". ושאלנו, אם נצטרך לשכתב את הקוד שלנו, אילו יתרונות נוספים היינו רואים? והוא ענה "יווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווווו dat dat datär dat)

אם תתקין את Google Cloud Platform SDK ("gcloud"), תקבל את ההודעה הבאה:

נמען יקר,

ברצוננו להזכיר לכם שהתמיכה ב-Python 2 הוצאה משימוש, אז תזדיין

… וכולי. מעגל החיים.

אבל הנקודה היא שלכל מפתח יש בחירה. ואם תכריח אותם לשכתב את הקוד לעתים קרובות מספיק, הם עשויים לחשוב על זה אחרים אפשרויות. הם לא בני הערובה שלך, לא משנה כמה תרצה שהם יהיו. הם האורחים שלך. Python היא עדיין שפת תכנות מאוד פופולרית, אבל לעזאזל, Python 3(000) יצרה בלאגן כזה בעצמו, בקהילות שלה ובקרב המשתמשים בקהילות שלה, שההשלכות לא התבהרו כבר חמש עשרה שנה.

כמה תוכניות Python נכתבו מחדש ב-Go (או Ruby או חלופה אחרת) בגלל חוסר ההתאמה לאחור? כמה תוכנה חדשה נכתבה במשהו אחר מלבד Python, למרות שזה יכול להיות כתוב בפייתון, אם גוידו לא היה שרף את כל הכפר? קשה לומר, אבל ברור שפייטון סבל. זה בלאגן ענק וכולם מפסידים.

אז נניח שאפל לוקחת רמז מגאידו ושוברת את התאימות. מה לדעתך יקרה בהמשך? ובכן, אולי 80-90% מהמפתחים ישכתבו מחדש את התוכנה שלהם אם אפשר. במילים אחרות, 10-20% מבסיס המשתמשים עוברים אוטומטית לשפה מתחרה כלשהי, כמו Flutter.

עשה זאת מספר פעמים ותאבד מחצית מבסיס המשתמשים שלך. בדיוק כמו בספורט, בעולם התכנות, גם הצורה הנוכחית חשובה. всё. כל מי שמאבד מחצית מהמשתמשים שלו בחמש שנים ייחשב ל-Big Fat Loser. אתה חייב להיות טרנדי בעולם הפלטפורמות. אבל זה המקום שבו אי תמיכה בגרסאות ישנות יותר יהרוס לך עם הזמן. כי בכל פעם שאתה נפטר מכמה מפתחים, אתה (א) מאבד אותם לנצח כי הם כועסים עליך על הפרת החוזה, ו-(ב) מוסר אותם למתחרים שלך.

למרבה האירוניה, גם עזרתי לגוגל להפוך לפרימדונה כזו שמתעלמת מתאימות לאחור כשיצרתי את Grok, מערכת ניתוח והבנת קוד מקור שמקלה לבצע אוטומציה ומכשיר של הקוד עצמו - בדומה ל-IDE, אבל כאן מאחסנים שירותי הענן ייצוגים התממשו של כל מיליארדי השורות של קוד המקור של Google במחסן נתונים גדול.

Grok סיפקה לגוגלרים מסגרת רבת עוצמה לביצוע ריפקטורים אוטומטיים על פני כל בסיס הקוד שלהם (ממש בכל Google). המערכת מחשבת לא רק את התלות שלך במעלה הזרם (בה אתה תלוי), אלא גם בְּמוֹרַד הַזֶרֶם (שהם תלויים בך) אז כשאתה משנה ממשקי API אתה מכיר את כל מי שאתה שובר! כך, כשאתה מבצע שינויים, אתה יכול לוודא שכל צרכן של ה-API שלך התעדכן לגרסה החדשה, ובמציאות, לעתים קרובות עם הכלי Rosie שהם כתבו, אתה יכול להפוך את התהליך לאוטומטי לחלוטין.

זה מאפשר לבסיס הקוד של גוגל להיות פנימי כמעט נקי באופן על-טבעי, מכיוון שמשרתים רובוטיים אלה מסתובבים בבית ומנקים הכל באופן אוטומטי אם ישנו את השם של SomeDespicablyLongFunctionName ל-SomeDespicablyLongMethodName כי מישהו החליט שזה נכד מכוער ואת הצרכים שלו להרדים.

ולמען האמת, זה עובד די טוב עבור גוגל... פנימית. כלומר, כן, קהילת Go בגוגל אכן צוחקת טוב עם קהילת ג'אווה בגוגל בגלל ההרגל שלהם לרפקטור מתמשך. אם אתה מפעיל מחדש משהו N פעמים, זה אומר שלא רק דפקת אותו N-1 פעמים, אלא לאחר זמן מה די ברור שכנראה פישלת אותו גם בניסיון ה-N. אבל, בגדול, הם נשארים מעל כל המהומה הזו ושומרים על הקוד "נקי".

הבעיה מתחילה כשהם מנסים לכפות את הגישה הזו על לקוחות הענן שלהם ומשתמשים בממשקי API אחרים.

הצגתי לכם קצת את Emacs, Android ו-Java; בואו נסתכל על הפלטפורמה המצליחה האחרונה ארוכת חיים: האינטרנט עצמו. האם אתה יכול לדמיין כמה איטרציות עבר HTTP מאז 1995 כשהשתמשנו בתגיות מהבהבות? וסמלים של "בבנייה" בדפי אינטרנט.

אבל זה עדיין עובד! והדפים האלה עדיין עובדים! כן, חבר'ה, הדפדפנים הם אלופי העולם בתאימות לאחור. כרום הוא דוגמה נוספת לפלטפורמת גוגל הנדירה שראשיה מוברגים כהלכה, וכפי שאולי ניחשתם, כרום פועלת למעשה כחברה בארגז חול נפרדת משאר גוגל.

אני גם רוצה להודות לחברים שלנו במפתחי מערכות ההפעלה: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD וכו', על שהם עושים עבודה כל כך נהדרת של תאימות לאחור בפלטפורמות המוצלחות שלהם (אפל מקבלת C במקרה הטוב עם The החיסרון הוא שהם שוברים הכל כל הזמן ללא סיבה מוצדקת, אבל איכשהו הקהילה עוקפת את זה עם כל מהדורה, ומכולות OS X עדיין לא מיושנות לגמרי... עדיין).

אבל רגע, אתה אומר. האם אנחנו לא משווים תפוחים לתפוזים - מערכות תוכנה עצמאיות במכונה אחת כמו Emacs/JDK/Android/Chrome לעומת מערכות ריבוי שרתים וממשקי API כמו שירותי ענן?

ובכן, צייצתי על זה אתמול, אבל בסגנון של לארי וול (יוצר שפת התכנות Perl - בערך לכל) על עיקרון "מבאס/חוקים" חיפשתי את המילה הוצא משימוש באתרי המפתחים של גוגל ואמזון. ולמרות שיש ל-AWS מאות פי יותר מהיצע השירותים מאשר GCP, תיעוד המפתחים של Google מזכיר הוצאה משימוש בערך פי שבעה יותר.

אם מישהו בגוגל קורא את זה, הוא כנראה מוכן לשלוף תרשימים בסגנון דונלד טראמפ המראים שהם למעשה עושים הכל נכון, ושאני לא צריך לעשות השוואות לא הוגנות כמו "מספר אזכורים של המילה הוצאה משימוש לעומת מספר שירותים" "

אבל אחרי כל השנים האלה, גוגל קלאוד הוא עדיין השירות מספר 3 (מעולם לא כתבתי מאמר על הניסיון הכושל להפוך למקום 2), אבל אם להאמין למקורבים, יש כמה חששות שהם עלולים לרדת בקרוב ל- מס' 4.

אין לי טיעונים משכנעים "להוכיח" את התזה שלי. כל מה שיש לי הן הדוגמאות הצבעוניות שצברתי במשך 30 שנה כמפתח. כבר הזכרתי את האופי הפילוסופי העמוק של בעיה זו; במובנים מסוימים זה פוליטי בקהילות מפתחים. יש המאמינים בכך יוצרים פלטפורמות צריכות לדאוג לתאימות, בעוד שאחרות חושבות שזה חשש משתמש (המפתחים עצמם). אחד מתוך שניים. אכן, האם זו לא סוגיה פוליטית כאשר אנו מחליטים מי צריך לשאת בעלויות הבעיות הנפוצות?

אז זו פוליטיקה. וכנראה שיהיו תגובות נזעמות לנאום שלי.

כמו משתמש Google Cloud Platform, וכמשתמש AWS במשך שנתיים (תוך כדי עבודה עבור Grab), אני יכול לומר שיש הבדל עצום בין הפילוסופיות של אמזון לגוגל בכל הנוגע לסדרי עדיפויות. אני לא מפתח באופן פעיל ב-AWS, אז אני לא יודע כל כך באיזו תדירות הם מסירים ממשקי API ישנים. אבל יש חשד שזה לא קורה כמעט באותה תדירות כמו בגוגל. ואני באמת מאמין שהמקור הזה למחלוקת ותסכול מתמידים ב-GCP הוא אחד הגורמים הגדולים ביותר המעכבים את התפתחות הפלטפורמה.

אני יודע שלא ציינתי דוגמאות ספציפיות למערכות GCP שאינן נתמכות עוד. אני יכול לומר שכמעט כל מה שהשתמשתי בו, מרשתות (מהעתיקות ועד VPC) ועד לאחסון (Cloud SQL v1-v2), Firebase (עכשיו Firestore עם API שונה לגמרי), App Engine (בוא לא נתחיל אפילו) , נקודות קצה בענן Cloud Endpoint ועד... אני לא יודע - לחלוטין את כל זה אילצו אותך לשכתב את הקוד לאחר מקסימום 2-3 שנים, והם מעולם לא הפכו את ההעברה אוטומטית עבורך, ולעתים קרובות לא היה נתיב הגירה מתועד כלל. כאילו זה היה אמור להיות כך.

ובכל פעם שאני מסתכל על AWS, אני שואל את עצמי למה לעזאזל אני עדיין ב-GCP. ברור שהם לא צריכים לקוחות. הם צריכים קונים. אתה מבין את ההבדל? הרשה לי להסביר.

ל-Google Cloud יש Marketplace, שם אנשים מציעים את פתרונות התוכנה שלהם, וכדי להימנע מאפקט המסעדה הריקה, הם היו צריכים למלא אותו בכמה הצעות, אז הם התקשרו עם חברה בשם Bitnami כדי ליצור חבורה של פתרונות שנפרסים ב"לחיצה אחת", או שצריך אני כותב את זה בעצמי "פתרונות", כי אלה לא פותרים שום דבר. הם פשוט קיימים כתיבות סימון, כחומר מילוי שיווקי, ולגוגל מעולם לא היה אכפת אם כל אחד מהכלים אכן עובד. אני מכיר מנהלי מוצר שהיו במושב הנהג, ואני יכול להבטיח לך שלאנשים האלה לא אכפת.

קח, למשל, פתרון פריסה כביכול "בלחיצה אחת". פרקונה. הייתי חולה עד מוות על הניסיונות של Google Cloud SQL, אז התחלתי להסתכל על בניית אשכול Percona משלי כחלופה. והפעם נראה שגוגל עשה עבודה טובה, הם הולכים לחסוך לי קצת זמן ומאמץ בלחיצת כפתור!

טוב, בוא נלך. בוא נעקוב אחר הקישור ונלחץ על כפתור זה. בחר "כן" כדי להסכים לכל הגדרות ברירת המחדל ולפרוס את האשכול בפרויקט הענן שלך ב-Google. חחח זה לא עובד. שום דבר מהשטויות האלה לא עובד. הכלי מעולם לא נבדק והוא התחיל להירקב מהדקה הראשונה, וזה לא יפתיע אותי אם יותר ממחצית מה"פתרונות" הם פריסות בלחיצה אחת (עכשיו אנחנו מבינים למה הציטוטים) באופן כללי לא עובד. זוהי חושך חסר תקנה לחלוטין, שבו עדיף לא להיכנס.

אבל גוגל צודק דחפים לך להשתמש בהם. הם רוצים אותך קנה. עבורם זו עסקה. הם לא רוצים כלום לתמוך. זה לא חלק מה-DNA של גוגל. כן, מהנדסים תומכים זה בזה, כפי שמעיד הסיפור שלי עם Bigtable. אבל במוצרים ושירותים לאנשים רגילים הם תמיד היו חסרי רחמים בפנים סגירת כל שירות, שאינה עומדת ברף הרווחיות גם אם יש לה מיליוני משתמשים.

וזה מהווה אתגר אמיתי עבור GCP מכיוון שזהו ה-DNA מאחורי כל הצעות הענן. הם לא מנסים לתמוך בשום דבר; זה ידוע שהם מסרבים לארח (כשירות מנוהל) כל תוכנת צד שלישי עד, עד ש-AWS עושה את אותו הדבר ותבנה סביבו עסק מצליח, וכשהלקוחות ממש דורשים את אותו הדבר. עם זאת, נדרש מאמץ כדי לגרום לגוגל לתמוך במשהו.

חוסר תרבות תמיכה זה, יחד עם המנטליות של "בואו נשבור את זה כדי לעשות את זה יותר יפה", מרחיקים מפתחים.

וזה לא דבר טוב אם אתה רוצה לבנות פלטפורמה ארוכת חיים.

גוגל, תתעורר, לעזאזל. עכשיו 2020. אתה עדיין מפסיד. זה הזמן להעיף מבט חזק במראה ולענות האם אתה באמת רוצה להישאר בעסקי הענן.

אם אתה רוצה להישאר אז להפסיק לשבור הכל. חבר'ה, אתם עשירים. אנחנו המפתחים לא. אז כשזה מגיע למי ייקח את נטל התאימות, אתה צריך לקחת את זה על עצמך. לא בשבילנו.

כי יש עוד לפחות שלושה עננים ממש טובים. הם קורצים.

ועכשיו אעבור לתקן את כל המערכות השבורות שלי. אה.

עד הפעם הבאה!

נ.ב עדכון לאחר קריאת חלק מהדיונים במאמר זה (הדיונים מצוינים, אגב). התמיכה ב-Firebase לא הופסקה ואין תוכניות שאני מודע להן. עם זאת, יש להם באג סטרימינג מגעיל שגורם ללקוח Java להיתקע ב-App Engine. אחד המהנדסים שלהם עזר לי לפתור את הבעיה הזו, כשעבדתי בגוגל, אבל הם מעולם לא תיקנו את הבאג, אז יש לי פתרון מחורבן של צורך להפעיל מחדש את אפליקציית GAE כל יום. וכך זה היה כבר ארבע שנים! עכשיו יש להם Firestore. זה ייקח הרבה עבודה כדי לעבור אליו מכיוון שזו מערכת שונה לחלוטין והבאג של Firebase לעולם לא יתוקן. איזו מסקנה אפשר להסיק? אתה יכול לקבל עזרה אם אתה עובד בחברה. אני כנראה היחיד שמשתמש ב-Firebase ב-GAE מכיוון שאני רושם פחות מ-100 מפתחות באפליקציה מקורית של 100% והיא מפסיקה לעבוד כל יומיים בגלל באג ידוע. מה אני יכול לומר מלבד השימוש בו על אחריותך בלבד. אני עובר לרדיס.

ראיתי גם כמה משתמשי AWS מנוסים יותר אומרים ש-AWS בדרך כלל לא מפסיק לתמוך בשירותים כלשהם, ו-SimpleDB היא דוגמה מצוינת. ההנחות שלי של-AWS אין את אותו סוף של מחלת התמיכה כמו לגוגל נראות מוצדקות.

בנוסף, שמתי לב שלפני 20 יום צוות Google App Engine שבר את אירוח ספריית Go קריטית, וסגר יישום GAE מאחד ממפתחי הליבה של Go. זה היה ממש טיפשי.

לבסוף, שמעתי שגוגלרים כבר דנים בנושא הזה ובאופן כללי מסכימים איתי (אוהבים אתכם!). אבל נראה שהם חושבים שהבעיה אינה ניתנת לפתרון מכיוון שלתרבות של גוגל מעולם לא היה מבנה התמריצים הנכון. חשבתי שזה יהיה טוב לקחת קצת זמן כדי לדון בחוויה המדהימה שהייתה לי בעבודה עם מהנדסי AWS בזמן העבודה ב-Grab. מתישהו בעתיד, אני מקווה!

וכן, בשנת 2005 היו להם סוגים שונים של בשר כרישים במזנון הענק בבניין 43, והאהוב עלי היה בשר כריש הפטיש. עם זאת, עד 2006, לארי וסרגיי נפטרו מכל החטיפים הלא בריאים. אז במהלך הסיפור של Bigtable ב-2007 באמת לא היו כרישים והולימתי אותך.

כשהסתכלתי על ענן Bigtable לפני ארבע שנים (תן או קח), כאן היה העלות. נראה שזה קצת ירד עכשיו, אבל זה עדיין הרבה מאוד עבור מחסן נתונים ריק, במיוחד מאז הסיפור הראשון שלי מראה כמה חסר משמעות טבלה גדולה ריקה בקנה מידה שלהם.

סליחה על הפגיעה בקהילת אפל ולא אומרת שום דבר נחמד על מיקרוסופט וכו'. אתה בסדר, אני באמת מעריך את כל הדיון שהמאמר הזה יצר! אבל לפעמים אתה צריך לעשות קצת גלים כדי להתחיל דיון, אתה יודע?

תודה שקראת.

עדכון 2, 19.08.2020/XNUMX/XNUMX. פס מעדכן את ה-API בצורה נכונה!

עדכון 3, 31.08.2020/2/2. יצר איתי קשר על ידי מהנדס גוגל ב-Cloud Marketplace שהתברר כי הוא חבר ותיק שלי. הוא רצה להבין למה CXNUMXD לא עובד, ובסופו של דבר הבנו שזה בגלל שבניתי את הרשת שלי לפני שנים, ו-CXNUMXD לא עבד על רשתות מדור קודם בגלל שפרמטר רשת המשנה היה חסר בתבניות שלהם. אני חושב שעדיף למשתמשי GCP פוטנציאליים לוודא שהם מכירים מספיק מהנדסים ב-Google...

מקור: www.habr.com