Strong Versus Collective Ownership (ความเป็นเจ้าของแบบเข้มข้นเทียบกับแบบร่วมกัน)

ใน "Defining ownership" เราได้พูดถึงประเภทต่างๆ ของความเป็นเจ้าของ และสำรวจผลกระทบของรูปแบบความเป็นเจ้าของเหล่านี้ในบริบทของการเปลี่ยนแปลงโค้ด สรุปสั้นๆ รูปแบบหลักสองแบบของความเป็นเจ้าของโค้ดที่เราอธิบายไปคือ:

Strong ownership

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

Collective ownership

ทีมไหนก็สามารถเปลี่ยนแปลงไมโครเซอร์วิสไหนก็ได้ ต้องมีการประสานงานอย่างระมัดระวังเพื่อให้แน่ใจว่าทีมต่างๆ จะไม่ก้าวก่ายกัน

มาสำรวจผลกระทบของโมเดลความเป็นเจ้าของเหล่านี้กันต่อ และดูว่ามันช่วย (หรือขัดขวาง) การผลักดันไปสู่ความเป็นอิสระของทีมที่มากขึ้นได้อย่างไร

Strong Ownership (ความเป็นเจ้าของแบบเข้มข้น)

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

ท้ายที่สุดแล้ว strong ownership คือการปรับให้เหมาะสมที่สุดสำหรับความเป็นอิสระของทีมนั้นๆ กลับมาที่วิธีการทำงานแบบ Amazon จาก Think Like Amazon :

เมื่อพูดถึง Two-Pizza Team อันโด่งดังของ Amazon คนส่วนใหญ่มักพลาดประเด็นสำคัญ มันไม่ได้อยู่ที่ขนาดของทีม แต่อยู่ที่ความเป็นอิสระ ความรับผิดชอบ และความคิดแบบผู้ประกอบการของทีม Two-Pizza Team คือการติดตั้งอาวุธให้ทีมเล็กๆ ภายในองค์กรสามารถทำงานได้อย่างเป็นอิสระและคล่องตัว

โมเดล strong ownership เปิดโอกาสให้เกิดความหลากหลายในระดับท้องถิ่นได้มากขึ้น ตัวอย่างเช่น คุณอาจไม่ซีเรียสถ้าทีมหนึ่งตัดสินใจสร้างไมโครเซอร์วิสของตัวเองด้วยสไตล์ functional ของ Java เพราะนั่นเป็นการตัดสินใจที่ควรส่งผลกระทบแค่กับพวกเขาเอง แน่นอนว่าความหลากหลายนี้ก็ต้องมีการควบคุมอยู่บ้าง เพราะการตัดสินใจบางอย่างจำเป็นต้องมีความสอดคล้องกันในระดับหนึ่ง ตัวอย่างเช่น ถ้าทุกคนใช้ REST-over-HTTP API สำหรับ endpoint ของไมโครเซอร์วิส แต่คุณตัดสินใจใช้ GRPC คุณอาจสร้างปัญหาให้กับคนอื่นที่อยากใช้ไมโครเซอร์วิสของคุณ ในทางกลับกัน ถ้า GRPC endpoint นั้นถูกใช้แค่ภายในทีมของคุณเอง ก็อาจไม่เป็นปัญหา ดังนั้นเมื่อตัดสินใจในระดับท้องถิ่นที่ส่งผลกระทบต่อทีมอื่น ก็อาจยังต้องมีการประสานงานอยู่ดี เราจะสำรวจว่าจะรู้ได้อย่างไรว่าเมื่อไรและอย่างไรที่ควรดึงองค์กรที่กว้างขึ้นเข้ามาเกี่ยวข้อง เมื่อเราพูดถึงการสร้างสมดุลระหว่างการปรับให้เหมาะสมในระดับท้องถิ่นกับระดับส่วนกลางในไม่ช้า

โดยพื้นฐานแล้ว ยิ่งทีมสามารถใช้โมเดล ownership ที่เข้มข้นมากเท่าไร ก็ยิ่งต้องการการประสานงานน้อยลงเท่านั้น และทีมก็จะยิ่งมีผลิตภาพมากขึ้นตามไปด้วย

How far does strong ownership go? (strong ownership ไปได้ไกลแค่ไหน?)

