Figma ย้ายไปใช้ K8s ภายใน 12 เดือนได้อย่างไร

 (figma.com)
1 คะแนน โดย GN⁺ 2024-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Figma ตั้งเป้าย้ายบริการหลักที่ถูกคอนเทนเนอร์ไว้แล้วจาก ECS ไปยัง Kubernetes บน EKS เพื่อลดข้อจำกัดของแพลตฟอร์มในระยะยาวโดยไม่ให้เกิด downtime
  • บน ECS มีข้อจำกัดใหญ่ทั้งการไม่มี StatefulSets, ความยากในการรัน OSS ที่อิง Helm chart และข้อจำกัดด้านการแยก node ขณะที่ Kubernetes เปิดทางเลือกใน ระบบนิเวศ CNCF เช่น Keda, Karpenter และ Istio
  • การย้ายระบบจำกัดขอบเขตไว้ที่การคงรูปแบบการรันบริการ การ deploy และ abstraction ของเครื่องมือเดิม แล้วเปลี่ยนเฉพาะ orchestration โดยรวมการตั้งค่าบริการแบบ Bazel และสถาปัตยกรรม EKS 3 คลัสเตอร์ ไว้ในขอบเขตเริ่มต้น
  • ระหว่างการเปลี่ยนผ่าน Figma ใช้การทดสอบโหลด, การย้ายทราฟฟิกแบบค่อยเป็นค่อยไปด้วย Weighted DNS, การย้ายบริการจริงตั้งแต่เนิ่น ๆ, การซ่อน raw YAML และการทำงานร่วมกับเจ้าของบริการ เพื่อให้ rollback ได้
  • ภายในเดือนมกราคม 2024 บริการที่มีความสำคัญสูงส่วนใหญ่ถูกย้ายไป EKS แล้ว พร้อมได้ทั้งการลดต้นทุนจาก overprovisioning, ความน่าเชื่อถือที่ดีขึ้น และประสบการณ์นักพัฒนาที่ดีขึ้น ก่อนเดินหน้าต่อด้วยงานด้าน logging, autoscaling และการย้ายไป Graviton

ทำไมจึงย้ายจาก ECS ไป Kubernetes

  • เมื่อต้นปี 2023 Figma รันทุกบริการด้วย คอนเทนเนอร์ อยู่แล้ว และใช้ AWS Elastic Container Service (ECS) เป็นแพลตฟอร์ม orchestration
  • เมื่อพิจารณาแพลตฟอร์มคอมพิวต์รุ่นถัดไป Figma มองว่าการต่อยอดบน ECS ต่อไปจะทำให้สร้างความสามารถที่ต้องการในระยะยาวได้ยาก
  • Figma ไม่ใช่บริษัทที่ดูแลไมโครเซอร์วิสหลายพันตัว จึงสามารถควบคุมขอบเขตของการย้ายไป Kubernetes ได้อย่างสมจริง
    • แม้บางครั้งจะต้องมีบริการใหม่เพื่อเหตุผลด้าน isolation หรือ performance แต่บริการหลักก็ให้ทั้งการแยกโมดูลพื้นฐานและการแยกทราฟฟิกอยู่แล้ว
    • ผลิตภัณฑ์ใหม่ก็มักรองรับโดยเพิ่ม logic เข้าไปในบริการหลักเดิม แทนการสร้างบริการใหม่

ความสามารถที่ ECS ยังขาด

  • ECS ไม่รองรับ StatefulSets ของ Kubernetes ทำให้การดูแล data store แบบ consensus ที่ต้องการ strong consistency อย่าง etcd ทำได้ยาก
    • Figma แก้ปัญหาชั่วคราวด้วยโค้ด custom ที่อัปเดต membership ของคลัสเตอร์แบบไดนามิกตอนเริ่มคอนเทนเนอร์ etcd
    • วิธีนี้เปราะบางและดูแลรักษายาก ขณะที่บน Kubernetes โดยทั่วไปจะใช้การกำหนด network แบบมี state ของ StatefulSets
  • บน ECS รันชุดบริการที่นิยามด้วย Helm charts ได้ยาก
    • หลายทีมต้องการรันซอฟต์แวร์ OSS อย่าง Temporal แต่บน ECS ต้องพอร์ตแต่ละบริการมาเป็นนิยาม Terraform ด้วยมือ
  • แม้แต่การปิดเครื่อง EC2 เครื่องเดียวที่มีปัญหาอย่างนุ่มนวลบน ECS on EC2 ก็ยังยุ่งยาก
    • บน EKS หาก cordon node ที่มีปัญหา API server จะเคารพขั้นตอนการยุติงานและย้าย Pod ไปยังเครื่องอื่นได้

ระบบนิเวศ CNCF และทางเลือกของแพลตฟอร์ม

  • หากใช้ ECS ต่อไป การนำเทคโนโลยีโอเพนซอร์สใน Cloud Native Computing Foundation (CNCF) ecosystem มาใช้จะทำได้ยาก
  • autoscaling เป็นหัวข้อสำคัญของแพลตฟอร์มคอมพิวต์รุ่นถัดไป
    • ในเวลานั้น Figma ยังไม่ได้ใช้ autoscaling กับบริการที่รันในคอนเทนเนอร์
    • บริการถูก provision ไว้เพื่อรองรับโหลดช่วงพีค แม้ในช่วงทราฟฟิกต่ำอย่างกลางคืนและวันหยุดสุดสัปดาห์ ทำให้เกิดต้นทุนที่ไม่จำเป็น
    • Keda ใน ecosystem ของ Kubernetes รองรับการสเกลจากทั้งการใช้งาน CPU, ความยาวคิว AWS SQS และ custom metric จาก Datadog
  • service mesh ก็อาจกลายเป็นสิ่งจำเป็นในระยะยาว
    • ทราฟฟิกระหว่างบริการเดิมถูก route ผ่าน AWS Application Load Balancers (ALB) และ Network Load Balancers (NLB)
    • NLB ใช้เวลาหลายนาทีในการลงทะเบียน target ใหม่และถอด target เดิม ทำให้การ deploy ฉุกเฉินช้าลงและเพิ่มเวลาเฉลี่ยในการกู้คืนจาก incident
    • Envoy ให้ความยืดหยุ่นในการปรับแต่งสูงกว่าและรองรับการรัน custom filter
    • Figma เคยวางคลัสเตอร์เครื่อง Envoy แบบแยกไว้หน้าบริการหลักเพื่อทำหน้าที่เป็น proxy และเคยใช้ custom filter เพื่อลดโหลดระหว่าง incident
    • บน EKS มีตัวเลือกโอเพนซอร์สอย่าง Istio มากมาย แต่บน ECS ฟีเจอร์ลักษณะเดียวกันจะต้องสร้างขึ้นใหม่เอง

