อย่าเพิ่งใช้ Kubernetes
(matt-rickard.com)สตาร์ทอัพระยะเริ่มต้นไม่ควรรีบนำ Kubernetes มาใช้แบบผลีผลาม
ส่วนใหญ่แล้วมักยังเร็วเกินไป
สำหรับทีมขนาดเล็ก (1~10 คน) ควรใช้ Serverless container service จะดีกว่า
(AWS ECS - Fargate, Google Cloud Run ของ GCP)
13 ความคิดเห็น
ตอนนี้ k8s ไม่ใช่เรื่องชอบหรือไม่ชอบอีกต่อไป แต่เป็นเรื่องของการอยู่รอดแล้วไม่ใช่หรือ?
ผมคิดว่าต่อให้ไม่รู้ AWS ก็ยังพอว่าได้ แต่เป็นสถานการณ์ที่ต้องรู้จัก k8s แล้วครับ
ผมไม่เห็นด้วยกับความเห็นนี้
ผมคิดว่าข้อเสียเพียงอย่างเดียวของ k8s คือมีแค่เรื่อง learning curve เท่านั้น
แม้ว่าทีมจะมีสมาชิกแค่ประมาณ 5 คน ตอนเริ่มต้นอาจจะยาก แต่เมื่อระดับความเข้าใจเกี่ยวกับ k8s สูงขึ้นเกินจุดหนึ่งแล้ว ก็ไม่มีทางกลับไปใช้แบบเดิมได้อีก ผลลัพธ์ด้าน productivity ที่ได้จากมันนั้นเทียบกันไม่ได้เลย
สิ่งอย่าง ci/cd, gitops, canary deployment ฯลฯ จะทำโดยไม่มี k8s ก็ได้ แต่การทำทั้งหมดนี้บน k8s ด้วยกันนั้นเข้าใจได้ง่ายกว่าและจัดการได้สะดวกกว่า
ในฐานะคนที่เคยผ่านประสบการณ์ย้ายระบบมาด้วยตัวเอง การบอกว่ายังเร็วเกินไปนั้น
ทำให้นึกถึงยุค on-premise ที่เคยลังเลจะนำมาใช้เพียงเพราะยังไม่คุ้นเคยกับ aws cloud
"โฟกัสที่ธุรกิจ" ไม่ใช่ในระดับของการพูดเชิงหลักการแบบนั้น แต่ผมเห็นด้วยได้ยากกับการตัดสินใจที่ทำให้ต้องผูกติดกับเทคโนโลยีเฉพาะบางอย่าง
ถ้าเป็นบทความที่บอกให้ใช้ PaaS อย่าง beanstalk/app engine/heroku อย่างจริงจังก็คงเห็นด้วยอย่างมาก แต่ทุกวันนี้ข้อดีที่ทีมเล็กจะได้จากการเลือก ECS/cloud run/docker swarm แทบไม่มีเลย ถ้าเป็นเมื่อ 4~5 ปีก่อนก็ว่าไปอย่าง
ในแง่ของต้นทุนแล้ว serverless ได้เปรียบอย่างท่วมท้น
ผมก็เห็นด้วยครับ ในกรณีส่วนใหญ่
docker-swarmหรือไม่ก็docker-composeก็เพียงพอและเกินพอแล้วนี่ก็เป็นความเห็นที่มีคนพูดกันเยอะมากในคอมเมนต์ของ Hacker News เหมือนกัน..... [1]
รู้สึกสับสนนิดหน่อยเพราะตัวบทความตั้งต้นอยู่บนสมมติฐานว่า "Kubernetes นั้นยาก"
ทุกวันนี้ ecosystem ของ Kubernetes พัฒนาไปมากแล้ว ดังนั้นถ้าไม่ได้ติดตั้ง Kubernetes เองบน on-prem ก็ไม่ได้ยากขนาดนั้น
อีกทั้งการดูแลการทำงานของ Kubernetes ก็เป็นสิ่งที่เรากำหนดระดับความซับซ้อนได้พอสมควร และถ้าจะทำแค่คอนฟิกพื้นฐานก็ไม่ได้ลำบากอะไร แน่นอนว่าถ้าภายหลังค่อย ๆ เพิ่ม addon นู่นนี่เข้ามาก็ย่อมยากขึ้น
เดี๋ยวนี้ก็มีคนจำนวนมากที่ได้สัมผัสสภาพแวดล้อมการ deploy ตั้งแต่ EKS ตอนยังเป็นมือใหม่แบบผมด้วย
ถ้าจะพูดให้ชัด ๆ ก็คือ ผมไม่ค่อยเข้าใจว่าการตั้งค่า k8s Deployment, Ingress พื้นฐาน (แน่นอนว่า DB ใช้ managed service แยกต่างหาก) มันยากกว่าการตั้งค่า AWS ECS Fargate เองอย่างที่บทความนั้นพูดไว้ตรงไหน
เพราะสุดท้ายทั้งสองแบบก็ต้องตั้งค่า VPC, cluster, CDN, load balancer เหมือนกันอยู่ดี... ในคอมเมนต์ยังมีหลายคนบอกด้วยซ้ำว่า ECS ใช้งานไม่สะดวกกว่า
[1] https://news.ycombinator.com/item?id=31795160
เห็นด้วยครับ ผมคิดว่าการตั้งค่าพื้นฐานก็ไม่ได้ยากขนาดนั้น และความยากในการดูแลรักษาก็ไม่ได้สูงนักด้วยนะ ไม่ว่าจะเอาการตั้งค่าที่ซับซ้อนอย่างหนึ่งบนคลาวด์ไปย้ายเป็นการตั้งค่า Kubernetes yml ก็พูดได้ไม่เต็มปากนักว่ามันดีกว่าอะไรขนาดนั้น
พอบริษัทของเรามีนักพัฒนาเกิน 100 คน ก็เริ่มรู้สึกว่าจำเป็น เลยกำลังย้ายจาก ECS -> EKS อยู่ แต่บางทีก็รู้สึกเสียดายเหมือนกัน
แม้จะบอกว่า "การดูแลระบบ Kubernetes สามารถกำหนดระดับความซับซ้อนได้ด้วยตัวเองพอสมควร" แต่ในมุมของคนที่ยังไม่ค่อยรู้ ก็มีด้านที่ทำให้คิดว่าสิ่งต่าง ๆ ที่ถูกพูดถึงใน ecosystem ของ Kubernetes คงเป็นสิ่งที่จำเป็นทั้งหมด ก็เลยใส่เข้าไปหมด
มีคนบอกว่าการตั้งค่า load balancer ก็เหมือนกันอยู่ดี แต่ผมคิดว่ามันต่างกันระหว่างแค่ต้องรู้ ALB กับต้องรู้ทั้ง ALB + Ingress
เหมือนกับที่ในระบบขนาดเล็กไม่จำเป็นต้องมี MSA, Kubernetes มีเรื่องที่ต้องรู้อยู่มากกว่าที่คิด ดังนั้นในระดับที่ "ควรโฟกัสกับแอปพลิเคชัน" ผมคิดว่ามันก็ถือว่า over-spec จริง
อย่างไรก็ตาม ถ้ามีใครสักคนวางสภาพแวดล้อม Kubernetes ไว้อย่างดีแล้ว การ deploy แอปพลิเคชันบนมันก็ดูเหมือนจะมีผลเรื่อง lock-in น้อยกว่า เพราะนิยามออกมาในรูปแบบที่เป็นกลางต่อ cloud
พอฟังที่คุณพูดแล้วก็รู้สึกว่ามีมุมแบบนั้นอยู่จริง ๆ ครับ/ค่ะ ดูเหมือนว่าผม/ฉันจะมองว่าสิ่งที่ได้เรียนรู้จากการใช้ Kubernetes เป็นเรื่องที่แน่นอนเกินไปหน่อย
และก็ยอมรับเหมือนกันว่าช่วงนี้มี add-on ที่ออกมาจากฝั่ง Kubernetes เยอะมาก เลยทำให้ตัดสินใจเลือกใช้ค่อนข้างยาก
ผม/ฉันยังไม่มีประสบการณ์ migration แบบ ECS -> EKS ก็เลย...เลยอยากถามว่าถ้านอกเหนือจากเรื่อง lock-in effect แล้ว หลังย้ายมาแล้วมีจุดไหนที่ดีขึ้นบ้างไหมครับ/คะ
อ้อ เผื่อไว้ก่อนว่าประสบการณ์ของผมที่พูดถึงนี้อิงกับ EKS นะครับ มันต่างจากการติดตั้ง k8s บน on-prem เองแล้วดูแล etcd กับ Control Plane ด้วยตัวเองมากเลย ฮ่าๆ
ในมุมของคนที่เริ่มต้นมาจาก k8s พออ่านบทความนี้แล้วกลับคิดในทางตรงกันข้ามว่า แล้วจำเป็นต้องเสียเวลาไปเรียน ECS โดยเฉพาะด้วยเหรอ...
ยังไงก็ตาม ผมคิดว่าไม่จำเป็นต้องกำหนดอย่างเป็นทางการแบบนั้นก็ได้ อย่างแรกคือใช้วิธีที่ทีมรู้สึกว่าสะดวกก่อนน่าจะถูกต้องกว่า
ผมเห็นด้วยกับแนวทางการเริ่มต้นใช้ k8s ครับ
เห็นด้วยมากครับ
ผมไม่ได้มองบวกกับการนำ k8s มาใช้แค่ในทีม 10 คนเท่านั้น แต่รวมถึงบริษัทที่มีขนาดทั่ว ๆ ไปด้วย
ผมคิดว่ามันจะมีความหมายก็ต่อเมื่อการถูกผูกติดกับผู้ให้บริการคลาวด์กลายเป็นปัญหาในระดับวิกฤต หรือมีการใช้อินฟราสตรักเจอร์แบบ on-prem ร่วมกันในระดับหนึ่ง
ผมเคยคิดอยู่เหมือนกันว่ามีด้านหนึ่งที่เรามักจะทำตามเทคสแตกของบริษัทระดับองค์กรแบบติดเป็นนิสัย
พอดีมีบทความที่สรุปประเด็นนี้ไว้ และขึ้นบน Hacker News เลยนำมาแชร์ครับ