จากการสอนและแบ่งปันเรื่องการออกแบบระบบ
ตามแนวคิด Microservices ที่ Skooldio มา
มีหนึ่งสิ่งที่อยากแนะนำคือ
เมื่อเราเข้าใจและปัญหาที่ Microservices เข้ามาช่วยแก้ไขปัญหา
แต่ถ้าเรานำมาใช้แล้วดันเกิดปัญหามากกว่าเดิม
มันบ่งบอกว่า คุณไม่เข้าใจ หรือ เข้าใจผิด หรือ แก้ปัญหาด้วยวิธีการที่ผิดหรือไม่ ?
มาดูกันว่ามีอะไรบ้าง
ปัญหาใหญ่ แยกกันแล้วแต่ยังผูกมัดกันไปมา
เมื่อมีการแก้ไข ต้องแก้ไขหลาย service
เมื่อต้องการ deploy หรือ scale ก็กระทบไปกันหมด
ยังไม่พอ เมื่อเกิดปัญหา หาและแก้ไขยากกว่าเดิมอีก
หรืออาจจะมาในรูปแบบ layer หรือ service มาตรฐานของแต่ละงาน
จะมี service layer ที่เกี่ยวข้องกัน เช่น
- Data service
- Orchestration service
- Backend-for-Frontend
- Messaging
แต่ข้อดีของวิธีการนี้คือ
- ทุกคนในทีมและบริษัทจะพูดในทางเดียวกัน
- ทำให้ไม่ต้องสร้างขึ้นมาใหม่ทุกครั้ง
- ง่ายต่อการจัดการ
- ง่ายต่อการบอกว่า จะต้องสร้าง service อะไรบ้าง และแต่ละ service ทำอะไร
แน่นอนว่า มีทั้งข้อดีและข้อเสีย
ปัญหาต่อมาคือ มักจะแยก service level มากกว่า database layer
ซึ่งทำให้ระบบ scale ได้ยากมาก ๆ
เรามักจะทำอะไรที่มันง่ายกว่าเสมอหรือไม่ ?
เรานำแนวคิด Microservices มาใช้เพราะว่าอะไร
มีปัญหาหรือไม่
หรือต้องทำเพราะว่า โดนสั่ง
หรือต้องทำเพราะว่า มันคือ trend
แนะนำคือ ต้องเริ่มที่ปัญหาและยอมรับปัญหาก่อน
จากนั้นจึงหาวิธีการแก้ไขปัญหานั้น ๆ
ซึ่งอาจจะแก้ไขได้หรือไม่ ด้วยแนวคิด Microservices ก็ได้
เราทำ Microservices แต่เรามีทีมดูแล Core service นะ
Core service คือ service หลักที่ service อื่น ๆ เรียกใช้งาน
เรามักจะบอกว่า มันคือ reuse service นั่นเอง
แน่นอนว่า จำเป็นต้องมีทีมดูแลมากเป็นพิเศษ
เพราะว่ามีคนใช้งานเยอะ
ถ้าคนใช้งานหนึ่ง ขอเปลี่ยนแปลงบางอย่าง จะทำได้ไหมนะ ?
ถ้าทำได้หนึ่งคน แสดงว่าจะมี logic ของคนนั้นมาอยู่ใน core service
คำถามคือ core service มันคือ core service จริงไหม ?
ความรู้เกี่ยวกับ Core domain จะกระจุกอยู่กับ core team เท่านั้นใช่ไหม
ซึ่งมันขัดแย้งกับแนวคิดของ cross-functional team หรือไม่
เพราะว่าเป็นการทำงานแบบ component teamปัญหายังคงอยู่ไหมนะ ?
ยังไม่พอ ทีมสร้างพัฒนา กับทีมดูแล เป็นคนละทีมกัน ?
คาดว่ามีความสนุกแน่นอน
การติดต่อสื่อสารระหว่าง service ก็ไม่ใช่เลือกตามอารมณ์
ต้องรู้และเข้าใจก่อนว่าในแต่ละ use case การติดต่อสื่อสาร
ควรเป็นอะไรsync หรือ async หรือ event-based เป็นต้น
แบ่งเป็น service เล็ก ๆ ให้ทำงานเป็นอิสระต่อกันแล้ว แต่เมื่อมีปัญหากลับรู้จากผู้ใช้งาน
แต่ทีมหรือบริษัทกลับไม่รู้ หรือ รู้ช้า
นั่นคือปัญหาเรื่องของ observability เช่น logging, tracing และ metric
ที่ยังไม่เพียงพอ หรือ พร้อม หรือไม่
ง่าย ๆ คือ ถ้าทำลงไปแล้ว กลับแย่มากกว่าส่งผลดี
แสดงว่า เรากำลังเดินไปในเส้นทางที่ผิด
ให้ลองหยุดและกลับมามองว่า
ข้อผิดพลาดคืออะไรกันแน่เพื่อปรับปรุง ปรับเปลี่ยนให้มันถูกต้อง