Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

สรุปเรื่องของ Modular Monolith จากระบบของ Shopify

$
0
0

จาก VDO เรื่อง Deconstructing the Monolith (Shopify Unite Track 2019)
ทำการอธิบายถึง architecture ระบบของ Shopify
ว่ามีความเป็นมาอย่างไร
ตั้งแต่แบบ Monolith เมื่อระบบมีขนาดใหญ่และซับซ้อน 
จึงเกิดปัญหาและส่งผลกระทบต่อระบบ บริษัท
รวมไปถึง productivity ในการพัฒนาระบบงาน
ดังนั้นทาง Shopify จึงต้องทำการแก้ไขและปรับปรุงนั่นเอง

จาก VDO สรุปได้ว่า

ระบบแบบ Monolith นั้น มันไม่ใช่ architecture ที่แย่ไปเสียหมด
ยังมีข้อดีต่าง ๆ มากเช่นกัน
ทั้ง code อยู่ที่เดียวกัน
ทั้งการทดสอบง่าย 
ทั้งการ deploy ระบบ เพราะว่ามีที่เดียว
แน่นอนว่า ช่วยทำให้พัฒนาและส่งมอบ feature ได้อย่างรวดเร็ว

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

มันคือเรื่องของ Design Payoff Line นั่นเอง

โดยทาง Shopify นั้นก็ได้ทำการปรับปรุงเช่นกัน
ไม่ใช่การเปลี่ยนไปยังรูปแบบของ Microservices
แต่เป็นการปรับไปใช้แนวคิดของ Modular Monolith แทน

มันคืออะไรสำหรับ Modular Monolith ?

จาก VDO อธิบายไว้ว่า
มันคือการนำข้อดีของ Monolith และ Microservices มาใช้ร่วมกัน
ทั้ง code อยู่ที่เดียวกัน
ทั้งการทดสอบและ deploy ที่ง่าย
ส่วน Microservices ก็เช่นเรื่องของ modular
และความเป็นอิสระของแต่ละ services

แสดงดังรูป


https://engineering.shopify.com/blogs/engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity

เป้าหมายหลัก ๆ ของการปรับปรุงก็ไม่มีอะไรซับซ้อน

นั่นคือ ต้องการให้แต่ละส่วนการทำงานแยกกันชัดเจนและอิสระ
แต่ไม่เพิ่ม effort ของการ deploy หรือส่งมอบระบบงาน
รวม ๆ คือ เพิ่ม productivity ของการพัฒนาระบบนั่นเอง

การปรับเปลี่ยนครั้งนี้มีส่วนที่สำคัญคือ

  • โครงสร้างของ code
  • การแยก dependency ให้ชัดเจน
  • กำหนดกรอบการทำงานของแต่ละ module และไม่ให้ทำการเรียกใช้ข้ามกรอบหรือขอบเขตที่กำหนด

การปรับเปลี่ยน architecture ครั้งนี้

สิ่งที่ได้รับกลับมาคือ 
สามารถตอบรับกับความต้องการจากทาง business ได้เป็นอย่างดี
นั่นคือ เป้นการปรับปรุงที่เหมาะกับงานหรือ context นั้น ๆ
ดีที่อื่น อาจจะไม่ดีที่นี่ก็ได้
หรือในทางกลับกัน คือ ดีที่นี่ อาจจะไม่ดีกับที่อื่น
เพราะว่าต่าง context หรืองานนั่นเอง

สุดท้ายแล้ว ถ้าการปรับปรุง

กลับทำให้การดูแลรักษายากขึ้น
กลับทำให้การพัฒนายากขึ้น
กลับทำให้การทดสอบยากขึ้น
กลับทำให้การ dpeloy ยากขึ้น
กลับทำให้ productivity แย่ลง
คิดว่า น่าจะไม่ใช่การปรับปรุงนะ ว่าไหม ?

Reference Websites


Viewing all articles
Browse latest Browse all 1997

Trending Articles