A Principled Approach (แนวทางที่มีหลักการ)

Rules are for the obedience of fools and the guidance of wise men.

Generally attributed to Douglas Bader

การตัดสินใจ ในการออกแบบระบบล้วนเกี่ยวกับ trade-off ทั้งนั้น และสถาปัตยกรรมไมโครเซอร์วิสก็ให้ trade-off มากมายให้เราต้องตัดสินใจ! เมื่อเลือก data store เราจะเลือกแพลตฟอร์มที่เรามีประสบการณ์น้อยกว่าแต่ให้การขยายสเกลที่ดีกว่าไหม เราจะมี technology stack สองแบบในระบบของเราได้ไหม แล้วสามแบบล่ะ บางการตัดสินใจสามารถทำได้ทันทีด้วยข้อมูลที่มีอยู่ ซึ่งเป็นการตัดสินใจที่ง่ายที่สุด แต่แล้วการตัดสินใจที่ต้องทำโดยมีข้อมูลไม่ครบถ้วนล่ะ

การจัดกรอบความคิด (framing) ช่วยได้ในเรื่องนี้ และวิธีที่ดีในการช่วยจัดกรอบการตัดสินใจของเราคือการกำหนดชุดของหลักการ (principles) และแนวปฏิบัติ (practices) ที่ชี้นำการตัดสินใจนั้น โดยอิงจากเป้าหมายที่เรากำลังพยายามบรรลุ มาดูแต่ละแง่มุมของการจัดกรอบนี้ทีละอย่างกัน

Strategic Goals (เป้าหมายเชิงกลยุทธ์)

บทบาท ของสถาปนิกก็หนักหนาพออยู่แล้ว โชคดีที่เราไม่ต้องเป็นคนกำหนดเป้าหมายเชิงกลยุทธ์เองด้วย! เป้าหมายเชิงกลยุทธ์ควรสะท้อนว่าบริษัทของคุณกำลังมุ่งหน้าไปทางไหน และมองว่าบริษัทจะทำให้ลูกค้าพึงพอใจที่สุดได้อย่างไร นี่จะเป็นเป้าหมายระดับสูงและอาจไม่รวมถึงเทคโนโลยีเลยด้วยซ้ำ มันอาจถูกกำหนดในระดับบริษัทหรือระดับดิวิชั่น มันอาจเป็นอะไรอย่างเช่น "ขยายไปยังเอเชียตะวันออกเฉียงใต้เพื่อเปิดตลาดใหม่" หรือ "ให้ลูกค้าทำสิ่งต่างๆ ได้มากที่สุดผ่าน self-service" กุญแจสำคัญคือมันกำหนดว่าองค์กรของคุณกำลังมุ่งหน้าไปทางไหน ดังนั้นคุณต้องมั่นใจว่าเทคโนโลยีสอดคล้องกับสิ่งนั้น

ถ้าคุณเป็นคนที่กำหนดวิสัยทัศน์ทางเทคนิคของบริษัท นี่อาจหมายความว่าคุณต้องใช้เวลามากขึ้นกับส่วนที่ไม่ใช่เทคนิคขององค์กร (หรือที่เรียกว่า "the business") อะไรคือวิสัยทัศน์ที่ขับเคลื่อนธุรกิจ และมันเปลี่ยนแปลงไปอย่างไร

Principles (หลักการ)

หลักการคือกฎที่คุณสร้างขึ้นเพื่อปรับสิ่งที่คุณกำลังทำให้สอดคล้องกับเป้าหมายที่ใหญ่กว่า และบางครั้งมันก็เปลี่ยนแปลงได้ ตัวอย่างเช่น ถ้าหนึ่งในเป้าหมายเชิงกลยุทธ์ขององค์กรคือการลด time to market สำหรับฟีเจอร์ใหม่ คุณอาจกำหนดหลักการที่ว่าทีมส่งมอบมีอำนาจควบคุมเต็มที่ตลอดวงจรชีวิตของซอฟต์แวร์ของตน สามารถส่งมอบได้เมื่อไรก็พร้อม โดยไม่ขึ้นกับทีมอื่น ถ้าอีกเป้าหมายหนึ่งคือองค์กรของคุณกำลังขยายตัวอย่างรวดเร็วในประเทศอื่นๆ คุณอาจตัดสินใจนำหลักการที่ว่าทั้งระบบต้องพกพาได้ (portable) มาใช้ เพื่อให้สามารถ deploy ในพื้นที่ได้ ในการเคารพอธิปไตยของข้อมูล (data sovereignty)

