หลังย้ายไป Kubernetes นาน 11 สัปดาห์ บริษัทก็ลืมเหตุผลที่ตัวเองมีอยู่ (2020)

 (theolognion.com)
1 คะแนน โดย GN⁺ 2024-03-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สตาร์ทอัพซิลิคอนแวลลีย์ Xenobroom Inc. ตัดสินใจย้ายโครงสร้างพื้นฐานเซิร์ฟเวอร์เดิมไปใช้ Kubernetes หลังการใช้งานรายวันพุ่งสูงขึ้นในช่วงการระบาดใหญ่เมื่อเดือนพฤษภาคม 2020
  • การย้ายระบบขยายจากการปรับปรุงการ deploy แบบง่าย ๆ ไปเป็นงานระยะยาวในการทบทวนและออกแบบโครงสร้างที่อิง bash script และ VPS ใหม่
  • ขอบเขตงานขยายตัวต่อเนื่อง โดยมีทั้งการอัปเกรด dependency และไลบรารี การเปลี่ยนบางส่วนของ PostgreSQL ไปเป็น distributed KV storage และการใช้ประโยชน์จากความยืดหยุ่นของ AWS
  • staging server เดิมและการ deploy รายวันจาก develop branch ถูกแทนที่ด้วย workflow production-only CI, dynamic routing, A/B testing และการรองรับ dependency ตามภูมิภาค
  • เมื่อดูเหมือนว่าการย้ายระบบเสร็จสิ้นแล้ว ไม่มีใครในทีมจำ วัตถุประสงค์ของผลิตภัณฑ์ ได้ และผู้ใช้กับนักลงทุนก็ยอมรับว่าไม่เคยเข้าใจผลิตภัณฑ์เดิมตั้งแต่แรก ทำให้การกู้คืนแทบเป็นไปไม่ได้

ขอบเขตงานที่ขยายใหญ่ขึ้นจากการย้ายไป Kubernetes

  • Xenobroom Inc. เริ่มอัปเกรดโครงสร้างพื้นฐานเซิร์ฟเวอร์ในเดือนพฤษภาคม 2020
    • ตามเศษบันทึกประจำวันของ CEO และโน้ตวิศวกรรมของ CTO การใช้งานรายวันเพิ่มขึ้นอย่างรวดเร็วในช่วงการระบาดใหญ่
    • หลังจากนั้นจึงตัดสินใจย้ายโครงสร้างพื้นฐานเดิมไปใช้ Kubernetes
  • งานใช้เวลานานกว่าที่คาด
    • ต้องสร้าง ทบทวน และ re-engineer bash script แบบง่าย ๆ กับเครื่อง VPS ขึ้นใหม่
    • ภายในบริษัทมองว่าโอกาสนี้ยังสามารถอัปเกรด dependency และไลบรารีของซอฟต์แวร์ได้ด้วย
  • การเปลี่ยนแปลงโครงสร้างพื้นฐานนำไปสู่การปรับโครงสร้างที่ใหญ่กว่า
    • ประเมินว่าสามารถเปลี่ยนส่วนใหญ่ของฐานข้อมูล PostgreSQL ที่เคยทำงานบนเครื่องเดี่ยวไปเป็น distributed KV storage ได้
    • ยังมีเหตุผลเรื่องการใช้ประโยชน์จากความยืดหยุ่นของ AWS เพิ่มเข้ามา
    • staging server แบบง่ายที่เคย deploy ทุกวันจาก develop branch หายไป
    • แทนที่ด้วย workflow production-only CI ที่มี dynamic routing และกลายเป็นการตั้งค่าที่รองรับ A/B testing กับ dependency ตามภูมิภาคได้อย่างราบรื่น