ข้อดีด้านการปฏิบัติการจากการใช้แพลตฟอร์มยอดนิยม

  • Figma ไม่ต้องการเป็นผู้ใช้รายใหญ่ที่สุดของบริการหรือซอฟต์แวร์ใด ๆ
    • ผู้ใช้รายใหญ่ที่สุดมักชนกับข้อจำกัดและจุดหยาบของระบบก่อนใคร
    • Kubernetes ถูกใช้โดยบริษัทขนาดใหญ่จำนวนมากกับแพลตฟอร์มคอมพิวต์ขนาดมหาศาล ทำให้ Figma ยังเป็นผู้ใช้ที่เล็กกว่ามาก
  • Kubernetes ช่วยลด vendor lock-in
    • EKS ให้ข้อดีของ control plane ที่ผู้ให้บริการดูแลให้
    • แต่บริการต่าง ๆ ก็ถูกเขียนให้รันบน Kubernetes มาตรฐานได้ จึงไม่ต้องแบกรับภาระมากนักหากต้องย้ายไปแพลตฟอร์ม Kubernetes จากผู้ให้บริการรายอื่นหรือแพลตฟอร์มที่โฮสต์เอง
  • การจ้างวิศวกรที่มีประสบการณ์ Kubernetes ก็ทำได้ง่ายกว่า
    • วิศวกรที่มีประสบการณ์เดิมสามารถปรับตัวได้เร็ว และช่วยเติมบริบทในส่วนที่อาจเป็นการตัดสินใจใหม่สำหรับ Figma

หลักการกำหนดขอบเขตของการย้ายระบบ

  • ในการย้ายระบบขนาดใหญ่ วิธีที่ปลอดภัยคือเปลี่ยนเฉพาะ ระบบแกนหลัก ที่ต้องการเปลี่ยน และคง abstraction ที่ผู้ใช้แพลตฟอร์มมองเห็นไว้ให้มากที่สุด
  • Figma จึงจำกัดขอบเขตไว้ที่การย้ายจากการรันบน ECS ไปเป็น EKS โดยไม่เปลี่ยนวิธีรันบริการ วิธี deploy หรือเครื่องมือที่บริการใช้โต้ตอบกัน
  • แม้งานบางอย่างจะดูไม่เหมือนการเปลี่ยนฟีเจอร์ แต่ก็อาจสร้าง ผลกระทบลำดับสอง ได้ ทำให้กำหนดการของการย้ายระบบขนาดใหญ่บานปลายได้ง่าย
  • มีข้อยกเว้นอยู่สองกรณี
    • หากการบังคับให้ระบบใหม่ทำงานเหมือนระบบเดิมต้องใช้ความพยายามเพิ่มมากเกินไป ก็อาจยอมรับผลกระทบลำดับสองและเลือกแนวทางใหม่
    • หากเป็นการตัดสินใจแบบ one-way door ที่กลับมาเปลี่ยนทีหลังได้ยากหรือมีค่าใช้จ่ายสูง ก็อาจใช้แนวทางใหม่ตั้งแต่แรก

การปรับปรุงที่รวมไว้ในขอบเขต

  • ประสบการณ์นักพัฒนา

    • นิยามบริการบน ECS เดิมส่วนใหญ่ถูกสร้างและแก้ไขด้วย Terraform
    • กระบวนการนี้ใช้ Terraform apply เพื่อสร้าง template ของ ECS task set ที่มีอินสแตนซ์เป็น 0 ก่อน จากนั้นในขั้นตอน deploy จึงคัดลอก template ไปแทนที่ image hash แล้วค่อย deploy task set ที่มีจำนวนอินสแตนซ์ไม่เป็น 0 ไปยัง ECS
    • แม้แต่การเพิ่ม environment variable เพียงตัวเดียวก็ต้องเขียนและ apply Terraform ก่อน แล้วจึงค่อย deploy และถ้าลำดับผิดก็จะใช้ environment variable ในโค้ดอย่างปลอดภัยไม่ได้จนเกิดบั๊ก
    • บน EKS Figma เปลี่ยนมาเก็บนิยามบริการไว้ที่เดียวและ deploy การเปลี่ยนแปลงในขั้นตอนเดียว
    • Figma สร้างแนวทางภายในแบบเรียบง่ายโดยนิยามบริการผ่านไฟล์ตั้งค่า Bazel แล้วสร้าง YAML ของ service definition และ configuration YAML อย่าง Ingress โดยอัตโนมัติ
    • YAML จะถูกสร้างโดยเครื่องมือ CI ตอน commit โค้ด และนำไป apply ผ่านระบบ deploy ภายในบริษัท

  • ความน่าเชื่อถือ

    • สำหรับแต่ละบริการ Figma ตั้งค่าให้มี EKS 3 คลัสเตอร์ รัน Pod และรับทราฟฟิก
    • เมื่อทุก operation เกิดขึ้นในระดับคลัสเตอร์ ความเสียหายจาก outage ทั้งหมดจะลดลงเหลือกระทบเพียง 1 ใน 3 ของบริการ
    • สำหรับบริการที่รองรับการ retry ของ request หรือการประมวลผลแบบ asynchronous มักลดผลกระทบต่อผู้ใช้ได้อย่างมาก
    • แม้สถาปัตยกรรมนี้จะเพิ่มความซับซ้อนด้าน operation อย่างมาก เช่นใน deployment pipeline แต่ Figma มองว่าคุ้มกว่าจะทำตั้งแต่ช่วงย้ายระบบ มากกว่าค่อยเพิ่มทีหลัง

  • ประสิทธิภาพด้านต้นทุน

    • แม้จะไม่ใส่งาน optimization ต้นทุนที่ซับซ้อนมากนักไว้ในขอบเขตการย้าย แต่ก็รองรับ node autoscaling ตั้งแต่ต้น
    • บริการบน ECS on EC2 เดิมต้อง overprovision เครื่องไว้เพื่อรองรับโหลดที่พุ่งขึ้นระหว่างการ deploy
    • บน EKS ใช้ Karpenter เพื่อขยายและลดจำนวน node แบบไดนามิกตามความต้องการ

