สถาปัตยกรรม Microservices เทียบกับ Monolithic: คุณควรสร้างแบบไหน?
ครั้งหนึ่ง ผู้ก่อตั้งคนหนึ่งเคยขอให้ผมช่วยรีวิวแผนนำเสนอสถาปัตยกรรม (architecture pitch)
เอเจนซี่เสนอให้ใช้ถึง 11 บริการ (services), message queue และ service mesh ทั้งที่มันเป็นเพียงเครื่องมือจองแบบง่ายๆ ที่ยังไม่มีผู้ใช้งานเลยด้วยซ้ำ
นั่นคือกับดัก
การตัดสินใจเรื่องสถาปัตยกรรมจะเป็นตัวกำหนดค่าใช้จ่ายในการโฮสต์ (hosting bills), ความเร็วในการส่งมอบงาน (shipping speed) และแผนการจ้างงานของคุณ คุณต้องรู้ต้นทุนก่อนที่จะมอบงบประมาณให้กับนักพัฒนา
Monolith Monolith ใช้ codebase เดียว, การ deploy ครั้งเดียว และฐานข้อมูลเดียว มันมีความเรียบง่าย
ในวันแรก คุณยังไม่รู้ขอบเขตของโดเมน (domain boundaries) ที่ชัดเจน หากคุณแยกบริการเร็วเกินไป คุณจะต้องเสียเวลาไปกับการย้ายกำแพงที่จริงๆ แล้วไม่ควรมีอยู่ Monolith นั้นจัดการได้ง่ายกว่าเมื่อทีมของคุณยังมีขนาดเล็ก คุณสามารถเรียกใช้ function แทนที่จะต้องตั้งค่า API และเมื่อเกิด bug ตอนตี 2 ข้อผิดพลาดจะชี้ไปที่ตัวโค้ดโดยตรง ไม่ใช่ความล้มเหลวของระบบเครือข่าย (network failure)
Microservices Microservices ช่วยแก้ปัญหาในเชิงองค์กร ช่วยให้ทีมต่างๆ สามารถส่งมอบโค้ดตามกำหนดการของตนเองได้ Netflix ใช้สิ่งนี้เพื่อป้องกันไม่ให้ความผิดพลาดเพียงจุดเดียวทำให้ระบบทั้งหมดล่ม
อย่างไรก็ตาม คุณต้องจ่ายราคาที่ต้องแลกในทุกๆ วัน การเรียกใช้งานผ่านเครือข่าย (network calls) ทำให้เกิดความหน่วง (latency) ความสอดคล้องของข้อมูล (data consistency) กลายเป็นเรื่องยาก คุณต้องใช้เครื่องมือเฉพาะทางและทีมขนาดใหญ่เพื่อจัดการ logs และการทำ tracing หากไม่มีจำนวนพนักงานที่เหมาะสม คุณจะลงเอยด้วย "distributed monolith" ซึ่งจะให้ความซับซ้อนของระบบเครือข่ายทั้งหมด แต่กลับไม่มีความเป็นอิสระต่อกันเลย
Modular Monolith นี่คือทางสายกลาง มันคือแอปพลิเคชันเดียวที่มีการแบ่งขอบเขตระหว่างส่วนต่างๆ ของโค้ดอย่างชัดเจน เช่น ระบบเรียกเก็บเงิน (Billing) จะไม่สามารถเข้าไปยุ่งกับส่วนสำคัญของระบบคำสั่งซื้อ (orders) ได้
Shopify และ GitHub ใช้แนวทางนี้ คุณจะได้ขอบเขตที่ชัดเจนและหลีกเลี่ยง "ภาษีเครือข่าย" (network tax) เมื่อส่วนใดส่วนหนึ่งของแอปจำเป็นต้องขยายขนาด (scale) แยกต่างหากในภายหลัง คุณก็สามารถแยกมันออกมาได้ง่ายเพราะมีการกำหนดขอบเขตไว้เรียบร้อยแล้ว
วิธีการตัดสินใจ:
- ขนาดของทีม: หากคุณมีคนเพียง 3 คน คุณไม่สามารถจัดการบริการที่แยกจากกันและระบบการเข้าเวร (on-call rotation) ที่จำเป็นได้
- ความเสถียรของผลิตภัณฑ์: หากผลิตภัณฑ์ของคุณมีการเปลี่ยนแปลงทุกสัปดาห์ ขอบเขตของบริการที่คุณตั้งไว้จะผิดเพี้ยนไปในเดือนถัดไป
- การปฏิบัติการ (Operations): คุณมีระบบ rollback อัตโนมัติและระบบรวบรวม log (log aggregation) หรือไม่? ถ้าไม่มี Microservices จะสร้างความลำบากให้คุณอย่างมาก
- การขยายตัว (Scale): อย่าสร้างเพื่อรองรับการเติบโตที่สมมติขึ้นมา แต่จงสร้างเพื่อรองรับเส้นทางที่จับต้องได้จริงที่คุณมองเห็น
หากคำตอบของคุณคือ "ยังไม่ถึงเวลา" ให้สร้าง modular monolith
อย่าเรียกร้องขอใช้ microservices เพียงเพราะคำนี้ฟังดูทันสมัย แต่จงบอกพาร์ทเนอร์ของคุณว่าผลิตภัณฑ์ทำอะไรได้บ้าง และใครจะเป็นคนดูแลมัน
ผลิตภัณฑ์ล้มเหลวเพราะไม่เคยถูกปล่อยออกมาใช้งานจริง การสร้าง Monolith ที่เป็นระเบียบคือวิธีที่เร็วที่สุดในการเข้าถึงผู้ใช้งาน จงสร้างสิ่งนั้นขึ้นมาก่อน แล้วปล่อยให้จำนวนผู้ใช้งานเป็นตัวบอกคุณเองว่าเมื่อไหร่ถึงเวลาที่ต้องแยกส่วนประกอบเหล่านั้นออกมา
ชุมชนแห่งการเรียนรู้ (เลือกเข้าร่วมได้): https://t.me/GyaanSetuAi