จากการสอนและแบ่งปันเรื่องการออกแบบระบบ
ตามแนวคิด 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
ที่ยังไม่เพียงพอ หรือ พร้อม หรือไม่

ง่าย ๆ คือ ถ้าทำลงไปแล้ว กลับแย่มากกว่าส่งผลดี
แสดงว่า เรากำลังเดินไปในเส้นทางที่ผิด
ให้ลองหยุดและกลับมามองว่า
ข้อผิดพลาดคืออะไรกันแน่เพื่อปรับปรุง ปรับเปลี่ยนให้มันถูกต้อง