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

 (theolognion.com)
1 คะแนน โดย GN⁺ 2024-03-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

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

  • Xenobroom Inc. สตาร์ทอัพหน้าใหม่ในซิลิคอนแวลลีย์ เริ่มกระบวนการอัปเกรดโครงสร้างพื้นฐานเซิร์ฟเวอร์ในเดือนพฤษภาคม 2020

  • เมื่อการใช้งานรายวันพุ่งสูงขึ้นท่ามกลางสถานการณ์แพร่ระบาดทั่วโลก บริษัทจึงตัดสินใจย้ายโครงสร้างพื้นฐานเดิมไปยัง Kubernetes

  • การทบทวนและออกแบบใหม่ให้กับสคริปต์ Bash แบบเรียบง่ายและเครื่อง VPS ใช้เวลานานกว่าที่คาดไว้

  • บริษัทมองว่านี่เป็นโอกาสดีในการอัปเกรด dependency และไลบรารีของซอฟต์แวร์

  • ส่วนใหญ่ของฐานข้อมูล PostgreSQL ที่เคยรันอยู่บนเครื่องเดียว ถูกแปลงเป็นระบบจัดเก็บ KV แบบกระจายที่ใช้ความยืดหยุ่นของ AWS

  • เซิร์ฟเวอร์ staging ทั่วไปที่ทำการ deploy รายวันจาก branch develop ถูกแทนที่ด้วย workflow เฉพาะ production ที่รองรับ CI

  • เมื่อกระบวนการย้ายเสร็จสิ้น ก็ไม่มีใครในบริษัทจำจุดประสงค์ของผลิตภัณฑ์ได้อีกต่อไป

  • ทั้งผู้ใช้และนักลงทุนต่างก็ไม่เข้าใจผลิตภัณฑ์ดั้งเดิมอยู่แล้ว และหลังจาก downtime หลายสัปดาห์ การกู้คืนความหมายของผลิตภัณฑ์ก็แทบเป็นไปไม่ได้

  • CEO จึงขอความช่วยเหลือจากผู้เชี่ยวชาญด้านพลังจิต Phutar Afrayughum ผู้ซึ่งเป็นที่รู้จักว่าเคยช่วยให้ส่วนแบ่งตลาดแอปส่งข้อความของ Google เพิ่มขึ้น

