สถาปัตยกรรม MACH ไม่ได้เกี่ยวข้องกับ Mach number (หน่วยวัดความเร็ว) หรือ Mach kernel ที่อยู่ภายใต้ GNU Hurd; แต่เป็นคำย่อสำหรับการสร้างซอฟต์แวร์ระดับองค์กรจากส่วนประกอบที่สามารถถอดเปลี่ยนได้ MACH ย่อมาจาก Microservices, API-first, Cloud-native และ Headless และได้รับการส่งเสริมโดย MACH Alliance ซึ่งเป็นองค์กรอุตสาหกรรมไม่แสวงหาผลกำไรที่ก่อตั้งขึ้นในปี 2020 คู่มือนี้จะอธิบายแต่ละเสาหลักด้วยภาษาที่เข้าใจง่าย เปรียบเทียบ MACH กับแนวทางแบบ monolith และ SOA ที่เข้ามาแทนที่ และแสดงให้เห็นว่ามันเหมาะสมกับที่ใด รวมถึงการพิจารณาถึง แพลตฟอร์ม API ที่คุณจะใช้สำหรับระบบไมโครเซอร์วิส
MACH หมายถึงอะไรกันแน่
MACH คือชุดของหลักการออกแบบ ไม่ใช่ผลิตภัณฑ์ที่คุณสามารถซื้อได้ ตัวอักษรแต่ละตัวจะตั้งชื่อหลักการหนึ่ง และระบบจะนับว่าเป็น MACH ก็ต่อเมื่อเป็นไปตามหลักการทั้งสี่ MACH Alliance มีความเข้มงวดในเรื่องนี้: การแสดงคุณสมบัติเพียงหนึ่งหรือสองอย่างไม่ถือว่ามีคุณสมบัติครบถ้วน
นี่คือคำย่อโดยสรุป
| ตัวอักษร | หลักการ | ความหมาย |
|---|---|---|
| M | Microservices | ความสามารถทางธุรกิจแต่ละอย่างเป็นบริการที่สามารถปรับใช้ได้อย่างอิสระ |
| A | API-first | ทุกฟังก์ชันจะถูกเปิดเผยผ่าน API ซึ่งได้รับการออกแบบก่อนการเขียนโค้ด |
| C | Cloud-native | สร้างขึ้นเพื่อทำงานเป็น SaaS บนโครงสร้างพื้นฐานคลาวด์ มีความยืดหยุ่นและได้รับการจัดการ |
| H | Headless | ส่วนหน้า (front end) ถูกแยกออกจากส่วนหลัง (back end) และสื่อสารกันผ่าน API |
แนวคิดคือความสามารถในการประกอบ (composability) แทนที่จะเป็นผลิตภัณฑ์ขนาดใหญ่เพียงชิ้นเดียวที่ทำทุกอย่าง คุณจะรวบรวมบริการที่ดีที่สุดที่แต่ละอย่างทำสิ่งเดียว และคุณสามารถสลับเปลี่ยนส่วนใดก็ได้โดยไม่ต้องสร้างส่วนที่เหลือใหม่ นี่คือเป้าหมายเดียวกันเบื้องหลังการเคลื่อนไหว "composable enterprise" ที่กว้างขึ้น MACH คือสูตรทางเทคนิคที่ทำให้ความเป็น composability เป็นไปได้
ไมโครเซอร์วิส (Microservices)
Monolith จะรวมทุกฟีเจอร์ไว้ใน codebase และการปรับใช้เดียว ไมโครเซอร์วิสจะแยกส่วนเหล่านั้นออกจากกัน ตรรกะของแค็ตตาล็อก, รถเข็น, การค้นหา และการชำระเงินของคุณจะกลายเป็นบริการแยกต่างหากที่มีข้อมูลและวงจรการออกผลิตภัณฑ์ของตัวเอง ทีมหนึ่งสามารถจัดส่งบริการค้นหาในวันอังคารโดยไม่ต้องแตะบริการรถเข็นเลย
ข้อเสียคือความซับซ้อนในการดำเนินงาน ตอนนี้คุณมีบริการ, ฐานข้อมูล และการเรียกเครือข่ายจำนวนมากระหว่างกัน หากคุณต้องการรายละเอียดเพิ่มเติม โปรดดู แอปพลิเคชัน Monolith เทียบกับไมโครเซอร์วิส
API-first
API-first หมายถึง API เป็นจุดเริ่มต้น ไม่ใช่สิ่งที่คิดขึ้นภายหลัง คุณออกแบบสัญญา, endpoint, รูปแบบคำขอและการตอบกลับ ก่อนที่ใครจะเริ่มเขียนโค้ด ทุกความสามารถในระบบ MACH จะเข้าถึงโลกภายนอกผ่าน API นั้น ดังนั้น สัญญาจึงกลายเป็นพื้นผิวผลิตภัณฑ์ที่แท้จริง
นี่คือเสาหลักที่มีผลกระทบมากที่สุดต่อการทำงานในแต่ละวันของทีม และเป็นส่วนที่เครื่องมือมีความสำคัญที่สุด เราจะกลับมาพูดถึงเรื่องนี้ในภายหลัง สำหรับหลักการต่างๆ การพัฒนาแบบ API-first ครอบคลุมถึงพื้นฐาน
คลาวด์เนทีฟ (Cloud-native)
Cloud-native ในความหมายของ MACH นั้นมุ่งเน้นไปที่ SaaS เป็นอย่างมาก ส่วนประกอบต่างๆ ถูกสร้างขึ้นเพื่อทำงานบนโครงสร้างพื้นฐานคลาวด์ และมักถูกใช้งานเป็นบริการที่มีการจัดการ คุณไม่ต้องแพตช์เซิร์ฟเวอร์หรือวางแผนกำลังการผลิตสำหรับการจราจรที่หนาแน่น บริการจะปรับขนาดได้โดยอัตโนมัติ และผู้ขายจะจัดการการอัปเดต ซึ่งแตกต่างจาก "เราย้ายแอปเก่าของเราขึ้นไปบน VM ในคลาวด์" Cloud-native หมายถึงซอฟต์แวร์ได้รับการออกแบบมาสำหรับสภาพแวดล้อมนั้นตั้งแต่ต้น
Headless
Headless แยกเลเยอร์การนำเสนอออกจากตรรกะทางธุรกิจ แบ็คเอนด์ไม่มีส่วนหน้าในตัว; เพียงแค่ให้บริการข้อมูลและการดำเนินการผ่าน API เว็บไซต์, แอปมือถือ, สมาร์ทวอทช์, คีออสก์ หรือผู้ช่วยเสียงของคุณจะใช้ API เดียวกันและแสดงประสบการณ์ของตัวเอง
ผลตอบแทนคือการเข้าถึง แบ็คเอนด์เดียวสามารถป้อนข้อมูลให้ส่วนหน้าหลายส่วน และคุณสามารถออกแบบส่วนหน้าใหม่ได้โดยไม่ต้องย้ายกลไกการค้าที่อยู่ภายใต้ API แบบ Headless กลายเป็นผลิตภัณฑ์ เพราะเป็นช่องทางเดียวในการเข้าถึง
MACH เทียบกับ Monolith เทียบกับ SOA
สิ่งนี้จะช่วยให้เห็นว่า MACH อยู่ตรงไหนเมื่อเทียบกับรูปแบบที่มาก่อนหน้า
| Monolith | SOA | MACH | |
|---|---|---|---|
| หน่วยการปรับใช้ | แอปพลิเคชันเดียว | บริการหยาบๆ บนบัส | ไมโครเซอร์วิสแบบละเอียด |
| การรวมระบบ | การเรียกใช้ในกระบวนการ | Enterprise service bus มักใช้ SOAP | API แบบ REST/GraphQL ที่มีน้ำหนักเบา |
| ส่วนหน้า (Front end) | เชื่อมโยงกัน, เรนเดอร์บนเซิร์ฟเวอร์ | มักจะเชื่อมโยงกัน | Headless, แยกออกจากกันอย่างสมบูรณ์ |
| การโฮสต์ | เซิร์ฟเวอร์ที่คุณจัดการ | On-premise หรือ โฮสต์ | Cloud-native SaaS |
| เปลี่ยนส่วนประกอบ | สร้างใหม่และปรับใช้ใหม่ | ยาก, เชื่อมโยงกับบัส | เปลี่ยนบริการเดียว |
Monolith นั้นเริ่มต้นได้เร็วและเข้าใจง่าย ซึ่งเป็นเหตุผลที่ยังคงเป็นทางเลือกที่เหมาะสมสำหรับทีมขนาดเล็กจำนวนมาก SOA พยายามที่จะแยกส่วนระบบเมื่อสิบปีก่อน แต่บ่อยครั้งรวมศูนย์ทุกอย่างไว้บน enterprise service bus ที่มีน้ำหนักมาก ซึ่งกลายเป็นคอขวดของตัวเอง MACH ยังคงแนวคิดการแยกส่วนและละทิ้งบัส โดยเชื่อมต่อบริการด้วย API แบบธรรมดาและผลักภาระการโฮสต์ไปยังคลาวด์
MACH โดยพื้นฐานแล้วคือคำตอบยุคใหม่ในยุคคลาวด์สำหรับคำถามที่ SOA เคยถาม หากคุณต้องการแผนผังรูปแบบที่กว้างขึ้น รูปแบบสถาปัตยกรรม API จะแสดงไว้
เมื่อใดควรนำ MACH มาใช้ (และเมื่อใดไม่ควร)
MACH แก้ปัญหาจริงได้ แต่ก็มีค่าใช้จ่าย พิจารณาใช้เมื่อข้อจำกัดต่างๆ สอดคล้องกัน
เหมาะสมดีเมื่อ:
- คุณกำลังประสบปัญหาคอขวดกับแพลตฟอร์มแบบ monolith และวงจรการออกผลิตภัณฑ์ช้าเนื่องจากทุกอย่างถูกจัดส่งพร้อมกัน
- หลายทีมต้องทำงานพร้อมกันโดยไม่ทับซ้อนกัน
- คุณให้บริการเนื้อหาหรืออีคอมเมิร์ซไปยังหลายช่องทาง (เว็บ, มือถือ, ในร้านค้า) และต้องการแบ็คเอนด์เดียวรองรับทั้งหมด
- คุณต้องการเปลี่ยนผู้ขายสำหรับความสามารถเดียวโดยไม่ต้องเปลี่ยนแพลตฟอร์มทั้งหมด
คิดให้ดีเมื่อ:
- คุณเป็นทีมเล็กๆ ที่มีผลิตภัณฑ์ที่เรียบง่าย ค่าใช้จ่ายในการดำเนินงานของบริการ ท่อส่งข้อมูล และสัญญาจำนวนมากจะทำให้คุณช้าลงมากกว่า monolith
- คุณยังไม่มีทักษะด้านแพลตฟอร์ม MACH ถือว่าคุณมีความคุ้นเคยกับโครงสร้างพื้นฐานคลาวด์, CI/CD และการออกแบบ API
- ปริมาณการใช้งานและทีมของคุณมีเสถียรภาพและไม่มากนัก ความยืดหยุ่นที่คุณลงทุนไปอาจไม่ถูกใช้งานเลย
เส้นทางที่ซื่อสัตย์ที่พบบ่อยคือการเริ่มต้นด้วย monolith ที่มีโครงสร้างดี จากนั้นค่อยๆ แยกบริการออกไปเมื่อมีปัญหาเฉพาะจุดเกิดขึ้น คุณไม่จำเป็นต้องใช้ MACH เต็มรูปแบบตั้งแต่วันแรก
ระบบนิเวศของเครื่องมือ
MACH เป็นอิสระจากผู้ขายโดยการออกแบบ แต่ระบบทั่วไปจะดึงมาจากหลายหมวดหมู่:
- Headless CMS สำหรับเนื้อหา เช่น Contentstack หรือ Contentful
- Headless หรือ composable commerce engines เช่น commercetools
- การค้นหาและการปรับแต่งเฉพาะบุคคล เป็นบริการ API แยกต่างหาก
- CDN และ edge สำหรับการจัดส่งแบบคลาวด์เนทีฟ ซึ่งมักจะจับคู่กับส่วนหน้าสไตล์ Jamstack เอกสาร Jamstack ของ Netlify เป็นข้อมูลอ้างอิงที่เป็นประโยชน์สำหรับส่วนหน้าแบบ decoupled
- API gateways และ identity สำหรับการกำหนดเส้นทาง, รักษาความปลอดภัย และตรวจสอบสิทธิ์การรับส่งข้อมูลระหว่างบริการ
สิ่งที่เชื่อมโยงทั้งหมดเข้าด้วยกันคือ API ทุกกล่องในรายการนั้นสื่อสารกับกล่องอื่นๆ ผ่านสัญญา ดังนั้นคุณภาพของสัญญาเหล่านั้นจะเป็นตัวตัดสินว่าระบบทั้งหมดจะคงอยู่ได้หรือไม่
ที่ซึ่งสัญญา API กลายเป็นผลิตภัณฑ์
นี่คือตัว "A" ใน MACH และเป็นส่วนที่คุณควบคุมได้โดยตรงที่สุด ในระบบไมโครเซอร์วิสแบบ headless ไม่มีใครเข้าถึงบริการของคุณผ่าน UI ที่คุณสร้างขึ้น พวกเขาเข้าถึง API ดังนั้น สัญญาคือผลิตภัณฑ์ และต้องได้รับการดูแลเช่นเดียวกับผลิตภัณฑ์ใดๆ: การออกแบบ, mock, การทดสอบ และเอกสารประกอบ
Apidog คือเลเยอร์คุณภาพ API สำหรับงานนั้น ไม่ใช่ CMS, commerce engine หรือ gateway และไม่ได้ "ทำ" MACH หรือ headless ให้คุณ เป็นที่ที่คุณจัดการสัญญาเอง:
- Design-first OpenAPI. คุณกำหนดสัญญาของแต่ละไมโครเซอร์วิสใน Apidog ก่อนการนำไปใช้งาน เพื่อให้ทีมผู้ใช้งานเห็นด้วยกับรูปแบบล่วงหน้า
- เซิร์ฟเวอร์จำลอง (Mock servers). Apidog สร้าง mock จากสเปก ทำให้ทีมส่วนหน้าสามารถสร้างโดยใช้ Cart API ได้ก่อนที่บริการ Cart จะมีอยู่จริง ทีมที่ทำงานแยกกันจึงไม่ขัดขวางกัน
- การดำเนินการทดสอบแบบ Headless. Apidog CLI รันการทดสอบ API ของคุณโดยไม่มี GUI โดยตรงใน CI ซึ่งสอดคล้องกับระบบแบบ headless: สัญญาได้รับการตรวจสอบโดยเครื่องจักร ไม่ใช่การคลิกด้วยมือ
- MCP สำหรับเอเจนต์. ผ่าน MCP คุณสามารถจัดการและสอบถาม API จาก AI agent หรือ IDE ของคุณได้ เพื่อให้สัญญายังคงเข้าถึงได้จากเครื่องมือที่ทีมของคุณใช้งานอยู่แล้ว
สิ่งนี้ทำให้ Apidog ซื่อสัตย์ต่อบทบาทของมัน มันเป็นเจ้าของเสาหลัก API-first เพื่อให้บริการของคุณได้รับการอธิบาย ทดสอบ และสร้าง mock ได้อย่างดีทั่วทั้งระบบ แนวคิดเดียวกันนี้ปรากฏใน API ในฐานะผลิตภัณฑ์ ซึ่งเป็นแนวคิดที่ MACH บังคับให้คุณต้องมี อยากลองไหม? ดาวน์โหลด Apidog และชี้ไปที่สเปกของบริการหนึ่ง
คำถามที่พบบ่อย
MACH เหมือนกับสถาปัตยกรรมแบบ Composable หรือไม่?
มีความเกี่ยวข้องอย่างใกล้ชิดแต่ไม่เหมือนกัน สถาปัตยกรรม Composable เป็นแนวคิดทางธุรกิจที่กว้างกว่า: สร้างระบบของคุณจากส่วนประกอบที่สามารถเปลี่ยนและประกอบใหม่ได้ MACH คือรูปแบบทางเทคนิคที่เฉพาะเจาะจง (ไมโครเซอร์วิส, API-first, คลาวด์เนทีฟ, headless) ที่ทำให้ความเป็น composable สามารถทำได้ คุณสามารถคิดว่า MACH เป็นพิมพ์เขียวทางวิศวกรรมสำหรับองค์กรแบบ composable
จำเป็นต้องเป็นสมาชิก MACH Alliance เพื่อใช้ MACH หรือไม่?
ไม่ MACH Alliance เป็นองค์กรไม่แสวงหาผลกำไรที่รับรองผู้ขายตามหลักการทั้งสี่ ซึ่งช่วยให้ผู้ซื้อสามารถระบุผลิตภัณฑ์ที่เป็น composable ได้อย่างแท้จริง คุณสามารถสร้างระบบ MACH ทั้งหมดจากเครื่องมือที่ไม่ใช่สมาชิก หรือแม้แต่บริการของคุณเอง หลักการเหล่านี้เป็นแบบเปิดกว้าง การเป็นสมาชิกเป็นการรับรองผู้ขาย ไม่ใช่ใบอนุญาตในการใช้รูปแบบนี้
MACH แตกต่างจากการตั้งค่าไมโครเซอร์วิสทั่วไปอย่างไร?
ไมโครเซอร์วิสเป็นหนึ่งในสี่เสาหลักของ MACH ไม่ใช่ทั้งหมด แบ็คเอนด์ไมโครเซอร์วิสที่มีส่วนหน้าที่เชื่อมโยงกันอย่างแน่นหนาและโฮสติ้งแบบ on-premise ไม่ใช่ MACH MACH เพิ่มระเบียบวินัย API-first, โมเดล SaaS แบบคลาวด์เนทีฟ และการแยกส่วนแบบ headless เข้าไป หากคุณกำลังเลือกโครงสร้างพื้นฐานสำหรับบริการ วิธีเลือกแพลตฟอร์ม API สำหรับไมโครเซอร์วิส จะแนะนำสิ่งที่คุณควรพิจารณา
MACH สำหรับอีคอมเมิร์ซเท่านั้นหรือ?
เริ่มต้นในภาคธุรกิจอีคอมเมิร์ซ ซึ่งการเปลี่ยนผู้ให้บริการชำระเงินหรือการค้นหาโดยไม่ต้องเปลี่ยนแพลตฟอร์มทั้งหมดมีคุณค่าที่ชัดเจน แต่รูปแบบนี้สามารถนำไปใช้ได้ทุกที่ที่คุณให้บริการหลายช่องทางจากตรรกะแบ็คเอนด์ที่ใช้ร่วมกัน สื่อ, ธนาคาร, การเดินทาง และผลิตภัณฑ์ SaaS ล้วนใช้การแยกส่วนแบบ MACH
สรุป
MACH คือวิธีสร้างซอฟต์แวร์จากส่วนประกอบที่คุณสามารถเปลี่ยนได้: ไมโครเซอร์วิสสำหรับการปรับใช้ที่เป็นอิสระ, API-first เพื่อให้ทุกความสามารถมีสัญญาที่ชัดเจน, คลาวด์เนทีฟเพื่อให้ปรับขนาดเป็น SaaS ได้, และ headless เพื่อให้แบ็คเอนด์เดียวป้อนข้อมูลให้ส่วนหน้าหลายส่วน มีประสิทธิภาพเมื่อคุณมีขนาดและทีมที่จะใช้งาน และจะเกินความจำเป็นเมื่อคุณไม่มี
ไม่ว่าคุณจะเลือกทางใด สัญญา API คือส่วนสำคัญที่รองรับระบบทั้งหมด เมื่อสัญญาเป็นผลิตภัณฑ์ จงออกแบบให้ดี, สร้าง mock ตั้งแต่เนิ่นๆ และทดสอบใน CI Apidog มอบเลเยอร์คุณภาพ API นั้นเพื่อให้ระบบ MACH ของคุณได้รับการอธิบายอย่างดีตั้งแต่บริการแรกจนถึงบริการสุดท้าย