คุณคงไม่อยากมีหลักการเยอะเกินไป น้อยกว่า 10 ข้อเป็นจำนวนที่ดี เล็กพอที่คนจะจำได้ หรือพิมพ์ลงโปสเตอร์ขนาดเล็กได้ ยิ่งคุณมีหลักการมากเท่าไร โอกาสที่มันจะซ้อนทับหรือขัดแย้งกันเองก็ยิ่งมากขึ้นเท่านั้น

Heroku's Twelve Factors เป็น ชุดหลักการออกแบบที่จัดโครงสร้างรอบเป้าหมายในการช่วยให้คุณสร้างแอปพลิเคชันที่ทำงานได้ดีบน Heroku แพลตฟอร์ม หลักการเหล่านี้อาจสมเหตุสมผลในบริบทอื่นๆ ด้วยเช่นกัน บางข้อจริงๆ แล้วเป็นข้อจำกัด (constraints) ที่อิงจากพฤติกรรมที่แอปพลิเคชันของคุณต้องแสดงออกเพื่อให้ทำงานบน Heroku ได้ ข้อจำกัดคือสิ่งที่ยากมาก (หรือแทบเป็นไปไม่ได้) ที่จะเปลี่ยนแปลง ในขณะที่หลักการคือสิ่งที่เราเลือกเอง คุณอาจตัดสินใจแยกให้ชัดว่าอะไรเป็นหลักการและอะไรเป็นข้อจำกัด เพื่อเน้นย้ำสิ่งที่คุณเปลี่ยนแปลงไม่ได้จริงๆ ส่วนตัวผมคิดว่าการเก็บทั้งสองอย่างไว้ในลิสต์เดียวกันก็มีคุณค่า เพื่อกระตุ้นให้ท้าทายข้อจำกัดเป็นระยะๆ และดูว่ามันเปลี่ยนแปลงไม่ได้จริงหรือไม่!

Practices (แนวปฏิบัติ)

แนวปฏิบัติของเราคือวิธีที่เรามั่นใจว่าหลักการของเราถูกนำไปปฏิบัติจริง มันคือชุดแนวทางเชิงปฏิบัติที่ละเอียดสำหรับการทำงานต่างๆ มักจะเจาะจงกับเทคโนโลยี และควรอยู่ในระดับที่นักพัฒนาคนไหนก็เข้าใจได้ แนวปฏิบัติอาจรวมถึงแนวทางการเขียนโค้ด ข้อเท็จจริงที่ว่าข้อมูล log ทั้งหมดต้องถูกเก็บไว้ที่ศูนย์กลาง หรือข้อเท็จจริงที่ว่า HTTP/REST เป็นรูปแบบการผสานรวมมาตรฐาน เนื่องด้วยลักษณะทางเทคนิคของมัน แนวปฏิบัติมักจะเปลี่ยนแปลงบ่อยกว่าหลักการ

เช่นเดียวกับหลักการ บางครั้งแนวปฏิบัติก็สะท้อนข้อจำกัดภายในองค์กรของคุณ ตัวอย่างเช่น ถ้าคุณตัดสินใจเลือก Azure เป็นแพลตฟอร์มคลาวด์ นี่จำเป็นต้องสะท้อนอยู่ในแนวปฏิบัติของคุณด้วย

แนวปฏิบัติควรรองรับหลักการของคุณ หลักการที่ระบุว่าทีมส่งมอบควบคุมวงจรชีวิตเต็มรูปแบบของระบบของตนเอง อาจหมายความว่าคุณมีแนวปฏิบัติที่ระบุว่าไมโครเซอร์วิสทั้งหมดถูก deploy ลงใน AWS account ที่แยกจากกัน ให้บริการจัดการทรัพยากรแบบ self-service และแยกตัวจากทีมอื่น

