จากการแบ่งปันเรื่องของ Microservices ซึ่งเป็นหนึ่งแนวทางในการแก้ไขปัญหา
แต่สิ่งที่มักจะพบเจอ คือ ทำไปแล้วมีปัญหาหนักกว่าเก่า
แสดงว่า อาจจะไม่ได้นำมาเพื่อแก้ไขปัญหาหรือเปล่านะ
เมื่อกลับมาดูที่โครงสร้างของระบบงาน
บ่อยครั้งจะพบปัญหามากมาย จึงทำการสรุปรูปแบบของปัญหาไว้นิดหน่อย
อาจจะไม่ใช่ปัญหาก็ได้นะ
เรื่องแรกคือ Sharing หรือ Reuse มากเกินไป ทำให้เกิดมะเร็ง service
รูปแบบที่เจอเยอะมาก ๆ
เนื่องจากเริ่มแรกน่าจะดี เพราะว่า มีการ reuse หรือ sharing หรือ common service
แต่เมื่อเวลาผ่านไป พบว่า service เหล่านี้จะใหญ่ขึ้น
มีการนำ logic ของคนใช้งานจากระบบต่าง ๆ เข้ามาด้วย
ทำให้สูญเสียความเป็นตัวเองไป
แก้ไขให้บางระบบ แล้วกระทบหลายระบบ
จนสุดท้ายก็ให้เกิดผลกระทบเยอะมาก ๆ
ปัญหาเกิดจากเรื่องขอบเขตของหน้าที่รับผิดชอบของ service ไม่ชัดเจน
อาจจะมาจากคำว่า ขอเพิ่มอีกนิดหน่อยได้ไหม !!
หรืออาจจะบอกว่า เรามีเวลาไม่มาก ต้องรีบแล้ว
เลยทำ ๆ ให้เสร็จไปก่อน แล้วค่อยมาแก้ไขทีหลัง (Develop + Test + Deploy)
จะพบว่า ไม่มีการกลับมาแก้ไขเลย (Later === Never)
เรื่องที่สอง แยก service เยอะมาก ๆ ทำให้เกิด overhead ของการติดต่อสื่อสารระหว่าง service
เป็นเรื่องที่เจอเยอะมาก ๆ คือ แบ่งมากจนเกินไป
อะไรที่ต้องทำงานด้วสยกันเสมอ ก็ดันไปแยก (Low cohesion)
หรือ แยกไว้เผื่ออนาคต แต่ว่าปัจจุบันยังไม่รอดเลย
ทำให้เกิดปัญหาตามมามากมาย
เช่น response time สูงขึ้นมา, network ใช้งานเยอะเกินไป เป็นต้น
หนักกว่านั้น เมื่อบาง service มีปัญหาแล้ว
ทำให้ระบบโดยรวมมีปัญหาไปด้วยหมดเลย !! (Cascade failure)
แถมไม่เคยวางแผนเรื่องของการจัดการเมื่อเกิดปัญหาไว้อีกด้วย (Plan for failure)
สิ่งที่น่าสนใจคือ
Decomposition != Decoupling นะ
เกิด Distributed monolith ไหมนะ ?
เรื่องที่สามคือ ข้อมูลกระจายหลายที่ เรื่องความถูกต้องก็ขาดหายไป
ต้องมาแก้ไขปัญหาเฉพาะหน้าเสมอ
เช่น ต้องมาแก้ไขข้อมูลในระบบต่าง ๆ ให้เท่ากันตลอด !!
เบื่อไหมนะ
ทำไปทำมา รวมกัน data เหมือนเดิมดีกว่า
มันยังไงกัน
เรื่องที่สี่ คือ ระบบ monitoring หรือ observability ของ service ที่ไม่ดี หรือ เพียงพอ
เมื่อเกิดปัญหาขึ้นมา เรารู้ปัญหาได้รวดเร็วไหม
หรือรู้ว่า น่าจะเกิดปัญหาในอนาคตอันใกล้
เมื่อมีปัญหาขึ้นมา เราสามารถเข้าไปถึงจุดเกิดเหตุได้เร็วหรือไม่ ?
ยิ่งเข้าถึงได้รวดเร็ว น่าจะแก้ไขได้เร็วขึ้น
ดีกว่านั้น ถ้าระบบมีปัญหาสามารถ recover กลับมาได้ง่าย
หรือปิด feature เหล่านั้นไปเลยจะดีกว่า ทำให้ปัญหาขยายวงกว้าง ?
ดังนั้นเรื่อง observability สำคัญมาก ๆ
- Alert system
- Application metric
- Distributed tracing
- Centralized logging
- Exception tracking
น่าสนใจว่า เราแก้ไขปัญหา หรือ สร้างปัญหาขึ้นมา
เรื่องนี้สำคัญมาก ๆ
