Software Architecture แบบไหนเหมาะกับธุรกิจของคุณ

Monolith

โปรแกรมเมอร์ส่วนใหญ่น่าจะรู้จักและเคยผ่านมากันเกือบทุกคน มันคือ Software Architechture รูปแบบหนึ่งที่มีการใช้ resource และ environment เดียวกันทั้งโปรเจค แต่การพัฒนาการสามารถแยกกัน หรือพัฒนาไปพร้อมกันระหว่าง Backend และ Frontend ขึ้นอยู่กับทีมว่าแบบไหนเหมาะ และเร็วกับทีม

ข้อดี

แน่นอนว่าเมื่อ software architechture มันมีการใช้งาน environment เดียวกันมันจึงช่วยให้ทีมที่พัฒนาสามารถใช้งาน library เดียวกันและ เมื่อมีการเปลี่ยนแปลงใดๆ ทีมก็จะได้ code base เดียวกัน ทำให้สามารถพัฒนา produdct หรือ mvp ออกมาได้เร็วตามไปด้วย

ข้อเสีย

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

เหมาะกับใคร

• เหมาะกับทีมเล็กๆ ไม่เกิน 4 คน 
• ต้องการสร้าง product ที่เป็น MVP (Minimal Viable Product)
• ไม่ต้องการเสียเวลากับ Architecture ที่ซับซ้อน 
• ไม่ต้องการเสียเวลากับการ deploy ทีละ componentBackend/Frontendฃ

สำหรับทีมที่แบ่งหน้าที่ความรับผิดชอบกันชัดเจน คือมีทีมที่ดูแล code base แยกกัน ซึ่งการพัฒนาระบบที่แยกกันชัดเจนแบบนี้จะช่วยในเรื่องของอิสระในการพัฒนา ในการใช้งาน library ต่างๆ 

เหมาะกับใคร

• ทีมตั้งแต่ 5 คนขึ้นไป
• product ที่ออกแบบเพื่อให้ scale แยกกันได้
• มี pm/po ที่ทำหน้าที่ในการสื่อสารระหว่างทีม เพื่อให้ทุกคนเห็นภาพเดียวกัน

ข้อดี

• การพัฒนาแยกส่วนชัดเจน
• มีความคล่องตัวในการพัฒนา และการ deploy ที่เป็นอิสระ
• การ scale ของแต่ละส่วนทำได้ง่ายและเป็นอิสระ
• ภาษาโปรแกรมที่ใช้พัฒนาขึ้นกับความถนัดของแต่ละทีม 

ข้อเสีย

• ต้องมีการสื่อสารระหว่างทีมที่ดี
• ทรัพยากรที่ต้องใช้มากขึ้นทั้งคน และงบประมาณ
• บางทีการจะ deploy แต่ละ feature อาจจะต้องรอให้อีกฝ่ายทำให้เสร็จก่อนค่อย deploy ตามได้ Microservice

คือการแยก service ต่างๆ ออกมาตาม business logic หรือวัตถุประสงค์ของงานนั้นๆ ทำให้ service ต่างๆ สามารถทำงานได้ด้วยตัวเองโดยไม่ยึดติดกับ service อื่นๆ มากนัก ซึ่งการสื่อสารจะทำผ่าน API Gateway เป็นหลัก และเมื่อมี service ใดๆ ทำงานผิดพลาดก็จะไม่กระทบไปยัง service อื่นๆ ทำให้ระบบมีความน่าเชื่อถือขึ้นด้วยนั่นเอง

เหมาะกับใคร

• ทีมขนาดใหญ่ 
• product ที่ต้องการความน่าเชื่อถือของระบบสูง

ข้อดี

• developer สามารถพัฒนาด้วยภาษาที่ตัวเองถนัด หรือเหมาะสมกับ service นั้นๆ 
• การ deploy เป็นอิสระ
• การ scale เป็นอิสระ
• เมื่อ service ใดๆ มีปัญหาก็จะไม่กระทบกับระบบโดยรวม

ข้อเสีย

• ต้องมี format ของข้อมูลเพื่อให้สอดคล้องกันมากที่สุด
• ใช้ทรัพยาการค่อนข้างมาก ทั้งเรื่องของการ monitor, deploy และการทำ infra automation
• เมื่อ service มีจำนวนมาก การ deploy หรือการทำ manual จะยากมากเช่นกัน