Microservices ได้รับความนิยมและจัดหาวิธีการใหม่ ๆ สำหรับ บริษัท เทคโนโลยีในการปรับปรุงบริการของพวกเขาสำหรับผู้ใช้แต่การเปลี่ยนไปใช้ไมโครเซิร์ตมีผลกระทบอย่างไรต่อวัฒนธรรมของทีมและขวัญกำลังใจ?CTOs นักพัฒนาและผู้จัดการโครงการควรพิจารณาประเด็นใดเมื่อใดที่ตัวเลือกทางเทคโนโลยีที่ดีที่สุดคือการย้ายไปยัง Microservices?
ด้านล่างนี้คุณจะพบคำแนะนำที่สำคัญและข้อมูลเชิงลึกจาก CTOs และผู้นำโครงการในขณะที่พวกเขาสะท้อนประสบการณ์ของพวกเขากับวัฒนธรรมของทีมและไมโครไซต์
คุณไม่สามารถสร้างไมโครเซิร์ตที่ประสบความสำเร็จได้หากปราศจากวัฒนธรรมทีมที่ประสบความสำเร็จ
เมื่อฉันทำงานกับนักพัฒนา Java มีความตึงเครียดภายในค่ายเกี่ยวกับผู้ที่ได้ทำงานกับคุณสมบัติใหม่ล่าสุดและเนื้อสัตว์ความเป็นผู้นำทางวิศวกรรมของเราได้ตัดสินใจว่าเราจะใช้ Java เพื่อสร้าง Microservices ใหม่ทั้งหมด
มีเหตุผลที่ดีสำหรับการตัดสินใจครั้งนี้ แต่อย่างที่ฉันจะอธิบายในภายหลังการตัดสินใจที่เข้มงวดเช่นนี้มาพร้อมกับผลกระทบบางอย่างการสื่อสาร“ ทำไม” ของการตัดสินใจทางเทคนิคสามารถไปไกลในการสร้างวัฒนธรรมที่ผู้คนรู้สึกรวมและได้รับการแจ้ง
เพิ่มเติมเกี่ยวกับ microservices
- Microservices Cheat Sheet
- วิธีอธิบายไมโครไซต์ให้กับซีอีโอของคุณ
- ebook ฟรี: Microservices กับสถาปัตยกรรมที่มุ่งเน้นบริการ
- หลักสูตรออนไลน์ฟรี: การพัฒนาแอพพลิเคชั่นคลาวด์ที่มีสถาปัตยกรรม Microservices
- บทความ Microservices ล่าสุด
เมื่อคุณจัดระเบียบและจัดการทีมรอบ ๆ Microservices มันเป็นเรื่องท้าทายที่จะสร้างความสมดุลระหว่างอารมณ์ขวัญกำลังใจและวัฒนธรรมโดยรวมในกรณีส่วนใหญ่ความเป็นผู้นำจำเป็นต้องสร้างความสมดุลให้กับความเสี่ยงของสมาชิกในทีมโดยใช้เทคโนโลยีใหม่กับความต้องการของลูกค้าและธุรกิจ
ภาวะที่กลืนไม่เข้าคายไม่ออกนี้และอื่น ๆ อีกมากมายเช่นนี้ทำให้ CTOs ถามคำถามตัวเองเช่น: ฉันควรให้อิสระเท่าไหร่เมื่อต้องใช้เทคโนโลยีใหม่ ๆและที่สำคัญกว่านั้นคือฉันจะจัดการวัฒนธรรมที่ครอบคลุมในค่ายของฉันได้อย่างไร
ให้โอกาสสมาชิกทุกคนในทีมเจริญเติบโต
เมื่อผู้นำด้านวิศวกรรมในตัวอย่างข้างต้นตัดสินใจว่า Java เป็นเทคโนโลยีที่ดีที่สุดที่จะใช้เมื่อสร้าง Microservices การตัดสินใจที่ดีที่สุดสำหรับ บริษัท : Java เป็นนักแสดงและผู้อาวุโสหลายคนในทีมมีความรอบรู้อย่างไรก็ตามไม่ใช่ทุกคนในทีมที่มีประสบการณ์กับ Java
ปัญหาคือทีมของเราถูกแบ่งออกเป็นสองค่าย: พวก Java และพวก JavaScriptเมื่อเวลาผ่านไปและโครงการใหม่ที่น่าตื่นเต้นเกิดขึ้นเราจะไปถึง Java เพื่อทำงานให้เสร็จอีกไม่นานความรำคาญบางอย่างในค่ายจาวาสคริปต์ก็พุ่งเข้ามา:“ ทำไมพวก Java ถึงทำงานในโครงการใหม่ที่น่าตื่นเต้นในขณะที่เราออกไปทำงานด้านหน้าของโลกนี้เช่นการใช้เครื่องมือวิเคราะห์ของบุคคลที่สาม?เราต้องการโครงการที่ยิ่งใหญ่และน่าตื่นเต้นในการทำงานด้วย!”
เช่นเดียวกับรอยแยกส่วนใหญ่มันเริ่มเล็ก แต่มันก็แย่ลงเมื่อเวลาผ่านไป
บทเรียนที่ฉันเรียนรู้จากประสบการณ์นั้นคือการคำนึงถึงความเชี่ยวชาญของทีมและเทคโนโลยีที่ได้รับความนิยมเมื่อเลือกสแต็กเทคโนโลยีที่เป็นพฤตินัยสำหรับไมโครไซต์ของคุณและเมื่อปรับระดับอิสระของทีมในการเลือกและเลือกเครื่องมือของพวกเขา
แน่นอนว่าคุณต้องการโครงสร้างบางอย่าง แต่ถ้าคุณเข้มงวดเกินไป - หรือแย่กว่านั้นคือคนตาบอดต่อความปรารถนาของสมาชิกในทีมที่จะคิดค้นด้วยเทคโนโลยีที่แตกต่างกัน - คุณอาจมีความแตกแยกของคุณเองในการจัดการ
ดังนั้นประเมินทีมของคุณอย่างใกล้ชิดและคิดแผนการที่ให้อำนาจทุกคนด้วยวิธีนี้ทุกส่วนในทีมของคุณสามารถมีส่วนร่วมในโครงการสำคัญและไม่มีใครรู้สึกว่าพวกเขาถูกทิ้งไว้บนม้านั่ง
ตัวเลือกเทคโนโลยี: ความเสถียรกับความยืดหยุ่น
สมมติว่าคุณจ้างนักพัฒนาจูเนียร์คนใหม่ที่ตื่นเต้นกับกรอบ JavaScript ใหม่ล่าสุด
เฟรมเวิร์กนั้นในขณะที่กีฬาความก้าวหน้าทางเทคนิคบางอย่างอาจไม่ได้พิสูจน์ตัวเองในสภาพแวดล้อมการผลิตและอาจไม่มีการสนับสนุนที่ยอดเยี่ยมCTOs ต้องเป็นทางเลือกที่ยากลำบาก: การเคลื่อนไหวที่กำลังใจในการทำงานของทีมหรือปฏิเสธเพื่อปกป้อง บริษัท และบรรทัดล่างและเพื่อให้โครงการมีความมั่นคงเมื่อกำหนดเวลา
คำตอบขึ้นอยู่กับปัจจัยต่าง ๆ มากมาย (ซึ่งหมายความว่าไม่มีคำตอบที่ถูกต้องเพียงอย่างเดียว)
เสรีภาพทางเทคโนโลยี
“ เราให้ทีมของเราและเรามีอิสระ 100% ในการพิจารณาทางเลือกเทคโนโลยีในที่สุดเราก็ระบุเทคโนโลยีสองหรือสามแห่งที่ไม่ควรใช้ในที่สุดเนื่องจากไม่ต้องการทำให้เรื่องราวการปรับใช้ของเราซับซ้อนขึ้น”เบนจามินเคอร์ติสผู้ร่วมก่อตั้งhoneybadger-
“ กล่าวอีกนัยหนึ่งเราพิจารณาแนะนำภาษาใหม่และแนวทางใหม่ ๆ ในสแต็กเทคโนโลยีของเราเมื่อสร้างไมโครไซต์ของเราและเราได้ปรับใช้ Microservice ที่ผลิตบนสแต็กที่แตกต่างกัน ณ จุดหนึ่ง[ในขณะที่เราทำโดยทั่วไป] ยึดติดกับเทคโนโลยีที่เรารู้เพื่อลดความซับซ้อนของ OPS Stack ของเราเรากลับมาอีกครั้งเป็นระยะเพื่อดูว่าประสิทธิภาพหรือผลประโยชน์ที่น่าเชื่อถือจะได้รับจากการใช้เทคโนโลยีใหม่ แต่จนถึงตอนนี้เรายังไม่ได้ทำการเปลี่ยนแปลง” เคอร์ติสกล่าวต่อ
เมื่อฉันพูดด้วยสตีเฟ่นบลัม, CTO ที่ที่ตีพิมพ์เขาแสดงมุมมองที่คล้ายกันต้อนรับเทคโนโลยีใด ๆ ที่ตัดมัสตาร์ด:“ เราเปิดกว้างโดยสิ้นเชิงเราต้องการที่จะก้าวไปข้างหน้าด้วยเทคโนโลยีโอเพนซอร์สใหม่ที่มีอยู่และเรามีข้อ จำกัด สองสามข้อกับทีมที่ยุติธรรมมาก: [มัน] ต้องทำงานในสภาพแวดล้อมคอนเทนเนอร์และต้องมีประสิทธิภาพ”
เสรีภาพสูงความรับผิดชอบสูง
ตรรกะซูโม่CTOคริสเตียน Beedgenและหัวหน้าสถาปนิกStefan Zierขยายในหัวข้อนี้ยอมรับว่าหากคุณจะให้อิสระแก่นักพัฒนาในการเลือกเทคโนโลยีของพวกเขามันจะต้องมาพร้อมกับความรับผิดชอบในระดับสูงที่แนบมา“ เป็นเรื่องสำคัญมากที่ [ใครก็ตามที่สร้าง] ซอฟต์แวร์ใช้ความเป็นเจ้าของอย่างเต็มที่กล่าวอีกนัยหนึ่งพวกเขาไม่เพียง แต่สร้างซอฟต์แวร์ แต่พวกเขายังเรียกใช้ซอฟต์แวร์และยังคงรับผิดชอบวงจรชีวิตทั้งหมด”
Beedgen และ Zier แนะนำให้ใช้ระบบที่มีลักษณะคล้ายกับระบบของรัฐบาลกลางโดยรักษาเสรีภาพเหล่านั้นในการตรวจสอบโดยการเพิ่มความรับผิดชอบ:“ [คุณต้องการ] วัฒนธรรมของรัฐบาลกลางจริงๆคุณต้องมีระบบที่หลายทีมอิสระสามารถมารวมกันเพื่อเป้าหมายที่ยิ่งใหญ่กว่านั่น จำกัด ความเป็นอิสระของหน่วยในระดับหนึ่งเนื่องจากพวกเขาต้องยอมรับว่าอาจมีรัฐบาลบางประเภทแต่ภายในกลุ่มเล็ก ๆ เหล่านั้นพวกเขาสามารถตัดสินใจได้มากเท่าที่พวกเขาต้องการภายในแนวทางที่กำหนดไว้ในระดับที่สูงขึ้น”
การกระจายอำนาจของรัฐบาลกลางหรืออย่างไรก็ตามคุณวางกรอบวิธีการนี้ในการจัดโครงสร้างทีมไมโครเซอบริการให้แต่ละทีมและสมาชิกในทีมแต่ละคนได้รับอิสรภาพที่พวกเขาต้องการโดยไม่ทำให้ทุกคนสามารถดึงโครงการออกจากกัน
อย่างไรก็ตามไม่ใช่ทุกคนที่เห็นด้วย
จำกัด เทคโนโลยีเพื่อทำให้สิ่งต่าง ๆ ง่ายขึ้น
ดาร์บี้เฟรย์ผู้ร่วมก่อตั้งเป็นผู้นำอย่างตรงไปตรงมาใช้วิธีการที่เข้มงวดมากขึ้นในการเลือกเทคโนโลยี
“ ใน บริษัท สุดท้ายของฉันเรามีบริการมากมายและมีทีมค่อนข้างเล็กและเป็นหนึ่งในสิ่งสำคัญที่ทำให้มันใช้งานได้โดยเฉพาะอย่างยิ่งสำหรับขนาดทีมที่เรามีคือทุกแอพนั้นเหมือนกันบริการแบ็กเอนด์ทุกครั้งเป็นแอพทับทิม” เขาอธิบาย
Frey อธิบายว่าสิ่งนี้ช่วยให้ชีวิตสมาชิกในทีมของเขาง่ายขึ้น:“ [บริการทุกอย่างมี] กรอบการทดสอบเดียวกันแบ็กเอนด์ฐานข้อมูลเดียวกันเครื่องมือการประมวลผลงานพื้นหลังเดียวกันและอื่น ๆทุกอย่างเหมือนกัน
“ นั่นหมายความว่าเมื่อวิศวกรจะข้ามไปมาระหว่างแอพพวกเขาไม่ต้องเรียนรู้รูปแบบใหม่หรือเรียนรู้ภาษาที่แตกต่างกันในแต่ละครั้ง” เฟรย์กล่าวต่อ“ ดังนั้นเราจึงตระหนักดีและเข้มงวดมากเกี่ยวกับการรักษาความสามัคคีนั้น”
ในขณะที่เฟรย์มีความเห็นอกเห็นใจต่อนักพัฒนาที่ต้องการแนะนำภาษาใหม่ยอมรับว่าเขา“ รักความคิดในการลองสิ่งใหม่ ๆ ” เขารู้สึกว่าข้อเสียยังคงมีมากกว่าข้อดี
“ การมีสถาปัตยกรรม Polyglot สามารถเพิ่มค่าใช้จ่ายในการพัฒนาและบำรุงรักษาหากมันเหมือนกันทั้งหมดคุณสามารถมุ่งเน้นไปที่คุณค่าทางธุรกิจและคุณสมบัติทางธุรกิจและไม่จำเป็นต้องเงียบมากในการทำงานของบริการของคุณฉันไม่คิดว่าทุกคนชอบการตัดสินใจนั้น แต่ในตอนท้ายของวันเมื่อพวกเขาต้องแก้ไขบางอย่างในช่วงสุดสัปดาห์หรือกลางดึกพวกเขาชื่นชมมัน” เฟรย์กล่าว
องค์กรกลางหรือกระจายอำนาจ
วิธีการที่ทีมของคุณมีโครงสร้างจะส่งผลกระทบต่อวัฒนธรรมวิศวกรรม Microservices ของคุณไม่ว่าจะดีขึ้นหรือแย่ลง
ตัวอย่างเช่นเป็นเรื่องปกติที่วิศวกรซอฟต์แวร์จะเขียนโค้ดก่อนที่จะส่งไปยังทีมปฏิบัติการซึ่งจะปรับใช้กับเซิร์ฟเวอร์แต่เมื่อสิ่งต่าง ๆ แตก (และสิ่งต่าง ๆ มักจะแตก!) ความขัดแย้งภายในเกิดขึ้น
เนื่องจากวิศวกรปฏิบัติการไม่ได้เขียนรหัสด้วยตัวเองพวกเขาไม่ค่อยเข้าใจปัญหาเมื่อเกิดขึ้นครั้งแรกเป็นผลให้พวกเขาต้องติดต่อกับผู้ที่ทำรหัส: วิศวกรซอฟต์แวร์ดังนั้นจากการเดินทางคุณจะได้รับการถ่ายทอดมิดเดิลแมนข้อความระหว่างปัญหาและทีมที่สามารถแก้ไขปัญหานั้นได้
เพื่อเพิ่มความซับซ้อนเป็นพิเศษเนื่องจากวิศวกรซอฟต์แวร์ไม่ได้เกี่ยวข้องกับการดำเนินงานพวกเขามักจะไม่สามารถชื่นชมได้อย่างเต็มที่ว่ารหัสของพวกเขามีผลต่อการทำงานโดยรวมของแพลตฟอร์มโดยรวมพวกเขาเรียนรู้ปัญหาเฉพาะเมื่อวิศวกรปฏิบัติการบ่นเกี่ยวกับพวกเขา
อย่างที่คุณเห็นนี่คือความสัมพันธ์ที่กำหนดไว้สำหรับความขัดแย้งอย่างต่อเนื่อง
การนำทางความขัดแย้ง
วิธีหนึ่งในการโจมตีปัญหานี้คือการติดตามผู้นำของ Netflix และ Amazon ซึ่งทั้งคู่ชอบการปกครองแบบกระจายอำนาจผู้นำความคิดการพัฒนาซอฟต์แวร์ James Lewis และ Martin Fowler รู้สึกว่าการกำกับดูแลการกระจายอำนาจเป็นวิธีที่จะไปเมื่อมันมาถึงองค์กรทีม Microservice ตามที่พวกเขาอธิบายใน Aโพสต์บล็อก-
“ หนึ่งในผลที่ตามมาของการกำกับดูแลส่วนกลางคือแนวโน้มที่จะสร้างมาตรฐานบนแพลตฟอร์มเทคโนโลยีเดียวประสบการณ์แสดงให้เห็นว่าวิธีการนี้เป็นวิธีการที่ไม่ จำกัด - ไม่ใช่ทุกปัญหาที่เป็นเล็บและไม่ใช่ทุกวิธีแก้ปัญหาที่เป็นค้อน” บทความอ่าน“ บางที apogee ของการปกครองแบบกระจายอำนาจคือ ‘build it run it‘ ethos ที่ได้รับความนิยมจาก Amazonทีมมีหน้าที่รับผิดชอบทุกด้านของซอฟต์แวร์ที่พวกเขาสร้างรวมถึงการใช้งานซอฟต์แวร์ 24/7”
Netflix, Lewis และ Fowler Write เป็นอีก บริษัท หนึ่งที่ผลักดันความรับผิดชอบในระดับที่สูงขึ้นในทีมพัฒนาพวกเขาตั้งสมมติฐานว่าเพราะพวกเขาจะต้องรับผิดชอบและเรียกร้องให้มีอะไรผิดพลาดในภายหลังบรรทัดจะมีการดูแลมากขึ้นในระหว่างขั้นตอนการพัฒนาและการทดสอบเพื่อให้แน่ใจว่าแต่ละ microservice อยู่ในรูปของเรือ
“ ความคิดเหล่านี้อยู่ห่างไกลจากรูปแบบการกำกับดูแลแบบรวมศูนย์แบบดั้งเดิมเท่าที่จะเป็นไปได้” พวกเขาสรุป
ใครในวันหยุดสุดสัปดาห์ Pagerduty?
เมื่อพิจารณาถึงวัฒนธรรมส่วนกลางหรือการกระจายอำนาจลองคิดดูว่ามันส่งผลกระทบต่อสมาชิกในทีมของคุณอย่างไรเมื่อปัญหาเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ในเวลาที่ไม่เหมาะสมระบบการกระจายอำนาจแสดงให้เห็นว่าแต่ละทีมที่มีการกระจายอำนาจจะต้องรับผิดชอบต่อบริการหนึ่งหรือชุดหนึ่งชุดแต่นั่นก็สร้างปัญหา: ไซโล
นั่นเป็นเหตุผลหนึ่งว่าทำไม Frey ของ LEAD อย่างตรงไปตรงมาจึงไม่ได้เป็นผู้สนับสนุนแนวคิดเรื่องการปกครองแบบกระจายอำนาจ
“ รูปแบบของ ‘ทีมเดียวมีหน้าที่รับผิดชอบบริการเฉพาะ” เป็นสิ่งที่คุณเห็นในสถาปัตยกรรม microservice มากมายเราไม่ทำอย่างนั้นด้วยเหตุผลสองประการเหตุผลทางธุรกิจหลักคือเราต้องการทีมที่ไม่รับผิดชอบสำหรับรหัสเฉพาะ แต่สำหรับคุณสมบัติที่ต้องเผชิญกับลูกค้าทีมอาจรับผิดชอบในการประมวลผลคำสั่งซื้อดังนั้นจะต้องสัมผัสกับฐานรหัสหลายฐาน แต่ผลลัพธ์สุดท้ายสำหรับธุรกิจคือมีทีมหนึ่งที่เป็นเจ้าของสิ่งทั้งหมดจบลงจนจบดังนั้นจึงมีรอยร้าวน้อยลงสำหรับสิ่งต่าง ๆ ที่จะล้มลง "Frey อธิบาย
อีกเหตุผลหลักที่เขากล่าวต่อคือนักพัฒนาสามารถเป็นเจ้าของโครงการโดยรวมได้มากขึ้น:“ พวกเขาสามารถคิดถึง [โครงการ] แบบองค์รวมได้จริง”
Nathan Peck ผู้พัฒนาผู้สนับสนุนบริการคอนเทนเนอร์ที่ Amazon Web Servicesอธิบายปัญหานี้ในเชิงลึกมากขึ้น-ในสาระสำคัญเมื่อคุณแยกวิศวกรซอฟต์แวร์และวิศวกรปฏิบัติการคุณทำให้ชีวิตของคุณยากขึ้นเมื่อใดก็ตามที่มีปัญหาเกิดขึ้นกับรหัส - ซึ่งเป็นข่าวร้ายสำหรับผู้ใช้เช่นกัน
แต่การกระจายอำนาจจำเป็นต้องนำไปสู่การแยกและ siloization หรือไม่?
Peck อธิบายว่าทางออกของเขาอยู่ในDevopsแบบจำลองที่มุ่งเน้นการกระชับข้อเสนอแนะโดยนำทีมทั้งสองเข้าด้วยกันเข้าด้วยกันมากขึ้นเสริมสร้างวัฒนธรรมของทีมและการสื่อสารในกระบวนการPeck อธิบายสิ่งนี้ว่าเป็นวิธีการ“ คุณสร้างมันคุณเรียกใช้”
อย่างไรก็ตามนั่นไม่ได้หมายความว่าทีมจะต้องเงียบหรือห่างไกลจากการเข้าร่วมในงานบางอย่างเนื่องจาก Frey แนะนำอาจเกิดขึ้น
“ หนึ่งในวิธีการที่ทรงพลังที่สุดในการกำกับดูแลการกระจายอำนาจคือการสร้างความคิดของ“ Devops” Peck เขียน“ [ด้วยวิธีการนี้] วิศวกรมีส่วนร่วมในทุกส่วนของไปป์ไลน์ซอฟต์แวร์: การเขียนโค้ดการสร้างมันปรับใช้ผลิตภัณฑ์ที่ได้และการดำเนินงานและตรวจสอบในการผลิตวิธีการ Devops นั้นตรงกันข้ามกับรุ่นเก่าของการแยกทีมพัฒนาจากทีมปฏิบัติการโดยให้ทีมพัฒนาจัดส่งรหัส "เหนือกำแพง" ไปยังทีมปฏิบัติการที่รับผิดชอบในการดำเนินการและรักษาไว้ "
Devops เช่นเดียวกับคลังอาวุธCTOIsaac Mosqueraอธิบายว่าเป็นกรอบการพัฒนาซอฟต์แวร์ที่คล่องตัวและวัฒนธรรมที่ได้รับแรงฉุดขอบคุณ - ดีทุกอย่างที่ Peck กล่าว
ที่น่าสนใจ Mosquera รู้สึกว่าวิธีการนี้จริง ๆ แล้วบินผ่านหน้าของกฎหมายของ Conway-
"องค์กรที่ออกแบบระบบ ... ถูก จำกัด ให้สร้างการออกแบบซึ่งเป็นสำเนาของโครงสร้างการสื่อสารขององค์กรเหล่านี้"- M. Conway
“ แทนที่จะออกแบบการออกแบบซอฟต์แวร์การขับขี่ตอนนี้สถาปัตยกรรมซอฟต์แวร์ขับเคลื่อนการสื่อสารทีมงานไม่เพียง แต่ทำงานและจัดระเบียบแตกต่างกัน แต่ต้องใช้ชุดเครื่องมือและกระบวนการใหม่เพื่อสนับสนุนสถาปัตยกรรมประเภทนี้เช่น, Devops,” Mosquera อธิบาย
Chris McFaddenรองประธานฝ่ายวิศวกรรมที่จุดประกายเสนอตัวอย่างที่น่าสนใจที่อาจคุ้มค่าต่อไปนี้ที่ SparkPost คุณจะพบการกำกับดูแลที่มีการกระจายอำนาจ-แต่คุณจะไม่พบวัฒนธรรมหนึ่งทีมต่อบริการ
“ ทีมที่กำลังพัฒนาไมโครเซิร์ตเหล่านี้เริ่มต้นจากการเป็นทีมเดียว แต่ตอนนี้พวกเขาแบ่งออกเป็นสามทีมภายใต้กลุ่มใหญ่เดียวกันแต่ละทีมมีความรับผิดชอบในระดับหนึ่งรอบโดเมนและความเชี่ยวชาญบางอย่าง แต่การเป็นเจ้าของบริการเหล่านี้ไม่ได้ จำกัด อยู่ที่หนึ่งในทีมใด ๆ เหล่านี้” McFadden อธิบาย
วิธีการนี้ McFadden ยังคงดำเนินต่อไปอนุญาตให้ทีมใด ๆ ทำงานกับอะไรก็ได้ตั้งแต่คุณสมบัติใหม่ไปจนถึงการแก้ไขข้อผิดพลาดไปจนถึงปัญหาการผลิตที่เกี่ยวข้องกับบริการใด ๆ เหล่านั้นมีความยืดหยุ่นทั้งหมดและไม่ใช่ไซโลในสายตา
“ มันช่วยให้ [ทีมเป็น] มีความยืดหยุ่นมากขึ้นทั้งในแง่ของการพัฒนาผลิตภัณฑ์ใหม่เช่นกันเพียงเพราะคุณไม่ได้ถูก จำกัด มากเกินไปและนั่นก็ขึ้นอยู่กับขนาดของเราในฐานะ บริษัท และเป็นทีมวิศวกรรมเราต้องรักษาความยืดหยุ่นไว้จริงๆ” เขากล่าว
อย่างไรก็ตามขนาดอาจมีความสำคัญที่นี่McFadden ยอมรับว่าถ้า SparkPost มีขนาดใหญ่กว่ามาก“ จากนั้นมันก็สมเหตุสมผลกว่าที่จะมีทีมงานที่ใหญ่กว่าเป็นหนึ่งในไมโครไซต์เหล่านั้น”
“ [มัน] ดีกว่าฉันคิดว่าการมีความรับผิดชอบในวงกว้างมากขึ้นสำหรับบริการเหล่านี้และทำให้คุณมีความยืดหยุ่นมากขึ้นอย่างน้อยก็ใช้ได้ผลสำหรับเราในเวลานี้ที่เราอยู่ในฐานะองค์กร” เขากล่าว
วัฒนธรรมทางวิศวกรรมของไมโครเซิร์ตที่ประสบความสำเร็จเป็นการกระทำที่สมดุล
เมื่อพูดถึงเทคโนโลยีเสรีภาพ - ด้วยความรับผิดชอบ - ดูเป็นเส้นทางที่คุ้มค่าที่สุดสมาชิกในทีมที่มีการตั้งค่าทางเทคโนโลยีที่แตกต่างกันจะมาและไปในขณะที่ความท้าทายใหม่อาจทำให้คุณต้องใช้เทคโนโลยีที่เคยให้บริการคุณเป็นอย่างดีการพัฒนาซอฟต์แวร์อยู่ในฟลักซ์อย่างต่อเนื่องดังนั้นคุณจะต้องปรับสมดุลความต้องการของทีมอย่างต่อเนื่องคืออุปกรณ์ใหม่เทคโนโลยีและลูกค้าที่เกิดขึ้น
สำหรับการจัดโครงสร้างทีมของคุณวิธีการกระจายอำนาจ แต่ยังไม่ได้ใช้ประโยชน์ซึ่งใช้ประโยชน์จาก DevOps และปลูกฝัง“ คุณสร้างมันขึ้นมา” ความคิดดูเหมือนว่าจะเป็นที่นิยมแม้ว่าจะมีโรงเรียนแห่งความคิดอื่น ๆ ก็ตามตามปกติคุณจะต้องทดลองเพื่อดูว่าอะไรที่เหมาะสมกับทีมของคุณที่สุด
นี่คือการสรุปอย่างรวดเร็วเกี่ยวกับวิธีการให้แน่ใจว่าวัฒนธรรมของทีมของคุณเข้ากันได้ดีกับสถาปัตยกรรม Microservices:
ยั่งยืน แต่ยืดหยุ่น: สร้างสมดุลระหว่างความยั่งยืนโดยไม่ลืมความยืดหยุ่นและความต้องการให้ทีมของคุณเป็นนวัตกรรมเมื่อมีโอกาสที่เหมาะสมมาถึงอย่างไรก็ตามมีความคิดเห็นที่แตกต่างกันอย่างชัดเจนว่าคุณควรบรรลุความสมดุลนั้นอย่างไร
ให้โอกาสที่เท่าเทียมกัน: อย่าชอบทีมของคุณในอีกส่วนหนึ่งหากคุณกำลังจะกำหนดข้อ จำกัด ตรวจสอบให้แน่ใจว่าจะไม่ทำให้สมาชิกในทีมแปลกแยกออกจากการเดินทางลองคิดดูว่าแผนงานผลิตภัณฑ์ของคุณมีรูปร่างและคาดการณ์ว่าจะสร้างอย่างไรและใครจะไปทำงาน
จัดโครงสร้างทีมของคุณให้มีความคล่องตัว แต่ยังรับผิดชอบ: การกำกับดูแลการกระจายอำนาจและการพัฒนาความคล่องตัวเป็นรสชาติของวันด้วยเหตุผลที่ดี แต่อย่าลืมติดตั้งความรับผิดชอบในแต่ละทีม
