จากการแบ่งปันเรื่อง Microservices นั้น มักจะแนะนำให้เริ่มจาก Monolithic app ไปก่อน
ทำให้มันดีก่อน ที่จะแยกไปเป็น service ย่อย ๆ
จากนั้นทำการ monitor ว่าแนวทางนั้นมันส่งผลกระทบต่อระบบ และ การทำงานหรือไม่
เช่น productivity ของการส่งมอบ ผลกระทบจากการส่งมอบ
รวมถึงการ maintain ระบบ ว่ายากขึ้นหรือไม่ ?
มีคำถามว่า Monolithic App นั้นมีรูปแบบไหนบ้าง ?
จึงทำการสรุปไว้คร่าว ๆ ดังนี้
- รูปแบบที่ 1 มุมมองของ code คือ Single repository นั่นเอง เข้าที่เดียวมีครบ เช่นรวม frontend กับ backend เป็นต้น
- รูปแบบที่ 2 มุมมองของ database คือ Single database มีจำนวน table เยอะ ๆ หนักกว่านั้นแยก database scahema นะ แต่ join ข้าม databaseซะงั้น
- รูปแบบที่ 3 Service ใหญ่ ๆ มีหน้าที่รับผิดชอบเยอะมาก ๆ เพิ่มไปเรื่อย ๆ รูปว่าไม่ดีก็ยังเพิ่มเข้าไปอีก ไม่ใช่หน้าที่โดยตรงก็ดันเพิ่มเข้าไป
- รูปแบบที่ 4 App ใหญ่ ๆ เพิ่ม feature ไปเรื่อย ๆ ส่งช้าลงเรื่อย ๆ มีปัญหาขึ้นเรื่อย ๆ เช่น Supur app เป็นต้น แต่ถ้าจัดการดีก็ดีไป
ในการรวมกันนั้นมีทั้งข้อดีและข้อเสีย
แต่ถ้ามาแนวทางนี้แล้ว จำเป็นต้องมีการออกแบบและลงมือทำที่ดีด้วย
ยกตัวอย่างเช่น
- ความเข้าใจใน requirement แบบ end-to-end ไม่ใช่เพียงรู้ในส่วนที่ตัวเองทำหรือรับผิดชอบเท่านั้น
- แบ่งส่วนการทำงานแบบ modular ให้ดี ลดการผูกมักระหว่าง module ลงไปให้เยอะ (loose couple)
- ออกแบบโครงสร้างข้อมูลของแต่ละ module/domain ให้ชัดเจน แยก database schema ให้ชัดเจน
- แนวทางในการทดสอบที่ดี
- ในแต่ละ service ควรมีการแยกการ deploy ให้เป็นอิสระมากยิ่งขึ้น
- ระบบ monitoring และ observability ที่ดี เพื่อเป็นข้อมูลในการตัดสินใจ
ข้อควรระวัง !!!
- เมื่อแยก database schema แล้ว ก็อย่าให้เรียกข้ามกัน
- เมื่อแยก module แล้วก็อย่าให้ผูกมัดกัน
- เมื่อแยก service กัน ก็อย่าเรียกกันไปมา มันจะเกิด Distributed monolithic ได้
- เมื่อ productivity เริ่มลดลง ก็ได้เวลาหยุด เพื่อทำการปรับปรุง ( Later === Never )