ไอ้ 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 ดังนั้นเมื่อเห็นแวบแรกฉันก็อ่านข้อความประมาณนี้:
เรียนท่านผู้รับ
สวัสดีจากบางทีม เราอยากจะสื่อสารออกไป บลา บลา บลา บลา บลา บลา บลา บลา บลา บลา และบลา บลา บลา ทันที
โปรดแจ้งให้เราทราบหากคุณสามารถกำหนดเวลาอันมีค่าของคุณสำหรับ blah blah blah
ขอให้โชคดี
คำสั่งบางอย่าง
ฉันเกือบจะลบมันทิ้งไปทันที แต่เมื่อหมดสติ ฉันก็รู้สึกเจ็บปวดและจู้จี้จุกจิกแบบนั้น ไม่ได้จริงๆ ดูเหมือนจดหมายทางการเลย อย่างชัดเจนว่าผู้รับผิดเพราะไม่ได้ใช้ Bigtable
แต่มันก็แปลก
ฉันใช้เวลาที่เหลือของวันสลับกันคิดเรื่องงานและเนื้อปลาฉลามชนิดไหนที่จะลองในครัวขนาดเล็ก ซึ่งอย่างน้อย XNUMX ชิ้นก็อยู่ใกล้พอที่จะโยนบิสกิตที่เล็งเป้ามาอย่างดีจากที่นั่งของฉัน แต่ ความคิดในการเขียนไม่เคยทำให้ฉันมีความรู้สึกวิตกกังวลเล็กน้อย
พวกเขาพูดชื่อของฉันอย่างชัดเจน และอีเมลถูกส่งไปยังที่อยู่อีเมลของฉัน ไม่ใช่ของคนอื่น และไม่ใช่ cc: หรือ bcc: น้ำเสียงมีความเป็นส่วนตัวและชัดเจนมาก บางทีนี่อาจเป็นข้อผิดพลาดบางอย่าง?
ในที่สุด ความอยากรู้อยากเห็นก็เข้าครอบงำฉัน และฉันก็ไปดูคอนโซล Borg ในศูนย์ข้อมูลที่พวกเขาพูดถึง
และแน่นอนว่า ฉันมีพื้นที่เก็บข้อมูล BigTable ภายใต้การบริหาร ฉันขอโทษอะไร? ฉันดูเนื้อหาแล้วว้าว! ข้อความนี้มาจากศูนย์บ่มเพาะ Codelab ที่ฉันนั่งอยู่ในช่วงสัปดาห์แรกที่ Google ในเดือนมิถุนายน 2005 Codelab บังคับให้คุณเรียกใช้ Bigtable เพื่อเขียนค่าบางค่าที่นั่น และดูเหมือนว่าฉันไม่เคยปิดที่เก็บข้อมูลเลยหลังจากนั้น มันยังคงทำงานอยู่แม้ว่าจะผ่านไปนานกว่าสองปีแล้วก็ตาม
มีแง่มุมที่น่าสังเกตหลายประการในเรื่องนี้ ประการแรก งานของ Bigtable นั้นไม่มีนัยสำคัญมากในระดับของ Google จนเพียงสองปีต่อมาก็ไม่มีใครสังเกตเห็นพื้นที่เก็บข้อมูลเพิ่มเติม และเพียงเพราะเวอร์ชันของไบนารี่ล้าสมัยเท่านั้น เปรียบเทียบผมเคยคิดจะใช้ สำหรับเกมออนไลน์ของฉัน ในขณะนั้น บริการนี้มีค่าใช้จ่ายประมาณ 16 เหรียญสหรัฐต่อปี ว่างเปล่า Bigtable บน GCP ฉันไม่ได้บอกว่าพวกเขากำลังหลอกลวงคุณ แต่ในความคิดส่วนตัวของฉัน นั่นเป็นเงินจำนวนมากสำหรับฐานข้อมูลที่ว่างเปล่า
ที่น่าสังเกตอีกประการหนึ่งก็คือการจัดเก็บข้อมูล ยังคงทำงานหลังจากสองปี. อะไรนะ? ศูนย์ข้อมูลมีทั้งแบบเข้าและออก พวกเขาประสบปัญหาไฟฟ้าขัดข้อง ได้รับการบำรุงรักษาตามกำหนดเวลา และเปลี่ยนแปลงตลอดเวลา ฮาร์ดแวร์ได้รับการอัปเดต สวิตช์ถูกเปลี่ยน ทุกอย่างได้รับการปรับปรุงอย่างต่อเนื่อง พวกเขาทำให้โปรแกรมของฉันทำงานต่อไปเป็นเวลาสองปีโดยมีการเปลี่ยนแปลงทั้งหมดนี้ได้อย่างไร? นี่อาจดูเหมือนเป็นความสำเร็จเล็กน้อยในปี 2020 แต่ในปี 2005-2007 ก็ถือว่าน่าประทับใจทีเดียว
และแง่มุมที่ยอดเยี่ยมที่สุดคือ ทีมวิศวกรภายนอกในรัฐอื่นเข้ามาหาฉัน ซึ่งเป็นเจ้าของ Bigtable ตัวเล็กๆ ที่เกือบจะว่างเปล่า ซึ่งมี การจราจรเป็นศูนย์ ในช่วงสองปีที่ผ่านมา - และกำลังเสนอความช่วยเหลือในการอัปเดต
ฉันขอบคุณพวกเขา ลบที่เก็บข้อมูล และชีวิตก็ดำเนินไปตามปกติ แต่สิบสามปีต่อมา ฉันยังคงคิดถึงจดหมายฉบับนั้นอยู่ เพราะบางครั้งฉันก็ได้รับอีเมลที่คล้ายกันจาก Google Cloud พวกเขามีลักษณะเช่นนี้:
เรียนผู้ใช้ Google Cloud
โปรดทราบว่าเราจะยุติบริการ [บริการที่จำเป็นที่คุณใช้] ในเดือนสิงหาคม 2020 หลังจากนั้นคุณจะไม่สามารถอัปเกรดอินสแตนซ์ของคุณได้ เราขอแนะนำให้อัปเกรดเป็นเวอร์ชันล่าสุด ซึ่งอยู่ในการทดสอบเบต้า ไม่มีเอกสารประกอบ ไม่มีเส้นทางการย้ายข้อมูล และล้าสมัยไปแล้วด้วยความช่วยเหลือจากเรา
เรามุ่งมั่นที่จะสร้างความมั่นใจว่าการเปลี่ยนแปลงนี้มีผลกระทบน้อยที่สุดต่อผู้ใช้แพลตฟอร์ม Google Cloud ทั้งหมด
เพื่อนที่ดีที่สุดตลอดกาล,
แพลตฟอร์มคลาวด์ของ Google
แต่ฉันแทบไม่เคยอ่านจดหมายแบบนี้เลย เพราะสิ่งที่พวกเขาพูดจริงๆ คือ:
เรียนท่านผู้รับ
ตกนรก. เย็ดคุณ เย็ดคุณ เย็ดคุณ ทิ้งทุกสิ่งที่คุณทำเพราะมันไม่สำคัญ สิ่งสำคัญคือเวลาของเรา เราเสียเวลาและเงินไปกับการรักษาเรื่องไร้สาระของเรา และเราเบื่อกับมันแล้ว ดังนั้นเราจะไม่สนับสนุนมันอีกต่อไป ดังนั้น เลิกแผนการบ้า ๆ ของคุณและเริ่มขุดค้นเอกสารห่วย ๆ ของเรา ขอเรื่องที่สนใจในฟอรั่ม และอีกอย่าง เรื่องใหม่ของเราแตกต่างไปจากเรื่องเก่า ๆ อย่างสิ้นเชิง เพราะเราทำให้ดีไซน์นี้พังไปเลยทีเดียว หึหึ แต่นั่นมันของคุณ ปัญหา ไม่ใช่ของเรา
เราพยายามอย่างต่อเนื่องเพื่อให้แน่ใจว่าการพัฒนาทั้งหมดของคุณจะใช้งานไม่ได้ภายในหนึ่งปี
กรุณามีเพศสัมพันธ์ออก
แพลตฟอร์มคลาวด์ของ Google
และความจริงก็คือฉันได้รับจดหมายดังกล่าวประมาณเดือนละครั้ง สิ่งนี้เกิดขึ้นบ่อยครั้งและต่อเนื่องจนหลีกเลี่ยงไม่ได้ ผลักออกไป ฉันจาก GCP สู่ค่ายต่อต้านคลาวด์ ฉันไม่ตกลงที่จะพึ่งพาการพัฒนาที่เป็นกรรมสิทธิ์ของพวกเขาอีกต่อไป เพราะในความเป็นจริงแล้ว Devops จะรักษาระบบโอเพ่นซอร์สบนเครื่องเสมือนเปล่าๆ ได้ง่ายกว่าการพยายามตาม Google ด้วยนโยบายในการปิดผลิตภัณฑ์ที่ "ล้าสมัย"
ก่อนที่ฉันจะกลับไปใช้ Google Cloud เพราะฉัน ไม่ได้ใกล้เคียง ยังวิพากษ์วิจารณ์พวกเขาไม่จบ ลองดูผลการดำเนินงานของบริษัทในด้านอื่นๆ บ้าง วิศวกรของ Google ภูมิใจในวินัยทางวิศวกรรมซอฟต์แวร์ของตน และนี่คือสาเหตุที่ทำให้เกิดปัญหาอย่างแท้จริง ความภูมิใจเป็นกับดักสำหรับผู้ที่ไม่ระวัง และทำให้พนักงาน Google หลายคนคิดว่าการตัดสินใจของตนถูกต้องเสมอ และการถูกต้อง (ตามคำจำกัดความที่คลุมเครือบางอย่าง) มีความสำคัญมากกว่าการเอาใจใส่ลูกค้า
ฉันจะยกตัวอย่างแบบสุ่มจากโครงการขนาดใหญ่อื่นๆ นอกเหนือจาก Google แต่ฉันหวังว่าคุณจะเห็นรูปแบบนี้ทุกที่ มันเป็นดังนี้: ความเข้ากันได้แบบย้อนหลังช่วยให้ระบบมีความคงอยู่และทันสมัยมานานหลายทศวรรษ.
ความเข้ากันได้แบบย้อนหลังคือเป้าหมายการออกแบบของระบบที่ประสบความสำเร็จทั้งหมดที่ออกแบบมาเพื่อ เปิด การใช้งาน กล่าวคือ นำไปใช้กับโค้ดโอเพ่นซอร์สและ/หรือมาตรฐานเปิด ฉันรู้สึกเหมือนกำลังพูดอะไรบางอย่างที่ชัดเจนเกินไปจนทุกคนอึดอัดด้วยซ้ำ แต่ก็ไม่ นี่เป็นประเด็นทางการเมือง ดังนั้นจึงจำเป็นต้องมีตัวอย่าง
ระบบแรกที่ฉันจะเลือกคือระบบที่เก่าแก่ที่สุด: GNU Emacs ซึ่งเป็นระบบลูกผสมระหว่าง Windows Notepad, เคอร์เนล OS และสถานีอวกาศนานาชาติ มันอธิบายยากนิดหน่อย แต่โดยสรุป Emacs เป็นแพลตฟอร์มที่สร้างขึ้นในปี 1976 (ใช่แล้ว เกือบครึ่งศตวรรษที่ผ่านมา) สำหรับการเขียนโปรแกรมเพื่อให้คุณมีประสิทธิผลมากขึ้น แต่ปลอมตัวเป็นโปรแกรมแก้ไขข้อความ
ฉันใช้ Emacs ทุกวัน ใช่ ฉันยังใช้ IntelliJ ทุกวัน มันได้เติบโตขึ้นเป็นแพลตฟอร์มเครื่องมือที่ทรงพลังในตัวมันเอง แต่การเขียนส่วนขยายสำหรับ IntelliJ นั้นเป็นงานที่ทะเยอทะยานและซับซ้อนมากกว่าการเขียนส่วนขยายสำหรับ Emacs และที่สำคัญกว่านั้น ทุกอย่างที่เขียนขึ้นสำหรับ Emacs จะถูกเก็บรักษาไว้ ชั่วฟ้าดินสลาย.
ฉันยังคงใช้ซอฟต์แวร์ที่ฉันเขียนให้กับ Emacs เมื่อปี 1995 และฉันแน่ใจว่ามีคนใช้โมดูลที่เขียนขึ้นสำหรับ Emacs ในช่วงกลางทศวรรษที่ 80 หากไม่ใช่ก่อนหน้านี้ อาจต้องมีการปรับแต่งเล็กน้อยเป็นครั้งคราว แต่ก็ค่อนข้างหายากจริงๆ ฉันไม่รู้อะไรเลยที่ฉันเคยเขียนให้กับ Emacs (และฉันเขียนมาเยอะมาก) ที่จำเป็นต้องมีสถาปัตยกรรมใหม่
Emacs มีฟังก์ชันที่เรียกว่า make-obsolete สำหรับเอนทิตีที่ล้าสมัย คำศัพท์เฉพาะทางของ Emacs สำหรับแนวคิดพื้นฐานของคอมพิวเตอร์ (เช่น "หน้าต่าง" คืออะไร) มักจะแตกต่างจากแบบแผนทางอุตสาหกรรม เนื่องจาก Emacs เปิดตัวคำเหล่านี้มานานแล้ว นี่เป็นอันตรายโดยทั่วไปสำหรับผู้ที่อยู่ก่อนเวลา: เงื่อนไขทั้งหมดของคุณไม่ถูกต้อง แต่ Emacs มีแนวคิดเรื่องการเลิกใช้งาน ซึ่งในศัพท์แสงของพวกเขาเรียกว่า ความล้าสมัย.
แต่ในโลกของ Emacs ดูเหมือนว่าจะมีคำจำกัดความการทำงานที่แตกต่างออกไป ปรัชญาพื้นฐานที่แตกต่างออกไป หากคุณต้องการ
ในโลกของ Emacs (และในด้านอื่นๆ ซึ่งเราจะกล่าวถึงด้านล่าง) สถานะ API ที่เลิกใช้แล้วโดยพื้นฐานแล้วหมายถึง: "คุณไม่ควรใช้แนวทางนี้จริงๆ เพราะในขณะที่วิธีนี้ใช้ได้ผล ก็จะต้องทนทุกข์ทรมานจากข้อบกพร่องต่างๆ ที่เราจะ รายการที่นี่ แต่ท้ายที่สุดแล้ว มันอยู่ที่คุณเลือก"
ในโลกของ Google การล้าสมัยหมายถึง "เรากำลังละเมิดคำมั่นสัญญาที่เรามีต่อคุณ" นี่เป็นเรื่องจริง นี่คือความหมายที่แท้จริง ซึ่งหมายความว่าพวกเขาจะบังคับคุณ สม่ำเสมอ ทำงานบ้างอาจจะงานมากเพื่อเป็นการลงโทษที่เชื่อในสิ่งเหล่านั้น : เรามีซอฟต์แวร์ที่ดีที่สุด ที่เร็วที่สุด! คุณทำทุกอย่างตามคำแนะนำ เปิดแอปพลิเคชันหรือบริการของคุณ จากนั้นแบม หลังจากผ่านไปหนึ่งหรือสองปีมันก็พัง
เหมือนขายรถมือสองที่พังแน่นอนหลัง 1500 กม.
นี่เป็นคำจำกัดความทางปรัชญาที่แตกต่างกันอย่างสิ้นเชิงสองประการของ "ความล้าสมัย" คำจำกัดความของกลิ่นของ Google . ฉันไม่เชื่อสิ่งนี้ ในความเป็นจริง การวางแผนล้าสมัยในแง่เดียวกับ Apple แต่ Google กำลังวางแผนที่จะทำลายโปรแกรมของคุณในลักษณะวงเวียนอย่างแน่นอน ฉันรู้สิ่งนี้เพราะฉันทำงานที่นั่นเป็นวิศวกรซอฟต์แวร์มานานกว่า 12 ปี พวกเขามีแนวทางภายในที่คลุมเครือว่าควรปฏิบัติตามความเข้ากันได้แบบย้อนหลังมากน้อยเพียงใด แต่ท้ายที่สุดแล้วจะขึ้นอยู่กับแต่ละทีมหรือบริการ ไม่มีคำแนะนำระดับองค์กรหรือวิศวกรรม และคำแนะนำที่ชัดเจนที่สุดในแง่ของวงจรความล้าสมัยคือ “พยายามให้เวลาลูกค้าอัปเกรด 6-12 เดือนก่อนที่จะทำลายระบบทั้งหมด”
ปัญหาใหญ่กว่าที่พวกเขาคิดมากและจะคงอยู่ต่อไปอีกหลายปี เนื่องจากการดูแลลูกค้าไม่ได้อยู่ใน DNA ของพวกเขา เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง
ณ จุดนี้ ฉันจะแถลงการณ์อย่างกล้าหาญว่า Emacs ประสบความสำเร็จในระดับสูงและสม่ำเสมอ เป็นพื้น เพราะพวกเขาให้ความสำคัญกับความเข้ากันได้แบบย้อนหลังเป็นอย่างมาก จริงๆแล้วนี่คือวิทยานิพนธ์ของบทความของเรา ระบบเปิดที่ประสบความสำเร็จและมีอายุยืนยาวเป็นผลมาจากความสำเร็จของชุมชนย่อยที่อาศัยอยู่รอบตัวพวกเขามานานหลายทศวรรษ ส่วนขยาย/ปลั๊กอิน. นี่คือระบบนิเวศ ฉันได้พูดคุยไปแล้วเกี่ยวกับลักษณะของแพลตฟอร์มและความสำคัญของแพลตฟอร์มเหล่านั้น และวิธีที่ Google ไม่เคยเข้าใจมาก่อนว่าอะไรจะนำไปสู่การสร้างแพลตฟอร์มแบบเปิดที่ประสบความสำเร็จนอกเหนือจาก Android หรือ Chrome
จริงๆ แล้วฉันควรจะพูดถึง Android สั้นๆ เพราะคุณคงคิดเรื่องนี้อยู่
ครั้งแรก แอนดรอยด์ไม่ใช่กูเกิล. พวกเขาแทบไม่มีอะไรเหมือนกันเลย Android เป็นบริษัทที่ Google ซื้อไปในเดือนกรกฎาคม พ.ศ. 2005 บริษัทได้รับอนุญาตให้ทำงานแบบอิสระไม่มากก็น้อย และในความเป็นจริง ส่วนใหญ่ยังคงไม่มีใครแตะต้องในช่วงหลายปีที่ผ่านมา Android เป็นกองเทคโนโลยีที่มีชื่อเสียงและเป็นองค์กรที่เต็มไปด้วยหนามที่ฉาวโฉ่ไม่แพ้กัน ดังที่ Googler คนหนึ่งกล่าวไว้ “คุณไม่สามารถเข้าสู่ระบบ Android ได้”
ในบทความก่อนหน้านี้ ฉันได้พูดคุยถึงความเลวร้ายในการตัดสินใจในการออกแบบ Android ในช่วงแรกๆ ตอนที่ฉันเขียนบทความนั้น พวกเขากำลังเผยแพร่สิ่งที่เรียกว่า "แอปทันใจ" ซึ่งตอนนี้กลายเป็นเรื่องไร้สาระไปแล้ว (เซอร์ไพรส์!) และฉันเห็นอกเห็นใจหากคุณโง่พอที่จะฟัง Google และย้ายเนื้อหาของคุณไปยัง Instant App เหล่านี้
แต่มีความแตกต่างตรงนี้ ข้อแตกต่างที่สำคัญก็คือ คน Android เข้าใจจริงๆ ว่าแพลตฟอร์มมีความสำคัญเพียงใด พวกเขาพยายามอย่างเต็มที่เพื่อให้แอป Android รุ่นเก่าทำงานได้ต่อไป ในความเป็นจริง ความพยายามของพวกเขาในการรักษาความเข้ากันได้แบบย้อนหลังนั้นรุนแรงมาก แม้แต่ฉันในช่วงสั้นๆ ที่แผนก Android เมื่อไม่กี่ปีก่อน ก็พบว่าตัวเองกำลังพยายามโน้มน้าวให้พวกเขายกเลิกการรองรับอุปกรณ์และ API ที่เก่าแก่ที่สุดบางตัว (ฉันคิดผิด เช่นเดียวกับหลายๆ เรื่องทั้งในอดีตและปัจจุบัน ขออภัยเพื่อนๆ Android ตอนนี้ผมไปอินโดนีเซียแล้ว ผมเข้าใจแล้วว่าทำไมเราถึงต้องการพวกเขา)
ผู้ใช้ Android ผลักดันความเข้ากันได้แบบย้อนหลังไปสู่ความสุดขั้วที่แทบจะจินตนาการไม่ได้ ทำให้เกิดหนี้ทางเทคนิคแบบเดิมจำนวนมหาศาลในระบบและห่วงโซ่เครื่องมือของพวกเขา โอ้พระเจ้า คุณควรเห็นสิ่งบ้าๆ ที่พวกเขาต้องทำในระบบบิลด์ ทั้งหมดนี้ในนามของความเข้ากันได้
ด้วยเหตุนี้ ฉันจึงมอบรางวัล "คุณไม่ใช่ Google" อันเป็นที่ปรารถนาให้กับ Android พวกเขาไม่ต้องการเป็น Google จริงๆ ซึ่งไม่รู้ว่าจะสร้างแพลตฟอร์มที่ทนทานได้อย่างไร แต่เป็น Android รู้, ทำอย่างไร. ดังนั้น Google จึงฉลาดมากในแง่หนึ่ง นั่นคือการอนุญาตให้ผู้คนทำสิ่งต่าง ๆ ในแบบของตนเองบน Android
อย่างไรก็ตาม Instant App สำหรับ Android ถือเป็นแนวคิดที่โง่มาก และคุณรู้ไหมว่าทำไม? เพราะพวกเขาเรียกร้อง เขียนใหม่และออกแบบแอปพลิเคชันของคุณใหม่! เหมือนกับว่าผู้คนจะเขียนแอปพลิเคชันใหม่กว่าสองล้านแอปพลิเคชัน ฉันเดาว่า Instant Apps เป็นความคิดของ Googler
แต่มีความแตกต่าง ความเข้ากันได้แบบย้อนหลังมีค่าใช้จ่ายสูง Android เองก็เป็นผู้รับภาระค่าใช้จ่ายเหล่านี้ ในขณะที่ Google ยืนยันว่าจะต้องรับภาระนั้น คุณ, ลูกค้าที่ชำระเงิน
คุณสามารถเห็นความมุ่งมั่นของ Android ที่จะเข้ากันได้แบบย้อนหลังใน API ของมัน เมื่อคุณมีระบบย่อยที่แตกต่างกันสี่หรือห้าระบบที่ทำสิ่งเดียวกันอย่างแท้จริง มันเป็นสัญญาณที่ชัดเจนว่ามีความมุ่งมั่นที่จะความเข้ากันได้แบบย้อนหลังที่แกนกลาง ซึ่งในโลกของแพลตฟอร์มนั้นมีความหมายเหมือนกันกับความมุ่งมั่นต่อลูกค้าและตลาดของคุณ
ปัญหาหลักของ Google ที่นี่คือความภาคภูมิใจในด้านสุขอนามัยทางวิศวกรรม พวกเขาไม่ชอบเมื่อมีวิธีการต่างๆ มากมายในการทำสิ่งเดียวกัน โดยที่วิธีเก่าๆ ที่ไม่น่าปรารถนามาอยู่ข้างๆ วิธีใหม่ที่แปลกใหม่กว่า มันเพิ่มเส้นโค้งการเรียนรู้สำหรับผู้ที่เพิ่งเริ่มใช้ระบบ มันเพิ่มภาระในการบำรุงรักษา API รุ่นเก่า มันทำให้ความเร็วของคุณสมบัติใหม่ช้าลง และบาปสำคัญก็คือมันไม่สวย Google - เหมือน Lady Ascot จาก Alice in Wonderland ของ Tim Burton:
เลดี้แอสคอต:
- อลิซคุณรู้ไหมว่าฉันกลัวอะไรมากที่สุด?
- ความเสื่อมถอยของชนชั้นสูง?
- ฉันกลัวว่าฉันจะมี หลานน่าเกลียด.
เพื่อทำความเข้าใจข้อดีข้อเสียระหว่างความสวยงามและการใช้งานจริง เรามาดูแพลตฟอร์มที่ประสบความสำเร็จอันดับสาม (รองจาก Emacs และ Android) และดูวิธีการทำงาน: Java เอง
Java มี API ที่ล้าสมัยจำนวนมาก การเลิกใช้งานเป็นที่นิยมอย่างมากในหมู่โปรแกรมเมอร์ Java และได้รับความนิยมมากกว่าในภาษาโปรแกรมส่วนใหญ่ด้วยซ้ำ Java เอง ภาษาหลัก และไลบรารีต่างๆ เลิกใช้ API อยู่ตลอดเวลา
เพื่อยกตัวอย่างเพียงหนึ่งจากหลายพันตัวอย่าง ถือว่าล้าสมัย เลิกใช้แล้วตั้งแต่เปิดตัว Java 1.2 ในเดือนธันวาคม 1998 เป็นเวลา 22 ปีแล้วนับตั้งแต่สิ่งนี้เลิกใช้แล้ว
แต่โค้ดจริงของฉันในการผลิตยังคงฆ่าเธรดอยู่ ทุกวัน. คุณคิดว่ามันดีจริงๆเหรอ? อย่างแน่นอน! ฉันหมายถึงว่า ถ้าฉันต้องเขียนโค้ดใหม่ในวันนี้ ฉันจะใช้มันแตกต่างออกไป แต่โค้ดสำหรับเกมของฉัน ซึ่งทำให้ผู้คนหลายแสนคนมีความสุขในช่วงสองทศวรรษที่ผ่านมา ถูกเขียนขึ้นโดยมีฟังก์ชันเพื่อปิดเธรดที่ค้างนานเกินไป และฉันก็ ไม่เคยต้องเปลี่ยนมัน. ฉันรู้จักระบบของฉันดีกว่าใครๆ ฉันมีประสบการณ์ 25 ปีในการทำงานกับมันในการผลิตจริง และฉันสามารถพูดได้อย่างแน่นอน: ในกรณีของฉัน การปิดเธรดผู้ปฏิบัติงานเฉพาะเหล่านี้ทำได้อย่างสมบูรณ์ ไม่เป็นอันตราย. มันไม่คุ้มค่ากับเวลาและความพยายามในการเขียนโค้ดนี้ใหม่ และขอบคุณ Larry Ellison (อาจ) ที่ Oracle ไม่ได้บังคับให้ฉันเขียนมันใหม่
Oracle อาจจะเข้าใจแพลตฟอร์มเช่นกัน ใครจะรู้.
หลักฐานสามารถพบได้ทั่วทั้ง Java API หลัก ซึ่งเต็มไปด้วยคลื่นแห่งความล้าสมัย เช่น แนวธารน้ำแข็งในหุบเขา คุณสามารถค้นหาตัวจัดการการนำทางด้วยแป้นพิมพ์ที่แตกต่างกันห้าหรือหกตัว (KeyboardFocusManager) ในไลบรารี Java Swing ได้อย่างง่ายดาย จริงๆ แล้วเป็นการยากที่จะค้นหา Java API ที่ไม่เลิกใช้ แต่พวกเขายังคงทำงานอยู่! ฉันคิดว่าทีมงาน Java จะลบ API จริงๆ ก็ต่อเมื่ออินเทอร์เฟซก่อให้เกิดปัญหาด้านความปลอดภัยที่ชัดเจนเท่านั้น
นี่คือสิ่งที่ผู้คน: พวกเรานักพัฒนาซอฟต์แวร์ต่างก็ยุ่งมากและในทุก ๆ ด้านของซอฟต์แวร์เราต้องเผชิญกับทางเลือกที่แข่งขันกัน ในเวลาใดก็ตาม โปรแกรมเมอร์ในภาษา X กำลังพิจารณาว่าภาษา Y เป็นสิ่งทดแทนที่เป็นไปได้ โอ้คุณไม่เชื่อฉันเหรอ? คุณต้องการเรียกมันว่าสวิฟท์ไหม? แบบว่าทุกคนกำลังย้ายไป Swift และไม่มีใครละทิ้งมันใช่ไหม? ว้าว คุณรู้น้อยแค่ไหน บริษัทต่างๆ กำลังนับต้นทุนของทีมพัฒนาอุปกรณ์เคลื่อนที่แบบคู่ (iOS และ Android) และพวกเขาเริ่มตระหนักว่าระบบการพัฒนาข้ามแพลตฟอร์มที่มีชื่อตลกๆ เช่น Flutter และ React Native ใช้งานได้จริงและสามารถใช้เพื่อลดขนาดขององค์กรได้ ทีมเคลื่อนที่สองครั้ง หรือในทางกลับกัน ทำให้พวกเขามีประสิทธิผลเพิ่มขึ้นสองเท่า มีเงินเป็นเดิมพันจริงๆ ใช่ มีการประนีประนอม แต่ในทางกลับกัน เงิน
สมมุติฐานว่า Apple ยอมรับคำสั่งจาก Guido van Rossum อย่างโง่เขลาและประกาศว่า Swift 6.0 เข้ากันไม่ได้กับ Swift 5.0 แบบย้อนหลัง เช่นเดียวกับที่ Python 3 เข้ากันไม่ได้กับ Python 2
ฉันอาจจะเล่าเรื่องนี้เมื่อสิบปีที่แล้ว แต่เมื่อประมาณสิบห้าปีที่แล้ว ฉันไป O'Reilly's Foo Camp กับ Guido นั่งในเต็นท์กับ Paul Graham และคนสำคัญอีกหลายคน เรานั่งท่ามกลางอากาศร้อนอบอ้าวเพื่อรอให้แลร์รี เพจบินด้วยเฮลิคอปเตอร์ส่วนตัวของเขา ขณะที่กุยโดโดรนเกี่ยวกับ "Python 3000" ซึ่งเขาตั้งชื่อตามจำนวนปีที่ทุกคนต้องใช้เวลาในการอพยพไปที่นั่น เราเอาแต่ถามเขาว่าทำไมเขาถึงทำลายความเข้ากันได้ และเขาก็ตอบว่า: “Unicode” และเราถามว่าหากเราต้องเขียนโค้ดใหม่ เราจะเห็นประโยชน์อะไรอีกบ้าง และเขาก็ตอบว่า
หากคุณติดตั้ง Google Cloud Platform SDK (“gcloud”) คุณจะได้รับการแจ้งเตือนต่อไปนี้:
เรียนท่านผู้รับ
เราขอเตือนคุณว่าการรองรับ Python 2 นั้นเลิกใช้แล้ว ดังนั้นให้ตายเถอะ
…และอื่น ๆ วงเวียนชีวิต.
แต่ประเด็นก็คือนักพัฒนาทุกคนมีทางเลือก และถ้าคุณบังคับให้พวกเขาเขียนโค้ดใหม่บ่อยเพียงพอ พวกเขาอาจจะคิดถึงเรื่องนี้ อื่น ๆ ตัวเลือก. พวกเขาไม่ใช่ตัวประกันของคุณ ไม่ว่าคุณต้องการให้พวกเขาเป็นตัวประกันมากแค่ไหนก็ตาม พวกเขาเป็นแขกของคุณ Python ยังคงเป็นภาษาโปรแกรมที่ได้รับความนิยมอย่างมาก แต่ Python 3(000) สร้างความยุ่งเหยิงในตัวเอง ในชุมชนและในหมู่ผู้ใช้ในชุมชน โดยที่ผลที่ตามมายังไม่ได้รับการแก้ไขเป็นเวลาสิบห้าปีแล้ว
มีโปรแกรม Python กี่โปรแกรมที่ถูกเขียนใหม่ใน Go (หรือ Ruby หรือทางเลือกอื่น) เนื่องจากความไม่เข้ากันแบบย้อนหลังนี้ มีซอฟต์แวร์ใหม่จำนวนเท่าใดที่ถูกเขียนด้วยสิ่งอื่นที่ไม่ใช่ Python อาจจะเป็น เขียนด้วยภาษา Python ถ้า Guido ไม่ได้เผาทั้งหมู่บ้านล่ะ? มันยากที่จะพูด แต่ Python ได้รับความเดือดร้อนอย่างชัดเจน มันเป็นเรื่องใหญ่และทุกคนก็สูญเสีย
สมมติว่า Apple รับฟังสัญญาณจาก Guido และทำลายความเข้ากันได้ คุณคิดว่าจะเกิดอะไรขึ้นต่อไป? นักพัฒนา 80-90% อาจจะเขียนซอฟต์แวร์ใหม่หากเป็นไปได้ กล่าวอีกนัยหนึ่ง 10-20% ของฐานผู้ใช้ไปที่ภาษาคู่แข่งโดยอัตโนมัติ เช่น Flutter
ทำหลายครั้งแล้วคุณจะสูญเสียฐานผู้ใช้ไปครึ่งหนึ่ง เช่นเดียวกับในกีฬา ในโลกแห่งการเขียนโปรแกรม รูปแบบปัจจุบันก็มีความสำคัญเช่นกัน ทั้งหมด. ใครก็ตามที่สูญเสียผู้ใช้ไปครึ่งหนึ่งในห้าปีจะถือว่าเป็นผู้แพ้รายใหญ่ คุณจะต้องอินเทรนด์ในโลกของแพลตฟอร์ม แต่นี่คือจุดที่การไม่รองรับเวอร์ชันเก่าจะทำให้คุณเสียหายเมื่อเวลาผ่านไป เพราะทุกครั้งที่คุณกำจัดนักพัฒนาบางรายออกไป คุณ (ก) สูญเสียพวกเขาไปตลอดกาล เพราะพวกเขาโกรธคุณที่ผิดสัญญา และ (ข) มอบพวกเขาให้กับคู่แข่งของคุณ
น่าแปลกที่ฉันยังช่วยให้ Google กลายเป็นพรีมาดอนน่าที่เพิกเฉยต่อความเข้ากันได้แบบย้อนหลังเมื่อฉันสร้าง Grok ซึ่งเป็นระบบการวิเคราะห์และทำความเข้าใจซอร์สโค้ดที่ทำให้ง่ายต่อการสร้างอัตโนมัติและใช้เครื่องมือโค้ดเอง - คล้ายกับ IDE แต่ที่นี่บริการคลาวด์จัดเก็บ การแสดงซอร์สโค้ดของ Google นับพันล้านบรรทัดในคลังข้อมูลขนาดใหญ่
Grok ช่วยให้ Googler มีเฟรมเวิร์กอันทรงพลังสำหรับการดำเนินการปรับโครงสร้างใหม่อัตโนมัติทั่วทั้งโค้ดเบสทั้งหมด (ทั่วทั้ง Google อย่างแท้จริง) ระบบจะคำนวณไม่เพียงแต่การขึ้นต่อกันของอัปสตรีมของคุณ (ซึ่งคุณต้องพึ่งพา) เท่านั้น แต่ยังคำนวณด้วย จากมากไปน้อย (ซึ่งขึ้นอยู่กับคุณ) ดังนั้นเมื่อคุณเปลี่ยน API คุณจะรู้จักทุกคนว่าคุณกำลังพัง! ด้วยวิธีนี้ เมื่อคุณทำการเปลี่ยนแปลง คุณจะสามารถตรวจสอบได้ว่าผู้บริโภค API ทุกคนของคุณอัปเดตเป็นเวอร์ชันใหม่แล้ว และในความเป็นจริง บ่อยครั้งด้วยเครื่องมือ Rosie ที่พวกเขาเขียน คุณสามารถทำให้กระบวนการเป็นแบบอัตโนมัติได้อย่างสมบูรณ์
สิ่งนี้ช่วยให้โค้ดเบสของ Google ภายในเกือบจะสะอาดเหนือธรรมชาติ เนื่องจากมีหุ่นยนต์คนรับใช้วิ่งไปรอบ ๆ บ้านและทำความสะอาดทุกอย่างโดยอัตโนมัติหากพวกเขาเปลี่ยนชื่อ SomeDespicableLongFunctionName เป็น SomeDespicableLongMethodName เพราะมีคนตัดสินใจว่ามันเป็นหลานที่น่าเกลียดและจำเป็นต้องหลับใหล
และจริงๆ แล้ว มันใช้งานได้ค่อนข้างดีสำหรับ Google... ภายใน ฉันหมายถึงว่าใช่ ชุมชน Go ของ Google หัวเราะเยาะชุมชน Java ของ Google เพราะพวกเขานิสัยชอบปรับเปลี่ยนโครงสร้างใหม่อย่างต่อเนื่อง หากคุณรีสตาร์ทบางสิ่ง N ครั้ง นั่นหมายความว่าคุณไม่เพียงแต่ทำมันเสียหาย N-1 ครั้งเท่านั้น แต่หลังจากนั้นไม่นานก็ค่อนข้างชัดเจนว่าคุณอาจทำมันพังในการลองครั้งที่ N เช่นกัน แต่โดยส่วนใหญ่แล้ว พวกเขายังคงอยู่เหนือความยุ่งยากทั้งหมดนี้และรักษาโค้ดที่ "สะอาด"
ปัญหาเริ่มต้นเมื่อพวกเขาพยายามกำหนดทัศนคตินี้กับไคลเอนต์คลาวด์และผู้ใช้ API อื่น ๆ
ฉันได้แนะนำคุณเล็กน้อยเกี่ยวกับ Emacs, Android และ Java; มาดูแพลตฟอร์มล่าสุดที่ประสบความสำเร็จมายาวนาน: เว็บนั่นเอง คุณลองจินตนาการดูว่า HTTP วนซ้ำกี่ครั้งแล้วนับตั้งแต่ปี 1995 เมื่อเราใช้แท็กแบบกะพริบ และไอคอน "อยู่ระหว่างการก่อสร้าง" บนหน้าเว็บ
แต่มันก็ยังใช้งานได้! และเพจเหล่านี้ยังคงใช้งานได้! ใช่แล้ว เบราว์เซอร์คือแชมป์โลกในด้านความเข้ากันได้แบบย้อนหลัง Chrome เป็นอีกตัวอย่างหนึ่งของแพลตฟอร์ม Google ที่หายากซึ่งมีการขันอย่างถูกต้อง และอย่างที่คุณอาจเดาได้ Chrome ดำเนินงานอย่างมีประสิทธิผลในฐานะบริษัทแซนด์บ็อกซ์ที่แยกจากส่วนที่เหลือของ Google
ฉันอยากจะขอบคุณเพื่อนๆ ของเราที่เป็นผู้พัฒนาระบบปฏิบัติการ เช่น Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD และอื่นๆ ที่ทำงานร่วมกันได้อย่างยอดเยี่ยมในการทำงานร่วมกันแบบย้อนหลังบนแพลตฟอร์มที่ประสบความสำเร็จของพวกเขา (Apple ได้เกรด C ที่ดีที่สุดด้วย The ข้อเสียคือพวกมันทำลายทุกอย่างตลอดเวลาโดยไม่มีเหตุผลที่ดี แต่อย่างใดชุมชนก็หลีกเลี่ยงมันได้ทุกครั้งที่เปิดตัว และคอนเทนเนอร์ OS X ก็ยังไม่ล้าสมัยไปทั้งหมด...)
แต่เดี๋ยวก่อนคุณพูด เราไม่ได้เปรียบเทียบแอปเปิ้ลกับส้ม - ระบบซอฟต์แวร์แบบสแตนด์อโลนบนเครื่องเดียวเช่น Emacs/JDK/Android/Chrome เทียบกับระบบหลายเซิร์ฟเวอร์และ API เช่นบริการคลาวด์ใช่หรือไม่
เมื่อวานฉันทวีตเกี่ยวกับเรื่องนี้ แต่ในรูปแบบของ Larry Wall (ผู้สร้างภาษาโปรแกรม Perl - ประมาณต่อ) บนหลักการของ "ห่วย/กฎ" ฉันค้นหาคำว่า เลิก บนไซต์นักพัฒนาซอฟต์แวร์ของ Google และ Amazon และถึงแม้ว่า AWS จะมีก็ตาม หลายร้อย มีการเสนอบริการมากกว่า GCP ถึงเท่าตัว เอกสารสำหรับนักพัฒนาซอฟต์แวร์ของ Google กล่าวถึงการเลิกใช้งานบ่อยกว่าประมาณเจ็ดเท่า
หากใครก็ตามที่ Google อ่านข้อความนี้ พวกเขาคงพร้อมที่จะดึงแผนภูมิสไตล์ Donald Trump ออกมาแสดงให้เห็นว่าพวกเขากำลังทำทุกอย่างถูกต้องจริงๆ และฉันไม่ควรเปรียบเทียบอย่างไม่ยุติธรรม เช่น "จำนวนการกล่าวถึงคำที่เลิกใช้แล้วเทียบกับ จำนวนบริการ" "
แต่ตลอดหลายปีที่ผ่านมา Google Cloud ยังคงเป็นบริการอันดับ 3 (ฉันไม่เคยเขียนบทความเกี่ยวกับความพยายามที่ล้มเหลวในการเป็นอันดับ 2) แต่หากคนวงในเชื่อว่ามีความกังวลบางประการที่อาจลดลงในไม่ช้า ลำดับที่ 4.
ฉันไม่มีข้อโต้แย้งที่น่าสนใจในการ "พิสูจน์" วิทยานิพนธ์ของฉัน ทั้งหมดที่ฉันมีคือตัวอย่างที่มีสีสันที่ฉันสั่งสมมาเป็นเวลา 30 ปีในฐานะนักพัฒนา ฉันได้กล่าวถึงธรรมชาติเชิงปรัชญาอันลึกซึ้งของปัญหานี้แล้ว ในบางแง่มันก็เป็นเรื่องการเมืองในชุมชนนักพัฒนา บางคนเชื่อเช่นนั้น ผู้สร้าง แพลตฟอร์มควรให้ความสำคัญกับความเข้ากันได้ ในขณะที่แพลตฟอร์มอื่นๆ คิดว่านี่เป็นข้อกังวล ผู้ใช้ (ผู้พัฒนาเอง) หนึ่งในสอง อันที่จริงมันไม่ใช่ประเด็นทางการเมืองเมื่อเราตัดสินใจว่าใครควรเป็นผู้รับผิดชอบปัญหาทั่วไป?
นี่คือการเมือง และคงจะมีปฏิกิริยาตอบโต้ด้วยความโกรธต่อคำพูดของฉัน
ในขณะที่ ผู้ใช้งาน Google Cloud Platform และในฐานะผู้ใช้ AWS เป็นเวลาสองปี (ขณะทำงานให้กับ Grab) ฉันสามารถพูดได้ว่ามีความแตกต่างอย่างมากระหว่างปรัชญาของ Amazon และ Google ในเรื่องลำดับความสำคัญ ฉันไม่ได้พัฒนาบน AWS อย่างจริงจัง ดังนั้นฉันจึงไม่ทราบดีนักว่าพวกเขาลบ API เก่าบ่อยเพียงใด แต่มีข้อสงสัยว่าสิ่งนี้ไม่ได้เกิดขึ้นบ่อยเท่าที่ Google และฉันเชื่ออย่างแท้จริงว่าแหล่งที่มาของความขัดแย้งและความหงุดหงิดอย่างต่อเนื่องใน GCP เป็นหนึ่งในปัจจัยที่ใหญ่ที่สุดที่ขัดขวางการพัฒนาของแพลตฟอร์ม
ฉันรู้ว่าฉันไม่ได้ตั้งชื่อตัวอย่างเฉพาะของระบบ GCP ที่ไม่ได้รับการสนับสนุนอีกต่อไป ฉันสามารถพูดได้ว่าเกือบทุกอย่างที่ฉันเคยใช้ ตั้งแต่เครือข่าย (ตั้งแต่เก่าที่สุดไปจนถึง VPC) ไปจนถึงที่เก็บข้อมูล (Cloud SQL v1-v2), Firebase (ตอนนี้ Firestore ที่มี API ที่แตกต่างไปจากเดิมอย่างสิ้นเชิง), App Engine (อย่าเพิ่งเริ่มด้วยซ้ำ) , cloud endpoints Cloud Endpoint และจนถึง... ไม่รู้สิ - ทั้งหมดนี้อย่างแน่นอน บังคับให้คุณเขียนโค้ดใหม่หลังจากผ่านไปสูงสุด 2-3 ปี และพวกมันไม่เคยโอนย้ายแบบอัตโนมัติให้คุณเลย และบ่อยครั้ง . ราวกับว่ามันควรจะเป็นเช่นนั้น
และทุกครั้งที่ดู AWS ฉันจะถามตัวเองว่าทำไมฉันถึงยังใช้ GCP อยู่ เห็นได้ชัดว่าพวกเขาไม่ต้องการลูกค้า พวกเขาต้องการ ผู้ซื้อ. คุณเข้าใจความแตกต่างหรือไม่? ให้ฉันอธิบาย.
Google Cloud ก็มี ที่ซึ่งผู้คนเสนอโซลูชันซอฟต์แวร์ของตน และเพื่อหลีกเลี่ยงผลกระทบจากร้านอาหารที่ว่างเปล่า พวกเขาจำเป็นต้องกรอกข้อเสนอบางอย่าง ดังนั้นพวกเขาจึงเซ็นสัญญากับบริษัทที่ชื่อ Bitnami เพื่อสร้างโซลูชันจำนวนมากที่ปรับใช้ได้ด้วย "คลิกเดียว" หรือควร ฉันเขียนมันเองว่า “วิธีแก้ปัญหา” เพราะสิ่งเหล่านี้ไม่ได้แก้ปัญหาอะไรสักอย่าง เพียงแต่มีอยู่เป็นช่องทำเครื่องหมาย เป็นเพียงเครื่องมือทางการตลาด และ Google ไม่เคยสนใจว่าเครื่องมือใดๆ จะใช้งานได้จริงหรือไม่ ฉันรู้จักผู้จัดการผลิตภัณฑ์ที่เคยอยู่ในที่นั่งคนขับ และฉันรับรองได้เลยว่าคนเหล่านี้ไม่สนใจ
ยกตัวอย่าง โซลูชันการปรับใช้ที่คาดคะเนว่า "คลิกเดียว" . ฉันเบื่อหน่ายกับนิสัยแปลกๆ ของ Google Cloud SQL มาก ดังนั้นฉันจึงเริ่มมองหาการสร้างคลัสเตอร์ Percona ของตัวเองเป็นทางเลือกแทน และครั้งนี้ดูเหมือนว่า Google จะทำงานได้ดี พวกเขาจะช่วยฉันประหยัดเวลาและความพยายามด้วยการคลิกเพียงปุ่มเดียว!
เจ๋งไปเลย ไปกันเลย เราไปตามลิงค์แล้วคลิกปุ่มนี้ เลือก “ใช่” เพื่อยอมรับการตั้งค่าเริ่มต้นทั้งหมดและปรับใช้คลัสเตอร์ในโครงการ Google Cloud ของคุณ ฮ่าๆ มันใช้งานไม่ได้ ไม่มีอึนี้ทำงาน เครื่องมือนี้ไม่เคยได้รับการทดสอบและเริ่มเน่าตั้งแต่นาทีแรก และฉันจะไม่แปลกใจเลยหาก "โซลูชัน" มากกว่าครึ่งหนึ่งเป็นแบบคลิกเดียว (ตอนนี้เราเข้าใจแล้วว่าทำไมถึงเสนอราคา) โดยทั่วไป ไม่ทำงาน, ไม่เป็นผล. นี่เป็นความมืดมิดที่สิ้นหวังอย่างยิ่งซึ่งไม่ควรเข้าไปจะดีกว่า
แต่ Google ถูกต้อง ขอเรียกร้องให้ คุณใช้มัน พวกเขาต้องการให้คุณ ซื้อ. สำหรับพวกเขามันเป็นธุรกรรม พวกเขาไม่ต้องการอะไร สนับสนุน. มันไม่ได้เป็นส่วนหนึ่งของ DNA ของ Google ใช่ วิศวกรสนับสนุนซึ่งกันและกัน ดังที่เห็นได้จากเรื่องราวของฉันกับ Bigtable แต่ในด้านสินค้าและบริการสำหรับคนธรรมดานั้น เสมอ โหดเหี้ยมใน ซึ่งไม่เป็นไปตามเกณฑ์ในการทำกำไรแม้ว่าจะมีผู้ใช้หลายล้านคนก็ตาม
และนี่ถือเป็นความท้าทายอย่างแท้จริงสำหรับ GCP เพราะนี่คือ DNA ที่อยู่เบื้องหลังข้อเสนอระบบคลาวด์ทั้งหมด พวกเขาไม่ได้พยายามสนับสนุนอะไรเลย เป็นที่ทราบกันดีว่าพวกเขาปฏิเสธที่จะโฮสต์ (เป็นบริการที่ได้รับการจัดการ) ซอฟต์แวร์ของบุคคลที่สามใดๆ จนกระทั่งจนกว่า AWS จะทำเช่นเดียวกันและสร้างธุรกิจที่ประสบความสำเร็จ และเมื่อลูกค้าต้องการสิ่งเดียวกันอย่างแท้จริง อย่างไรก็ตาม ต้องใช้ความพยายามพอสมควรเพื่อให้ Google สนับสนุนบางสิ่งบางอย่าง
การขาดวัฒนธรรมการสนับสนุน ควบคู่ไปกับแนวคิด "มาทำลายมันเพื่อทำให้สวยงามยิ่งขึ้นกันเถอะ" ทำให้นักพัฒนาแปลกแยก
และนั่นไม่ใช่สิ่งที่ดีหากคุณต้องการสร้างแพลตฟอร์มที่มีอายุการใช้งานยาวนาน
Google ตื่นสิ ไอ้บ้า ตอนนี้ปี 2020 แล้ว คุณยังคงสูญเสีย ถึงเวลาส่องกระจกอย่างจริงจังแล้วตอบว่าคุณอยากอยู่ในธุรกิจคลาวด์ต่อไปหรือไม่
ถ้าอยากอยู่ต่อแล้ว. หยุดทำลายทุกสิ่งทุกอย่าง. พวกคุณรวยแล้ว นักพัฒนาเราไม่ทำ ดังนั้นเมื่อพูดถึงว่าใครจะเป็นผู้แบกรับภาระด้านความเข้ากันได้ คุณจะต้องรับภาระนั้นเอง ไม่ใช่สำหรับเรา
เพราะมีเมฆดีๆ อีกอย่างน้อยสามก้อน พวกเขากวักมือเรียก
และตอนนี้ฉันจะดำเนินการแก้ไขระบบที่เสียหายทั้งหมดของฉันต่อไป เอ๊ะ
จนกว่าจะถึงครั้งต่อไป!
PS Update หลังจากอ่านการสนทนาบางส่วนในบทความนี้ (การสนทนานั้นเยี่ยมมาก แต่อย่างไรก็ตาม) การสนับสนุน Firebase ไม่ได้ถูกยกเลิกและไม่มีแผนใดๆ ที่ฉันทราบ อย่างไรก็ตาม มีข้อบกพร่องในการสตรีมที่น่ารังเกียจซึ่งทำให้ไคลเอ็นต์ Java หยุดทำงานใน App Engine วิศวกรคนหนึ่งของพวกเขาช่วยฉันแก้ปัญหานี้ เมื่อฉันทำงานที่ Googleแต่พวกเขาไม่เคยแก้ไขข้อบกพร่องเลย ดังนั้นฉันจึงมีวิธีแก้ไขเส็งเคร็งที่ต้องรีสตาร์ทแอป GAE ทุกวัน และนี่ก็ผ่านมาสี่ปีแล้ว! ตอนนี้พวกเขามี Firestore แล้ว จะต้องทำงานหนักมากในการโยกย้าย เนื่องจากเป็นระบบที่แตกต่างไปจากเดิมอย่างสิ้นเชิง และข้อบกพร่องของ Firebase จะไม่ได้รับการแก้ไข ข้อสรุปอะไรที่สามารถสรุปได้? คุณสามารถขอความช่วยเหลือได้ ถ้าคุณทำงานในบริษัท. ฉันอาจเป็นคนเดียวที่ใช้ Firebase บน GAE เพราะฉันบันทึกคีย์น้อยกว่า 100 คีย์ในแอปแบบเนทีฟ 100% และแอปหยุดทำงานทุกๆ สองสามวันเนื่องจากข้อบกพร่องที่ทราบ ฉันจะพูดอะไรได้นอกจากการใช้มันโดยยอมรับความเสี่ยงเอง ฉันกำลังเปลี่ยนไปใช้ Redis
ฉันยังเห็นผู้ใช้ AWS ที่มีประสบการณ์มาบ้างกล่าวว่าโดยปกติแล้ว AWS จะไม่หยุดสนับสนุนบริการใดๆ และ SimpleDB ก็เป็นตัวอย่างที่ดี ข้อสันนิษฐานของฉันที่ว่า AWS ไม่มีจุดสิ้นสุดของการสนับสนุนแบบเดียวกับที่ Google ดูเหมือนจะสมเหตุสมผล
นอกจากนี้ ฉันสังเกตเห็นว่าเมื่อ 20 วันที่แล้ว ทีมงาน Google App Engine ทำลายโฮสต์ของไลบรารี Go ที่สำคัญ โดยปิดแอปพลิเคชัน GAE จากนักพัฒนา Go หลักรายหนึ่ง มันโง่จริงๆ
สุดท้ายนี้ ฉันได้ยินชาว Googler พูดคุยเกี่ยวกับปัญหานี้แล้ว และโดยทั่วไปก็เห็นด้วยกับฉัน (รักพวกคุณนะ!) แต่ดูเหมือนว่าพวกเขาคิดว่าปัญหานั้นไม่สามารถแก้ไขได้ เนื่องจากวัฒนธรรมของ Google ไม่เคยมีโครงสร้างแรงจูงใจที่เหมาะสม ฉันคิดว่าคงจะดีถ้าจะใช้เวลาพูดคุยถึงประสบการณ์ที่น่าทึ่งอย่างยิ่งที่ได้ร่วมงานกับวิศวกร AWS ขณะทำงานที่ Grab สักวันหนึ่งในอนาคต ฉันหวังว่า!
ใช่แล้ว ในปี 2005 พวกเขามีเนื้อฉลามหลายประเภทในบุฟเฟ่ต์ยักษ์ในอาคาร 43 และที่ฉันชอบคือเนื้อฉลามหัวค้อน อย่างไรก็ตาม ภายในปี 2006 Larry และ Sergei เลิกทานอาหารว่างที่ไม่ดีต่อสุขภาพทั้งหมด ดังนั้นระหว่างเรื่องราวของ Bigtable ในปี 2007 ไม่มีฉลามจริงๆ และฉันก็หลอกคุณ
เมื่อฉันดู Cloud Bigtable เมื่อสี่ปีที่แล้ว (ให้หรือรับ) นี่คือจุดที่ต้นทุนเกิดขึ้น ดูเหมือนว่าจะลดลงเล็กน้อยแล้ว แต่ก็ยังถือว่าแย่มากสำหรับคลังข้อมูลที่ว่างเปล่า โดยเฉพาะอย่างยิ่งเมื่อเรื่องราวแรกของฉันแสดงให้เห็นว่าตารางขนาดใหญ่ที่ว่างเปล่านั้นไม่สำคัญในระดับเท่าใด
ขออภัยที่ทำให้ชุมชน Apple ขุ่นเคืองและไม่ได้พูดอะไรดีๆ เกี่ยวกับ Microsoft ฯลฯ คุณไม่เป็นไร ฉันซาบซึ้งจริงๆ สำหรับการสนทนาทั้งหมดที่บทความนี้สร้างขึ้น! แต่บางครั้งคุณจำเป็นต้องสร้างกระแสเล็กน้อยเพื่อเริ่มการสนทนา รู้ไหม?
ขอบคุณที่อ่าน.
อัปเดต 2, 19.08.2020/XNUMX/XNUMX ลายทาง !
อัปเดต 3, 31.08.2020/2/2. ฉันได้รับการติดต่อจากวิศวกรของ Google ที่ Cloud Marketplace ซึ่งกลายเป็นเพื่อนเก่าของฉัน เขาต้องการทราบว่าเหตุใด CXNUMXD จึงไม่ทำงาน และในที่สุดเราก็พบว่าเป็นเพราะฉันสร้างเครือข่ายเมื่อหลายปีก่อน และ CXNUMXD ไม่ทำงานบนเครือข่ายเดิมเนื่องจากพารามิเตอร์เครือข่ายย่อยหายไปในเทมเพลต ฉันคิดว่าวิธีที่ดีที่สุดสำหรับผู้ใช้ GCP เพื่อให้แน่ใจว่าพวกเขารู้จักวิศวกรที่ Google เพียงพอ...
ที่มา: will.com