คำถามที่คนทำแอพต้องถามตัวเอง (Intro to Well-Architected)
ได้ยินคำนี้ครั้งแรกจาก Keynote session งาน AWS Summit 2018 ก็รู้สึกเลยว่า เฮ้ย นี่แหละ คำจำกัดความของสิ่งที่เรากำลังตามหา “สถาปัตย์ที่ดีงาม”
แอพที่เราสร้างมาถือว่ามีการออกแบบ และก่อสร้างมาดีแล้วรึยัง? แล้วอะไรละที่เรียกว่าดี? คราวนี้ต้องใช้อะไรเป็นตัววัด? เรียกได้ว่าคอนเซปท์นี้ช่วยเปิดโลกทัศน์ และสร้างแนวคิดที่เอามาต่อยอดให้เป็นรูปเป็นร่างได้อีกเพียบบบบ
ขอท้าวความก่อนว่า AWS (Amazon Web Service) เป็น Cloud Platform ที่มาภายใต้คอนเซปท์ที่ว่า “จงทิ้งเรื่อง infra ให้ AWS แล้วให้ทีมพัฒนาได้มุ่งมั่นพัฒนาแอพดีๆกันต่อไป” เพื่อให้รองรับทุกความต้องการของนักพัฒนา AWS จึงมี infra-features ร้อยกว่า service และทยอยออกใหม่ทั้งปี ทุกปี ทำให้เกิดท่วงท่านับล้านในการประกอบร่างกันเป็นระบบ ซึ่งเทคนิคการต่อ service จะแตกต่างกันไปตามแต่ว่าระบบนั้นๆต้องสร้างมาเพื่อทำอะไร และเน้นหนักด้านไหน ความปลอดภัย ความไว ราคา scale ฯลฯ
เมื่อมีล้านท่วงท่า ก็ตามมาด้วยล้านคำถามว่าจะทำยังไงให้ออกแบบระบบได้อย่างเหมาะสม
ในปี 2018 AWS จึงออก AWS Well-Architected Framework มาเป็นไกด์ไลน์ให้เหล่านักพัฒนาแอพพลิเคชั่น และผู้ดูแลระบบได้ถามตัวเองว่าสิ่งที่คุณสร้างมามีโครงสร้างที่ดีรึยัง พร้อมทั้งนิยามความดีงามของระบบออกมาว่ามีองค์ประกอบแบ่งเป็น 5 เสาหลักตามนี้
Operational Excellence
“คุณจัดการ และรับมือกับการ deliver ระบบได้ดีขึ้นเรื่อยๆหรือไม่”
ความสามารถในการเปลี่ยน code ของโปรแกรมเมอร์ให้กลายเป็นแอพพลิเคชั่น เราทำได้เร็ว และราบรื่นพอที่ user จะใช้งานแบบไม่สะดุดมั้ย?
มี policy ควบคุมการ publish application หรือไม่? อย่างไร?
ทุกวันนี้มั่นใจแค่ไหนว่ากระบวนการ publish application ให้ user ใช้งานจะถูกต้องตาม policy 100%?
รวมไปถึงถ้ามี developer เข้ามาทำงานใหม่ จะใช้เวลาทำความคุ้นเคยกับระบบนานแค่ไหนกว่าจะคล่องตัว?
Operational Excellence พยายามชี้ให้เห็นความสำคัญของการ deliver สิ่งที่โปรแกรมเมอร์สร้างไปเป็น application ที่ user ใช้ได้อย่างรวดเร็ว และส่งผลกระทบต่อผู้ใช้งานให้น้อยที่สุด พร้อมทั้งตอกย้ำให้ทีมพัฒนาเข้าใจความจริงที่ว่าการจัดการภายในทีมเองก็เป็นสิ่งหนึ่งที่ต้องได้รับการปรับปรุงให้ดีขึ้นเรื่อยๆเช่นเดียวกันกับโปรแกรม
Security
“แน่ใจนะว่าป้องกันได้ทั้ง infra, data และ application ทั้งจาก hacker และ developer ด้วยกันเอง”
ใครบ้างที่สามารถเข้าถึง infra, data และ application?
ได้บันทึกไว้มั้ย ว่าใคร ทำอะไรกับ infra, data และ application และทำไปเมื่อไหร่?
แน่ใจมั้ยว่าระหว่างที่ระบบส่ง data ออกสู่โลกอินเตอร์เน็ตไปถึงมือผู้ใช้งาน data จะไม่ถูกแกะออกดู หรือแก้ไข?
เสาหลักแท่งนี้กำลังบอกเราว่าการจะป้องกันความปลอดภัย ต้องทำให้ได้ครอบคลุมทั้งสามระดับ infrastructure, data และ application แล้วยังต้องวางบทบาทให้แน่ชัดว่าบุคลากรในทีมสามารถเข้าถึงระบบได้มากน้อยแค่ไหน เพราะหลายครั้งที่ human error ก็นำมาซึ่งหายนะ 555
Reliability
“ระบบของคุณจะพร้อมให้ user ใช้งานได้ทุกเมื่อที่เขาต้องการรึเปล่า”
เมื่อเทียบระยะเวลาที่ระบบเปิดอยู่กับระบบขัดข้อง % เป็นเท่าไหร่?
ต้อง down ระบบเพื่อ maintenance บ่อยมั้ย แล้วปกติใช้เวลาเท่าไหร่?
เวลาเกิดปัญหาร้ายแรง เราสามารถถอนทัพกลับเวอร์ชั่นเดิมได้เร็วแค่ไหน?
เวลาเกิดปัญหา เรารู้ก่อนผู้ใช้งานหรือไม่?
เวลาเกิดเหตุการณ์ไม่คาดฝัน หรือการเปลี่ยนแปลงภายใน (business requirement) และภายนอก (technology trend) เรามีแผนรับมือยังไง?
Reliability เรียกได้ว่าเป็นเสาหลักชี้เป็นชี้ตายของคนทำแอพพลิเคชั่น เพราะ user ที่เข้ามาเจอ Page not found หรือทำในสิ่งที่เคยทำไม่ได้ นอกจากจะหัวร้อนแล้ว ยังสูญเสียความไว้วางใจในเสถียรภาพของโปรแกรม ยิ่งในโลกที่คนทั่วไปโหลดและลบแอพกันวันต่อวัน First Impression ยิ่งเป็นสิ่งที่สำคัญเอามากๆ
Performance Efficiency
“มีตัววัดว่าแอพของคุณยังสุขภาพดีอยู่หรือไม่”
รู้หรือไม่ว่า ถ้า server ของคุณ CPU, RAM, Hard disk, Bandwidth เต็มจะทำให้แอพช้าลงเรื่อยๆและล่มในที่สุด?
มีระบบแจ้งเตือนว่า server ของคุณ CPU, RAM, Hard disk, Bandwidth กำลังจะเต็มแล้วหรือยัง?
มีเครื่องวัดมั้ยว่า Experience ที่ user มีต่อแอพเป็นอย่างไรบ้าง?
ถ้า server เกิดมีอันเป็นไป มีแผนการรับมืออย่างไรบ้าง และเพื่อดำเนินการตามแผนดังกล่าว ต้องใช้เวลานานแค่ไหน เสียค่าใช้จ่ายอะไรบ้าง คุ้มมั้ยที่จะแลก?
Performance Efficiency หลายๆคนอาจคิดถึงความเร็วในการตอบสนองของแอพเพียงอย่างเดียว แต่จริงๆแล้วการป้องกัน และแจ้งเตือนให้ทีมได้รู้ถึง capability ของระบบอยู่ตลอดเวลาต่างหากที่เป็นคีย์ที่จะก่อให้เกิดการตื่นรู้ว่าควรขยับขยาย หรือปรับปรุงอะไรเมื่อไหร่
Cost Optimization
“มั่นใจมั้ยว่าแอพของคุณรันอยู่บนระบบที่คุ้มราคา”
แน่ใจรึเปล่าว่าไม่ได้ซื้อเครื่อง server ใหญ่เกินความจำเป็น?
ระบบต่างๆใน application จริงๆแล้วสามารถหั่นออกเป็นชิ้นเล็กๆ เพื่อวางไว้ใน Cloud Service ที่เหมาะสมทั้งการใช้งาน และราคา ได้ออกแบบให้เหมาะสมหรือยัง อย่างไรบ้าง?
มีระบบตรวจสอบหรือไม่ว่าค่าใช้จ่ายทางด้าน server ยังมีสัดส่วนที่สมเหตุสมผลตามการใช้งาน?
Cloud Service มีโมเดลการคิดเงินแบบ Pay per use ซึ่งต่างกับ Physical Server ทั่วไปที่ลงทุนครั้งเดียวใช้ไป 5 ปี 10 ปี เสาหลักแท่งนี้กำลังเตือนให้เราคำนึงถึงค่าใช้จ่ายบน Cloud ที่ดูดเงินจากเราทุกบาททุกสตางค์ การประหยัดงบบนระบบ Cloud อยู่ที่ว่าเราจะสามารถออกแบบระบบให้มีความยืดหยุ่นพอที่จะตัดแบ่งบางส่วนของระบบให้อยู่ใน Service ที่เหมาะสมทั้งในแง่การใช้งานและราคาได้หรือไม่
มาถึงจุดนี้ ถ้ายังมีคำถามที่ไม่สามารถตอบได้เยอะมากเท่าไหร่ เรียกได้ว่าแอพของเราก็มีความเสี่ยงมากขึ้นเท่านั้น หากเทคโนโลยีที่ใช้ส่งผลโดยตรงกับการเติบโตทาง Business ขององค์กร การหยุดอยู่กับที่ของเทคโนโลยีก็หมายถึงความเสี่ยงที่เราจะวิ่งตามโลกไม่ทันได้เพิ่มขึ้นอีกหนึ่งวัน
แน่นอนว่าการจะเปลี่ยนแปลงให้ด้านใดด้านหนึ่งเข้มแข็ง มันตามมาด้วยค่าใช้จ่าย พลังกาย พลังใจ เวลาของทีม แล้วยังลามไปถึงการเปลี่ยนแปลงความเคยชินของ user, Switching cost และอื่นๆอีกมากมาย ซึ่งสิ่งเหล่านี้เราพอจะทำแผนรับมือกับ Budget plan ให้เห็นภาพก่อนได้
ก็ต้องถามทีมของเราแล้วละ ว่าพร้อมจะ trade-off มั้ย
บล็อคนี้มีคำว่า (Intro) ห้อยท้าย นั่นหมายความว่ามัน(อาจ)จะมีแบบละเอียดตามมาในภายหลัง ครั้งนี้ขอทิ้งไว้แค่คำถามให้ไปคุยกับทีมพัฒนากันก่อนนะคะ คราวหน้าจะกลับมาพร้อม Best Practice ของแต่ละเสาหลักอย่างเข้มข้นกันอีกที
จริงๆแล้วนี่คือบล็อคแรก(ในรอบสิบปี)ค่ะ มีหลายเรื่องมากที่อยากเขียน ทั้ง Agile Manifesto, Scrum, Redis 4.0.1 มีอะไรดี ทำไมต้องเปลี่ยน, ทำไมปลาวาฬเพชรฆาตถึงครีบพับ, ทำไม Design sprint ถึง fail, ICANN กับ 14 อัศวินเทมพลาผู้ปกปักรักษาโลกอินเตอร์เน็ต
ความสนใจมันหลากหลายมากจริงๆค่ะ
สัญญากับตัวเองว่าจะทยอยเขียนไปเรื่อยๆ แล้วใส่ tag เป็นหมวดหมู่ไว้ โปรดติดตามตอนต่อไปกันด้วยนะคะ :)
