Defining System Boundaries (การกำหนดขอบเขตของระบบ)

ขอ ใช้อุปมาของสถาปนิกในฐานะนักผังเมืองต่ออีกสักหน่อย โซนของเราคืออะไรบ้าง มันคือขอบเขตไมโครเซอร์วิสของเรา หรือบางทีก็คือกลุ่มไมโครเซอร์วิสแบบหยาบๆ ในฐานะสถาปนิก เราต้องกังวลน้อยลงมากกับสิ่งที่ เกิดขึ้น ภายใน โซน และกังวลมากขึ้นกับสิ่งที่เกิดขึ้น ระหว่าง โซน นั่นหมายความว่าเราต้องใช้เวลาคิดว่าไมโครเซอร์วิสของเราคุยกันอย่างไร และมั่นใจว่าเราสามารถ monitor สุขภาพโดยรวมของระบบได้อย่างเหมาะสม จากมุมมองด้านสถาปัตยกรรม นี่คือวิธีที่เราสร้าง universal space ของเราเอง ด้วยการกำหนดขอบเขตเฉพาะเจาะจง เราชี้ให้เพื่อนร่วมงานที่กำลังสร้างระบบเห็นว่าพื้นที่ไหนที่สามารถเปลี่ยนแปลงได้อย่างอิสระมากขึ้นโดยไม่ทำลายแง่มุมพื้นฐานของสถาปัตยกรรมของเรา

ลองดูตัวอย่างง่ายๆ ใน Figure 16-1 เราเห็นไมโครเซอร์วิส Recommendations เข้าถึงข้อมูลจากไมโครเซอร์วิส Promotions และ Sales อย่างที่เราพูดถึงมาอย่างละเอียดแล้ว เราสามารถเปลี่ยนฟังก์ชันการทำงานที่ซ่อนอยู่ภายในไมโครเซอร์วิสทั้งสามนี้ได้อย่างอิสระโดยไม่ต้องกังวลว่าจะทำระบบโดยรวมพัง ผมสามารถเปลี่ยนอะไรก็ได้ใน Sales หรือ Promotions ตราบใดที่ผมยังคงรักษาสิ่งที่ Recommendations คาดหวังไว้เกี่ยวกับวิธีที่มันจะปฏิสัมพันธ์กับไมโครเซอร์วิสปลายทางเหล่านี้

Figure 16-1. การเปลี่ยนแปลงภายในขอบเขตไมโครเซอร์วิสทำได้ง่าย ตราบใดที่ปฏิสัมพันธ์ระหว่างไมโครเซอร์วิสไม่เปลี่ยนแปลง

เราสามารถสร้างพื้นที่สำหรับการเปลี่ยนแปลงในระดับที่ใหญ่กว่าได้เช่นกัน ใน Figure 16-2 เราเห็นไมโครเซอร์วิสจาก Figure 16-1 อยู่ในโซนการตลาดที่สอดคล้องกับความรับผิดชอบของทีมหนึ่งโดยเฉพาะ เราได้กำหนดพฤติกรรมที่คาดหวังในแง่ของวิธีที่ฟังก์ชันการตลาดปฏิสัมพันธ์กับระบบที่ใหญ่กว่า ภายในโซนการตลาด เราสามารถเปลี่ยนแปลงอะไรก็ได้ตามใจ ตราบใดที่ยังคงความเข้ากันได้กับระบบที่ใหญ่กว่า กลับมาที่แนวคิดการเข้าใจว่าอะไรยากที่จะเปลี่ยนแปลง โครงสร้างองค์กรมักตกอยู่ในหมวดหมู่นี้ ดังนั้นโครงสร้างทีมที่มีอยู่แล้วจึงช่วยกำหนดโซนเหล่านี้ให้คุณได้ การประสานงานการเปลี่ยนแปลงภายในทีมข้ามไมโครเซอร์วิสที่ทีมนั้นเป็นเจ้าของ จะง่ายกว่าการเปลี่ยนปฏิสัมพันธ์ที่เปิดเผยให้ทีมอื่นเห็น

Figure 16-2. การเปลี่ยนแปลงภายในโซนทำได้ง่ายกว่าการเปลี่ยนแปลงระหว่างโซน

สิ่งนี้เชื่อมโยงได้ดีกับแนวคิดของ team API ซึ่งเราพูดถึงใน "Small Teams, Large Organization" สถาปนิกสามารถช่วยอำนวยความสะดวกในการสร้าง team API เพื่อให้แน่ใจว่าไมโครเซอร์วิสและวิธีการทำงานของทีมสอดคล้องกับองค์กรในภาพรวม