งานที่ไม่นำมาไว้ในขอบเขต

  • logging pipeline เดิมมีความซับซ้อน
    • log ทั้งหมดถูกเขียนลง CloudWatch ก่อน
    • จากนั้น Lambda จะอ่าน log แล้วแปลงข้อมูล เช่น ลบ pattern บางอย่างและเพิ่ม tag
    • หลังจากนั้นจึงเขียนต่อไปยัง Datadog และ Snowflake
    • ค่าใช้จ่ายของ CloudWatch ในฐานะที่เก็บข้อมูลกลางก็เพิ่มสูงขึ้นเรื่อย ๆ
  • Figma วางแผนนำ Vector ซึ่งเป็นโปรเจกต์ CNCF มาใช้ในสแตก EKS เพื่อประมวลผลและส่งต่อ log ผ่าน sidecar
  • แต่บริษัทมองว่าไม่คุ้มที่จะรับผลกระทบลำดับสองจากการพอร์ต logic ของ log forwarder ไปเป็นการตั้งค่า Vector จึงตัดออกจากขอบเขตการย้าย
  • การทำ autoscaling ระดับ Pod ก็ไม่ได้รวมไว้ในการย้ายเช่นกัน
    • เพราะมองว่ามีความซับซ้อนสูงเกินไป
    • และเป็นสิ่งที่เพิ่มทีหลังได้ง่าย
  • งานที่ถูกตัดออกเหล่านี้จึงกลายเป็นงานต่อเนื่องภายหลัง และสามารถค่อย ๆ ปรับปรุงควบคู่ไปกับการย้ายบริการอื่นมายัง EKS

วิธีดำเนินการอย่างปลอดภัย

  • เนื่องจากสแตก ECS เดิมมีความเสถียรพอสมควร สแตก EKS ใหม่และกระบวนการย้ายจึงต้องมีความน่าเชื่อถืออย่างน้อยในระดับเดียวกัน

  • การทดสอบโหลด

    • Figma สร้างบริการ “Hello, World” และสเกลให้รันด้วยจำนวน Pod เท่ากับบริการที่ใหญ่ที่สุดของบริษัท
    • การทดสอบนี้ทำให้พบว่าต้องปรับขนาดและสเกลของบริการคอมพิวต์หลักที่รองรับทั้งแพลตฟอร์ม
    • Kyverno ซึ่งเป็นเครื่องมือตรวจสอบความปลอดภัยของคลัสเตอร์ อาจทำให้การเริ่ม Pod ใหม่ล่าช้าหากไม่ได้ตั้งขนาดไว้ใหญ่พอ

  • การ rollout แบบค่อยเป็นค่อยไป

    • ใช้รายการ DNS แบบ weighted เพื่อค่อย ๆ ย้ายทราฟฟิกจากบริการ ECS เดิมไปยังบริการคู่กันบน EKS
    • ความสามารถในการย้ายทราฟฟิกอย่างละเอียดและย้อนกลับได้เป็นหัวใจของการย้ายอย่างปลอดภัย
    • เพราะผลกระทบที่คาดไม่ถึงอาจเกิดขึ้นที่จุดหักเหซึ่งไม่รู้ล่วงหน้า จึงต้องลดขอบเขตผลกระทบและ rollback ได้อย่างรวดเร็ว

  • รันบริการจริงตั้งแต่เนิ่น ๆ

    • การนำ workload จริงขึ้นระบบช่วยให้เรียนรู้หลายอย่างที่ staging เพียงอย่างเดียวบอกไม่ได้
    • Figma ย้ายบริการหนึ่งตัวก่อน แม้จะยังสร้างสภาพแวดล้อม staging ไม่เสร็จสมบูรณ์
    • การย้ายตั้งแต่ต้นนี้ช่วยยืนยันความสามารถของระบบในการรัน workload แบบ end-to-end และช่วยหาคอขวดกับบั๊กต่าง ๆ

  • การทำ abstraction ของ YAML

    • หากให้ผู้ใช้กำหนดบริการด้วย raw Kubernetes YAML โดยตรงอาจทำให้สับสน
    • Figma จึงมอบ golden path ให้ผู้ใช้ และเปิดให้ปรับแต่งได้เฉพาะกรณีพิเศษ
    • การระบุให้ชัดว่าผู้ใช้ปรับอะไรได้และควรปรับอะไร ช่วยบังคับความสม่ำเสมอพื้นฐาน ทำให้ดูแลรักษาและเปลี่ยนแปลงในอนาคตได้ง่ายขึ้น

  • การร่วมมือกับเจ้าของบริการและการจัดกำลังคน

    • ทีมแพลตฟอร์มรับผิดชอบการตั้งค่าบริการใหม่ ส่วนการอัปเดต monitoring และ alerting ทำร่วมอย่างใกล้ชิดกับเจ้าของบริการที่เข้าใจสถานะของบริการดีที่สุด
    • ก่อนเริ่มย้ายระบบ Figma ก็หารือกับเจ้าของบริการอย่างเพียงพอเกี่ยวกับตัวเลือกและ trade-off ต่าง ๆ
    • การย้ายระบบขนาดใหญ่สามารถก่อให้เกิดปัญหาที่ไม่คาดคิด ปฏิสัมพันธ์ที่ซับซ้อน และบั๊กทั่วไปได้มาก จึงต้องมีทีมที่มีความเชี่ยวชาญทางเทคนิคลึกพอและมีความสามารถในการ debugging สูง

ไทม์ไลน์และผลลัพธ์ของการย้ายจริง

  • ในไตรมาส 1 ปี 2023 Figma จัดทำแผนและได้รับความเห็นชอบให้เดินหน้าการย้ายระบบ
  • ในไตรมาส 2 ปี 2023 สร้างสภาพแวดล้อม staging และย้ายบริการเดี่ยวหนึ่งตัว
  • ในไตรมาส 3 ปี 2023 มุ่งเน้นที่การทำ productionization, การทดสอบโหลด และการเตรียมย้ายบริการเพิ่มเติม
  • ตั้งแต่ไตรมาส 4 ปี 2023 จนถึงสัปดาห์แรกของเดือนมกราคม 2024 ค่อย ๆ สลับทราฟฟิกของบริการอย่างช้า ๆ
  • ภายในเดือนมกราคม 2024 บริการที่มีความสำคัญสูงส่วนใหญ่ถูกย้ายไปยังคลัสเตอร์ EKS ใหม่แล้ว
    • monolith ที่บรรจุ business logic หลัก
    • บริการที่ซับซ้อน ที่จัดการด้าน multiplayer ของการแก้ไขไฟล์ Figma
    • บริการในชุด Livegraph 100x ที่ push การอัปเดตแบบเรียลไทม์ไปยังไคลเอนต์ทั้งหมด
  • ผลลัพธ์คือสามารถลดต้นทุนจากการ overprovision เพื่อการ deploy เพิ่มความน่าเชื่อถือจากการรันแบบ 3 คลัสเตอร์ และปรับปรุงความสะดวกในการใช้งานสำหรับนักพัฒนา
  • งานทั้งหมดดำเนินไปโดยมี incident ขนาดเล็กและผลกระทบต่อลูกค้าในระดับต่ำ
  • มี incident หนึ่งที่ผู้ปฏิบัติการเผลอลบและสร้าง CoreDNS ใหม่ในหนึ่งในคลัสเตอร์ production
    • หากเป็นสถาปัตยกรรมเดิม เหตุการณ์นี้อาจกลายเป็น outage ทั้งระบบ
    • แต่ในสถาปัตยกรรม 3 คลัสเตอร์ ผลกระทบถูกจำกัดไว้เพียง 1 ใน 3 ของ request
    • บริการปลายทางส่วนใหญ่ retry request จนสำเร็จในที่สุด

