การเขียน Kubernetes Controller, Part 9— Process Model ของ TF-controller

Chanwit Kaewkasi
3 min readFeb 25, 2022

--

จากช่วงเวลา 2.5 เดือนที่เขียน TF-controller มาตั้งแต่ช่วง Proof-of-Concept ต้นแบบ จนถึง Release แรก ที่เรียกได้ว่าเป็น MVP คือ v0.8.0 เข้าสู่โจทย์ยากระดับ Re-architecture ใน v0.9.0 จะสังเกตสิ่งที่น่าสนใจในกระบวนการได้หลาย ๆ อย่าง โดยเฉพาะการเทียบกับ Agile / Scrum

Product Owner

ผมกลายเป็น Product Owner โดยปริยาย เนื่องจากเป็นคนสร้าง Project นี้ ตัว Requirements ก็จะวิ่งเข้ามาที่ผมคนเดียว เพราะทุก ๆ คนคิดว่าผมคือ Contact Person ทำให้การกรอง / การ Prioritize Requirements เกิดขึ้นที่ผมก่อนที่จะนำเข้าสู่ Issue

Quarterly Time-Box

เราใช้วิธีจัดการ Backlog ง่าย ๆ แบบนี้ Issue ที่ไม่มี Milestone กำกับคือ Product Backlog ส่วน Issue ที่มี Milestone กำกับคือ Sprint Backlog

โดยการ Refine ตัว Backlog ผมมักจะทำทุกวันจันทร์ก่อน Meeting กับ Management (ไม่มี Meeting กับทีม) เพื่อดู Direction ของ Project ให้สอดคล้องกับ Business และเราไม่มี Sprint เพื่อใช้คุม Release แต่ผมจะใช้วิธีตัด Release เพื่อ Test บนคลัสเตอร์ เช่น EKS หรือ OpenShift เมื่อ Feature มากถึงระดับนึง และจะไม่รีบตัดเกินไปถ้ามี Feature ระดับ EPIC ขวางอยู่ เช่น รอบนี้เจอ Feature ของการสนับสนุน Multi-Tenancy ซึ่งใช้เวลาเกิน 1 เดือนในการ Implement โดยแต่ละคนในทีม Dev ไม่รู้เลยว่าต้องเริ่มยังไง ถ้าเอาเวลา 2-week Sprint มาบีบผมมั่นใจว่าพังแน่นอน เพราะกลายเป็นต้อง Make Decision ให้จบภายในกรอบเวลาที่ไม่ Make Sense

จุดที่ทำให้กรอบตรงนี้ยืดออกก็คือการตั้ง Milestone และให้ Commitment ในระดับ Quarter (3 เดือน) ไม่ใช่ 2-week

ความหมายคือไม่ใช่ว่าเราจะ Release ทุก ๆ 3 เดือนนะครับ แต่เป็นการบอกว่าเราจะมี Feature อะไรบ้างใน 1 Quarter และใน 1 Quarter สามารถมีการตัด Release ได้มากเท่าที่ต้องการ

Release Often

การตีความมิติของเวลาแยกกันแบบนี้มีข้อดีคือ ทำให้การตัด Release เกิดขึ้นเมื่อไหร่ก็ได้ ไม่จำเป็นต้องรอให้จบ Sprint ก็จะได้เรื่องความยืดหยุ่น เช่น เมื่อเจอ Critical Bug เราก็สามารถแก้และ Release ได้เลย

การรอจบ Sprint เป็นเรื่องที่ไม่ควรทำในกรณีที่เจอ Bug แบบนี้

โดยเราจะ Release ให้ได้บ่อยที่สุดเท่าที่จะทำได้ใน Quarter นั้น ๆ

ในขณะเดียวกันเราจะยังสามารถคง Commitment กับ Management ได้อยู่เพราะโดยทั่ว ๆ ไป Management จะมี Goal อยู่ในระดับ Quarter แถมยังเป็นระบบเวลาเดียวกับองค์กรภายนอกบริษัทด้วยทำให้คุยเรื่อง Feature กับ Partner ได้ง่าย

