Microservices มีประโยชน์อย่างไร และจะจ่ายเงินให้กับธุรกิจของคุณหรือไม่?

แนวคิดของไมโครเซอร์วิส ซึ่งเป็นแนวทางในการออกแบบแอปพลิเคชันซอฟต์แวร์เป็นชุดของบริการขนาดเล็ก มีมาตั้งแต่ปี 2015 เป็นอย่างน้อย การให้ประโยชน์ต่างๆ เช่น ความสามารถในการปรับใช้ที่เป็นอิสระและความสามารถในการปรับขนาดของส่วนประกอบ ไมโครเซอร์วิสเป็นสิ่งที่เดือดดาลในปัจจุบัน นี่เป็นเพราะประโยชน์ของไมโครเซอร์วิสเหล่านี้แปลเป็นความเร็วการพัฒนาซอฟต์แวร์ที่เร็วขึ้นอย่างไม่น่าเชื่อ เนื่องจากผู้บริโภคเปลี่ยนความชอบและพฤติกรรมได้อย่างรวดเร็ว ผู้ใช้ไมโครเซอร์วิสจึงสามารถตามทัน พวกเขากล่าวว่าชีวิตตอนนี้ยิ่งใหญ่ มากถึง 56% ของบริษัทที่เข้าร่วมในแผนการสำรวจ IMB ล่าสุด เพื่อนำแนวทางไมโครเซอร์วิสมาใช้ในอีก 24 เดือนข้างหน้า

ผู้ใช้ปัจจุบันเกือบ 80% กล่าวว่าธุรกิจของพวกเขามีแนวโน้มที่จะเพิ่มการลงทุนในไมโครเซอร์วิส ข้อได้เปรียบของไมโครเซอร์วิสทำให้ Netflix, Amazon, eBay, Twitter และบริษัทเทคโนโลยียักษ์ใหญ่อื่นๆ ย้ายจากสถาปัตยกรรมแบบเสาหินไปเป็นไมโครเซอร์วิส แต่บริษัทของคุณควรใช้ไมโครเซอร์วิสหรือไม่? ขึ้นอยู่กับบริบทและหากไมโครเซอร์วิสมีข้อดีมากกว่าข้อเสียสำหรับแอปพลิเคชันของคุณ บล็อกนี้ให้ภาพรวมของไมโครเซอร์วิสเทียบกับแนวทางแบบเสาหิน และประโยชน์หลักห้าประการของการใช้สถาปัตยกรรมไมโครเซอร์วิส นอกจากนี้ยังแบ่งปันประสบการณ์ไมโครเซอร์วิสของ ITRex และให้คำแนะนำว่าเมื่อใดที่ธุรกิจต่างๆ ควร (ไม่) ใช้ไมโครเซอร์วิส การดำน้ำใน.

คำจำกัดความและการเปรียบเทียบไมโครเซอร์วิสกับสถาปัตยกรรมแบบเสาหิน

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

ไมโครเซอร์วิส:

• ได้รับการพัฒนาอย่างอิสระ
• ใช้ฐานข้อมูลของตนเองและอาจเขียนเป็นภาษาต่างๆ
• สื่อสารผ่าน API ด้วยโปรโตคอลขนาดเล็ก เช่น HTTP ตัวรับส่งข้อความ หรือการสตรีมเหตุการณ์ และ
• ทำหน้าที่ทางธุรกิจเฉพาะ

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

อย่างไรก็ตาม หากไม่ใช้สถาปัตยกรรมไมโครเซอร์วิส Amazon แทบจะไม่มีการพัฒนาให้เป็นหนึ่งในบริษัทที่มีมูลค่ามากที่สุดในโลก (มูลค่าตามราคาตลาดอยู่ที่ 1.694 ล้านล้านดอลลาร์ ณ เดือนธันวาคม 2564) การตัดสินใจใช้ประโยชน์จากไมโครเซอร์วิสเกิดขึ้นในช่วงต้นทศวรรษ 2000 เมื่อ Amazon เข้าใจว่าไม่สามารถปรับขนาดตามความเร็วของการเติบโตของฐานลูกค้าได้ เนื่องจากปัญหาด้านการพัฒนาและการเข้ารหัสที่ช้า