การปรับปรุงเครื่องมือหลังเปิดใช้งาน

  • Figma สร้างเครื่องมือเพื่อช่วยให้เจ้าของบริการ debug สิ่งที่เกิดขึ้นในคลัสเตอร์ได้
    • ตรวจสอบจำนวนอินสแตนซ์ที่กำลังรัน
    • เข้า container shell
    • ทำงานปฏิบัติการ เช่น การสเกลฉุกเฉิน
  • ไม่นานหลังเปิดใช้งานก็ได้รับ feedback ว่าเครื่องมือสำหรับเข้าถึงเหล่านี้ยังใช้งานไม่เป็นมิตรพอ
  • สาเหตุของความซับซ้อนมีสองส่วน
    • การใช้ 3 คลัสเตอร์ทำให้ผู้ใช้ต้องรันคำสั่งข้ามหลายคลัสเตอร์ และต้องระบุชื่อคลัสเตอร์เพิ่มในแต่ละคำสั่ง
    • การใช้ Kubernetes RBAC roles เพื่อให้สิทธิ์แบบละเอียดมากขึ้น ทำให้ผู้ใช้ต้องเข้าใจว่าตนมี role อะไรและงานใดต้องใช้ role แบบใด
  • Figma จึงหยุดงานอื่นทันทีและแก้เครื่องมือให้อนุมานคลัสเตอร์และ role ที่เหมาะสมให้อัตโนมัติ
  • ผู้ใช้จึงไม่ต้องเสียเวลาไล่หา role โดยเฉพาะในเหตุฉุกเฉินช่วงดึก