ด้วยการกำหนดพื้นที่ที่การเปลี่ยนแปลงเหล่านี้สามารถเกิดขึ้นได้โดยไม่กระทบระบบโดยรวม เราทำให้ชีวิตของนักพัฒนาง่ายขึ้น และยังโฟกัสความสนใจของเราไปที่ส่วนต่างๆ ของระบบที่เปลี่ยนแปลงยากกว่า จำแนวคิด information hiding ที่เราสำรวจใน Chapter 2 ได้ไหม อย่างที่เราสำรวจไว้ที่นั่น การซ่อนข้อมูลไว้ภายในขอบเขตไมโครเซอร์วิสทำให้สร้างอินเทอร์เฟซที่มั่นคงสำหรับผู้บริโภคได้ง่ายขึ้นมาก เมื่อเราเปลี่ยนแปลงไมโครเซอร์วิส มันจะง่ายขึ้นที่จะมั่นใจว่าเราไม่ได้ทำลายความเข้ากันได้กับผู้บริโภคภายนอก ในที่นี้ เราสามารถกำหนดสถาปัตยกรรมที่ให้ information hiding ในระดับทีม ไม่ใช่แค่ในระดับไมโครเซอร์วิส สิ่งนี้ให้เราอีกระดับหนึ่งของ information hiding และสร้างพื้นที่ปลอดภัยที่ใหญ่ขึ้นซึ่งทีมสามารถทำการเปลี่ยนแปลงในท้องถิ่นได้โดยไม่ทำลาย ระบบ ในภาพรวม

ภายในแต่ละไมโครเซอร์วิสหรือโซนที่ใหญ่กว่า คุณอาจจะโอเคที่ให้ทีมที่เป็นเจ้าของโซนนั้นเลือก technology stack หรือ data store ที่ต่างออกไป ข้อกังวลอื่นๆ อาจเข้ามาเกี่ยวข้องด้วย แนวโน้มที่คุณอยากให้ทีมเลือกเครื่องมือที่เหมาะสมกับงานอาจถูกลดทอนลงด้วยความจริงที่ว่ามันจะยากขึ้นที่จะจ้างคนหรือย้ายคนระหว่างทีม ถ้าคุณมี technology stack ถึง 10 แบบให้ต้องซัพพอร์ต ในทำนองเดียวกัน ถ้าแต่ละทีมเลือก data store ที่ต่างกันโดยสิ้นเชิง คุณอาจพบว่าตัวเองขาดประสบการณ์เพียงพอที่จะรัน data store เหล่านั้นในระดับสเกลใหญ่ Netflix ยกตัวอย่างเช่น ได้มาตรฐานส่วนใหญ่ไว้ที่ Cassandra เป็นเทคโนโลยี data store แม้มันอาจไม่ใช่ตัวเลือกที่ดีที่สุดสำหรับทุกกรณี แต่ Netflix รู้สึกว่าคุณค่าที่ได้จากการสร้างเครื่องมือและความเชี่ยวชาญรอบๆ Cassandra สำคัญกว่าการต้องซัพพอร์ตและดำเนินการแพลตฟอร์มอื่นๆ อีกหลายตัวในระดับสเกลใหญ่ ซึ่งอาจเหมาะกับงานบางอย่างมากกว่า Netflix เป็นตัวอย่างสุดโต่งที่สเกลน่าจะเป็นปัจจัยครอบงำที่แข็งแกร่งที่สุด แต่คุณก็คงเข้าใจแนวคิดแล้ว

ระหว่างไมโครเซอร์วิสนี่แหละที่สิ่งต่างๆ อาจยุ่งเหยิงได้ ถ้าไมโครเซอร์วิสหนึ่งตัดสินใจใช้ REST over HTTP อีกตัวใช้ gRPC และตัวที่สามใช้ Java RMI การผสานรวมกันก็จะกลายเป็นฝันร้าย เพราะไมโครเซอร์วิสที่บริโภคข้อมูลต้องเข้าใจและซัพพอร์ตรูปแบบการแลกเปลี่ยนข้อมูลหลายแบบ นี่คือเหตุผลที่ผมพยายามยึดแนวทางที่ว่าเราควร "กังวลเกี่ยวกับสิ่งที่เกิดขึ้นระหว่างกล่อง และปล่อยอิสระกับสิ่งที่เกิดขึ้นภายในกล่อง"

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