Should I Use Microservices? (ผมควรใช้ Microservices หรือไม่)

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

กระนั้น ผมอยากสรุปสถานการณ์บางอย่างที่มักเอียงผมออกห่างจาก—หรือเข้าหา—การเลือก microservices

Whom They Might Not Work For (ใครที่อาจไม่เหมาะกับ Microservices)

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

ผมเห็นสิ่งล่อใจสำหรับ startup ที่จะไปแนวทาง microservice ก่อน ด้วยเหตุผลว่า "ถ้าเราประสบความสำเร็จจริงๆ เราจะต้อง scale!" ปัญหาคือคุณไม่รู้แน่ชัดว่ามีใครอยากใช้ผลิตภัณฑ์ใหม่ของคุณหรือไม่ และแม้ว่าคุณจะประสบ ความสำเร็จมากพอที่ต้องการสถาปัตยกรรมที่ scale ได้สูง สิ่งที่คุณส่งมอบให้ผู้ใช้ในท้ายที่สุดอาจแตกต่างมาก จากสิ่งที่คุณเริ่มสร้างในตอนแรก Uber เริ่มต้นด้วยการมุ่งเน้นที่รถลีมูซีน และ Flickr แตกออกมาจากความ พยายามสร้างเกมออนไลน์แบบผู้เล่นหลายคน กระบวนการหา product market fit หมายความว่าคุณอาจจบลงด้วยผลิตภัณฑ์ ที่แตกต่างมากจากสิ่งที่คุณคิดว่าคุณจะสร้างเมื่อคุณเริ่มต้น

Startup โดยทั่วไปยังมีคนน้อยกว่าที่จะสร้างระบบ ซึ่งสร้างความท้าทายมากขึ้นเกี่ยวกับ microservices Microservices นำมาซึ่งแหล่งงานและความซับซ้อนใหม่ๆ ซึ่งอาจใช้ bandwidth อันมีค่าไป ทีมยิ่งเล็ก ต้นทุนนี้ ก็ยิ่งเด่นชัดขึ้น เมื่อทำงานกับทีมเล็กที่มีนักพัฒนาแค่หยิบมือ ผมลังเลอย่างมากที่จะแนะนำ microservices ด้วยเหตุผลนี้

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

สุดท้าย องค์กรที่สร้างซอฟต์แวร์ที่จะถูก deploy และจัดการโดยลูกค้าของพวกเขาเองอาจประสบปัญหากับ microservices อย่างที่เราได้ครอบคลุมไปแล้ว สถาปัตยกรรม microservice สามารถผลักความซับซ้อนจำนวนมากเข้าไป ในพื้นที่การ deploy และ operational หากคุณเป็นคนรันซอฟต์แวร์เอง คุณสามารถชดเชยความซับซ้อนใหม่นี้ได้ด้วย การรับเทคโนโลยีใหม่ พัฒนาทักษะใหม่ และเปลี่ยนแนวปฏิบัติในการทำงาน นี่ไม่ใช่สิ่งที่คุณคาดหวังให้ลูกค้าของ คุณทำได้ หากพวกเขาคุ้นเคยกับการรับซอฟต์แวร์ของคุณเป็น Windows installer มันจะเป็นเรื่องช็อกอย่างมากสำหรับ พวกเขาเมื่อคุณส่ง version ถัดไปของซอฟต์แวร์ของคุณและบอกว่า "แค่ใส่ 20 pod เหล่านี้ลงใน Kubernetes cluster ของคุณ!" ในความเป็นไปได้สูง พวกเขาจะไม่รู้เลยว่า pod, Kubernetes หรือ cluster คืออะไรด้วยซ้ำ

Where They Work Well (ที่ที่ Microservices เหมาะสม)

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

แอปพลิเคชัน Software as a Service (SaaS) โดยทั่วไปก็เหมาะสมกับสถาปัตยกรรม microservice เช่นกัน ผลิตภัณฑ์เหล่านี้มักถูกคาดหวังให้ทำงาน 24-7 ซึ่ง สร้างความท้าทายเมื่อพูดถึงการเปิดตัวการเปลี่ยนแปลง ความสามารถในการ release อย่างอิสระของสถาปัตยกรรม microservice เป็นข้อได้เปรียบมหาศาลในพื้นที่นี้ ยิ่งไปกว่านั้น microservice สามารถ scale ขึ้นหรือลงได้ ตามต้องการ นั่นหมายความว่าเมื่อคุณสร้าง baseline ที่สมเหตุสมผลสำหรับลักษณะภาระของระบบของคุณ คุณจะได้ ควบคุมมากขึ้นในการทำให้แน่ใจว่าคุณสามารถ scale ระบบของคุณในวิธีที่คุ้มค่าที่สุดเท่าที่จะเป็นไปได้

ธรรมชาติที่ไม่ยึดติดกับเทคโนโลยีของ microservices ทำให้แน่ใจว่าคุณสามารถได้ประโยชน์สูงสุดจาก cloud platform Public cloud vendor มอบ service และกลไกการ deploy มากมายสำหรับโค้ดของคุณ คุณสามารถจับคู่ความ ต้องการของ service เฉพาะกับ cloud service ที่จะช่วยคุณ implement มันได้ดีที่สุดได้ง่ายขึ้นมาก ตัวอย่างเช่น คุณอาจตัดสินใจ deploy service หนึ่งเป็นชุดของ function อีกตัวเป็น managed virtual machine (VM) และอีกตัว บน managed Platform as a Service (PaaS) platform

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

Microservices ยังนำเสนอประโยชน์ที่ชัดเจนสำหรับองค์กรที่มองหาการมอบ service ให้ลูกค้าของพวกเขาผ่านช่องทาง ใหม่ๆ ที่หลากหลาย ความพยายามในการทำ digital transformation จำนวนมากดูเหมือนจะเกี่ยวข้องกับการพยายามปลด ล็อกฟังก์ชันการทำงานที่ซ่อนอยู่ในระบบที่มีอยู่ ความปรารถนาคือการสร้างประสบการณ์ลูกค้าใหม่ที่สามารถรองรับ ความต้องการของผู้ใช้ผ่านกลไกการโต้ตอบใดก็ตามที่สมเหตุสมผลที่สุด

เหนือสิ่งอื่นใด สถาปัตยกรรม microservice เป็นสิ่งที่ให้ความยืดหยุ่นมากมายในขณะที่คุณยังคงพัฒนาระบบของคุณ ต่อไป ความยืดหยุ่นนั้นมีต้นทุนแน่นอน แต่หากคุณต้องการเปิดตัวเลือกไว้เกี่ยวกับการเปลี่ยนแปลงที่คุณอาจ ต้องการทำในอนาคต มันอาจเป็นราคาที่คุ้มค่าจะจ่าย