ความเห็นของ GN⁺

  • บทความนี้นำเสนอผลกระทบของกระบวนการย้ายไป Kubernetes ที่มีต่อบริษัทในเชิงเสียดสี ในโลกความเป็นจริง การย้ายเทคโนโลยีก็สามารถนำมาซึ่งการเปลี่ยนแปลงครั้งใหญ่ในการดำเนินงานขององค์กร และบางครั้งอาจทำให้สูญเสียเป้าหมายดั้งเดิมไปได้
  • เมื่อต้องพิจารณาการย้ายเทคโนโลยี จำเป็นต้องมีความเข้าใจที่ชัดเจนไม่เพียงด้านเทคนิค แต่รวมถึงวิสัยทัศน์และเป้าหมายขององค์กรด้วย สิ่งนี้ตอกย้ำหลักการที่ว่าเทคโนโลยีควรสนับสนุนจุดมุ่งหมายขององค์กร
  • Kubernetes เป็นแพลตฟอร์ม container orchestration ที่หลายบริษัทนิยมใช้ แต่ก่อนนำมาใช้จำเป็นต้องมีการเตรียมตัวและความเชี่ยวชาญอย่างเพียงพอ มิฉะนั้นความซับซ้อนและภาระในการดูแลจัดการอาจเพิ่มขึ้น
  • บทความนี้เตือนให้ตระหนักว่า การนำเทคโนโลยีมาใช้ไม่ได้ให้ผลลัพธ์เชิงบวกเสมอไป บางครั้งเทคโนโลยีอาจทำให้คุณค่าและเป้าหมายที่เป็นแก่นแท้ขององค์กรพร่ามัวลงได้
  • แพลตฟอร์มอื่นที่มีความสามารถคล้าย Kubernetes ได้แก่ Docker Swarm และ Apache Mesos ซึ่งอาจเป็นทางเลือกแทน Kubernetes ได้ขึ้นอยู่กับสถานการณ์

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

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

 
GN⁺ 2024-03-02
ความคิดเห็นบน Hacker News

  • กรณีเลิกจ้างผู้จัดการระดับกลาง 20% แล้วทำให้ผลิตภาพการพัฒนาเพิ่มขึ้น 3 เท่า

    มีกรณีหนึ่งที่บริษัทเลิกจ้างผู้จัดการระดับกลาง 20% แล้วบังเอิญทำให้ผลิตภาพการพัฒนาเพิ่มขึ้น 3 เท่า

  • แบ่งปันประสบการณ์การย้ายไป Kubernetes

    ชี้ให้เห็นว่าการย้ายไป Kubernetes ที่กำลังดำเนินอยู่ในตอนนี้ผ่านไปแล้ว 2 ปีแต่ยังไม่เสร็จถึง 30% และคนที่เคยผลักดัน Kubernetes อย่างหนักในตอนแรก ตอนนี้กลับไปสนใจ LLMs แล้ว สะท้อนให้เห็นว่ามีคนที่ชอบของใหม่แวววาวอยู่เสมอ และบทบาทแบบนี้ก็อาจมีประโยชน์ในตัวมันเอง

  • บทความสนุก ๆ ในบล็อก Theolognion

    ในบล็อก Theolognion มีบทความน่าสนใจหลายชิ้น โดยเฉพาะเรื่อง "นักพัฒนาที่สร้างระบบรวบรวมโน้ตที่สมบูรณ์แบบ" และเรื่องที่ AI วิเคราะห์คอมเมนต์ใน Hacker News แล้วแก้ปัญหาการเมือง เศรษฐกิจ และการแพทย์ได้ทั้งหมด ซึ่งอ่านสนุกมาก

  • มุกตลกเกี่ยวกับสาเหตุของความล้มเหลว

    มีการสมมุติว่าในโพสต์มอร์เท็ม (post-mortem) ที่วิเคราะห์สาเหตุของความล้มเหลว บริษัทคงมองว่านี่เป็นโอกาสดีในการอัปเกรด dependency และไลบรารีซอฟต์แวร์ และอาจเปลี่ยน PostgreSQL database ส่วนใหญ่ที่รันอยู่บนเครื่องเดียวให้กลายเป็น distributed KV storage โดยใช้ประโยชน์จากความยืดหยุ่นของ AWS

  • กรณีความสำเร็จจริงของการย้ายไป Kubernetes ภายใน 11 สัปดาห์

    ในความเป็นจริง การย้ายไป Kubernetes ให้เสร็จภายใน 11 สัปดาห์ถือเป็นความสำเร็จครั้งใหญ่ที่ควรได้รับการยอมรับ

  • เคล็ดลับการย้ายบริการไป Kubernetes

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

  • ความง่ายและต้นทุนต่ำของการดูแลระบบ

    การดูแลระบบในปัจจุบันง่ายและถูกกว่าที่เคยมาก แต่เหล่าวิศวกรมักเลือกวิธีที่ซับซ้อนและไม่มีประสิทธิภาพในการทำงานง่าย ๆ อยู่บ่อยครั้ง

  • ปัญหาของวงการที่เกี่ยวข้องกับการเลือกเทคโนโลยี

    สำหรับการย้ายแอปพลิเคชันที่ทำงานได้สมบูรณ์อยู่แล้วไปใช้เทคโนโลยีอย่าง GraphQL/React/Next คนที่อยู่ในวงการมานานให้ความเห็นว่าตนรู้สึกว่าหลายคนไม่รู้จริง ๆ ว่ากำลังทำอะไรอยู่

  • ประสบการณ์การย้ายไปใช้ cloud storage

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

  • ประสบการณ์การนำคอมพิวเตอร์มาใช้ในสำนักงานกฎหมายยุคทศวรรษ 1970

    มีการเล่าประสบการณ์การทำงานเป็นทนายความหนุ่มในปี 1977 ที่คิดค่าบริการแบบรายชั่วโมง และการซื้อคอมพิวเตอร์ Tandy I ในปี 1979 เพื่อใช้โปรแกรมฐานข้อมูลอย่าง Foxbase ต่อมาในปี 1981 ได้เปิดสำนักงานกฎหมายของตนเอง ในเวลานั้นเครื่องแฟกซ์และเครื่องพิมพ์ดีดไฟฟ้าคือเทคโนโลยีล้ำสมัยที่ช่วยเพิ่มผลิตภาพในสำนักงาน แต่ยังไม่ได้ใช้คอมพิวเตอร์ส่วนบุคคล ผู้เขียนซื้อคอมพิวเตอร์ Compaq ให้เลขานุการทุกคน ใช้เวลาอย่างมากไปกับการเขียนโปรแกรมบันทึกเวลาและวางบิลเพื่อแทนระบบคิดค่าบริการแบบทำมือ และยังติดตั้งเครือข่ายด้วย อย่างไรก็ตาม เมื่อมัวแต่ทุ่มเทให้กับเทคโนโลยี ก็ละเลยทั้งงานในฐานะทนายความและการรักษาความสัมพันธ์กับลูกค้าธุรกิจ สุดท้ายจึงต้องปิดสำนักงานในปี 1994 ตอนนั้นทุกสำนักงานใช้คอมพิวเตอร์เพื่อทำ word processing แล้ว แต่ยังไม่มีโปรแกรมวางบิลเชิงพาณิชย์ และแม้ทนายจากสำนักงานอื่นจะอยากได้โปรแกรมวางบิลของผู้เขียน ผู้เขียนก็มัวแต่สนุกกับการเขียนโปรแกรมจนทำให้ธุรกิจล้มเหลว