จากการแบ่งปันเรื่อง 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 )