ขั้นต่อไป

  • Figma กำลังเดินหน้าทั้งการย้ายบริการที่เหลือและการปรับปรุงแพลตฟอร์มคอมพิวต์ใหม่ไปพร้อมกัน
  • โฟกัสหลักในตอนนี้คือ
    • ทำให้การออกแบบ logging pipeline ง่ายขึ้น
    • รองรับ horizontal Pod autoscaling ผ่าน Keda
    • ย้ายบริการที่มีต้นทุนสูงที่สุดของ Figma ไปยังโปรเซสเซอร์ Graviton เพื่อลดค่าใช้จ่าย และเปิดทางให้บริการอื่นรันบน Graviton ในอนาคต
  • ยังมีส่วนอื่นที่ตั้งใจจะสำรวจเพิ่มเติม แม้ยังไม่ได้ลงทุนลึกมากนัก
    • พิจารณา service mesh offerings เพื่อปรับปรุงความน่าเชื่อถือและ observability ของ networking stack
    • จัดการ resource เพิ่มเติมผ่าน AWS Controllers for Kubernetes (ACKs) เพื่อลดการพึ่งพา Terraform และทำให้สแตกง่ายขึ้นและรวมศูนย์มากขึ้น
    • ทำงานร่วมกับทีมประสบการณ์นักพัฒนาเพื่อรวมวิธีรันบริการในสภาพแวดล้อมพัฒนาเข้ากับวิธีรันในสภาพแวดล้อมอื่น ๆ

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

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

 
GN⁺ 2024-08-10
ความคิดเห็นจาก Hacker News

  • โดยส่วนตัวแล้วชอบ Kubernetes มาก ผมดูแลร้านค้าอีคอมเมิร์ซแบบปรับแต่งเฉพาะหลายแห่งที่เล็กแต่ซับซ้อน และยังรับผิดชอบทั้งการตลาด การเงิน และซัพพอร์ตลูกค้าด้วย
    เมื่อก่อนรันบนเซิร์ฟเวอร์เฉพาะ แต่สแต็กค่อนข้างซับซ้อน ทำให้การ deploy กลายเป็นฝันร้าย และสุดท้ายภาระเรื่องการ deploy ก็ทำให้ความเร็วของบริษัทเล็กๆ ช้าลง
    ใช้เวลาหนึ่งเดือนในการเรียนรู้และย้ายไป Kubernetes ตอนนี้รันบริการประมาณ 25 ตัว เช่น frontend, ตัวจัดการสินค้า, แดชบอร์ดโลจิสติกส์, การปรับเส้นทางจัดส่งให้เหมาะสม, OSRM, ERP, recommendation engine, search ฯลฯ
    การรวมการตั้งค่า cluster ไว้ที่เดียวทำให้จัดโครงสร้างได้แบบทำซ้ำได้ และรู้ได้อย่างแม่นยำว่าแต่ละบริการอยู่ในสถานะใดและกำลังรันเวอร์ชันไหนอยู่ นอกจากนี้ยังทำ rolling deployment แบบไม่มี downtime ได้ด้วย แม้มันจะซับซ้อน แต่โปรแกรมเมอร์ก็จัดการกับสิ่งซับซ้อนอยู่แล้ว ไฟล์ตั้งค่า Nginx ก็ซับซ้อนเหมือนกัน
    ยิ่งลงลึกก็ยิ่งเข้าใจว่าทำไมสถาปัตยกรรมของ Kubernetes ถึงสมเหตุสมผล และมันบังคับให้ทำตาม 12-factor อย่างเคร่งครัด ถ้ารายได้ของคุณผูกกับ availability และเสถียรภาพของสแต็กโดยตรง high availability ก็เป็นมากกว่าแค่สิ่งที่ “มีก็ดี” ค่าโฮสติ้งก็ราวๆ 400 ดอลลาร์ต่อเดือน จึงไม่ได้แพงขนาดนั้น

    • Figma ก่อนหน้านี้ก็รันบน ECS อยู่แล้ว จึงไม่ใช่ว่าใช้แต่เซิร์ฟเวอร์เฉพาะอย่างเดียว
      ผมค่อนข้างเชื่อใน Kubernetes แต่ก็ยอมรับว่ามันซับซ้อนจริงๆ มันเป็นเครื่องมือที่แก้ปัญหายากๆ ถ้าเป็น multi-cloud ก็ไม่ต้องคิดมาก และถ้าต้องการโครงสร้างพื้นฐานที่ซับซ้อนซึ่งแมปกับ local แบบ 1:1 ก็เหมาะดี
      แต่ถ้ามีนักพัฒนาน้อยกว่า 100 คนและแค่ deploy container บน AWS ผมว่าในปี 2024 การใช้ EKS แทน ECS + Fargate นี่ไม่สมเหตุสมผลเลย
    • ถ้าดูแลร้านค้าอีคอมเมิร์ซแบบปรับแต่งเฉพาะหลายแห่งที่เล็กและซับซ้อน อยากรู้ว่าจัดการกับ การขาด multi-tenancy ของ Kubernetes อย่างไร

  • การย้ายเพื่อปรับปรุงฐานของ infrastructure เองเป็นเรื่องดี แต่แปลกใจที่หนึ่งในแรงจูงใจคืออยากให้ทีมต่างๆ ใช้ Helm chart แทนการแปลงเป็น Terraform
    ในทางปฏิบัติแทบไม่เคยเห็นการใช้ Helm chart ใดๆ แบบไม่แก้ไขแล้วเสถียรจริงๆ และถ้าส่งเสริมให้ใช้ สุดท้ายทีมก็มักจะ fork และแก้ chart กันอยู่ดี Helm เป็นเครื่องมือที่แย่มากจนไม่อยากดูแล Helm chart แบบปรับแต่งเอง
    ผมว่าการเขียนใหม่ด้วย Terraform ยังดูแลเวอร์ชัน local ได้ง่ายกว่า ถ้ามีตัวอย่างแย้งก็อยากฟัง บางทีตอนนี้ความบ้าคลั่งของ indent 4 ใน Helm และปัญหา string template หลายชั้นอาจหายไปแล้วก็ได้

    • ผมมองว่า Helm chart กับ Terraform เป็นคนละอย่างกัน Terraform เหมาะกว่าสำหรับ deploy cloud resource เช่น S3 bucket, EKS cluster, EKS worker, RDS
      จะใช้ Terraform จัดการ Kubernetes workload ก็ได้ แต่ไม่แนะนำ Kubernetes เองก็มี state อยู่แล้ว ถ้า Terraform ก็มี state ด้วย การใช้ Terraform + Kubernetes ร่วมกันจะกลายเป็นเรื่องเจ็บปวด Helm ถูกสร้างมาสำหรับ Kubernetes ส่วน Terraform ไม่ใช่
      แต่ก็ไม่ได้หมายความว่าผมชอบ Helm หรอก YAML แบบ templated ไม่ค่อยดี และความบ้าคลั่งของ indent 4 ก็ยังอยู่ Kustomize ดีเมื่อเป็นงานง่ายๆ แต่พอแอปซับซ้อนขึ้น ผมว่ามันแย่กว่า Helm อีก เช่น ถ้าต้อง deploy แอปที่มี Ingress, TLS certificate และ external-dns สำหรับหลาย environment แทนที่จะใช้ตัวแปรเดียวในสามจุด กลับต้อง patch resource สามครั้ง
      ทั้ง Helm และ Terraform ได้รับความนิยมมากเลยถูกพูดถึงบ่อย แต่สุดท้ายผมคิดว่าจะมีเครื่องมือที่มาแทนสองตัวนี้ ซึ่งตอนนี้ยังไม่แพร่หลาย ออกมาแน่
    • ที่ BigCo ที่ผมทำงานอยู่ตอนนี้ ใช้ Terraform จัดการทั้ง infrastructure และ deployment ในสเกลที่ใหญ่จนน่าขัน และมันคือฝันร้าย
      ปัญหาของ Terraform คือคุณต้องออกแบบ workspace ไม่ให้เกินจำนวน resource ที่แนะนำต่อ workspace คือประมาณ 100–200 รายการ ไม่อย่างนั้น plan จะช้าลงมากเพราะต้องตรวจสอบแม้แต่ database หรือ network ที่คุณไม่ได้แตะและไม่ได้คิดจะแตะ ทำให้เวลา deploy ยาวขึ้น
      ในความเป็นจริงจะลงเอยด้วยการสร้างตารางของ Terraform workspace ที่ trigger กันไปมา ซึ่งตอนนี้ยังไม่มีเครื่องมือโอเพนซอร์สดีๆ ที่รองรับเรื่องนี้อย่างเหมาะสม
      เท่าที่ดูตอนนี้ ทางที่ดีที่สุดคือให้ Terraform ติดตั้งเครื่องมือ continuous deployment อย่าง ArgoCD เป็นส่วนหนึ่งของ infrastructure แล้วให้เครื่องมือ CD รับผิดชอบ deployment ประจำวัน และเครื่องมือ CD ส่วนใหญ่ก็要求ให้ package การ deploy ด้วยอะไรอย่าง Helm
    • ถ้าพูดถึง Helm โดยส่วนตัวตอนนี้เกลียดเข้าไส้ไปแล้ว ตอนออกมาแรกๆ มันยอดเยี่ยมและเติมเต็มช่องว่างที่จำเป็นได้
      แต่มี กับดัก มากเกินไป จนต้องเสียเวลาทำงานของวิศวกรคนอื่นซ้ำและ debug
      หวังว่าเครื่องมือใหม่ชื่อ timoni จะได้รับแรงส่ง มันแก้ข้อไม่พอใจแทบทั้งหมดที่ผมมีต่อ Helm ได้ ถ้ากำลังมองหาทางออกที่ดีกว่า ก็น่าลองดู timoni
    • ทีมเราก็เจอปัญหาที่กล่าวถึงกับ Helm chart สาธารณะเหมือนกัน ถ้าจะให้ทำงานถูกต้องใน environment ของตัวเอง แทบจะต้อง customize อะไรบางอย่างเสมอ
      เราเลือกวิธีใช้ Helm chart สาธารณะตามเดิม แล้วจัดการ customization ด้วย kustomize —enable-helm
    • เห็นด้วยว่าการเขียน Helm chart ไม่ได้สนุกเป็นพิเศษ แต่ฝั่งคนใช้อาจค่อนข้างโอเคได้
      ในกรณีของเรา มี Helm chart ฐานสำหรับแอปพลิเคชัน/บริการเดียวที่ให้ค่า default สมเหตุสมผล และ deployment ทั้งหมดจะ extend จากตัวนี้ ฝั่งผู้ใช้ต้องตั้งค่า Helm values น้อยมาก และแทบไม่เคยต้องใส่ template เอง เพราะ chart ฐานเปิดจุดปรับแต่งไว้เพียงพอ
      chart ของ third-party จำนวนมากสามารถ deploy ได้ตรงๆ และบางครั้งก็เพิ่มฟีเจอร์ที่ต้องการกลับไป upstream ด้วย PR มีบ้างที่ต้อง wrap หรือ fork แต่ chart ของ third-party ที่ deploy ได้ตรงๆ มีมากกว่ามาก
      เวลา maintain custom chart นั้น helm unittest (https://github.com/helm-unittest/helm-unittest) ช่วยหลีกเลี่ยง regression ได้มาก
      แม้เราจะใช้ Terraform จัดการ resource บางส่วนของ Kubernetes รวมถึง ArgoCD แต่โดยทั่วไป การ deploy Helm chart ผ่าน ArgoCD นั้นดูแลง่ายกว่าและมี productivity ดีกว่ามาก

  • แปลกใจที่ใน HN มี ทัศนคติต่อต้าน Kubernetes เยอะขนาดนี้ สงสัยว่าเป็นเพราะคนคอมเมนต์ส่วนใหญ่เป็นนักพัฒนาที่คุ้นกับบริการอย่าง Heroku, fly.io, render.com หรือเพราะรันแอปบน VM กันแน่

    • ในช่วงราว 10 ปีที่ผ่านมา มีคนจำนวนมากเบื่อหน่ายกับความซับซ้อนที่ไม่จำเป็นซึ่งระเบิดขึ้นในวงการซอฟต์แวร์ และก็สมควรแล้ว
      นี่ไม่ใช่ปัญหาที่จำกัดอยู่แค่กรณีใดกรณีหนึ่ง แต่เป็นปัญหาที่เกิดจากแรงจูงใจที่บิดเบี้ยวอย่างหนักทั่วทั้งอุตสาหกรรม และส่วนหนึ่งจากยุคตื่นทองในช่วงดอกเบี้ยต่ำ
      พูดตรง ๆ ถ้ามองจากสภาพปัจจุบัน ในสาขาอื่นเราคงดูเหมือนช่างฝีมือที่แทบไม่มีประโยชน์นัก หมกมุ่นกับเครื่องมือและงานเมตาอย่างไม่ดีต่อสุขภาพ และโยนการใช้ทรัพยากรอย่างสมเหตุสมผลทิ้งออกนอกหน้าต่างอยู่เรื่อย ๆ เพียงเพื่อจะได้ใช้เครื่องมือบางอย่าง คล้ายสถานการณ์แบบ “วิศวกร FAANG ที่กำลังลำบากชั่วคราว”
    • โดยส่วนตัวผมหงุดหงิดนิดหน่อยกับการเสนอให้ใช้ Kubernetes เพราะความต้องการทางธุรกิจเชิงทฤษฎีในจินตนาการ เช่น สักวันหนึ่งอาจต้องใช้มัลติคลาวด์ หรืออาจต้อง deploy แบบ on-premises
      ยากที่จะอธิบายได้ว่าถ้าสร้างบน Kubernetes แทนโมเดลการ deploy ที่เลือกได้บน AWS เช่น VM image ของ EC2, Elastic Beanstalk, ECS/Fargate หรือ Lambda จะใช้เวลานานขึ้นแค่ไหน ต้องใช้ความเชี่ยวชาญมากขึ้นแค่ไหน เปราะบางขึ้นแค่ไหน และเสียเงินมากขึ้นแค่ไหน
      ผมไม่อยากติดตั้งและดูแล ELK stack หรือ Prometheus เอง ไม่อยากปล้ำกับ CNI plugin, Kafka, Postgres แบบ high availability, Argo, Helm และการอัปเกรด control plane ด้วย บริการที่เทียบกันของ AWS แทบจะเริ่มใช้ได้ทันที แทบไม่ต้องดูแล และต้นทุนก็มักเริ่มต้นแบบเชิงเส้นจากจุดที่ใกล้ศูนย์
      สามารถแก้ปัญหาทางธุรกิจได้เร็วกว่าและมีประสิทธิภาพกว่ามาก นี่คือความแตกต่างระหว่างสถานการณ์ที่ทำได้เกินความคาดหวังอย่างมาก กับสถานการณ์ที่ทั้งทีมล้าหลังไปหลายไตรมาส
      แต่ถ้ามีความต้องการมัลติคลาวด์หรือ on-premises จริง ๆ ผมก็ไม่อยากใช้อะไรนอกจาก Kubernetes เช่นกัน สำหรับบริษัทใหญ่ที่มีวิศวกรชำนาญ Kubernetes จำนวนมาก มันอาจไม่ได้แย่ขนาดนั้น อย่างน้อยที่ที่ผมเคยทำงานก็ไม่ใช่แบบนั้น
    • การที่มีคนเกลียดเยอะ ในแง่หนึ่งก็เป็นสัญญาณของความสำเร็จด้วย
      เป็นเรื่องดีที่ได้เห็นองค์กรต่าง ๆ ย้ายไปใช้ โครงสร้างพื้นฐานโอเพนซอร์ส เป็นหลัก ซึ่งจำนวนมากมาจาก CNCF (https://landscape.cncf.io), ASF และหลายโปรเจกต์บน GitHub
    • ในบางสถานการณ์มันคุ้มค่าที่จะใช้ แต่ก็เป็นหนึ่งในเทคโนโลยีที่ถูกนำมาใช้แบบ cargo cult บ่อยเกินไป
    • สำหรับผม ปัญหาอยู่ฝั่ง VM มากกว่า ผมไม่สบายใจกับความคิดที่ว่า ถ้ามีช่องโหว่ในเคอร์เนล โค้ดประสงค์ร้ายอาจหลุดออกจากคอนเทนเนอร์แล้วไปค้นโฮสต์ Kubernetes ได้
      kata-containers อาจช่วยคลายความกังวลนั้นและทำให้ผมสนุกกับ Kubernetes ขึ้นก็ได้
      โดยรวมแล้ว ผมไม่ได้รู้สึกว่า Kubernetes มีอะไรเท่เป็นพิเศษ คอนเทนเนอร์, load balancer, YAML ระดับเมกะไบต์ ผมเห็นมาหมดแล้ว และไม่ได้รู้สึกว่าน่าสนใจพอจะลอง

  • สำหรับบริษัทขนาดนี้อาจเป็นเรื่องปกติ แต่ผมตามกระบวนการตัดสินใจของ migration หรือโปรเจกต์เทคนิคขนาดมหึมาแบบนี้ได้ยาก เพราะมันดูไม่เหมือนเกิดจากความต้องการของผู้ใช้หรือของบริษัท
    ตอน Figma เคยโพสต์บทความคล้าย ๆ กันเกี่ยวกับฐานข้อมูล ผมก็รู้สึกแบบเดียวกัน
    เช่น ถ้าเหตุผลที่อยากไป Kubernetes คือใช้ etcd/Helm บน ECS ไม่ได้ ก็ต้องถามก่อนว่าทำไมถึงอยากใช้ etcd/Helm มันสำคัญขนาดนั้นจริงหรือ? วิธีที่จะบรรลุเป้าหมายของบริษัทต้องเป็นวิธีนั้นเป๊ะ ๆ จริงหรือ?
    ถ้าการตัดสินใจตั้งอยู่บนความต้องการของผู้ใช้ ก็ตรวจสอบได้ง่ายว่าการตัดสินใจย่อย ๆ สมเหตุสมผลหรือไม่ แต่ถ้าตั้งอยู่บนความต้องการทางเทคนิค ต่อให้การตัดสินใจย่อย ๆ ดูสมเหตุสมผลในบริบทของความต้องการทางเทคนิคนั้น ก็ยังไม่แน่ชัดว่าในบริบทของผู้ใช้มันสมเหตุสมผลหรือไม่
    ผมคิดว่ามีสองอย่างอย่างใดอย่างหนึ่ง: ไม่ใช่ผมไม่เข้าใจองค์กรขนาดนี้ ก็เป็นเพราะองค์กรขนาดนี้โดยพื้นฐานแล้วระบุและให้เหตุผลเกี่ยวกับงานที่มีคุณค่าได้ยาก

    • ผมเป็นผู้เขียนบทความ คำถามดีและกรอบการมองก็ดี ผมเห็นด้วยว่า อย่างน้อยในการตัดสินใจใหญ่ ๆ บางอย่างรวมถึงเรื่องนี้ “องค์กรขนาดนี้โดยพื้นฐานแล้วระบุและให้เหตุผลเกี่ยวกับงานที่มีคุณค่าได้ยาก”
      โดยแก่นแล้วเราเป็นทีมแพลตฟอร์ม และบ่อยครั้งเราสร้างเครื่องมือให้ทีมแพลตฟอร์มอื่น ๆ ที่สร้างเครื่องมือเพื่อสนับสนุนนักพัฒนา Figma ซึ่งเป็นผู้สร้างประสบการณ์ผลิตภัณฑ์จริง ยิ่งห่างจากผู้ใช้ปลายทางมากเท่าไร การให้เหตุผลเพื่อเลือกการตัดสินใจที่ถูกต้องก็ยิ่งยากขึ้น แต่ในขณะเดียวกันก็เกิด leverage ขนาดใหญ่ด้วย
      ถ้าสร้างแพลตฟอร์มได้ดี ผลกระทบจะส่งต่อไปยังความสามารถของวิศวกรคนอื่น ๆ ทุกคนในการทำงานอย่างมีประสิทธิภาพและได้ผล ผลกระทบจำนวนมากในนั้นเป็นผลทางอ้อม
      แน่นอนว่ามีทางเลือกที่จะบอกว่าเราไม่สามารถรองรับ etcd และ Helm ได้ ให้ไปหาวิธีอ้อมอย่างอื่น แต่ทั้งสองอย่างนี้เป็นข้อมูลเพิ่มเติมที่ผลักดันให้เราสรุปว่าเรากำลังรันแพลตฟอร์ม Compute อยู่บนองค์ประกอบพื้นฐานที่ผิด
      แม้การให้เหตุผลจะยาก แต่ก็คุ้มค่ามากที่จะพยายามทำให้ดี เพราะในฐานะทีมแพลตฟอร์ม นี่คือวิธีตรวจสอบว่าเรากำลังทำสิ่งที่ถูกต้องเพื่อไปให้ถึงแพลตฟอร์มที่ดีที่สุดหรือไม่ ดังนั้นเราจึงใช้เวลามากกับการตัดสินใจนี้ และคิดว่าเป็นหัวข้อที่น่าสนใจพอจะเขียนถึง
    • เหตุผลที่ผู้คนย้ายจาก ECS ไป Kubernetes คือเพื่อใช้เครื่องมือและผลิตภัณฑ์ที่ไม่ผูกติดกับผู้ให้บริการคลาวด์
      migration ไป Kubernetes จำนวนมากของบริษัทใหญ่ ๆ น่าจะขับเคลื่อนด้วยความต้องการด้านมัลติคลาวด์หรือไฮบริด on-premises รวมถึงการลดความเสี่ยงด้านต้นทุน ความพร้อมใช้งาน และ vendor lock-in
    • การจัดการ VM มากกว่า 500 เครื่องเป็นงานเยอะมาก
      ต้องทำให้การอัปเกรด VM, การยืนยันตัวตน, การสำรองข้อมูล, log rotation ฯลฯ สอดคล้องกันทั้งหมด
      ใน Kubernetes สามารถให้ namespace, policy, volume แก่แต่ละคนได้ และด้วย DaemonSet กับสแต็ก Kubernetes/cloud native ก็ทำ log aggregation อัตโนมัติได้ด้วย
      ยังมี self-healing และอื่น ๆ อีก อธิบายยากว่ามันดีขึ้นมากแค่ไหน
    • ผมไม่ค่อยชอบ Helm แต่ ทางเลือกที่ดีของ etcd มีน้อยจนน่าประหลาดใจ
      เช่น แทบไม่มี data store ที่ทั้งมี high availability และ consistency สำหรับใช้เป็นสิ่งเทียบเท่าไฟล์ .pid ในสภาพแวดล้อมแบบกระจาย สิ่งที่นึกออกก็มี Zookeeper แต่ในแง่ปฏิบัติการมันเจ็บปวดจริง ๆ ต้องใช้ JVM เวอร์ชันเก่า และถึงอย่างนั้นโดยรวมก็ยังไม่เสถียร
    • มีทฤษฎีว่าเหตุการณ์แบบนี้เกิดขึ้นได้อย่างไรอยู่ที่นี่: https://lethain.com/grand-migration/

  • เมื่อโค้ด Terraform ถูก apply แล้ว จะสร้าง ECS task set ที่มีอินสแตนซ์ 0 ตัวเพื่อเปิด service template จากนั้นเมื่อนักพัฒนาปล่อยบริการ ก็ต้อง clone template task set นี้และทำงานแบบ manual หลายอย่าง ส่วนนี้ฟังดูเหมือนเป็นการทำให้ วิธีจัดการ deployment ด้วย Terraform + ECS ซับซ้อนเกินไป มากกว่าจะเป็นปัญหาของ ECS
    เข้าใจได้ว่าสร้าง template ไว้เพื่อตรวจสอบก่อน deploy จริง แต่เรื่องนี้ค่อนข้างก้ำกึ่ง

    • ผมเป็นผู้เขียน และเห็นด้วยเต็มที่ว่านี่ไม่ใช่ข้อจำกัดพื้นฐานของ ECS เราสามารถปรับปรุงการตั้งค่านี้ต่อไปให้ดีขึ้นได้
      ดังนั้นผมจึงตั้งใจจัดข้อนี้ไว้เป็นงานที่ตัดสินใจรวมเข้าไปในกระบวนการ migration ไม่ได้ใส่ไว้เป็นเหตุผลพื้นฐานที่ทำให้เริ่ม migration
    • เห็นด้วย ECS deployment ค่อนข้างไม่เจ็บปวดและเรียบง่าย
      อย่างไรก็ตามพอนึกออกว่ามีบาง scenario ที่วิธีนี้อาจจำเป็น เช่น มีบริการที่ deploy บน ECS จำนวนมากจน Terraform state มีขนาดใหญ่ขึ้น แบบนั้น plan และ apply จะช้าลงมาก และการ shard Terraform state ด้วยการ clone configuration ตาม template อาจปลอดภัยกว่ามาก
    • เห็นด้วยจริง ๆ ผมเคยสร้าง infrastructure บน ECS ด้วย Terraform ที่สองบริษัท และงานแบบนี้ไม่เคยมีขั้นตอน manual เลย
      ทั้งหมดก็แค่เพิ่ม environment variable ในไฟล์ Terraform, merge แล้วให้ CI deploy การเปลี่ยนแปลง configuration ส่วนใหญ่ที่เราทำก็จัดการผ่านกระบวนการนั้น

  • “การ migrate ไป Kubernetes อาจใช้เวลาหลายปี” นี่ผมกำลังอ่านอะไรอยู่กันแน่
    สำหรับใครล่ะ? ผมก็ไม่ค่อยเข้าใจว่าทำไมบริษัทต่าง ๆ ถึงต้องทำ migration แบบนี้ให้ยุ่งยากด้วย คุณค่าทางธุรกิจ อยู่ตรงไหน และประโยชน์ที่ลูกค้าได้อยู่ตรงไหน? นี่เป็นโปรเจกต์แนว “ศิลปะเพื่อศิลปะ” ที่ Figma ทำเพราะทำได้หรือเปล่า?

    • ผมเองก็ค่อนข้างตกใจกับประโยคนี้ และก็ตกใจกับส่วนที่ดูเหมือนภูมิใจว่าได้ย้ายไป Kubernetes ภายใน 1 ปี
      แม้แต่ในบริษัทที่ตั้งมาราว 30 ปีและมีภาระตกค้างตามวัย เราก็ย้ายไป Kubernetes ได้ในเวลาสั้นกว่านั้นมาก แต่เราไม่ได้พยายามย้ายทุกอย่างไป Kubernetes ย้ายเฉพาะสิ่งที่จะได้ประโยชน์เท่านั้น
      ข้อเสนอของเราประมาณนี้: ถ้าย้ายไป Kubernetes ตอนย้าย data center ที่วางแผนไว้ช่วงปลายปี คุณก็แทบไม่ต้องทำอะไรนอกจากตรวจสอบ หรือไม่อย่างนั้นก็ต้อง redeploy แอปไปยังเครื่องหรือ VM ใหม่และรับมือกับสารพัดปัญหาที่ตามมา ถ้ายังไม่ได้ containerize ก็ containerize ตอนนี้ แล้วที่เหลือเราจัดการให้
      ส่วนใหญ่ย้ายมาและพอใจกับผลลัพธ์มาก ในทางกลับกัน บริการที่อ่อนไหวต่อ latency หรืออยู่ในกลุ่ม high-performance computing ก็ไม่มีเหตุผลให้ฝืนย้าย และเราก็ไม่ได้พยายามยัดให้เข้ารูป
    • มันช่วยแก้ปัญหา “เพิ่งถูกซื้อกิจการ และมี resource มากมายที่ต้องใช้ให้หมด”

  • ต้องใช้เวลานานแค่ไหนถึงจะออกจากตรงนี้ได้?

    • ขึ้นอยู่กับว่ามี โค้ดแบบ Kubernetes-native มากแค่ไหน มีแอปพลิเคชันบางตัวที่ออกแบบมาให้รันบน Kubernetes และใช้ Kubernetes API เยอะ
      ถ้าแอปถูกทำเป็น microservices อยู่แล้ว การย้อนกลับก็ไม่ใช่เรื่องง่าย

  • เวลาอ่านบล็อกโพสต์ที่เอ่ยถึง โปรเจกต์ CNCF ชื่อเท่ ๆ ที่ไม่เคยได้ยินมาก่อน 6 ตัวอย่างสบาย ๆ เพียงเพื่อให้ได้ฟีเจอร์ที่ดูเผิน ๆ แล้วเรียบง่าย ผมรู้สึกเหมือนตัวเองตามยุคไม่ทัน
    ถึงขั้นสงสัยจริงจังว่าถึงเวลาที่ต้องแก่แล้วถอยออกจากวงการพัฒนาซอฟต์แวร์มืออาชีพหรือยัง

    • ไม่ถึงขนาดนั้นหรอก งานสำหรับ individual contributor ยังมีอีกมาก
      แค่หมายความว่าคุณอาจไม่คุ้นกับแนวทางหนึ่งในการ scale องค์กร ซึ่งก็คือการที่ทีม platform abstraction เรื่อง hardware, logging, retry ฯลฯ
      มันไม่ใช่แนวทางเดียว คุณอาจคุ้นกับวิธีอื่นอยู่แล้วก็ได้

  • ผมชอบบทความนี้ตรงที่อธิบายประโยชน์และเหตุผลที่จะได้จาก Kubernetes ได้ชัดเจนและเป็นระบบ
    หลายทีมกระโดดเข้าไปโดยไม่รู้ว่าจะได้อะไร หรือจำเป็นตั้งแต่แรกไหม แต่เหตุผลที่ยกมาที่นี่ดูใช้ได้

  • ถามด้วยความอยากรู้ล้วน ๆ มีระบบหรือบริการสมัยใหม่อะไรอีกไหมที่คนสติดีจะเอามาอวดว่า migrate เสร็จภายใน 1 ปี?

    • เป็นคำถามที่ตอบยาก ทุกระบบไม่ได้เหมือนกันทั้งในแง่ scale, scope และ impact
      ระบบอย่าง Kubernetes มักเป็นหัวใจของ infrastructure จึงกระทบทุกอย่างที่กำลังรันอยู่ พอรวมกับข้อจำกัดของทีมที่พูดถึงในบทความแล้ว 1 ปีก็ไม่ได้ฟังดูแย่ขนาดนั้น
      ตัวอย่างที่นึกออกทันทีคือเมื่อก่อน Amazon เคยย้ายจาก Oracle ไปเป็นฐานข้อมูลเชิงสัมพันธ์ของ Amazon/open source ทั้งหมด แต่ถ้าจำไม่ผิดเรื่องนั้นใช้เวลาหลายปี ถ้าทำเสร็จภายใน 1 ปี ก็คงเอามาอวดแน่นอน
    • ผมเห็น migration ที่ใช้เวลามากกว่า 1 ปีมาเยอะ
      ส่วนใหญ่เป็นเรื่อง technical debt, ความซับซ้อนของ integration และจำนวนคนที่ทุ่มลงไป มากกว่าตัวเทคโนโลยีเอง