ประเด็นเรื่องการคุยกับ Partner ยกตัวอย่าง เช่น ถ้าผมบอกไปว่า ผมจะมี Multi-Tenancy ใน Sprint หน้า หรือในอีก 2 Sprint การสื่อสารจะเริ่มยากแล้ว เพราะต้อง Map จากระบบเวลาแบบ Sprint ที่ทีมเข้าใจ ไปหาระบบเวลาแบบ Quarter ที่ Management และ Partner ใช้

แต่ถ้าผมบอกว่า Multi-Tenancy จะเสร็จใน Q1–2022 อันนี้ง่ายเลย Partner ภายนอกก็จะเข้าใจทันทีโดยไม่ต้องอธิบายอะไรเพิ่ม

โดยจะสังเกตได้ว่า Version ของ Software นั้นไม่ Make Sense เลยกับ Management หรือ Partner แต่เป็น Feature ในกรอบเวลาระดับ Quarter ต่างหากที่ Make Sense

Test-Driven Design

โปรเจ็คนี้ออกแบบด้วย TDD ตั้งแต่แรก เราใช้ TDD จาก Extreme Programming ในระดับ Integration Tests และ E2E โดยรันทั้งสองชุดขนานกันใน CI pipeline และถ้าพังจะไม่ merge (ยกเว้นว่าเป็น blocker จริง ๆ ที่ต้องแก้) การคุมเข้มระดับนี้ทำให้ Bug หลุดน้อยมาก — แต่ก็ยังมีหลุดนะครับ ซึ่งมักจะเป็นการใช้ Feature ที่ไม่ได้คาดไว้มากกว่าเป็น Bug เช่นการทำ Output Name Mapping จาก Terraform ไปยัง Secret ใน Kubernetes

Adaptive Agile

เรา Adapt ตาม Feedback / Requirements ได้ดีมาก และไม่รู้สึกฝืนเพราะกรอบ Quarterly Time-Box กว้างพอ ไม่อึดอัด ยกตัวอย่างเช่น ใน Road Map เดิม ผมวางไว้ว่าเราจะมี Multi-Tenancy ใน Q2 และเราจะทำ Performance Improvement ใน Q3 ปรากฎว่า การต่อรองเวลากับหลาย ๆ Customer หลาย ๆ Partner ที่ผมไม่ได้เป็นคนไปคุยเองเกิดขึ้นง่ายมาก เพราะเราใช้ระบบเวลาสากลแบบ Quarter ที่ทุกคนเข้าใจ มีการอยากให้ Multi-Tenancy ขยับขึ้นมาใน Q1 เพราะเริ่มมี Customer อยากใช้ และมี Feedback ว่า Performance Improvement อยู่ใน Q3 มันนานเกินไป

เลยมีการ Re-Prioritize ตัว Multi-Tenancy ขึ้นมา Q1 และ Performance Improvement ขึ้นมา Q2 และก็สามารถวางแผนเรื่องการหา Expert มาช่วยเสริมเรื่อง Performance ใน Q2 ได้อีกด้วยเพราะมีเวลาเตรียมตัวมากพอ โดยเราเลื่อนประเด็นเรื่อง Observability ออกไปแทน

คราวนี้ลองมาเทียบ Agile Principles กับสิ่งที่ใช้ไปในกระบวนการของ TF-controller ไล่เป็นข้อ ๆ

1. Satisfy Customers Through Early & Continuous Delivery

ข้อนี้ผ่าน เพราะเรา Release Often และ Validate กับ Customer ตั้งแต่ได้ MVP

2. Welcome Changing Requirements Even Late in the Project

ข้อนี้ผ่าน เพราะเรา Welcome Change มาก ๆ และ Re-Prioritize Requirements ตัว Feature ใหญ่อย่าง Multi-Tenancy ให้เร็วขึ้นได้อย่างชัดเจน

3. Deliver Value Frequently

ข้อนี้ผ่าน เราได้ MVP ไปคุยกับ Partner และ Customer ได้บ่อยมาก ๆ

4. Break the Silos of Your Project

ข้อนี้ผ่าน เพราะทั้ง Business, Customer Partner และ ทีมอื่น ๆ สามารถ Feedback ได้เต็มที่มาก

5. Build Projects Around Motivated Individuals