จนถึงตอนนี้ เราพูดถึงแง่มุมต่างๆ อย่างการเปลี่ยนแปลงโค้ดหรือการเลือกเทคโนโลยีเป็นหลัก แต่แนวคิดเรื่องความเป็นเจ้าของสามารถลึกซึ้งกว่านั้นมาก บางองค์กรใช้โมเดลที่ผมเรียกว่า full life-cycle ownership ด้วย full life-cycle ownership ทีมทีมเดียวจะเป็นผู้คิดค้นการออกแบบ ทำการเปลี่ยนแปลง deploy ไมโครเซอร์วิส จัดการมันใน production และท้ายที่สุดก็ปลดระวางไมโครเซอร์วิสนั้นเมื่อไม่จำเป็นอีกต่อไป

โมเดล full life-cycle ownership นี้ยิ่งเพิ่มความเป็นอิสระของทีมมากขึ้นไปอีก เพราะความจำเป็นในการประสานงานภายนอกลดลง ไม่ต้องเปิด ticket ให้ทีม operations เพื่อ deploy ไม่มีฝ่ายภายนอกต้องเซ็นอนุมัติการเปลี่ยนแปลง และทีมเป็นผู้ตัดสินใจเองว่าจะเปลี่ยนแปลงอะไรและจะ ship เมื่อไร

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

ผมไม่อยากจะบอกว่าโมเดลนี้จำเป็นสำหรับการใช้ไมโครเซอร์วิสแต่อย่างใด—ผมเชื่ออย่างแน่วแน่ว่า strong ownership สำหรับองค์กรที่มีหลายทีมคือโมเดลที่สมเหตุสมผลที่สุดในการได้ประโยชน์สูงสุดจากไมโครเซอร์วิส โมเดล strong ownership รอบๆ การเปลี่ยนแปลงโค้ดเป็นจุดเริ่มต้นที่ดี—คุณสามารถค่อยๆ ขยับไปสู่ full life-cycle ownership ได้ในภายหลัง

Collective Ownership (ความเป็นเจ้าของร่วมกัน)

ด้วย โมเดล collective ownership ไมโครเซอร์วิสหนึ่งๆ สามารถเปลี่ยนแปลงได้โดยทีมใดก็ได้จากหลายทีม หนึ่งในประโยชน์หลักของ collective ownership คือคุณสามารถย้ายคนไปที่ที่ต้องการได้ ซึ่งมีประโยชน์มากถ้า bottleneck ในการส่งมอบงานของคุณเกิดจากการขาดคน ตัวอย่างเช่น มีการเปลี่ยนแปลงหลายอย่างที่ต้องอัปเดตไมโครเซอร์วิส Payment เพื่อรองรับการเรียกเก็บเงินรายเดือนแบบอัตโนมัติ—คุณก็แค่มอบหมายคนเพิ่มเข้าไปทำการเปลี่ยนแปลงนี้ได้เลย แน่นอนว่าการโยนคนเพิ่มเข้าไปแก้ปัญหาไม่ได้ทำให้เร็วขึ้นเสมอไป แต่ด้วย collective ownership คุณก็มีความยืดหยุ่นมากขึ้นในแง่นี้อย่างแน่นอน

เมื่อทีม—และคน—ย้ายจากไมโครเซอร์วิสหนึ่งไปอีกไมโครเซอร์วิสหนึ่งบ่อยขึ้น เราก็ต้องการความสอดคล้องในระดับสูงขึ้นว่าสิ่งต่างๆ ถูกทำอย่างไร คุณไม่สามารถมีตัวเลือกเทคโนโลยีที่หลากหลาย หรือรูปแบบการ deploy ที่แตกต่างกันได้ ถ้าคุณคาดหวังให้นักพัฒนาทำงานกับไมโครเซอร์วิสคนละตัวในแต่ละสัปดาห์ เพื่อให้ได้ประสิทธิภาพในระดับหนึ่งจากโมเดล collective ownership กับไมโครเซอร์วิส ท้ายที่สุดคุณจะต้องมั่นใจว่าการทำงานกับไมโครเซอร์วิสหนึ่งจะคล้ายกันมากกับการทำงานกับไมโครเซอร์วิสอื่นๆ

