หลังจากอ่านบทความเรื่อง The MVP Dilemma: Scale Now or Scale Later?
ว่าด้วยเรื่องของการ scale ระบบงาน
ว่ามีแนวคิดที่น่าอย่างไรบ้าง
จึงทำการจดบันทึกสิ่งที่น่าสนใจไว้นิดหน่อย
ในการ scale ระบบนั้น เป็นเรื่องที่ไม่ง่ายเลย
มันขึ้นอยู่กับปัจจัยหลายสิ่งอย่าง
ถ้าไม่จัดการอะไรเลยตั้งแต่แรก หรือ under estimate
ก็อาจจะทำให้เกิดปัญหาต่อระบบ และ ต่อ business ได้
ถ้าระบบมัน work !!
หรือถ้าจัดการมากเกินไป หรือ over estimate
ก็ต้องลงทุนที่สูงเกินไป
จนอาจจะกระทบต่อ business ได้
ถ้าระบบมันไม่ work !!
ดังนั้นการ balance หรือ จัดการให้เหมาะสม
ซึ่งเป็นเรื่องที่ไม่ง่ายเลย
มาดูในส่วนของ requirment เกี่ยวกับการ scale ระบบ
ส่วนใหญ่จะเน้นไปในส่วนของ functional มากกว่า
ส่วนของ non-functional เช่น scalability และ security
จะไม่ได้ลงรายละเอียดมากนัก หรือ อาจจะเบลอ ๆ ไปอีก
เช่น user growth rate และ data growth rate เป็นอย่างไร ?
ทำให้ทีมอาจจะต้องมาเดากันเอง คิดกันเอง
ว่าระบบจะต้อง scale อย่างไรบ้าง !!
ในการพัฒนามักจะใช้แนวคิดของ MVP (Minimum Viable Product หรือ Minimum Valuable Product)
นั่นคือเลือกที่จะพัฒนาในส่วนที่สำคัญต่อ business และ ผู้ใช้งานก่อน
เพื่อใช้ในการ validate product ต่อผู้ใช้งาน ว่ามัน work หรือไม่
ซึ่งในเวลา และ ค่าใช้จ่ายที่ไม่สูงมาก
ในส่วนของ architecture และ การ scale ก็เช่นกัน
ก็ต้องมี minimum scalability requirement ของระบบด้วย (MVA = Minimum Viable Architecture)
ว่าเท่าไรที่จะตอบโจทย์ผู้ใช้งานและ business case นั้น ๆ ด้วย
แต่ไม่ over มากจนเกินไป หรือ ใช้ค่าใช้จ่ายมากจนเกินไป
ควรสัมพันธ์กับ market size และ การเติบโตของผู้ใช้งานและระบบ
เพื่อให้ได้ solution ที่เหมาะสม
แต่ต้องคอย monitoring เสมอว่า
solution ที่ใช้งานนั้น เริ่มมีปัญหาหรือไม่
ถ้าเริ่มมีปัญหาแล้ว ต้องทำการแก้ไขอย่างสม่ำเสมอ
ดังนั้นระบบ monitoring และ observability จึงมีความสำคัญมาก ๆ
เพื่อให้เห็นปัญหาต่าง ๆ ได้อย่างชัดเจน
เช่น feature หรือ end point ไหน
ที่ช้า ใช้ resource เยอะ และ query data ช้า หรือ เป็นคอขวด ก็ต้องรีบแก้ไข
อะไรที่มันเปลี่ยนแปลงบ่อย ก็แยกออกมาจากส่วนที่ไม่เปลี่ยนแปลง
อะไรที่ไม่ใช้งาน ก็ลบทิ้งไป เป็นต้น
ซึ่งการปรับเปลี่ยนต่าง ๆ ต้องชัดเจน รวมทั้งเปิดการตัดสินใจต่าง ๆ
ว่ามันช่วยให้ business และ องค์กร ดีขึ้นอย่างไรบ้าง
ปัญหาของการ scale มักจะมาจาก
- ปัญหาจากการแยก หรือ รวม ส่วนการทำงานต่าง ๆ ล้วนมีข้อดีและเสีย
- จัดการ shared resource หรือ สิ่งที่ใช้งานร่วมกันไม่ดี ทำให้ส่งผลกรพทบเมื่อมีปัญหา หรือ ใช้งานเยอะ ๆ
- การเลือกใช้ framework และ package/library ต่าง ๆ ต้องรู้และเข้าใจ
- ปัญหาอีกอย่างคือ Cloud syndrome หรือ โยนปัญหาไปให้ scale ที่ Cloud แทน แทนที่จะแก้ไขที่ root cause
- รูปแบบของการติดต่อสื่อสาร หรือ ทำงาน ทั้งแบบ Sync และ Async ที่ไม่เหมาะสมกับงาน
เรื่องที่น่าสนใจคือ Architecture experimentation เป็นสิ่งที่สำคัญมาก ๆ