ข้อนี้ผ่านเพราะ Engineer ที่มาช่วย Code ยังหยิบ Issue ไป Implement ด้วยตัวเองอยู่ และมี Effect ไปถึง Engineer ในทีมอื่น ๆ ที่ค่อย ๆ เริ่มอยากมาช่วย

6. The Most Effective Way of Communication is Face-to-face

ข้อนี้จะถึงว่าผ่านก็น่าจะได้ เพราะมีการคุยตรงทั้งแบบ Text Chat และ Call ภายในทีม Dev เราเน้นคุย Text เพราะว่า Effective กว่า

7. Working Software is the Primary Measure of Progress

ข้อนี้ผ่านแน่นอน เพราะเราใช้การ Deliver ตัว Software วัดความก้าวหน้าอยู่แล้ว

8. Maintain a Sustainable Working Pace

ข้อนี้ถ้ามองในเชิง Working Pace จะถือว่าผ่านซัก ½ นึงเพราะคนอื่น ๆ ในทีมมีงานอย่างอื่นนอกจาก Project นี้อยู่ด้วย

9. Continuous Excellence Enhances Agility

ข้อนี้ต้องถือว่าผ่าน 100% แต่ละคนไปหาวิธีเขียน Code แก้ปัญหากันแบบสุด โดยเฉพาะชิ้น mTLS และ Cert Rotation ที่ Engineer คนนึงไปเจอมาจาก Project Gatekeeper รวมทั้งวิธีใช้ Go Channel ทำการ Guard การ Generate Cert ของ Controller ที่ไม่ใช่ Leader อันนี้ต้องถือว่าสุดมาก

10. Simplicity is Essential

ข้อนี้ผ่าน ผมยึดหลัก Keep It Simple, Stupid และใช้ Unix Philosophy ในการออกแบบอยู่แล้ว ถึงจะครบบ้างไม่ครบบ้างก็ตาม อะไรที่จะเพิ่มความซับซ้อนให้ระบบก่อนเวลาที่จำเป็นจะถูกผลักออก และการเอา gRPC มาใช้ได้ตรงประเด็นตอนสร้าง Runner Pod Sub-System ก็เป็นอีกหนึ่ง Decision Making ที่คิดว่าถูกต้องมาก ๆ (จำมาจากโครงการ Docker ตอนแยก Docker ด้านหน้ากับ Containerd) เพราะทำให้สามารถ Re-Use Test Case ที่ใช้ในการออกแบบ (มาอย่างอยากลำบากด้วย TDD) ได้ทั้งหมดโดยไม่ต้องทิ้งหรือเขียนใหม่เลย เราสามารถ Evolve จาก Architecture แบบ Monolith ไปเป็น 2 ชิ้น (Controller/Runner) โดยใช้ Reconciliation Logics เดิมได้เกือบ 100%

11. Self-organizing Teams Generate Most Value

ข้อนี้ผ่าน เพราะแต่ละคนเลือก Area ที่ถนัด ทำให้ได้ Feature ใหญ่ที่โปรเจ็คต้นทาง เช่น Flux ใช้เวลาเกือบ 2 ปีในการค้นคว้าและพัฒนา แต่เราทำเสร็จได้ MVP ภายใน 2 เดือน

12. Regularly Reflect and Adjust Your Way of Work to Boost Effectiveness

ข้อนี้ต้องถือว่าผ่านแค่ ½ เดียว เพราะเราไม่ได้ Retro กันเอง โดยแต่ละคนจะ Retro กันกับแต่ละทีม ทำให้การปรับปรุง Process ยังอยู่ที่ผมคนเดียว

ภาพรวพก็พอจะสังเกตได้ว่าประสิทธิภาพการทำงานจะยังแกว่ง ๆ อยู่บ้าง แต่ก็เร็วกว่าแผนเป็นระดับเดือน จุดปรับปรุงก็จะยังมีอยู่ตลอด เป็นความท้าทายของการผสานเอา Process Model มาใช้กับโครงการ Open Source ที่มีลักษณะเป็น Product และมีทั้ง Technical Challenge, Management Challenge และมี Stakeholders หลายกลุ่ม

--

--

Chanwit Kaewkasi
Chanwit Kaewkasi

Written by Chanwit Kaewkasi

Technical Advisor at ConfigHub Inc. ex-weaveworks. Go nut since r57 (pre v1)

No responses yet