ทำความรู้จัก Modular Monolith: สถาปัตยกรรมที่สมดุลระหว่าง Monolith และ Microservices

#architecture #modular

Originally published at https://somprasongd.work/blog/architecture/modular-monolith

ในการออกแบบซอฟต์แวร์ สถาปัตยกรรมเป็นหนึ่งในปัจจัยสำคัญที่มีผลต่อความสามารถในการขยายตัว (scalability) การดูแลรักษา (maintainability) และประสิทธิภาพ (performance) ของระบบ แนวทางหลัก ๆ ในการออกแบบระบบ ได้แก่ Monolith, Modular Monolith, Microservices, และ Distributed Monolith ในบทความนี้ เราจะมุ่งเน้นไปที่ Modular Monolith ซึ่งเป็นทางเลือกที่สมดุลระหว่างความง่ายของ Monolith และความยืดหยุ่นของ Microservices

ทำความเข้าใจภาพรวมของสถาปัตยกรรมต่าง ๆ

รูปจาก: https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity

ก่อนที่เราจะเจาะลึกถึง Modular Monolith มาดูภาพรวมของแต่ละสถาปัตยกรรมที่แสดงในรูป:

Monolith: ระบบทั้งหมดรวมอยู่ในโค้ดเบสเดียวและ deploy เป็นหน่วยเดียวกัน (single deployment unit) ทำให้พัฒนาง่ายแต่ขยายระบบลำบาก
Microservices: แต่ละโมดูลแยกออกเป็นบริการอิสระ (independent services) สามารถพัฒนา ทดสอบ และ deploy แยกจากกันได้
Distributed Monolith: ระบบถูก deploy ออกเป็นหลายหน่วยแต่ยังคงมีการพึ่งพากันอย่างแน่นหนา ทำให้ขยายตัวยาก
Modular Monolith: โค้ดถูกแยกเป็นโมดูลภายในระบบเดียวกัน มีขอบเขตที่ชัดเจนแต่ยังคง deploy เป็นหน่วยเดียว

Modular Monolith คืออะไร?

Modular Monolith เป็นสถาปัตยกรรมที่พยายามนำข้อดีของ Monolith และ Microservices มารวมกัน โดยมีลักษณะดังนี้:

การแยกโมดูลภายในระบบเดียวกัน: ระบบถูกแบ่งเป็นโมดูลแยกจากกัน (เช่น Payments, Bookings, Reviews) โดยแต่ละโมดูลมีขอบเขตที่ชัดเจนและสื่อสารกันผ่าน API ภายใน
Deployment เป็นหน่วยเดียว: แม้ว่าโมดูลจะแยกกันชัดเจน แต่การ deploy ยังคงอยู่ในรูปแบบของแอปพลิเคชันเดียว
การรักษาความสมบูรณ์ของข้อมูล (Data Integrity): ต่างจาก Microservices ที่แต่ละบริการมีฐานข้อมูลของตัวเอง Modular Monolith มักใช้ฐานข้อมูลเดียวกัน แต่แบ่ง schema หรือใช้แนวทาง Database per Module
การสื่อสารภายในที่มีประสิทธิภาพ: โมดูลสามารถเรียกใช้กันโดยตรงผ่าน method calls หรือภายใน memory แทนที่จะต้องใช้ HTTP/gRPC เหมือนใน Microservices ทำให้ลด latency ลง
ง่ายต่อการเปลี่ยนไปใช้ Microservices: Modular Monolith ช่วยให้ทีมพัฒนาออกแบบระบบเป็นโมดูลตั้งแต่แรก ทำให้สามารถแยกโมดูลออกมาเป็น Microservices ได้ง่ายขึ้นในอนาคต

ข้อดีของ Modular Monolith

ลดความซับซ้อนของการ Deploy: เนื่องจากทุกโมดูลอยู่ในระบบเดียว การจัดการ deployment ง่ายกว่าการต้อง deploy หลาย services
พัฒนาง่ายและมีประสิทธิภาพสูง: นักพัฒนาสามารถทำงานใน codebase เดียวกัน โดยไม่ต้องเสียเวลาในการตั้งค่า service-to-service communication เหมือนใน Microservices
รักษาความสม่ำเสมอของข้อมูลได้ง่าย: ใช้ฐานข้อมูลเดียวกัน ทำให้ลดปัญหา data inconsistency ที่มักเกิดขึ้นใน Microservices
ลด Overhead ของ Infrastructure: ไม่ต้องจัดการระบบ orchestration ซับซ้อนเช่น Kubernetes หรือ API Gateway เหมือนใน Microservices
รองรับการขยายในอนาคต: ถ้าจำเป็น สามารถแยกโมดูลออกมาเป็น Microservices ได้โดยไม่ต้องรื้อโครงสร้างระบบทั้งหมด

ข้อเสียของ Modular Monolith

การ Deploy ยังต้องทำทั้งระบบ: แม้จะมีโมดูลแยกกัน แต่เมื่อมีการเปลี่ยนแปลงในโค้ด ระบบทั้งหมดต้องถูก deploy พร้อมกัน
อาจนำไปสู่ Distributed Monolith ถ้าออกแบบไม่ดี: หากโมดูลต่าง ๆ ถูก deploy แยกกันโดยที่ยังคงมีการพึ่งพากันสูง อาจทำให้เกิด Distributed Monolith ซึ่งมีปัญหาที่ยากต่อการจัดการ
ข้อจำกัดของ Scaling: ไม่สามารถ scale แต่ละโมดูลแยกจากกันได้ง่ายเหมือนใน Microservices

Modular Monolith เหมาะกับใคร?

ทีมที่ต้องการสร้างระบบที่มี ขอบเขตโมดูลชัดเจน แต่ยังไม่ต้องการความซับซ้อนของ Microservices
องค์กรที่ต้องการลด Overhead ของ Infrastructure และมีทีมขนาดเล็กถึงกลาง
ระบบที่ยังไม่ต้องการ scale แบบอิสระในแต่ละโมดูล แต่ต้องการเตรียมความพร้อมสำหรับอนาคต

สรุป

Modular Monolith เป็นแนวทางที่อยู่ระหว่าง Monolith และ Microservices ซึ่งให้ความสมดุลระหว่างความง่ายในการพัฒนาและการแยกโมดูลที่ชัดเจน เป็นตัวเลือกที่เหมาะสมสำหรับทีมที่ต้องการแยกโมดูลแต่ยังไม่ต้องการความซับซ้อนของ Microservices อย่างไรก็ตาม การออกแบบให้โมดูลมีขอบเขตที่ชัดเจนและลดการ coupling ระหว่างโมดูลเป็นสิ่งสำคัญ เพื่อป้องกันการกลายเป็น Distributed Monolith โดยไม่ตั้งใจ

หากระบบของคุณเติบโตขึ้นและต้องการขยายตัว Modular Monolith จะช่วยให้สามารถเปลี่ยนไปใช้ Microservices ได้ง่ายขึ้น ทำให้เป็นแนวทางที่ได้รับความนิยมในการออกแบบระบบยุคใหม่