The Monolith

ลักษณะของ software architecture ที่รวมทุก modules ไว้ใน project หรือ package เดียว เพื่อความง่ายในการเรียกใช้ function หรือ service ใน project โดยไม่ต้องแยก deploy ที่ต้องเรียกใช้งานผ่าน interface อย่างเช่น API อีกทั้งการส่งมอบงาน และ deploy ก็ง่ายเพราะ deploy ทั้ง package และการ reuse ในส่วนของ code ก็ทำได้สะดวกสบาย ถือเป็นหลักนิยมของการพัฒนา software ในยุคที่ผ่านมา จนกระทั้ง software ได้ถูกนำมาใช้เป็นบริการหลักของธุรกิจ ความต้องการใหม่ๆ ที่เพิ่มและแก้ไขตลอดเวลา รวมถึงการรองรับจำนวนผู้ใช้จำนวนมาก ทำให้รูปแบบการพัฒนาแบบเดิมเริ่มจะส่งผลในทางลบมากกว่า กล่าวคือ การเพิ่มทีมพัฒนาเข้าไปจะทำได้ยาก เพราะการวาง code ภาษาที่ใช้ จะรู้จักดีในเฉพาะทีมเท่านั้น แต่ละ module ที่มีการเรียกใช้งานเริ่มมีความซับซ้อน และต้อง share หรือรับงานที่มากขึ้น (overloaded) ความต้องการเพิ่มจำนวน process (scalability) ที่ต้องขยาย resource ทั้ง server การที่ทำให้ระบบทำงานได้อย่างต่อเนื่อง (availability) ด้วยประสิทธิภาพของการให้บริการที่ดีตลอดเวลา (reliability) รวมถึงการให้บริการได้แม้ในขณะที่ระบบเกิดปัญหา (Resiliency) การส่งมอบ software อย่างต่อเนื่อง (Continuous Delivery) โดยไม่ทำให้การบริการหยุดชะงัก ทำให้เกิดอัตราเร่งให้ต้องเปลี่ยนแปลงไปสู่ microservice architect

Forces

  • Developer หลายคนทำงานใน project เดียว
  • Developer ใหม่ของทีมสามารถเริ่มต้นทำงานได้อย่างรวดเร็ว
  • Application จะต้องง่ายในการทำความเข้าใจ และแก้ไข
  • ต้องการ apply continuous deployment practices
  • ความต้องการเรื่อง Scale up – Scalability, Availability และ Resiliency
  • ต้องการใช้ประโยชน์จาก technology ใหม่ใน project เช่น framework และ programming language

Solutions

  • สร้างหลายๆ module แล้ว pack ไว้ใน package เดียว เช่น WAR หรือ EAR
    • Deploy ทุกอย่างอยู่ในรูปแบบของ directory เดียว
    • อาจจะแยกหน้าที่ออกเป็นหลายๆ Tier (N-Tier Architechy)
    • ออกแบบเป็นลักษณะลำดับชั้น (Layered Architecture)

Resulting Context

  • การพัฒนา application มีรูปแบบที่ซับซ้อน (Complexity)
  • Web Server ทำงานหนัก ด้วยการทำงานทุกอย่างใน Server เดียว
  • การ deploy ส่ิงใหม่ๆ (continuous deliver) จะทำยากเพราะเกี่ยวพันกับหลาย module
  • การ scale out ใช้เวลามากเพราะต้องการ resource และ scale ทั้ง server
  • การแก้ไข เพื่อให้ใช้งานได้ไปก่อน (Technical debt) ไม่ได้เป็นแนวทางระยะยาว
  • ทำงานได้ใน scope อย่างไดอย่างหนึ่ง มีความยากในการต่อยอด

Leave a Reply

Your email address will not be published. Required fields are marked *