Netflix ตื่นขึ้นมาพร้อมกับประโยชน์ของสถาปัตยกรรมไมโครเซอร์วิสบนคลาวด์ในช่วงปลายทศวรรษ 2000 หลังจากที่ไม่สามารถส่งดีวีดีให้กับลูกค้าได้สองสามวันเนื่องจากฐานข้อมูลเสียหายจำนวนมาก หลังจากแบ่งแอปพลิเคชันของตนออกเป็นไมโครเซอร์วิสมากกว่า 700 แห่ง วิศวกรของ Netflix สามารถปรับใช้โค้ดได้หลายพันครั้งต่อวัน ทำให้บริษัทสามารถสตรีมเนื้อหาได้ประมาณ 250 ล้านชั่วโมงต่อวันไปยังสมาชิกมากกว่า 200 ล้านคนทั่วโลก ก่อนหน้านี้เทคโนโลยีสตาร์เหล่านี้และบริษัทอื่นๆ ใช้สถาปัตยกรรมแบบใดในช่วงก่อนใช้งานคลาวด์ พวกเขาใช้เสาหิน

สถาปัตยกรรมเสาหินคืออะไร?

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

• มี codebase เดียวสำหรับการทำงานทั้งหมด
• เป็นคู่กันแน่นและ
• ใช้ข้อมูลแบบรวมศูนย์

แอปพลิเคชันอีคอมเมิร์ซที่พัฒนาขึ้นโดยใช้วิธีการแบบเสาหินจะประกอบด้วยบริการส่วนหน้าและส่วนหลังที่เชื่อมต่อกันอย่างแน่นหนาซึ่งใช้งานเป็นหน่วยเดียว ซึ่งหมายความว่าการปรับแต่งใดๆ จะต้องมีการเปลี่ยนแปลงในฐานรหัสและแพลตฟอร์มส่วนหน้า (ดูแผนภาพด้านล่างสำหรับ การเปรียบเทียบ).

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

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

5 ประโยชน์หลักของไมโครเซอร์วิส

1. การปรับใช้อิสระ

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

2. รัศมีการระเบิดที่ต่ำกว่าของความล้มเหลว

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

3. การแยกข้อมูล

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

4. การใช้เทคโนโลยีที่เหมาะสม

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

5. ประสิทธิภาพ

แนวทางไมโครเซอร์วิสช่วยให้บริษัทต่างๆ สามารถจัดตั้งทีมข้ามสายงานขนาดเล็กโดยใช้บริการเดียวหรือชุดบริการที่สามารถทำงานได้อย่างคล่องตัว โมเดลนี้ลดจำนวนการแฮนด์ออฟเมื่อทีมหนึ่งต้องรอให้อีกทีมหนึ่งทำงานให้เสร็จ ไม่ว่าจะเป็นการปรับใช้หรือการทดสอบ ก่อนที่พวกเขาจะเริ่มงานได้ โดยไม่ต้องพึ่งพาทีมอื่น ความเร็วของการพัฒนาก็เร่งขึ้น ผู้ใช้งานกำลังรายงานข้อดีหลายประการของการใช้ไมโครเซอร์วิส ตามการสำรวจของ IMB ของผู้บริหารและนักพัฒนาด้านไอที 1,200 คน ข้อดีของไมโครเซอร์วิสที่สำคัญที่สุดที่พวกเขาสัมผัสได้ ได้แก่: 30% — ความพึงพอใจของลูกค้าสูงขึ้น 29% — ความปลอดภัยที่ดีขึ้นของข้อมูลบริษัท/ลูกค้า 29% — ใช้เวลาในการออกสู่ตลาดเร็วขึ้น 28% — ปรับปรุงประสิทธิภาพของแอพพลิเคชั่น 27% — มีความยืดหยุ่นมากขึ้นในการปรับขนาดทรัพยากรหรือ ลดลง 26% — เพิ่มประสิทธิภาพการทำงานของพนักงาน มีความท้าทายกับไมโครเซอร์วิสหรือไม่? อย่างที่พูดกันทั่วไปว่าไมโครเซอร์วิสไม่ใช่อาหารกลางวันฟรี อ่านต่อ.

ส่วนที่ไม่ดีเกี่ยวกับไมโครเซอร์วิส

1. ความซับซ้อน

ความซับซ้อนโดยธรรมชาติของไมโครเซอร์วิสเพิ่มขึ้นตามจำนวนบริการ ความซับซ้อนนี้มีหลายเท่าและเนื่องมาจากสาเหตุต่อไปนี้:

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

2. ค่าใช้จ่าย

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

3. ความเสี่ยงด้านความปลอดภัย

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

เมื่อ (ไม่) ใช้งานไมโครเซอร์วิส

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

นี่คือเคล็ดลับสำคัญของเราเมื่อไม่ใช้ไมโครเซอร์วิส:

1. หากคุณเป็นสตาร์ทอัพ ไมโครเซอร์วิสเป็นความคิดที่ไม่ดี จะดีกว่าหากเริ่มต้นด้วยแอปพลิเคชันแบบเสาหินและแบ่งเป็นส่วนประกอบที่เล็กกว่า เมื่อมันยากเกินไปสำหรับทีมพิซซ่าสองคน สิ่งที่คุณต้องการคือทำการทดลองราคาถูก แทนที่จะลงทุนเวลา แรงกาย และเงินจำนวนมากเพื่อสร้างสถาปัตยกรรมที่ซับซ้อนสำหรับผลิตภัณฑ์ซึ่งมูลค่าของลูกค้ายังไม่ได้รับการตรวจสอบ เสาหินเป็นวิธีที่สมบูรณ์แบบในการทดสอบ (และละทิ้ง) MVP เพื่อเรียนรู้อย่างรวดเร็วว่าอะไรจะสร้างคุณค่าให้กับลูกค้าของคุณ ตามที่มาร์ติน ฟาวเลอร์ กูรูด้านไมโครเซอร์วิสที่ได้รับความเชื่อถืออีกท่านหนึ่งกล่าวว่า i) เรื่องราวไมโครเซอร์วิสที่ประสบความสำเร็จเกือบทั้งหมดเริ่มต้นด้วยเสาหินที่ใหญ่เกินไปและแตกสลาย ii) เกือบทุกกรณีที่ฉันเคยได้ยินเกี่ยวกับระบบที่สร้างขึ้นเป็นระบบไมโครเซอร์วิสตั้งแต่เริ่มต้น ก็จบลงด้วยปัญหาร้ายแรง หมายเหตุ: หากโดเมนผลิตภัณฑ์ไม่แน่นอน คุณไม่ควรใช้ไมโครเซอร์วิสเช่นกันเมื่อเริ่มต้นใช้งาน อาจยังเร็วเกินไปที่จะก้าวกระโดดไปสู่การตัดสินใจด้านสถาปัตยกรรมที่ซับซ้อน และโอกาสที่แนวทางของคุณในการตั้งค่าการสื่อสารและขอบเขตจะไม่มีทางหายไปเมื่อโครงการของคุณเติบโตเต็มที่

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

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

ตกลงแล้ว แต่เมื่อใดควรใช้ไมโครเซอร์วิสเพื่อเก็บเกี่ยวผลประโยชน์?

Microservices มีเหตุผลเมื่อข้อความข้างต้นเป็นเท็จ กล่าวอีกนัยหนึ่ง:

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

ตัวอย่างที่ยุติธรรมและใช้งานได้จริงจากพอร์ตโฟลิโอ ITRex จะเป็นเครื่องมือรักษาความปลอดภัยทางไซเบอร์ภายในองค์กรที่ลูกค้าต้องการเปลี่ยนเป็นแพลตฟอร์ม Security-as-a-Service Microservices มีความเหมาะสมตามธรรมชาติสำหรับโครงการนี้ เนื่องจากสถาปัตยกรรมแบบเสาหินไม่สามารถให้ความสามารถในการปรับขนาดที่โซลูชัน SaaS จำเป็นต้องให้บริการลูกค้าที่มีจำนวนเพิ่มขึ้น หรือมีความยืดหยุ่นในการพัฒนาและนำหน้าแฮ็กเกอร์

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

และมีกระจกสำหรับออกกำลังกายที่ขับเคลื่อนด้วย AI ซึ่งติดตั้งกล้อง 3 มิติและรุ่น ML ที่มาพร้อมเซ็นเซอร์ IoT ที่ติดมากับอุปกรณ์ของผู้ใช้ องค์ประกอบหลัก รวมถึงแผงผู้ดูแลระบบ แอป Android และระบบการจัดการกฎ ได้รับการสร้างขึ้นโดยทีมต่างๆ ในขั้นตอนต่างๆ ของโปรเจ็กต์ โดยแต่ละทีมใช้โค้ดและสถาปัตยกรรมที่แตกต่างกัน เมื่อความซับซ้อนในการจัดการทั้งหมดนั้นล้นหลาม เราเข้าใจว่าเราจำเป็นต้องสร้างแบ็กเอนด์เดียวสำหรับการจัดการแบบรวมศูนย์ และเราแปลงเป็นไมโครเซอร์วิส ออกแบบโค้ดใหม่ และสร้างฐานข้อมูลใหม่ มีประโยชน์อื่นๆ ของการใช้วิธีไมโครเซอร์วิส เช่น การหลีกเลี่ยงโค้ดหรือฟังก์ชันที่ซ้ำกัน

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

Endnote

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

ยังสับสนอยู่หรือเปล่าว่าบริษัทของคุณควรล้มเพราะผลประโยชน์ของไมโครเซอร์วิส? ติดต่อกับที่ปรึกษา ITRex เราจะช่วยคุณคิดออก

เผยแพร่ครั้งแรกที่ https://itrexgroup.com เมื่อวันที่ 10 มกราคม 2022