การสูญเสียวัตถุประสงค์ของผลิตภัณฑ์และความช่วยเหลือจากภายนอก

  • เมื่อขั้นตอนการย้ายระบบดูเหมือนจะเสร็จสิ้นแล้ว ไม่มีใครในบริษัทจำ วัตถุประสงค์ของผลิตภัณฑ์ ได้
  • ผู้ใช้และนักลงทุนก็แก้สถานการณ์ไม่ได้
    • ทั้งสองกลุ่มยอมรับต่อสาธารณะว่าไม่เคยเข้าใจผลิตภัณฑ์อย่างถูกต้องมาตั้งแต่แรก
    • หลัง downtime หลายสัปดาห์ การกู้คืนความหมายของผลิตภัณฑ์จึงแทบเป็นไปไม่ได้
  • CEO ขอความช่วยเหลือจาก Phutar Afrayughum ผู้เป็นร่างทรงและผู้เชี่ยวชาญด้านการรับรู้พิเศษ
    • เขาถูกแนะนำว่าเป็นบุคคลที่ช่วยเพิ่มส่วนแบ่งตลาดของแอป messaging ของ Google และยังมีส่วนเกี่ยวข้องกับการพัฒนาเฟรมเวิร์ก Material Design
    • อย่างไรก็ตาม ความช่วยเหลือนี้ถูกระบุด้วยคำว่า “allegedly” จึงไม่ได้ยืนยันว่าเป็นข้อเท็จจริง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-02