Combining Principles and Practices (การรวมหลักการและแนวปฏิบัติเข้าด้วยกัน)

สิ่งที่คนหนึ่งเรียกว่าหลักการ อีกคนอาจเรียกว่าแนวปฏิบัติ คุณอาจตัดสินใจเรียกการใช้ HTTP/REST ว่าเป็นหลักการแทนที่จะเป็นแนวปฏิบัติ ตัวอย่างเช่น และนั่นก็ไม่มีปัญหาอะไร ประเด็นสำคัญคือมันมีคุณค่าที่จะมีแนวคิดครอบคลุมที่ชี้นำว่าระบบวิวัฒนาการไปอย่างไร และมีรายละเอียดมากพอที่ผู้คนจะรู้วิธีนำแนวคิดเหล่านั้นไปปฏิบัติ สำหรับกลุ่มที่เล็กพอ อาจเป็นแค่ทีมเดียว การรวมหลักการและแนวปฏิบัติเข้าด้วยกันอาจโอเค แต่สำหรับองค์กรที่ใหญ่กว่า ที่เทคโนโลยีและวิธีการทำงานอาจแตกต่างกันไปในแต่ละที่ คุณอาจต้องการชุดแนวปฏิบัติที่ต่างกันในแต่ละที่ ตราบใดที่ทั้งหมดยังสอดคล้องกับชุดหลักการร่วมกัน ตัวอย่างเช่น ทีม .NET อาจมีแนวปฏิบัติชุดหนึ่ง และทีม Java อีกชุดหนึ่ง แต่หลักการอาจเหมือนกันสำหรับทั้งสองทีม

A Real-World Example (ตัวอย่างจากโลกจริง)

เพื่อนร่วมงานเก่าของผม Evan Bottcher พัฒนาไดอะแกรมที่แสดงใน Figure 16-3 ขึ้นระหว่างทำงานกับลูกค้ารายหนึ่งของเขา ไดอะแกรมนี้แสดงความสัมพันธ์ระหว่างเป้าหมาย หลักการ และแนวปฏิบัติในรูปแบบที่ชัดเจนมาก ตลอดระยะเวลาสองสามปี แนวปฏิบัติทางด้านขวาสุดจะเปลี่ยนแปลงค่อนข้างบ่อย ในขณะที่หลักการจะค่อนข้างคงที่ ไดอะแกรมแบบนี้สามารถพิมพ์ลงกระดาษแผ่นเดียวได้อย่างเรียบร้อยและแชร์ต่อได้ และแต่ละแนวคิดก็ง่ายพอที่นักพัฒนาทั่วไปจะจำได้ แน่นอนว่ามีรายละเอียดมากกว่านี้อยู่เบื้องหลังแต่ละจุด แต่การสามารถอธิบายมันในรูปแบบสรุปได้ก็มีประโยชน์มาก

Figure 16-3. ตัวอย่างจากโลกจริงของหลักการและแนวปฏิบัติ

มันสมเหตุสมผลที่จะมีเอกสารสนับสนุนรายการเหล่านี้บางส่วน และยิ่งดีกว่านั้นคือการมีโค้ดใช้งานได้จริงที่แสดงให้เห็นว่าแนวปฏิบัติเหล่านี้ถูกนำไปใช้อย่างไร ใน "The Platform" เราดูว่าการสร้างชุดเครื่องมือร่วมกันช่วยให้นักพัฒนาทำสิ่งที่ถูกต้องได้ง่ายขึ้นอย่างไร ในอุดมคติ แพลตฟอร์มควรทำให้การทำตามแนวปฏิบัติเหล่านี้ง่ายที่สุดเท่าที่จะเป็นไปได้ และเมื่อแนวปฏิบัติเปลี่ยนแปลง แพลตฟอร์มก็ควรเปลี่ยนแปลงตาม