สวัสดีฮับ! ฉันนำเสนอให้คุณสนใจ การแปลบทความของผู้เขียน .
ในช่วงเวลาที่โลกไอทีค่อยๆ เคลื่อนไปสู่ไมโครเซอร์วิสและเครื่องมือต่างๆ เช่น Kubernetes มีเพียงปัญหาเดียวเท่านั้นที่เริ่มสังเกตเห็นได้ชัดเจนมากขึ้นเรื่อยๆ ปัญหานี้ - เวอร์ชันไมโครเซอร์วิส อย่างไรก็ตาม วงการไอทีเชื่อว่าสถานการณ์ปัจจุบันดีขึ้นกว่ามาก เทคโนโลยีรุ่นก่อนหน้า อย่างไรก็ตาม การกำหนดเวอร์ชันไมโครเซอร์วิสเป็นปัญหาที่ซับซ้อนมาก หลักฐานประการหนึ่งเกี่ยวกับเรื่องนี้อาจเป็นบทความเช่น .
หากคุณยังคงไม่เข้าใจปัญหาโดยการอ่านข้อความนี้ ให้ฉันอธิบาย สมมติว่าผลิตภัณฑ์ของคุณประกอบด้วยไมโครเซอร์วิส 10 รายการ ตอนนี้ สมมติว่ามีการเปิดตัวเวอร์ชันใหม่ 1 เวอร์ชันสำหรับไมโครเซอร์วิสเหล่านี้แต่ละรายการ มีเพียง 1 เวอร์ชัน - ฉันหวังว่าเราทุกคนจะเห็นพ้องกันว่านี่เป็นข้อเท็จจริงที่ไม่สำคัญและไม่มีนัยสำคัญ อย่างไรก็ตาม มาดูผลิตภัณฑ์ของเรากันอีกครั้ง ด้วยส่วนประกอบแต่ละเวอร์ชันใหม่เพียงเวอร์ชันเดียว ขณะนี้เรามีวิธีการเรียงสับเปลี่ยน 2^10 - หรือ 1024 วิธีในการประกอบผลิตภัณฑ์ของเรา
หากยังมีความเข้าใจผิดอยู่ ผมขอแจกแจงคณิตนะครับ ดังนั้นเราจึงมีไมโครเซอร์วิส 10 รายการ โดยแต่ละรายการจะได้รับการอัปเดตหนึ่งครั้ง นั่นคือเราได้รับ 2 เวอร์ชันที่เป็นไปได้สำหรับแต่ละไมโครเซอร์วิส (ทั้งเก่าหรือใหม่) ตอนนี้ สำหรับแต่ละส่วนประกอบของผลิตภัณฑ์ เราสามารถใช้เวอร์ชันใดเวอร์ชันหนึ่งจากสองเวอร์ชันนี้ได้ ในทางคณิตศาสตร์ก็เหมือนกับว่าเรามีเลขฐานสอง 10 หลัก ตัวอย่างเช่น สมมติว่า 1 เป็นเวอร์ชันใหม่และ 0 เป็นเวอร์ชันเก่า ดังนั้นการเรียงสับเปลี่ยนที่เป็นไปได้รายการหนึ่งสามารถแสดงเป็น 1001000000 โดยที่คอมโพเนนต์ที่ 1 และ 4 ได้รับการอัปเดต และส่วนประกอบอื่นๆ ทั้งหมดไม่มีการอัปเดต จากคณิตศาสตร์ เรารู้ว่าเลขฐานสอง 10 หลักสามารถมีค่าได้ 2^10 หรือ 1024 ค่า นั่นคือเราได้ยืนยันขนาดของจำนวนที่เรากำลังเผชิญอยู่
เรามาให้เหตุผลต่อไปว่าจะเกิดอะไรขึ้นหากเรามีไมโครเซอร์วิส 100 รายการ และแต่ละเวอร์ชันมี 10 เวอร์ชันที่เป็นไปได้ สถานการณ์ทั้งหมดค่อนข้างไม่เป็นที่พอใจ - ตอนนี้เรามีการเรียงสับเปลี่ยน 10^100 ครั้ง - ซึ่งเป็นจำนวนมาก อย่างไรก็ตาม ฉันชอบที่จะติดป้ายกำกับสถานการณ์นี้ด้วยวิธีนี้ เพราะตอนนี้เราไม่ได้ซ่อนอยู่หลังคำเช่น "kubernetes" อีกต่อไป แต่หันหน้าไปทางปัญหาตามที่เป็นอยู่
ทำไมฉันถึงหลงใหลกับปัญหานี้มาก? ส่วนหนึ่งเป็นเพราะเมื่อก่อนเคยทำงานในโลกของ NLP และ AI เราได้พูดคุยถึงปัญหาการระเบิดแบบผสมผสานกันมากเมื่อประมาณ 5-6 ปีที่แล้ว แทนที่จะเป็นเวอร์ชันเท่านั้นที่เรามีคำแต่ละคำ และแทนที่จะใช้ผลิตภัณฑ์ เรามีประโยคและย่อหน้า และแม้ว่าปัญหาของ NLP และ AI ส่วนใหญ่ยังไม่ได้รับการแก้ไข แต่ก็ต้องยอมรับว่ามีความก้าวหน้าอย่างมากในช่วงไม่กี่ปีที่ผ่านมา (ในความเห็นของผมสามารถก้าวหน้าได้оจะดีกว่านี้หากผู้คนในอุตสาหกรรมให้ความสนใจกับการเรียนรู้ของเครื่องน้อยลงเล็กน้อย และให้ความสนใจกับเทคนิคอื่นๆ มากขึ้นอีกเล็กน้อย แต่นี่เป็นเรื่องที่นอกประเด็นไปแล้ว)
กลับไปสู่โลกแห่ง DevOps และไมโครเซอร์วิส เรากำลังเผชิญกับปัญหาใหญ่หลวง โดยปลอมตัวเป็นช้างใน Kunstkamera - เพราะสิ่งที่ฉันได้ยินบ่อยๆ คือ "แค่เอา kubernetes และหางเสือ แล้วทุกอย่างจะเรียบร้อย!" แต่ไม่ ทุกอย่างจะไม่เป็นไรถ้าทุกอย่างยังเหมือนเดิม นอกจากนี้ ดูเหมือนว่าวิธีแก้ไขปัญหาเชิงวิเคราะห์สำหรับปัญหานี้จะไม่เป็นที่ยอมรับเนื่องจากมีความซับซ้อน เช่นเดียวกับใน NLP เราควรแก้ไขปัญหานี้ก่อนโดยจำกัดขอบเขตการค้นหาให้แคบลง ในกรณีนี้คือกำจัดการเรียงสับเปลี่ยนที่ล้าสมัย
สิ่งหนึ่งที่อาจช่วยได้คือสิ่งที่ฉันเขียนเมื่อปีที่แล้ว . สิ่งสำคัญที่ควรทราบคือกระบวนการ CI/CD ที่ได้รับการออกแบบมาอย่างดีช่วยลดความผันแปรได้อย่างมาก อย่างไรก็ตาม สถานการณ์ปัจจุบันของ CI/CD ยังไม่ดีพอที่จะแก้ไขปัญหาการเรียงสับเปลี่ยนโดยไม่ต้องใช้เครื่องมือเพิ่มเติมสำหรับส่วนประกอบทางบัญชีและการติดตาม
สิ่งที่เราต้องการคือระบบการทดลองในขั้นตอนการบูรณาการ ซึ่งเราสามารถกำหนดปัจจัยเสี่ยงสำหรับแต่ละส่วนประกอบได้ และยังมีกระบวนการอัตโนมัติสำหรับการอัปเดตส่วนประกอบต่างๆ และการทดสอบโดยไม่ต้องมีการแทรกแซงจากผู้ปฏิบัติงาน เพื่อดูว่าสิ่งใดใช้ได้ผลและสิ่งใดใช้ไม่ได้ผล
ระบบการทดลองดังกล่าวอาจมีลักษณะดังนี้:
- นักพัฒนาเขียนการทดสอบ (นี่เป็นขั้นตอนสำคัญ - เพราะไม่เช่นนั้นเราไม่มีเกณฑ์การประเมิน - มันเหมือนกับการติดป้ายกำกับข้อมูลในการเรียนรู้ของเครื่อง)
- แต่ละส่วนประกอบ (โครงการ) ได้รับระบบ CI ของตัวเอง - ขณะนี้กระบวนการนี้ได้รับการพัฒนาอย่างดีและปัญหาของการสร้างระบบ CI สำหรับส่วนประกอบเดียวได้รับการแก้ไขอย่างมาก
- “ระบบบูรณาการอัจฉริยะ” รวบรวมผลลัพธ์ของระบบ CI ต่างๆ และประกอบโครงการส่วนประกอบลงในผลิตภัณฑ์ขั้นสุดท้าย ดำเนินการทดสอบ และคำนวณเส้นทางที่สั้นที่สุดเพื่อให้ได้ฟังก์ชันการทำงานของผลิตภัณฑ์ที่ต้องการ โดยพิจารณาจากส่วนประกอบที่มีอยู่และปัจจัยความเสี่ยง หากไม่สามารถอัปเดตได้ ระบบนี้จะแจ้งให้นักพัฒนาทราบเกี่ยวกับส่วนประกอบที่มีอยู่และส่วนประกอบใดที่ทำให้เกิดข้อผิดพลาด เป็นอีกครั้งหนึ่งที่ระบบทดสอบมีความสำคัญอย่างยิ่ง เนื่องจากระบบบูรณาการใช้การทดสอบเป็นเกณฑ์การประเมิน
- ระบบซีดี ซึ่งรับข้อมูลจาก Smart Integration System และดำเนินการอัปเดตโดยตรง ขั้นตอนนี้สิ้นสุดวงจร
โดยสรุป ปัญหาที่ใหญ่ที่สุดประการหนึ่งสำหรับฉันในตอนนี้คือการไม่มี “ระบบบูรณาการอัจฉริยะ” ที่จะเชื่อมโยงส่วนประกอบต่างๆ เข้ากับผลิตภัณฑ์ และทำให้คุณสามารถติดตามวิธีการรวมผลิตภัณฑ์โดยรวมเข้าด้วยกันได้ ฉันจะสนใจความคิดของชุมชนเกี่ยวกับเรื่องนี้ (สปอยเลอร์ - ฉันกำลังทำโปรเจ็กต์อยู่) ซึ่งสามารถกลายเป็นระบบบูรณาการที่ชาญฉลาดได้)
สิ่งสุดท้ายที่ฉันอยากจะพูดถึงก็คือ สำหรับฉันแล้ว หินใหญ่ก้อนเดียวไม่เป็นที่ยอมรับสำหรับโครงการใดๆ แม้แต่ขนาดกลางก็ตาม สำหรับฉัน ความพยายามที่จะเร่งเวลาการใช้งานและคุณภาพของการพัฒนาโดยการกลับไปสู่รูปแบบใหญ่โตทำให้เกิดความสงสัยอย่างมาก ประการแรก เสาหินมีปัญหาที่คล้ายกันในการจัดการส่วนประกอบ - ในบรรดาไลบรารีต่าง ๆ ที่ประกอบด้วย แต่ทั้งหมดนี้ไม่ได้สังเกตเห็นได้ชัดและแสดงออกมาตามเวลาที่นักพัฒนาใช้เป็นหลัก ผลที่ตามมาของปัญหาใหญ่โตนี้ก็คือความเป็นไปไม่ได้เสมือนจริงในการเปลี่ยนแปลงโค้ด และความเร็วในการพัฒนาที่ช้ามาก
ไมโครเซอร์วิสช่วยปรับปรุงสถานการณ์ แต่แล้วสถาปัตยกรรมไมโครเซอร์วิสก็ประสบปัญหาการระเบิดแบบผสมผสานในขั้นตอนการรวมระบบ ใช่ โดยทั่วไป เราได้ย้ายปัญหาเดียวกันจากขั้นตอนการพัฒนาไปยังขั้นตอนการบูรณาการ อย่างไรก็ตาม ในความคิดของฉัน วิธีไมโครเซอร์วิสยังคงนำไปสู่ผลลัพธ์ที่ดีกว่า และทีมบรรลุผลเร็วขึ้น (อาจเป็นสาเหตุหลักมาจากการลดขนาดของหน่วยการพัฒนา - หรือ ขนาดแบทช์). อย่างไรก็ตาม การย้ายจากโมโนลิธไปสู่ไมโครเซอร์วิสยังไม่ได้นำมาซึ่งการปรับปรุงกระบวนการที่เพียงพอ - การกระจายเวอร์ชันไมโครเซอร์วิสแบบผสมผสานเป็นปัญหาใหญ่ และเรามีศักยภาพมากในการปรับปรุงสถานการณ์ในขณะที่เราแก้ไข
ที่มา: will.com