โดยธรรมชาติแล้ว สิ่งนี้อาจบั่นทอนประโยชน์สำคัญข้อหนึ่งของไมโครเซอร์วิส ย้อนกลับไปที่คำพูดที่เราใช้ตอนต้นของหนังสือ James Lewis เคยกล่าวว่า "ไมโครเซอร์วิสซื้อตัวเลือกให้คุณ" ด้วยโมเดล collective ownership ที่มากขึ้น คุณมักจะต้อง ลด ตัวเลือกลง เพื่อสร้างความสอดคล้องที่เข้มข้นขึ้นในสิ่งที่แต่ละทีมทำและวิธีที่ไมโครเซอร์วิสถูก implement

Collective ownership ต้องการการประสานงานในระดับสูงระหว่างบุคคลและระหว่างทีมที่บุคคลเหล่านั้นสังกัดอยู่ การประสานงานในระดับสูงนี้ส่งผลให้เกิด coupling ในระดับองค์กรที่เพิ่มขึ้น กลับไปที่บทความของ MacCormack และคณะที่กล่าวถึงในตอนต้นของบทนี้ เรามีข้อสังเกตนี้:

ในองค์กรที่มีความผูกพันแบบแน่น...แม้จะไม่ใช่ทางเลือกเชิงบริหารที่ชัดเจน การออกแบบก็จะมีความผูกพันแบบแน่นมากขึ้นตามธรรมชาติ

การประสานงานที่มากขึ้นสามารถนำไปสู่ organizational coupling ที่มากขึ้น ซึ่งในทางกลับกันก็นำไปสู่การออกแบบระบบที่ coupled มากขึ้น ไมโครเซอร์วิสจะทำงานได้ดีที่สุดเมื่อสามารถยึดถือแนวคิดของ independent deployability ได้อย่างเต็มที่—และสถาปัตยกรรมแบบ tightly coupled จะเป็นสิ่งตรงข้ามกับสิ่งที่คุณต้องการ

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

At a Team Level Versus an Organizational Level (ในระดับทีมเทียบกับระดับองค์กร)

แนวคิด ของ strong และ collective ownership สามารถนำไปใช้ได้ในระดับต่างๆ ขององค์กร ภายในทีม คุณอยากให้ทุกคนเข้าใจตรงกัน สามารถร่วมมือกันได้อย่างมีประสิทธิภาพ และผลที่ตามมาคือคุณอยากให้มีระดับ collective ownership ที่สูง ตัวอย่างเช่น สิ่งนี้จะแสดงออกในรูปของสมาชิกทุกคนในทีมสามารถเปลี่ยนแปลง codebase ได้โดยตรง ทีมที่มีทักษะหลากหลาย (poly-skilled) ที่โฟกัสไปที่การส่งมอบซอฟต์แวร์ที่ผู้ใช้เห็นแบบ end-to-end จำเป็นต้องเก่งมากในเรื่อง collective ownership ในระดับองค์กร ถ้าคุณต้องการให้ทีมมีความเป็นอิสระในระดับสูง ก็สำคัญมากที่ทีมเหล่านั้นต้องมีโมเดล strong ownership ด้วย

Balancing Models (การสร้างสมดุลระหว่างโมเดล)

ท้ายที่สุดแล้ว ยิ่งคุณเอียงไปทาง collective ownership มากเท่าไร ความสอดคล้องในวิธีการทำสิ่งต่างๆ ก็ยิ่งสำคัญมากขึ้นเท่านั้น ยิ่งองค์กรของคุณเอียงไปทาง strong ownership มากเท่าไร คุณก็ยิ่งสามารถปล่อยให้เกิดการปรับให้เหมาะสมในระดับท้องถิ่นได้มากขึ้น ดังที่เห็นใน Figure 15-1 สมดุลนี้ไม่จำเป็นต้องคงที่—คุณอาจปรับเปลี่ยนมันในเวลาต่างๆ กันและตามปัจจัยต่างๆ กัน ตัวอย่างเช่น คุณอาจให้อิสระทีมอย่างเต็มที่ในการเลือกภาษาโปรแกรม แต่ยังคงกำหนดให้ต้อง deploy บน cloud platform เดียวกัน

Figure 15-1. สมดุลระหว่างความสอดคล้องระดับส่วนกลางกับการปรับให้เหมาะสมระดับท้องถิ่น

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

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