สถาปัตยกรรม Composable คือวิธีการสร้างระบบซอฟต์แวร์จากส่วนประกอบอิสระที่เปลี่ยนแทนกันได้และเป็นเลิศในแต่ละด้าน (best-of-breed components) ซึ่งสื่อสารกันผ่าน API แทนที่จะเป็นแพลตฟอร์มขนาดใหญ่แบบรวมทุกอย่าง เป็นแนวคิดที่กว้างขึ้นที่การเคลื่อนไหวแบบ headless ครอบคลุม และมีความเชื่อมโยงอย่างใกล้ชิดกับ MACH Alliance ซึ่งเป็นองค์กรอุตสาหกรรมที่เป็นกลางที่ส่งเสริมเทคโนโลยีองค์กรแบบเปิดและ Composable
ทำความเข้าใจในเบื้องต้นก่อน
คำว่า “composable” ปรากฏในสามบริบทที่แตกต่างกันมาก มาทำความเข้าใจสิ่งเหล่านี้ตอนนี้เพื่อให้ส่วนที่เหลือของคู่มือนี้สมเหตุสมผล
- สถาปัตยกรรม Composable (บทความนี้) คือแนวทางการออกแบบซอฟต์แวร์ คุณประกอบแอปพลิเคชันจากส่วนประกอบทางธุรกิจที่แยกกัน โดยแต่ละส่วนจะผสานรวมกันผ่าน API
- โครงสร้างพื้นฐาน Composable เป็นแนวคิดเกี่ยวกับฮาร์ดแวร์และศูนย์ข้อมูล Compute, storage และ networking ถูกรวมกันเป็นพูลและจัดสรรให้กับปริมาณงานตามความต้องการ มันอยู่ใต้ระบบปฏิบัติการ ไม่ได้อยู่ในโค้ดแอปพลิเคชันของคุณ
- DeFi composability เป็นแนวคิดบล็อกเชน มักเรียกว่า “money legos” สัญญาอัจฉริยะ เช่น โปรโตคอลการให้กู้ยืมและการแลกเปลี่ยน ซ้อนทับกันเพื่อสร้างผลิตภัณฑ์ทางการเงินใหม่ๆ
เป็นคำรากศัพท์เดียวกัน แต่เป็นสามชั้นที่ไม่มีความเกี่ยวข้องกัน จากนี้ไป คำว่า “composable” จะหมายถึงความหมายในแง่ของสถาปัตยกรรมซอฟต์แวร์
สถาปัตยกรรม Composable หมายถึงอะไรกันแน่
ระบบ Composable สร้างขึ้นจากหน่วยโมดูลาร์ที่แยกจากกันโดยสมบูรณ์ ซึ่งแต่ละหน่วยมีความสามารถทางธุรกิจที่สมบูรณ์ในตัวเอง คุณสามารถเลือกเครื่องมือที่ดีที่สุดสำหรับแต่ละงาน เชื่อมต่อพวกมันผ่าน API และสับเปลี่ยนส่วนใดส่วนหนึ่งออกในภายหลังได้โดยไม่ต้องสร้างทุกอย่างใหม่
หน่วยของการประกอบมีชื่อว่า: packaged business capability หรือ PBC Gartner นิยาม PBCs ว่าเป็นความสามารถที่สามารถปรับใช้ได้อย่างอิสระซึ่งรวมถึงข้อมูลทางธุรกิจ ตรรกะ และกระบวนการที่แยกจากกัน และสื่อสารกับแอปพลิเคชันอื่น ๆ ผ่าน API และช่องทางเหตุการณ์ต่างๆ
ลองนึกภาพ PBC เป็นโดเมนธุรกิจทั้งหมดในกล่องหนึ่งกล่อง PBC "การชำระเงิน" จะดูแลวิธีการชำระเงิน การตรวจสอบการฉ้อโกง การคืนเงิน และข้อพิพาทต่างๆ PBC "การค้นหา" จะดูแลการทำดัชนี การจัดอันดับ และการจัดการการค้นหา แต่ละส่วนจะเปิดเผย API ในระดับธุรกิจ ไม่ใช่ตารางฐานข้อมูลดิบ และคุณสามารถจัดหาจากผู้ขายหรือสร้างขึ้นเองได้ คุณประกอบผลิตภัณฑ์ของคุณจากบล็อกเหล่านี้ในแบบที่คุณจะประกอบชิ้นส่วนของชุดอุปกรณ์
Composable กับ Monolith
Monolith จะรวมทุกความสามารถเข้าไว้ในแอปพลิเคชันเดียวที่สามารถปรับใช้ได้และใช้ฐานข้อมูลร่วมกัน มันง่ายที่จะเริ่มต้น แต่จะยากขึ้นในการเปลี่ยนแปลงเมื่อมันเติบโตขึ้น สถาปัตยกรรม Composable จะแยกความสามารถเหล่านั้นออกจากกันเพื่อให้แต่ละส่วนสามารถพัฒนาได้ด้วยตัวเอง หากคุณเคยอ่านเกี่ยวกับความแตกต่างระหว่าง monolith กับ microservices แล้ว Composable ก็คือการจัดกรอบความสามารถทางธุรกิจของการเปลี่ยนแปลงเดียวกัน: microservices คือการแยกส่วนทางเทคนิค ส่วน PBCs คือการแยกส่วนตามโดเมนธุรกิจ
นี่คือความแตกต่างโดยสรุป
| มิติ | Monolith | สถาปัตยกรรม Composable |
|---|---|---|
| หน่วยของการเปลี่ยนแปลง | แอปพลิเคชันทั้งหมด | PBC เดียว |
| ข้อมูล | ฐานข้อมูลที่ใช้ร่วมกันหนึ่งชุด | แต่ละความสามารถมีข้อมูลของตนเอง |
| ทางเลือกผู้จำหน่าย | หนึ่งแพลตฟอร์ม รับไปทั้งหมด | ดีที่สุดในแต่ละด้านสำหรับแต่ละความสามารถ |
| ส่วนหน้า (Front end) | ผูกติดกับส่วนหลัง (back end) | แยกออกจากกัน สามารถมีได้หลายช่องทาง |
| การผสานรวม | การเรียกใช้ฟังก์ชันภายใน | API และเหตุการณ์ |
| ความเสี่ยงจากการถูกผูกมัด | สูง | ต่ำกว่า ส่วนประกอบสามารถเปลี่ยนได้ |
การแลกเปลี่ยนนี้เป็นเรื่องจริง Composable ให้ความยืดหยุ่นและสามารถเปลี่ยนแทนได้ นอกจากนี้ยังทำให้คุณมีส่วนประกอบที่ต้องผสานรวม ตรวจสอบ และรักษาข้อตกลงกันมากขึ้น
MACH: มาตรฐานที่คนส่วนใหญ่นึกถึง
เมื่อทีมพูดว่า “composable” พวกเขามักจะหมายถึงสแต็กที่ปฏิบัติตามหลักการของ MACH MACH เป็นคำย่อ และ MACH Alliance (ก่อตั้งในปี 2020) ส่งเสริมสิ่งนี้ให้เป็นสถาปัตยกรรมสำหรับระบบ Composable แบบเปิด
- M, Microservices. ความสามารถถูกสร้างขึ้นเป็นบริการขนาดเล็กที่สามารถปรับใช้ได้อย่างอิสระ แทนที่จะเป็นบล็อกเดียว
- A, API-first. ทุกฟังก์ชันจะถูกเปิดเผยผ่าน API ส่วนต่อประสานผู้ใช้ (UI) เป็นเพียงผู้ใช้หนึ่งในหลายๆ ผู้ใช้ของ API นั้น ไม่ใช่ทางเข้าเดียว
- C, Cloud-native. ส่วนประกอบถูกสร้างขึ้นสำหรับคลาวด์ โดยใช้การปรับขนาดแบบยืดหยุ่นและบริการที่มีการจัดการ
- H, Headless. ส่วนหน้า (front end) ถูกแยกออกจากส่วนหลัง (back end) ทำให้คุณสามารถส่งไปยังเว็บ มือถือ ตู้คีออสก์ หรืออื่นๆ ได้จาก API ชุดเดียวกัน
โปรดสังเกตว่า composable, headless และ MACH ไม่ใช่คำพ้องความหมาย Headless เป็นหนึ่งในตัวอักษรของ MACH MACH เป็นวิธีการสร้างระบบ composable ที่เฉพาะเจาะจงและมีความคิดเห็นชัดเจน Composable เป็นแนวคิดที่กว้างกว่าทั้งหมด
แกนหลักที่เน้น API เป็นอันดับแรก
ไม่ว่าจะมองจากมุมไหนก็จะพบจุดเดียวกัน: API คือชั้นการผสานรวมที่ยึดระบบ Composable ไว้ด้วยกัน หากส่วนประกอบต่างๆ เป็นอิสระและแต่ละส่วนมีข้อมูลของตนเอง สิ่งเดียวที่เชื่อมโยงพวกมันเข้าด้วยกันคือสัญญาข้อตกลงระหว่างกัน
นั่นคือเหตุผลที่ การพัฒนาแบบ API-first เป็นเสาหลักที่เจรจาต่อรองไม่ได้ ในระบบ monolith โมดูลสองตัวสามารถเข้าถึงฐานข้อมูลเดียวกันและเรียกใช้ฟังก์ชันของกันและกันได้โดยตรง ในระบบ Composable ทางลัดนั้นไม่มีอยู่ ความสามารถจะมีประโยชน์ก็ต่อเมื่อ API ที่เปิดเผยออกมามีประสิทธิภาพ และระบบจะมีความเสถียรก็ต่อเมื่อสัญญาข้อตกลงระหว่างส่วนต่างๆ มีความมั่นคง
นี่คือช่วงเวลาที่ API ไม่ใช่ประตูข้างอีกต่อไป แต่กลายเป็นตัวผลิตภัณฑ์เอง เมื่อส่วนหน้าเป็นแบบ headless และความสามารถสามารถสับเปลี่ยนได้ API คือผลิตภัณฑ์ที่ทีมและพาร์ทเนอร์อื่นๆ ของคุณใช้จริง หากออกแบบโดยประมาท ผู้บริโภคปลายทางทุกคนจะรู้สึกได้ถึงผลกระทบ
ประโยชน์และข้อเสีย
สรุปข้อดีของ composable:
- ดีที่สุดในแต่ละด้าน (Best-of-breed) ใช้เครื่องมือที่แข็งแกร่งที่สุดสำหรับแต่ละความสามารถ แทนที่จะต้องยอมรับโมดูลที่อ่อนแอที่สุดของผู้จำหน่ายรายใดรายหนึ่ง
- การเปลี่ยนแปลงที่เป็นอิสระ เปลี่ยนหรืออัปเกรด PBC หนึ่งตัวได้โดยไม่ต้องยุ่งเกี่ยวกับส่วนที่เหลือ
- ลดการถูกผูกมัด (Less lock-in) ส่วนประกอบที่สามารถสับเปลี่ยนได้หมายความว่าคุณไม่ถูกผูกมัดกับแพลตฟอร์มเดียว
- ทีมคู่ขนาน ความสามารถที่แยกออกจากกันช่วยให้ทีมทำงานได้ตามตารางเวลาของตนเอง
- หลายช่องทาง (Multi-channel) ส่วนหน้าแบบ Headless ช่วยให้ชุด API เดียวกันสามารถให้บริการบนพื้นผิวได้หลายแบบ
และค่าใช้จ่ายที่แท้จริง:
- ค่าใช้จ่ายในการผสานรวม (Integration overhead) ส่วนประกอบที่มากขึ้นหมายถึงการเชื่อมต่อที่ต้องวางระบบและเฝ้าระวังมากขึ้น
- วินัยในข้อตกลง (Contract discipline) การเปลี่ยนแปลงที่ทำให้เกิดการเสียหายใน API หนึ่งตัวอาจส่งผลกระทบไปทั่วทุกสิ่งที่เรียกใช้
- ความซับซ้อนในการปฏิบัติงาน (Operational complexity) การเฝ้าระวัง การตรวจสอบสิทธิ์ และการจัดการเวอร์ชันครอบคลุมหลายบริการ ไม่ใช่แค่บริการเดียว
- การออกแบบล่วงหน้า (Upfront design) คุณต้องใช้เวลามากขึ้นกับขอบเขตและข้อตกลงก่อนที่จะเริ่มใช้งานจริง
Composable เหมาะสมอย่างยิ่งเมื่อคุณต้องการความยืดหยุ่น การปรับขนาด และหลายช่องทาง มันอาจมากเกินความจำเป็นหาก monolith ที่สร้างมาดีเพียงพอแล้ว
Apidog เข้ามามีบทบาทตรงไหน: เสาหลัก API-first
Apidog ไม่ได้ทำให้สถาปัตยกรรมของคุณเป็นแบบ Composable ไม่ใช่ CMS, เอนจิ้นอีคอมเมิร์ซ, API gateway หรือแพลตฟอร์ม MACH และจะไม่เข้ามาแทนที่สิ่งเหล่านั้น สิ่งที่ทำคือการรับผิดชอบ "A" ใน MACH ซึ่งเป็นเสาหลัก API-first ซึ่งเป็นชั้นที่ทุกสิ่งทุกอย่างในระบบ Composable ต้องพึ่งพา
เนื่องจาก API เป็นอินเทอร์เฟซเดียวระหว่างส่วนประกอบอิสระของคุณ สัญญาข้อตกลงจึงต้องถูกต้อง Apidog คือที่ที่คุณออกแบบ ทดสอบ สร้าง Mock และจัดทำเอกสารสัญญาข้อตกลงนั้น:
- สัญญาข้อตกลงที่เน้นการออกแบบเป็นอันดับแรก กำหนด API ของแต่ละความสามารถให้เป็นสัญญา OpenAPI ก่อนที่ใครจะเขียนการใช้งาน เพื่อให้ผู้ใช้และผู้ให้บริการตกลงในรูปแบบตั้งแต่เริ่มต้น
- เซิร์ฟเวอร์จำลอง (Mock servers) ทีมที่แยกจากกันไม่ควรรอซึ่งกันและกัน เซิร์ฟเวอร์จำลองช่วยให้ส่วนหน้าหรือพาร์ทเนอร์สามารถสร้างตามสัญญาข้อตกลงได้ในขณะที่ PBC ที่รองรับยังคงถูกสร้างขึ้น
- การเรียกใช้การทดสอบแบบ Headless Apidog CLI รันการทดสอบ API ของคุณโดยไม่มี GUI โดยตรงใน CI นั่นเป็นการสอดคล้องกับแนวคิด "headless" อย่างแท้จริง การทดสอบจะรันบนสัญญาข้อตกลง ไม่ใช่ผ่านหน้าจอ
- จัดการจากเครื่องมือของคุณ ผ่าน MCP คุณสามารถขับเคลื่อนโปรเจกต์ API ของคุณจาก AI agent หรือ IDE
หากระบบของคุณเป็นไปตามโมเดล API-คือ-ผลิตภัณฑ์ นี่คือชั้นคุณภาพที่ช่วยรักษาสัญญาให้ถูกต้อง ดาวน์โหลด Apidog เพื่อออกแบบและจำลองสัญญาข้อตกลงก่อนที่ส่วนหลังจะพร้อมใช้งาน
เมื่อใดควรนำสถาปัตยกรรม Composable มาใช้
พิจารณาใช้ composable เมื่อเงื่อนไขมากกว่าหนึ่งข้อต่อไปนี้เป็นจริง:
- คุณต้องการให้บริการหลายช่องทาง (เว็บ, มือถือ, ในร้านค้า, เสียง) จากตรรกะที่ใช้ร่วมกัน
- ความสามารถที่แตกต่างกันมีการเปลี่ยนแปลงในอัตราที่ต่างกันมาก และคุณเบื่อกับการปรับใช้ทุกอย่างใหม่สำหรับการแก้ไขเล็กๆ น้อยๆ
- คุณต้องการผู้จำหน่ายที่ดีที่สุดในแต่ละด้าน (best-of-breed) สำหรับแต่ละความสามารถ แทนที่จะเป็นชุดซอฟต์แวร์เดียว
- การถูกผู้จำหน่ายผูกมัดเป็นความเสี่ยงทางธุรกิจที่แท้จริงสำหรับคุณ
- คุณมีทีมงานและวินัยในการดูแลสัญญา API และการผสานรวมตลอดเวลา
หากคุณเป็นทีมเล็กๆ ที่กำลังสร้างผลิตภัณฑ์เดียวภายใต้กรอบเวลาที่จำกัด Monolith ที่สร้างมาดีมักจะเป็นทางเลือกที่ฉลาดกว่า Composable จะพิสูจน์ความซับซ้อนของมันได้เมื่อขยายขนาด
คำถามที่พบบ่อย
สถาปัตยกรรม Composable เหมือนกับ Microservices หรือไม่?
ไม่ แต่มีความคาบเกี่ยวกัน Microservices เป็นวิธีทางเทคนิคในการแยกส่วนระบบออกเป็นบริการขนาดเล็กที่ปรับใช้ได้ สถาปัตยกรรม Composable แยกส่วนตามความสามารถทางธุรกิจ (PBCs) และเพิ่มแนวคิดของส่วนประกอบ best-of-breed ที่สามารถสับเปลี่ยนได้ ซึ่งเชื่อมต่อกันด้วย API โดยปกติแล้ว Microservices คือวิธีที่คุณสร้างส่วนหลังของระบบ Composable สำหรับความแตกต่างที่กว้างขึ้น โปรดดูที่ monolith กับ microservices
Composable กับ Headless แตกต่างกันอย่างไร?
Headless หมายถึงส่วนหน้าถูกแยกออกจากส่วนหลัง เพื่อให้ไคลเอ็นต์ใดๆ ก็ตามสามารถใช้ API ชุดเดียวกันได้ Composable เป็นแนวทางที่กว้างกว่า: การประกอบระบบทั้งหมดจากความสามารถอิสระที่เชื่อมต่อกันด้วย API Headless เป็นหลักการหนึ่ง (ตัวอักษร "H" ใน MACH) ที่ระบบ Composable มักจะปฏิบัติตาม คุณสามารถเป็น headless ในความสามารถเดียวโดยไม่จำเป็นต้องเป็น composable อย่างสมบูรณ์ทั่วทั้งสแต็ก
Packaged Business Capability (PBC) คืออะไร?
PBC คือหน่วยที่แยกจากกันโดยสมบูรณ์ ซึ่งมีความสามารถทางธุรกิจที่สมบูรณ์ในตัวเอง รวมถึงข้อมูล ตรรกะ และ API ของตัวเอง Gartner อธิบาย PBCs ว่าเป็นความสามารถที่สามารถปรับใช้ได้อย่างอิสระซึ่งสื่อสารกับแอปพลิเคชันอื่น ๆ ผ่าน API และช่องทางเหตุการณ์ต่างๆ คอมโพเนนต์ "การค้นหา" "การชำระเงิน" หรือ "สินค้าคงคลัง" ซึ่งแต่ละส่วนจะเปิดเผย API ในระดับธุรกิจ ถือเป็น PBC ทั่วไป
ฉันจำเป็นต้องมีแพลตฟอร์ม API เพื่อใช้ Composable หรือไม่?
คุณจำเป็นต้องมีวิธีในการออกแบบ ทดสอบ และรักษาสัญญา API ของคุณให้เสถียร เพราะสัญญาเหล่านั้นเป็นสิ่งเดียวที่เชื่อมโยงส่วนประกอบอิสระเข้าไว้ด้วยกัน ซึ่งอาจเป็นชุดเครื่องมือแยกต่างหาก หรือเป็นแพลตฟอร์มเดียวที่ครอบคลุมการออกแบบ การจำลอง การทดสอบ และเอกสารในที่เดียว ประเด็นสำคัญคือวินัยในสัญญา ไม่ใช่ผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง
สรุป
สถาปัตยกรรม Composable เป็นประเภทหลัก และ headless, MACH และ microservices เป็นชนิดย่อยภายในประเภทนั้น จุดร่วมคือเรียบง่าย: ความสามารถที่เป็นอิสระ, ทางเลือก best-of-breed และ API เป็นตัวเชื่อมโยง ส่วนสุดท้ายนี้คือที่ที่ความเสี่ยงส่วนใหญ่อยู่ เพราะสัญญาคือระบบ ทำให้การออกแบบ API, การจำลอง, การทดสอบ และเอกสารถูกต้องด้วยเครื่องมืออย่าง Apidog และคำมั่นสัญญาอื่นๆ ของ Composable (เปลี่ยนแทนได้, หลายช่องทาง, ปลอดจากการถูกผูกมัด) ก็จะมีรากฐานที่มั่นคงให้ยืนหยัด