จากการแบ่งปันเรื่องการออกแบบระบบงานด้วยแนวคิด Microservices นั้น
มีคำถามที่น่าสนใจเกี่ยวกับ software architecture ที่เปลี่ยนไปว่า
ทำไมมันถึงมีพวกเครื่องมอื หรือ วิธีการแปลก ๆ เข้ามาเรื่อย ๆ
ทั้ง Microservices, Function as a Service
ทั้ง Apache Kafka
ทั้ง Docker และ Kubernetes
ทั้ง Caching ในส่วนต่าง ๆ
ซึ่งเยอะไปหมด เราต้องใช้มันด้วยหรือ ?
คำตอบคือ เราต้องการสิ่งเหล่านี้จากข้างต้นทั้งหมดจริง ๆ หรือไม่ ?
หรือเราใช้เพราะว่า มัน cool
หรือเราใช้เพราะว่า เขาบอกว่าต้องใช้ (เขาคือใคร
กลับมาที่ความต้องการของระบบ มันต้องการใช้จริง ๆ หรือไม่ ?
แต่คำตอบที่ได้รับกลับมาคือ ความเงียบ !!
ดังนั้นต้องตั้งสติก่อน start เพราะว่า ทุกสิ่งทุกอย่าง
มันถูกคิด ถูกสร้าง ขึ้นมา เพื่อแก้ไขปัญหาหนึ่ง ๆ
ดังนั้น เราต้องทำความเข้าใจมันก่อน (Know problems first, context is the king)
จากนั้นมาดูว่า ปัญหาของเรา และ เครื่องมือมันตรงกันไหม
ถ้าไม่แล้ว แทนที่จะเข้ามาแก้ไขปัญหา กลับมาสร้างปัญหาใหม่ก็ได้ !!
เหตุผลอยู่เหนืออารมณ์เสมอ
ขั้นตอนของการเลือกมีขั้นตอนดังนี้
- Simplicity เริ่มจากความเรียบง่าย แต่มันก็ไม่ง่าย มีเป้าหมาย เพื่อส่งมอบงานให้เร็วที่สุด แต่ยังคงคุณภาพที่สูงนะ
- Maintainability ต่อจากนั้นถ้าระบบงานเริ่มใหญ่ขึ้น ความซับซ้อนที่สูงขึ้น ทีมใหญ่ขึ้น การจัดการก็ต่างออกไป แก้ไขที่หนึ่งแล้วไปกระทบอีกหลาย ๆ ที่หรือไม่ ทั้งเรื่องของ feature, code และ ทีม เพื่อเตรียมตัวสำหรับการโตไปอีกขั้นของระบบ เช่น modular monolith เป็นต้น
- Decoupled to small services หรือ Microservices เมื่อผ่านทั้ง simplicity และ maintainability มาแล้ว ก็เริ่มแบ่งเป็น service ออกมาจากกันทั้งในรูปแบบของ physical server หรือ container ก็ว่าไป รวมทั้งการ deploy และ scale ที่ต้องแยกออกจากกัน ทำให้เกิดความเป็นอิสระต่อกัน ... และแน่นอนว่า ก็มีปัญหาอื่น ๆ ตามมาที่ต้องคิดและวางแผน เพื่อรองรับมัน ทั้งการทำงานร่วมกัน ทั้งการติดต่อสื่อสารระหว่างกัน ทั้งเรื่องของ performance ที่อาจจะ drop ลงไหม !! รวมทั้งเรื่อง error handling ต่าง ๆ (Plan for failure !!) ที่มีโอกาสเกิดขึ้นเยอะกว่าเดิม เพราะว่ายิ่งแยก ยิ่งเกิดความซับซ้อน
ดังนั้น context หรือความต้องการของแต่ละระบบจึงสำคัญมาก ๆ
จากนั้นเรื่องของ architecture จะค่อย ๆ เปลี่ยนไป ปรับไปตามความเหมาะสม