ความเห็นจาก Hacker News

  • อันนี้ตลกยิ่งกว่า: พอไล่ผู้จัดการระดับกลางออก 20% ผลิตภาพของนักพัฒนาก็ดันเพิ่มขึ้น 3 เท่าโดยบังเอิญ
    https://www.theolognion.com/p/company-accidentally-increased...

    • จะมองว่าเป็นงานเสียดสีก็ยังยากเลย

  • ที่ $dayjob ของเราก็กำลังทำ migration แบบนี้อยู่เหมือนกัน เริ่มมาตั้งแต่ 2 ปีก่อน แต่ตอนนี้ยังไม่ถึง 30% เลย
    คนที่เคยตะโกนดังที่สุดว่า “ต้องย้ายไป Kubernetes ต้องฆ่า monolith” ตอนนี้ลืม Kubernetes ไปแล้ว เพราะมัวแต่ไปลองเล่น LLM กัน
    บางคนชอบ proof of concept กับของใหม่วิบวับจริง ๆ และบทบาทแบบนั้นก็ดูจะมีประโยชน์ในแบบของมัน

    • มันเป็นโครงสร้างที่ให้ ความพึงพอใจในงาน จากเทคโนโลยีใหม่ ๆ ที่ดูวิบวับ
      เลยดูเหมือนว่าคนฉลาดจำนวนมากจะทำงานอย่างพอใจได้ แม้อยู่ในบริษัทยักษ์ใหญ่สายเทคโนโลยีที่ไร้จริยธรรม บริษัทโฆษณา หรือบริษัทสอดส่องข้อมูล
      เหตุผลที่บริษัทมีอยู่ หรือสิ่งที่มันทำจริง ๆ นอกคอมพิวเตอร์ของตัวเอง แทบไม่สำคัญเท่ากับอิสระในการไล่ตามเทคโนโลยีและของใหม่
      บริษัทก็ชอบผลิตภาพและความกระตือรือร้นที่คนกลุ่มนี้สร้างขึ้น และยังจ่ายค่าตอบแทนดีด้วย
      ปกตินักพัฒนาแบบนี้ก็มีมโนธรรมอยู่หรอก แต่บ่อยครั้งมโนธรรมนั้นจะถูกดูดซับไปเป็นกิจกรรมเพื่อสังคมแบบที่เป็นมิตรกับองค์กร แล้วนำมาแสดงให้เห็นภายนอก
    • นี่ไม่ใช่การขยายขอบเขตงานเท่าไร แต่ใกล้เคียงกับ การพัฒนาที่ขับเคลื่อนด้วยเรซูเม่ แบบตั้งใจมากกว่า
      มีคนกำลังติ๊กกล่องไปทีละข้อเพื่อจะได้พูดว่า “เคยทำ X มาแล้ว”
      ในทีมเล็ก วิธีแบบนี้สามารถหยุดผลิตภาพได้เร็วมาก และมักถูกห่อหุ้มว่าเป็นความพยายามจะแก้ทุกปัญหา
      แต่ผลลัพธ์คือไม่ได้แก้ปัญหาอะไรเลย แถมสร้างปัญหาใหม่เพิ่มอีก
    • ในบริษัทที่อยู่ละแวก FAANG นั้น การเลื่อนตำแหน่ง ยากมาก และด้วยระบบเลเวล หลายครั้งวิธีเดียวที่จะขึ้นเงินเดือนได้ก็คือเลื่อนตำแหน่ง
      การเลื่อนตำแหน่งต้องมี promotion packet และ promotion packet ก็ต้องมีโปรเจ็กต์ใหญ่ ๆ หนัก ๆ
      สุดท้ายปัญหาหลักที่พยายามจะแก้จึงกลายเป็นเรื่องการเลื่อนตำแหน่ง ไม่ใช่ความต้องการของธุรกิจ และก็เกิดโปรเจ็กต์ขนาดใหญ่ที่ออกตามหาปัญหามารองรับตัวเอง
    • มันอาจมีประโยชน์ถ้าเป้าหมายคือเผาเงินบริษัท
      จากที่อธิบายมา มันดูไม่เข้าข่ายแม้แต่ proof of concept ด้วยซ้ำ เพราะเงื่อนไขพื้นฐานของ proof of concept คืออย่างน้อยมันต้องทำงานได้ แต่นี่ดูใกล้เคียงกับการสร้างอะไรสักอย่างเพื่อวิ่งตามกระแสและทำให้ดูเหมือนงานยุ่งมากกว่า
      ในมุมพนักงานเองก็คงไม่ใช่สภาพแวดล้อมที่น่าอยู่นานนัก
    • คนแบบนั้นนั่นแหละน่าจะได้เลื่อนตำแหน่งมากที่สุด โครงสร้างมันบิดเบี้ยวจริง ๆ

  • ในบล็อกนั้นยังมีบทความที่ตลกกว่านี้อีกหลายชิ้น อันนี้ชอบเป็นพิเศษ:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    แล้วก็มีอันนี้ด้วย:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

    • เพิ่ม RSS แล้วด้วย: https://www.theolognion.com/feed
      คนอื่นจะได้ลดการคลิกไปได้สองครั้ง

  • ถึงจะรู้ว่าเป็นมุก แต่ถ้าจะทำ postmortem สาเหตุที่ล้มเหลวก็น่าจะเป็นประมาณว่า “คนจำนวนมากในบริษัทคิดว่านี่เป็นโอกาสดีที่จะทำ การอัปเกรด dependency ของซอฟต์แวร์และไลบรารี ไปพร้อมกัน แล้วก็มองว่าส่วนใหญ่ของฐานข้อมูล PostgreSQL ที่เคยรันอยู่บนเครื่องเดียว สามารถเปลี่ยนเป็น distributed key-value store โดยใช้ประโยชน์จากความยืดหยุ่นมหาศาลของ AWS ได้”
    ต้องคุม ขอบเขตงาน ให้ดี

    • นั่นแหละคือแก่นของมุกนี้เลย
      บนโลกนี้มีคนมากมายที่สนใจเทคโนโลยีที่ตัวเองใช้ มากกว่าผลิตภัณฑ์ที่ตัวเองกำลังสร้าง
      การโฟกัสที่ผลิตภัณฑ์หมายถึงการรู้ขอบเขต และไม่ออกแบบเกินความจำเป็นเร็วเกินไป
      มุกนี้โฟกัสที่ Kubernetes ก็จริง แต่จะเปลี่ยนเป็น server-side rendering, AI, $modernFrontendLib หรือ $modernLanguage ก็ใช้ได้เหมือนกัน
    • บริษัทเองก็ต้องคุมขอบเขตด้วย
      ถ้าธุรกิจของคุณไม่ใช่การขายโครงสร้างพื้นฐานคลาวด์ ก็ใช้ ผู้ให้บริการคลาวด์ ที่มีอยู่แล้วก็พอ
      โดยเฉพาะถ้าคุณจ่ายเงินให้ผู้ให้บริการคลาวด์อยู่แล้ว การไม่ใช้ Kubernetes มักจะดีกว่า

  • ในโลกความเป็นจริง การย้ายไป Kubernetes ภายใน 11 สัปดาห์ คงถูกนับว่าเป็นความสำเร็จครั้งใหญ่

    • เอาเข้าจริงคงใช้เวลา 11 เดือน และตอนนี้ก็คงกลายเป็นอะไรสักอย่างที่เรียกตัวเองว่า “cloud-native”
      แน่นอนว่าการดูแลฐานข้อมูลคงลำบากนิดหน่อย เพราะลืมตั้งค่า storage ของ Kubernetes ให้ถูกต้อง พอ pod ถูกย้ายกะทันหันข้อมูลก็หายไป
    • ถ้าใช้ Docker อยู่แล้ว แทบไม่มีเหตุผลอะไรเลยที่มันต้องใช้เวลานานขนาดนั้น
      ถ้ายังไม่ได้ใช้ Docker ปัญหาใน migration คล้าย ๆ กันก็น่าจะไม่ใช่ Kubernetes เอง

  • ไม่เคยมีช่วงไหนที่การรันระบบจะง่ายและถูกเท่าตอนนี้อีกแล้ว
    แต่พวกวิศวกรกลับชอบแนวทางที่ต้องระดมคณะสำรวจ ปีน Everest ไปถ่ายรูปพิซซ่าบนยอดเขา จากนั้นบินเอากลับบ้าน เช่า Lamborghini ไปวิ่ง Mongol Rally แล้วค่อย ส่งพิซซ่าหลังจาก 18 เดือน
    ทั้งที่จริง ๆ แค่ขี่สกู๊ตราคาถูกลงไปตามถนนก็ชนะแล้ว

    • ฉันยังไม่เคยทำงานที่ความซับซ้อนที่วิศวกรยัดเข้าไปจะสูสีกับความซับซ้อนที่ผู้บริหารยัดเข้ามาเลย

  • ถ้าเป็นเทคโนโลยีที่ซับซ้อน ก็ควรเรียนรู้มันก่อน ลองกับบริการเล็ก ๆ ที่ไม่สำคัญก่อน
    ทำทีละอย่าง และเริ่มจากความเรียบง่าย
    ฉันเคยย้ายบริการของเราไป Kubernetes ได้โดยไม่มีปัญหา แต่ต้องใช้เวลา 2 ปี ในการย้ายบริการเล็ก ๆ เพื่อเรียนรู้และทดลอง
    หลังจากลองมาหลายแนวทางก็พบวิธีที่เหมาะที่สุด ซึ่งไม่ใช่วิธีที่หาเจอได้ตรง ๆ จากบนอินเทอร์เน็ต
    เราใช้ GitOps แต่ไม่ทำแบบอัตโนมัติ แค่รัน kubectl apply -k กับสิ่งที่จำเป็น เพราะตอนนั้นมองว่า flux ซับซ้อนเกินจำเป็นสำหรับการเริ่มต้น
    ตอนนี้บริการมีเป็นหลายสิบตัวแล้ว และเราก็มีความเข้าใจมากขึ้น เลยกำลังคิดจะนำ flux มาใช้

  • ในปี 1977 ฉันทำงานเป็นทนายความว่าความหนุ่มในสำนักงานกฎหมายที่คิดค่าบริการเป็นรายชั่วโมง
    เราจะจดงานที่ทำในแต่ละคดีลงบนกระดาษ และเจ้าหน้าที่ธุรการจะตัดแถบที่ฉีกออกได้จากกระดาษที่กรอกเสร็จแล้วไปแปะบนแผ่นบอร์ดด้านในของแฟ้มกระดาษของแต่ละคดี
    ในปี 1979 ฉันซื้อ RadioShack Tandy I และไม่นานก็หมกมุ่นกับ Foxbase ซึ่งเป็นโปรแกรมฐานข้อมูลบน DOS ที่บ้าน ต่อมามันกลายเป็น FoxPro และ Microsoft ก็เข้าซื้อในช่วงต้นทศวรรษ 1990
    ในปี 1981 ฉันเปิดสำนักงานกฎหมายของตัวเอง และนวัตกรรมล่าสุดด้านงานสำนักงานในตอนนั้นคือแฟกซ์กับเครื่องพิมพ์ดีดไฟฟ้าที่มีหน้าจอหนึ่งบรรทัด หน่วยความจำ และดิสก์ขนาดเล็กไว้เก็บแบบฟอร์ม ตอนนั้นภาคธุรกิจยังไม่ได้ใช้คอมพิวเตอร์ส่วนบุคคล
    สำนักงานกฎหมายของฉันขยายเป็นทนายความราว 10 คนและพนักงานสนับสนุน 12 คนอย่างรวดเร็ว และฉันซื้อคอมพิวเตอร์ Compaq ให้เลขานุการทุกคน
    ฉันใช้เวลาไปมากกับการเขียนโปรแกรมบันทึกเวลาและออกบิลเพื่อแทนวิธีแปะแถบด้วยมือ และยังเรียนรู้วิธีติดตั้งเครือข่ายแล้วลงมือทำเองด้วย
    สำนักงานกฎหมายอื่นที่ฉันรู้จักไม่มีคอมพิวเตอร์เลยสักเครื่อง แต่เรามีมากกว่า 10 เครื่องสำหรับพนักงานสนับสนุน และมี Compaq แบบ “พกพา” อีก 4-5 เครื่องให้ทนายใช้ตรวจบิลก่อนส่งให้ลูกค้า
    ในขณะเดียวกัน ฉันก็กำลังทำลายธุรกิจของตัวเองอยู่ ตอนที่คนอื่นยังไม่มีคอมพิวเตอร์สักเครื่อง เรากลับมีเทคโนโลยีระดับแนวหน้าของโลก แต่ฉันไม่โฟกัสกับงานกฎหมายหรือการหาลูกค้าองค์กร กลับปิดประตูแล้วหมกตัวเขียนโปรแกรม
    สุดท้ายฉันก็ปิดสำนักงานกฎหมายในปี 1994
    ถึงอย่างนั้นก็ยังเป็นช่วงเวลาที่น่าตื่นเต้น ไม่นานทุกสำนักงานกฎหมายก็มีคอมพิวเตอร์ไว้ทำเวิร์ดโปรเซสซิง แต่ซอฟต์แวร์ออกบิลเชิงพาณิชย์ยังไม่มี
    ตลอดราว 24 เดือน ทนายจากสำนักงานกฎหมายอื่นที่ร่วมงานกับฉันต่างก็อยากได้โปรแกรมออกบิลของฉัน
    แต่ฉันต้องจมอยู่กับงานคดี ขณะเดียวกันก็หมกมุ่นอยู่กับการเขียนโปรแกรมที่สนุก และงานกฎหมายของฉันก็เป็นห้องทดลองที่สมบูรณ์แบบสำหรับโปรแกรมนั้น น่าเสียดายที่การเขียนโปรแกรมนั่นเองที่ทำให้ธุรกิจของฉันพัง

    • วิธีใช้แถบที่ฉีกออกได้นั่นน่าสนใจมาก อยากรู้ว่ามันเป็นวิธีที่ใช้กันทั่วไปในการติดตามเวลาตอนนั้นหรือเปล่า
      ถ้ายังมีรูปอยู่ก็อยากเห็น

  • ในสายงานของผม ถ้าเอา “Kubernetes” ไปแทนด้วย GraphQL/React/Next ก็ยังตรงเป๊ะ
    แน่นอนว่ามันคือการย้ายแอปที่ทำงานได้สมบูรณ์อยู่แล้ว ซึ่งส่วนใหญ่ก็เป็นแค่ CRUD
    ทั้งที่ไม่จำเป็นต้องรับ trade-off ที่มาพร้อมกับ GraphQL หรือฟรอนต์เอนด์แบบโต้ตอบเลยก็ยังทำกัน
    ยิ่งอยู่ในวงการนี้นานเท่าไร ก็ยิ่งเห็นว่าคนที่อยู่ในตำแหน่งรับผิดชอบจำนวนมากไม่ค่อยรู้ว่าตัวเองกำลังทำอะไร

    • ไม่มีใครได้รางวัลจากการทำให้สิ่งเดิมที่ใช้งานได้ดีอยู่แล้วดำเนินต่อไป
      คนได้รางวัลจากการเปลี่ยนแปลง และแค่ต้องทำให้ดูได้อย่างน้อยว่าการเปลี่ยนนั้นกำลังสร้างผลลัพธ์หรือสักวันหนึ่งจะสร้างผลลัพธ์

  • ตอนนี้ผมกำลังสู้ทั้งกลางวันกลางคืนมา 4 เดือนเพื่อย้ายบล็อบ 500,000 ชิ้นจาก MinIO แบบ self-hosted ไปยัง managed blob storage แต่เวลาที่ได้ทำงานที่มีประสิทธิผลจริง ๆ โดยไม่ติดการเมืองและระบบราชการรวมกันยังไม่ถึง 1 สัปดาห์
    เพราะงั้นการย้ายไป Kubernetes ที่ใช้เวลา 11 สัปดาห์ฟังดูเหมือนความสำเร็จครั้งใหญ่เลย