Shared Microservices (ไมโครเซอร์วิสที่ใช้ร่วมกัน)

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

Too Hard to Split (แยกยากเกินไป)

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

FinanceCo ซึ่งเป็นบริษัท FinTech ที่เราเคยพบมาก่อนใน "Toward Stream-Aligned Teams" ส่วนใหญ่ใช้โมเดล strong ownership ที่มีความเป็นอิสระของทีมในระดับสูง อย่างไรก็ตาม บริษัทก็ยังมีระบบ monolithic เดิมที่ค่อยๆ ถูกแยกออกทีละน้อย แอปพลิเคชัน monolithic นั้นแทบจะถือได้ว่าเป็นของหลายทีมร่วมกัน และต้นทุนที่เพิ่มขึ้นจากการทำงานใน codebase ที่ใช้ร่วมกันนี้ก็เห็นได้ชัดเจน

Cross-Cutting Changes (การเปลี่ยนแปลงแบบตัดข้ามหลายทีม)

สิ่งที่เราพูดถึงส่วนใหญ่ในหนังสือเล่มนี้เกี่ยวกับความสัมพันธ์ระหว่างโครงสร้างองค์กรและสถาปัตยกรรม มุ่งไปที่การลดความจำเป็นในการประสานงานระหว่างทีม ส่วนใหญ่ก็คือการพยายามลดการเปลี่ยนแปลงแบบ cross-cutting ให้ได้มากที่สุดเท่าที่จะทำได้ อย่างไรก็ตาม เราต้องยอมรับว่าการเปลี่ยนแปลงแบบ cross-cutting บางอย่างอาจหลีกเลี่ยงไม่ได้

FinanceCo เจอปัญหาแบบนี้เข้าจัง ตอนที่บริษัทเริ่มต้น หนึ่งบัญชีผูกกับผู้ใช้หนึ่งคน เมื่อบริษัทเติบโตขึ้นและรับผู้ใช้ทางธุรกิจมากขึ้น (ก่อนหน้านี้เน้นไปที่ผู้บริโภคทั่วไปมากกว่า) นี่กลายเป็นข้อจำกัด บริษัทต้องการเปลี่ยนไปใช้โมเดลที่หนึ่งบัญชีกับ FinanceCo รองรับผู้ใช้ได้หลายคน นี่เป็นการเปลี่ยนแปลงพื้นฐาน เพราะจนถึงตอนนั้นสมมติฐานทั่วทั้งระบบคือหนึ่งบัญชี = ผู้ใช้หนึ่งคน

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

ด้วยการจัดโครงสร้างทีมและสถาปัตยกรรมของเราใหม่เพื่อขจัดการเปลี่ยนแปลงแบบ cross-cutting ชุดหนึ่ง เราอาจเปิดตัวเองให้เจอกับการเปลี่ยนแปลงแบบ cross-cutting ชุดอื่นที่อาจส่งผลกระทบมากกว่าเดิม นี่คือสิ่งที่เกิดขึ้นกับ FinanceCo—การจัดโครงสร้างองค์กรใหม่แบบที่จำเป็นเพื่อลดต้นทุนของฟังก์ชันการทำงานแบบ multiuser จะเพิ่มต้นทุนของการเปลี่ยนแปลงทั่วไปอื่นๆ FinanceCo เข้าใจว่าการเปลี่ยนแปลงเฉพาะนี้จะเจ็บปวดมาก แต่มันเป็นการเปลี่ยนแปลงประเภทพิเศษมากจนความเจ็บปวดนี้ยอมรับได้

Delivery Bottlenecks (คอขวดในการส่งมอบงาน)

เหตุผลสำคัญข้อหนึ่งที่ผู้คนหันไปใช้ collective ownership โดยให้ไมโครเซอร์วิสถูกใช้ร่วมกันระหว่างทีม คือเพื่อหลีกเลี่ยงคอขวดในการส่งมอบงาน จะเกิดอะไรขึ้นถ้ามี backlog ขนาดใหญ่ของการเปลี่ยนแปลงที่ต้องทำในเซอร์วิสเดียว? ลองกลับไปที่ MusicCorp และลองจินตนาการว่าเรากำลังเปิดตัวความสามารถให้ลูกค้าเห็นแนวเพลง (genre) ของแทร็กเพลงในผลิตภัณฑ์ของเรา รวมถึงเพิ่มสินค้าประเภทใหม่เอี่ยม: เสียงเรียกเข้าเพลงแบบเสมือนสำหรับโทรศัพท์มือถือ ทีมเว็บไซต์ต้องเปลี่ยนแปลงเพื่อแสดงข้อมูล genre ในขณะที่ทีมแอปมือถือทำงานเพื่อให้ผู้ใช้เรียกดู ฟังตัวอย่าง และซื้อเสียงเรียกเข้าได้ การเปลี่ยนแปลงทั้งสองอย่างต้องทำกับไมโครเซอร์วิส Catalog แต่โชคร้ายที่ครึ่งหนึ่งของทีมติดอยู่กับการวินิจฉัยปัญหาที่เกิดขึ้นใน production ในขณะที่อีกครึ่งหนึ่งลาป่วยเพราะอาหารเป็นพิษหลังจากทีมไปกินที่ฟู้ดทรัคป็อปอัพในตรอกเมื่อไม่นานมานี้

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

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

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

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