จัดการ Terraform ตามเหตุผลที่เปลี่ยน: แนวคิด Domain-Driven Infrastructure
เจาะลึกปัญหาโครงสร้าง Terraform แบบเดิมที่แยกตามเทคโนโลยี และทางออกด้วยแนวคิด Domain-Driven Infrastructure
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- โครงสร้างโฟลเดอร์ Terraform แบบเดิมแยกตามเทคโนโลยีทำให้ไฟล์กระจัดกระจายเมื่อเกิดการเปลี่ยนแปลงทางธุรกิจ
- Domain-Driven Infrastructure นำหลักการจัดระเบียบตามเหตุผลที่เปลี่ยนมาใช้กับโครงสร้างโครงสร้างพื้นฐานคลาวด์
- ขอบเขตที่แท้จริงใน Terraform คือ State หรือหน่วยของคำสั่ง terraform apply ไม่ใช่แค่การย้ายโฟลเดอร์ไฟล์
- เครื่องมืออย่าง Terragrunt หรือ Terramate ช่วยจัดการวิธีทำ แต่แนวคิดนี้ช่วยตัดสินใจเรื่องจุดแบ่งขอบเขต
เช้าวันหนึ่ง วิศวกรคนใหม่ในทีมได้ตั้งคำถามง่ายๆ ว่า ฟังก์ชัน Lambda สำหรับระบบแจ้งเตือนใหม่ควรจะถูกจัดเก็บไว้ในไดเรกทอรี modules/ หรือที่อื่นกันแน่ เนื่องจากโครงสร้างเดิมมีโฟลเดอร์ modules/lambda/ อยู่แล้ว คำตอบที่ดูชัดเจนที่สุดจึงเป็นการนำไปวางไว้ที่นั่น ก่อนที่ความลังเลจะหยุดไว้ เพราะฟังก์ชันนี้เป็นส่วนหนึ่งของระบบคำสั่งซื้อ (Order Workflow) คำถามเดียวจึงซ่อนความสับสนระหว่างการเป็นโค้ดที่นำกลับมาใช้ใหม่ได้หรือเป็นส่วนหนึ่งของโดเมนคำสั่งซื้อ และโครงสร้างไดเรกทอรีเดิมไม่สามารถแยกแยะสิ่งเหล่านี้ได้
บทสนทนาดังกล่าวจบลงด้วยวิธีที่คุ้นเคยในหลายทีม นั่นคือการโยนมันลงไปใน modules/lambda/ ไปก่อนเพื่อความสะดวกในการทำงาน
เชื่อว่าหลายคนน่าจะคุ้นเคยกับโครงสร้างคลังโค้ด Terraform แบบดั้งเดิมที่มีลักษณะแบบนี้:
- โฟลเดอร์ modules/ ประกอบด้วย vpc/, ecs/, rds/, iam/, lambda/
- โฟลเดอร์ environments/ ประกอบด้วย dev/, prod/
โครงสร้างแบบนี้ทำงานได้ดี สามารถรันคำสั่ง plan และ apply ได้อย่างเป็นระเบียบ จนกระทั่งทางฝ่ายธุรกิจเริ่มมีความต้องการใหม่ๆ เข้ามา ไม่ว่าจะเป็นการส่งฟีเจอร์ใหม่ การเพิ่มสเกลเพราะทราฟฟิกพุ่งสูงเป็นสองเท่า หรือการปรับเปลี่ยนนโยบายความสอดคล้อง (Compliance) ที่ส่งผลกระทบต่อสิทธิ์การใช้งาน ทุกๆ คำขอเหล่านี้คือการเปลี่ยนแปลงทางธุรกิจหนึ่งครั้ง แต่มันกลับบังคับให้ทีมงานต้องเข้าไปแก้ไขไฟล์กระจัดกระจายในไดเรกทอรี vpc/, ecs/, rds/, iam/, secrets/ และ cloudwatch/
ในช่วงที่ผู้เขียนเคยทำงานด้วยวิธีแบบเดิม ช่วงเวลาตรวจสอบโค้ดมักจะไม่เป็นไปตามที่คาดคิด การตรวจสอบว่าโค้ดถูกต้องหรือไม่นั้นไม่ใช่เรื่องยาก แต่คำถามที่ตอบได้ยากที่สุดคือมันปลอดภัยพอที่จะนำไปใช้งานจริงหรือไม่ และไม่มีใครสามารถตอบคำถามนี้ได้จากหน้าต่าง Diff จนต้องหันไปถามบุคคลที่ยังพอจำได้ว่ามีส่วนประกอบอื่นใดบ้างที่พึ่งพากลุ่มความปลอดภัย (Security Group) ที่กำลังถูกแก้ไขอยู่
"Software design has a word for this: low cohesion. Things that change together are stored apart."
ในแวดวงการพัฒนาซอฟต์แวร์ เราได้เรียนรู้จากบทเรียนตลอดหลายทศวรรษเรื่อง Cohesion, Coupling และ Separation of Concerns ว่าสิ่งมักเปลี่ยนแปลงไปด้วยกันควรถูกจัดเก็บไว้ในที่เดียวกัน แต่ด้วยเหตุผลบางประการ คำศัพท์เหล่านี้กลับไม่เคยเดินทางมาถึงคลังโค้ดโครงสร้างพื้นฐานไอทีของเราเลย
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในมุมมองของการออกแบบระบบ แนวคิด Domain-Driven Infrastructure เปรียบเสมือนสะพานเชื่อมระหว่างโลกของการพัฒนาซอฟต์แวร์และวิศวกรรมโครงสร้างพื้นฐาน การย้ายมุมมองจากการมองแค่ประเภทของเทคโนโลยี (เช่น ฐานข้อมูลหรือระบบเครือข่าย) ไปสู่การมองว่าทรัพยากรใดบ้างที่ต้องถูกปรับเปลี่ยนไปพร้อมกันตามโจทย์ทางธุรกิจ ช่วยลดความซับซ้อนในการประเมินผลกระทบและจำกัดความเสี่ยงให้อยู่ในกรอบที่ควบคุมได้
ผู้เขียนได้เรียกขานแนวทางนี้ว่า Domain-Driven Infrastructure ซึ่งหมายถึงระเบียบวินัยในการประกาศขอบเขตของโดเมนทั้งในส่วนของโค้ดและการประเมินผล โดยโดเมนในที่นี้คือหน่วยที่มีเหตุผลในการเปลี่ยนแปลงร่วมกัน มีผู้รับผิดชอบ มีขอบเขตข้อบังคับ และมีกรอบความเสี่ยงเดียวกัน สำหรับใน Terraform แล้ว ขอบเขตการประเมินผลที่ชัดเจนที่สุดคือ State นั่นเอง
หากสรุปให้สั้นที่สุดคือ: จงจัดระเบียบตามเหตุผลที่ต้องเปลี่ยนแปลง ไม่ใช่จัดตามประเภทของเทคโนโลยี
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น