General design principles

Well-Architected Framework ได้ระบุชุดหลักการออกแบบทั่วไปเพื่อส่งเสริมการออกแบบที่ดีบนคลาวด์ไว้ดังนี้:

• เลิกคาดเดาความต้องการด้านความจุ (Stop guessing your capacity needs): หากตัดสินใจเรื่องความจุผิดพลาดขณะติดตั้งเวิร์กโหลด อาจลงเอยด้วยการมีทรัพยากรราคาแพงที่ปล่อยทิ้งไว้ว่าง ๆ หรือต้องรับมือกับผลกระทบด้านประสิทธิภาพเนื่องจากความจุไม่เพียงพอ ปัญหาเหล่านี้จะหมดไปเมื่อใช้ Cloud Computing เพราะสามารถใช้ความจุมากหรือน้อยเท่าที่จำเป็น และสามารถปรับขยายเข้า-ออก (Scale in/out) ได้โดยอัตโนมัติ

• ทดสอบระบบในสเกลการใช้งานจริง (Test systems at production scale): บนคลาวด์ สามารถสร้างสภาพแวดล้อมสำหรับทดสอบที่มีขนาดเท่ากับการใช้งานจริง (Production-scale) ได้ตามต้องการ เมื่อทดสอบเสร็จแล้วก็สามารถยกเลิกการใช้งานทรัพยากรเหล่านั้นได้ เนื่องจากจ่ายค่าสภาพแวดล้อมทดสอบเฉพาะตอนที่มันรันอยู่เท่านั้น จึงสามารถจำลองสภาพแวดล้อมจริงได้โดยจ่ายเพียงเศษเสี้ยวของต้นทุนเมื่อเทียบกับการทดสอบแบบ On-premises

• ใช้ระบบอัตโนมัติเพื่อเอื้อต่อการทดลองทางสถาปัตยกรรม (Automate with architectural experimentation in mind): ระบบอัตโนมัติช่วยให้สร้างและทำซ้ำเวิร์กโหลดได้ในต้นทุนที่ต่ำ และหลีกเลี่ยงค่าใช้จ่ายที่เกิดจากแรงงานคน สามารถติดตามการเปลี่ยนแปลงของระบบอัตโนมัติ ตรวจสอบผลกระทบ และย้อนกลับไปยังค่าพารามิเตอร์ก่อนหน้าได้เมื่อจำเป็น

• คำนึงถึงสถาปัตยกรรมที่วิวัฒนาการได้ (Consider evolutionary architectures): ในสภาพแวดล้อมแบบดั้งเดิม การตัดสินใจทางสถาปัตยกรรมมักถูกมองว่าเป็นเรื่องตายตัวที่เกิดขึ้นเพียงครั้งเดียว โดยมีเวอร์ชันหลักของระบบเพียงไม่กี่เวอร์ชันตลอดอายุการใช้งาน เมื่อธุรกิจและบริบทเปลี่ยนแปลงไป การตัดสินใจในตอนแรกอาจกลายเป็นอุปสรรคต่อความสามารถของระบบในการตอบสนองความต้องการทางธุรกิจที่เปลี่ยนไป แต่บนคลาวด์ ความสามารถในการสร้างระบบอัตโนมัติและการทดสอบตามต้องการจะช่วยลดความเสี่ยงจากผลกระทบของการเปลี่ยนการออกแบบ ทำให้ระบบสามารถวิวัฒนาการไปตามกาลเวลาเพื่อให้ธุรกิจใช้ประโยชน์จากนวัตกรรมใหม่ ๆ ได้จนเป็นเรื่องปกติ

• ขับเคลื่อนสถาปัตยกรรมด้วยข้อมูล (Drive architectures using data): บนคลาวด์ สามารถเก็บข้อมูลว่าการเลือกสถาปัตยกรรมของคุณส่งผลต่อพฤติกรรมของเวิร์กโหลดอย่างไร สิ่งนี้ช่วยให้คุณตัดสินใจปรับปรุงเวิร์กโหลดโดยอิงจากข้อเท็จจริง เนื่องจากโครงสร้างพื้นฐานคลาวด์ของคุณอยู่ในรูปแบบโค้ด (Infrastructure as Code) คุณจึงสามารถใช้ข้อมูลนั้นมาประกอบการตัดสินใจเลือกและพัฒนาสถาปัตยกรรมได้อย่างต่อเนื่อง

• ปรับปรุงผ่านกิจกรรมซ้อมรับมือเหตุการณ์ (Improve through game days): ทดสอบดูว่าสถาปัตยกรรมและกระบวนการของคุณทำงานเป็นอย่างไร โดยการกำหนดตารางกิจกรรม "Game days" อย่างสม่ำเสมอเพื่อจำลองเหตุการณ์ต่าง ๆ ที่อาจเกิดขึ้นจริงใน Production สิ่งนี้จะช่วยให้คุณเข้าใจว่าจุดใดที่ควรปรับปรุง และช่วยสร้างประสบการณ์ให้แก่องค์กรในการรับมือกับเหตุการณ์ต่าง ๆ