เมื่อเร็วๆ นี้ ทีมวิศวกรที่อยู่เบื้องหลัง Prime Video ได้ประกาศเปลี่ยนจากไมโครเซอร์วิสและสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ไปใช้แนวทางแบบเสาหินมากขึ้น ข่าวนี้ทำให้เกิดเสียงโห่ร้องมากมายบนโซเชียลมีเดีย หลายๆ คนต่างชื่นชมยินดีและประกาศถึง “ความตายของยุคไมโครเซอร์วิส” บางคนใช้ข่าวนี้เพื่อแสดงความไม่พอใจที่เพิ่มมากขึ้นต่อไมโครเซอร์วิสและความซับซ้อนในการพัฒนาซอฟต์แวร์ที่เพิ่มมากขึ้น แล้วมันอาจเป็นจุดสิ้นสุดของยุคจริงหรือ?
ไมโครเซอร์วิส และส่วนใหญ่แล้ว สถาปัตยกรรมเชิงบริการไม่ใช่สิ่งใหม่ล่าสุด แนวคิดของสถาปัตยกรรมเชิงบริการคือการออกแบบแอปพลิเคชันตามฟังก์ชันทางธุรกิจมากกว่าฟังก์ชันทางเทคนิค แทนที่จะมีแอปพลิเคชันแบบ 3 ปัจจัยที่ซอฟต์แวร์ของคุณจะถูกแบ่งออกเป็นเลเยอร์ส่วนต่อประสานกับผู้ใช้ เลเยอร์ตรรกะทางธุรกิจ และเลเยอร์ฐานข้อมูล คุณจะรวมเลเยอร์เหล่านั้นเข้าด้วยกัน ขอบเขตใหม่ของแอปพลิเคชันของคุณจะเป็นฟังก์ชันทางธุรกิจของแอปพลิเคชัน สถาปัตยกรรมใหม่นี้มาพร้อมกับอิสระในการสร้างทีมข้ามสายงานซึ่งจะช่วยลดคลังความรู้และลดการพึ่งพาข้ามทีมในขณะที่สร้างคุณสมบัติใหม่
หลังจากนั้น การปฏิวัติก็ได้เขย่าอุตสาหกรรมไอที Cloud Computing เริ่มกลายเป็นกระแสหลัก โดยนำเสนอการประมวลผลราคาถูกและเข้าถึงได้เพียงปลายนิ้วสัมผัส พร้อมคำมั่นสัญญาว่าจะขยายขีดความสามารถได้ไม่จำกัดและมีความพร้อมใช้งานสูง ใครก็ตามที่มีทักษะด้านไอทีเพียงเล็กน้อยหรือไม่มีเลยก็สามารถปรับใช้แอปพลิเคชันของตนกับแพลตฟอร์มคลาวด์ได้ภายในเวลาเพียงไม่กี่วินาทีเพื่อให้โลกได้เห็น
ไมโครเซอร์วิสและคลาวด์เป็นคู่กันที่เกิดขึ้นในสวรรค์ เราสามารถขยายแนวคิดของสถาปัตยกรรมเชิงบริการไปสู่ฟังก์ชันการทำงานที่เชื่อมโยงกับสิ่งประดิษฐ์ที่ปรับใช้ได้อย่างอิสระ ต้องขอบคุณความสามารถในการปรับขนาดจำนวนมหาศาลของแพลตฟอร์มคลาวด์ ทีมวิศวกรสามารถปรับขนาดได้จำนวนมากและทำงานอย่างอิสระในบริการของตนเอง บริการเหล่านั้นสามารถนำไปใช้เป็นหน่วยประมวลผลอิสระโดยไม่จำเป็นต้องสอดคล้องกับทีมอื่น คำสัญญาดังกล่าวนำมาซึ่งความหวังอย่างมากในอุตสาหกรรม โดยเฉพาะอย่างยิ่งสำหรับบริษัทที่ติดอยู่กับหนี้ทางเทคนิคจำนวนที่ไม่สามารถจัดการได้ แต่ด้วยความหวังก็เกิดกระแสฮือฮาขึ้นมา
หากมีสิ่งหนึ่งที่โซเชียลมีเดียเป็นเลิศ นั่นก็คือการสร้างความกลัวที่จะพลาด การพัฒนาซอฟต์แวร์ก็ไม่มีข้อยกเว้นสำหรับกฎนี้ มีกระแสใหม่ๆ เกิดขึ้นอย่างต่อเนื่อง ไม่ว่าจะเป็นกรอบการทำงานหรือเครื่องมือใหม่ สื่อเหล่านั้นจะทำให้คุณคิดว่าคุณจะถูกทิ้งไว้ข้างหลังหากคุณไม่กระโดดขึ้นรถไฟ จากเรื่องราวความสำเร็จบางเรื่อง ไมโครเซอร์วิสได้กลายเป็นหนึ่งในกระแสนิยมเหล่านั้น สำหรับนักพัฒนา นี่คือโอกาสในการทำงานกับเทคโนโลยีล้ำสมัยและเป็นส่วนหนึ่งของการเปลี่ยนแปลง สำหรับบริษัทต่างๆ มันเป็นโอกาสในการแก้ไขคอขวดในการพัฒนา ลดหนี้ด้านเทคนิค และดึงดูดผู้มีความสามารถหน้าใหม่ แต่หลายคนกลับลืมบางสิ่งที่เป็นพื้นฐานไประหว่างทาง ไมโครเซอร์วิสและสถาปัตยกรรมเชิงบริการเป็นเพียงต้นแบบหนึ่งในบรรดาสถาปัตยกรรมอื่นๆ อีกมากมาย ที่สำคัญกว่านั้นคือในสถาปัตยกรรมซอฟต์แวร์ ไม่มีโซลูชันเดียวที่เหมาะกับทุกปัญหา และสิ่งนี้นำไปสู่ปัญหาสองประการ
ประการแรก บริษัทบางแห่งที่ไม่ต้องการไมโครเซอร์วิส (หรืออาจพึงพอใจกับไมโครเซอร์วิสหลอก) กำลังใช้เวลาและเงินด้านวิศวกรรมจำนวนนับไม่ถ้วนในการสร้างสถาปัตยกรรมไมโครเซอร์วิสที่ซับซ้อน แทนที่จะมุ่งเน้นไปที่ธุรกิจหลักของตน ฉันเคยทำงานเป็นการส่วนตัวในบริษัทดังกล่าว เนื่องจากไม่น่าจะเห็นความต้องการในการขยายขนาดหรือการบำรุงรักษาเพิ่มขึ้นอย่างกะทันหัน แต่เราใช้เวลาหลายเดือน (และเพิ่มค่าบริการ AWS) ในการสร้างโซลูชันที่ซับซ้อนซึ่งอาจจำเป็นหรือไม่จำเป็นในวันหนึ่ง และนั่นอาจเป็นการเรียกใช้เมธอดง่ายๆ ควบคู่กับกลไกการแจ้งเตือนขั้นพื้นฐานในตอนแรก
ปัญหานี้อาจนำไปสู่ความคับข้องใจในด้านธุรกิจ เนื่องจากความต้องการทางธุรกิจอาจล่าช้าได้ เพื่อประโยชน์ในการวางแผนสำหรับความต้องการด้านความสามารถในการขยายขนาด (ที่เป็นไปได้) เหนือสิ่งอื่นใด นักพัฒนาบางคนอาจรู้สึกหงุดหงิดเพราะพวกเขาอาจใช้เวลาไปกับงานที่จับต้องได้ เช่น การสร้างคุณสมบัติใหม่ๆ แทนที่จะเป็นงานเชิงนามธรรม เช่น การออกแบบระบบไมโครเซอร์วิสที่ทนทานต่อข้อผิดพลาดและปรับขนาดได้
ปัญหาที่สองคือบางบริษัทที่อาจต้องการไมโครเซอร์วิสเททรัพยากรทั้งหมดของตนลงในสถาปัตยกรรมและการปรับโครงสร้างซอฟต์แวร์ที่สมบูรณ์ โดยหวังว่าจะแก้ไขปัญหาทั้งหมดในคราวเดียว น่าเสียดายที่โครงการดังกล่าวมักจะจบลงด้วยความล้มเหลว ฉันเคยทำงานในโครงการดังกล่าวซึ่งมีการสร้างองค์กร GitHub ใหม่พร้อมที่เก็บหลายร้อยแห่งในคราวเดียว โดยปกติโครงการเหล่านี้จะใช้เวลาหลายปีกว่าจะบรรลุผลและเกี่ยวข้องกับผู้จัดการโครงการ PO และวิศวกรหลายร้อยคน ผู้จัดการที่มักจะมีภาพรวมในใจมักจะเข้ามาและจากไป การพึ่งพามักถูกสร้างขึ้นในระหว่างการพัฒนา และความตึงเครียดระหว่างทีมก็เป็นเรื่องปกติ วิศวกรมักจะทำงานกับซอฟต์แวร์ที่มีขนาดเล็กมากและเป็นนามธรรมซึ่งอาจทำให้งานสูญเสียความหมายได้ โครงการต่างๆ มักล่าช้าและล่าช้าอย่างต่อเนื่อง หลายครั้งที่ผู้บริหารระดับสูงรู้สึกเบื่อหน่ายกับการขาดผลลัพธ์และดึงปลั๊กออก สุดท้ายก็ไม่มีใครมีความสุข
ดังนั้น การใช้ไมโครเซอร์วิสยังสมเหตุสมผลอยู่หรือไม่? เราไม่ควรหาวิธีที่ง่ายกว่าในการแก้ปัญหา SDLC และคอขวดทางสถาปัตยกรรมของเราหรือ ในความคิดของฉัน การคิดว่าไมโครเซอร์วิสเป็นข้อผิดพลาดนั้นผิดพอๆ กับการคิดว่าควรใช้ทุกที่ ความจริงอยู่ระหว่างนั้น ฉันคิดว่าหลายๆ บริษัทไม่ต้องการไมโครเซอร์วิส โดยเฉพาะในช่วงเริ่มต้น มีมวลชนจำนวนมากที่ไมโครเซอร์วิสใช้งานมากเกินไป ไม่ว่าจะขึ้นอยู่กับจำนวนบริการ คุณสมบัติ ความซับซ้อน จำนวนบรรทัดของโค้ด หรือจำนวนวิศวกรที่ทำงานบนโค้ดเบส ควรจะเหลือเพียงประสบการณ์และความรู้สึกที่กล้าหาญ เป็นไปได้มากว่ามันจะเป็นปัจจัยที่รวมกันอยู่แล้ว
แต่เป็นกรณีที่การใช้ไมโครเซอร์วิสเป็นหลักฐาน ซอฟต์แวร์จำนวนมากมีการใช้งานมากเกินไปและไม่สามารถบำรุงรักษาได้ และสถาปัตยกรรมแบบโมดูลาร์อาจไม่สามารถแก้ปัญหาเฉพาะบางประการได้ ฉันเคยทำงานกับ JEE monoliths เก่าๆ ที่สร้างจากโค้ดหลายล้านบรรทัด การเปลี่ยนแปลงโค้ดใดๆ อาจทำให้การทดสอบหน่วยเสียหายได้หลายสิบครั้งและส่งผลร้ายแรง การปั่นสภาพแวดล้อมการพัฒนาอาจใช้เวลานานถึงครึ่งวัน การทดสอบยิ่งแย่ลงไปอีก ในกรณีดังกล่าว ข้อดีของการใช้ไมโครเซอร์วิสจะเห็นได้ชัดเจนและรวดเร็ว ไม่เพียงแต่ช่วยให้สามารถปรับปรุงการบำรุงรักษาและความสามารถในการปรับขยายได้เท่านั้น แต่ยังสามารถควบคู่ไปกับการเขียนโค้ดใหม่ซึ่งสามารถช่วยขจัดความซับซ้อนที่ไม่จำเป็น และในหลายกรณี โค้ดที่ไม่ทำงาน
ในกรณีเหล่านั้น และเพื่อหลีกเลี่ยงข้อผิดพลาดที่กล่าวไว้ข้างต้น วิธีที่ดีที่สุดคือการระบุส่วนของโค้ดที่สามารถแยกส่วนได้อย่างง่ายดาย การคิดในแง่ของโดเมนหรือบริการมักจะมีประโยชน์ในการสร้างแผนผังซอฟต์แวร์ของคุณและระบุส่วนต่างๆ ที่สามารถแยกออกจากเสาหินที่มีอยู่ของคุณได้ คุณมีซอฟต์แวร์แชร์วิดีโอหรือไม่? ไมโครเซอร์วิสที่จะรับผิดชอบในการอัปโหลดวิดีโอไปยังพื้นที่จัดเก็บข้อมูลที่เปิดเผยโดยตำแหน่งข้อมูล REST จะเป็นจุดเริ่มต้นที่ดี แอพหาคู่เหรอ? ไมโครเซอร์วิสที่จัดการโปรไฟล์ผู้ใช้จะมีประโยชน์ สิ่งที่สำคัญที่สุดคือคุณเริ่มต้นจากเล็กๆ น้อยๆ และทำให้มันงี่เง่าเรียบง่าย คุณไม่จำเป็นต้องมีการติดตามแบบกระจายและกลไกการเข้าคิวที่ซับซ้อนในอนาคตอันใกล้นี้ เริ่มต้นจากเล็กๆ เก็บเกี่ยวผลประโยชน์ และทำซ้ำ ด้วยไมโครเซอร์วิส ผลประโยชน์จะอยู่ที่การเดินทางพอๆ กับที่จุดหมายปลายทาง
