หลังจากที่ได้แบ่งปันเรื่องของ Microservices ไปว่า มีที่มาที่ไปอย่างไร
นำมาแก้ไขและสร้างปัญหาอะไรบ้าง
โดยหนึ่งในเรื่องที่น่าสนใจคือ
ก่อนที่จะมาถึง Microservices นั้น มักจะมีการพูดถึง
แนวคิดของ Module, Subsystem และ Component
ว่าแต่มันคืออะไร ต่างกันอย่างไร ?
ดังนั้นจึงสรุปตามที่เข้าใจไว้นิดหน่อย ดังนี้
ปล. ก็ไม่รู้ว่าถูกหรือผิดนะ
มาเริ่มกันเลย
เริ่มจากแนวคิด Module
เป็นการแบ่งกลุ่มตาม logical ของ code ที่มาหน้าที่ต่างกัน ออกจากกัน
โดยที่ code ในแต่ละ module ยังอยู่ที่เดียวกัน หรือ physical เดียวกัน
ซึ่งจะเห็นได้ชัดเจนจากภาษาโปรแกรมต่าง ๆ เช่น
- Go คือ go module
- Java คือ package
- C# คือ namespace
มีเป้าหมายตามแนวคิด SRP (Single Responsibility Principle) นั่นเอง
ต่อมาเรื่องของ Subsystem
แปลตรงตัวก็คือ ระบบย่อย ๆ นั่นเอง
Subsystem คือ การจัดกลุ่มของ Module อีกชั้นหนึ่ง
ในแต่ละ Subsystem จะประกอบด้วย module ตั้งแต่ 1 ขึ้นไป
โดยแต่ละ Subsystem ไม่จำเป็นต้องแยกในระดับ physical
แต่ละ Subsystem อาจจะแบ่งตาม layer ของการทำงาน เช่น
- Presentation layer
- Business layer
- Data layer
ถ้าแบ่งออกตาม physical แล้ว เราจะเรียกว่า Tier ใช่ไหม
เช่น Presentation tier, Business tier เป็นต้น
หรือตามกลุ่มของการทำงานในเชิง business ก็ได้ (Boundary context)
ซึ่งถ้าแยกกันตาม physical แล้ว อาจจะอยู่ในรูปแบบของ service เล็ก ๆ
ที่สามารถทำงานจบได้ด้วยตัวเอง เป็นอิสระจากส่วนอื่น ๆ
เราก็อาจจะเรียกว่า Microservices ก็เป็นได้นะ
จะเห็นได้ว่า เป้าหมายของ Subsystem นั้น
เพื่อให้สามารถดูแลและจัดการได้ง่ายขึ้น
แต่ละ Subsystem ก็จะมีผู้เชี่ยวชาญด้านนั้น ๆ คอยดูแลและพัฒนาอย่างชัดเจน
เรื่องสุดท้ายคือ Component
ว่าด้วยการแยกส่วนการทำงานออกจากกันในเชิง physical นั่นเอง
ซึ่งในแต่ละ component สามารถประกอบไปด้วย Subsystem และ Module นั่นเอง
ในแต่ละ component จะมี interface ใช้สำหรับการติดต่อสื่อสาร
โดยที่ผู้ใช้งานไม่ต้องรู้ถึง implementation ข้างในเลยก็ได้
ทำให้ง่ายต่อการเปลี่ยนแปลง
รวมไปถึงการ deploy และ scale ที่ง่ายและเป็นอิสระขึ้น
ดังนั้นเรื่องของ Tier และ Microservices จึงมีพื้นฐานมาจาก Component ด้วยนั่นเอง
ต่างกันตรงที่รูปแบบของการแบ่งนั่นเอง ว่าเป็นอย่างไร
ปล. อย่าไปตีกับ component ในส่วนของพวก Frontend framework ละครับ !!
