ไมโครเซอร์วิสขจัดแนวโน้มเสาหินของสถาปัตยกรรมที่มุ่งเน้นการบริการแบบดั้งเดิมออกไป แต่องค์ประกอบบางอย่างอาจถูกมองข้ามไป
หลายๆ คนมองว่าไมโครเซอร์วิสเป็นวิวัฒนาการล่าสุดของสถาปัตยกรรมที่มุ่งเน้นการบริการ สถาปัตยกรรมที่มุ่งเน้นไมโครเซอร์วิสนั้นเป็น SOA รุ่นต่อไป ซึ่งเป็นที่ถกเถียงกันอยู่
แต่สถาปัตยกรรมทั้งสองไม่จำเป็นต้องเป็นสิ่งเดียวกัน มาร์ค ริชาร์ดส์ใน eBook ใหม่ ไมโครเซอร์วิสเทียบกับ สถาปัตยกรรมเชิงการบริการ ตามชื่อนี้ Richards วิเคราะห์กลไกเบื้องหลังปรัชญาทั้งสอง โดยสังเกตว่าไมโครเซอร์วิสสร้างขึ้นจาก SOA แต่มีบางส่วนที่ขาดหายไป
(NGINX, ผู้ให้บริการขยายขนาดแบบโอเพ่นซอร์สกำลังนำเสนอ สำเนา ของหนังสือให้ดาวน์โหลดฟรี Richards เป็นสถาปนิกซอฟต์แวร์ที่เชี่ยวชาญด้านไมโครเซอร์วิสและ SOA)
นี่คือประเด็นหลักของความแตกต่างระหว่างไมโครเซอร์วิสและ SOA แบบดั้งเดิม ตามที่ Richards ชี้ให้เห็น:
“หนึ่งในแนวคิดพื้นฐานที่ต้องจำก็คือสถาปัตยกรรมไมโครเซอร์วิสนั้นเป็น แบ่งปันให้น้อยที่สุดเท่าที่จะเป็นไปได้ รูปแบบสถาปัตยกรรมที่เน้นหนักไปที่แนวคิดของบริบทที่มีขอบเขต ในขณะที่ SOA คือ แบ่งปันให้มากที่สุด รูปแบบสถาปัตยกรรมที่เน้นหนักไปที่นามธรรมและการนำฟังก์ชันทางธุรกิจกลับมาใช้ใหม่"
ดังที่เราทุกคนทราบกันดีว่า SOA ได้รับส่วนแบ่งพอสมควรในช่วงไม่กี่ปีที่ผ่านมา ซึ่งมักถูกมองว่าเป็นโครงการขนาดใหญ่ด้านเทคโนที่ให้ผลตอบแทนอันล้ำค่าแก่ธุรกิจเพียงเล็กน้อย ในมุมมองนี้ SOA เองก็ถูกมองว่าบวมและเป็นเสาหิน ซึ่งเป็นคุณสมบัติเดียวกันกับแอปพลิเคชันที่ตั้งใจจะเปลี่ยน
ไมโครเซอร์วิสมีความละเอียดมากกว่าและมีเสาหินน้อยกว่า SOA แบบเดิม มีน้ำหนักเบากว่าและนำไปใช้ได้เร็วกว่า และไม่ขึ้นอยู่กับข้อกำหนดที่เป็นทางการ เคลื่อนไหวช้า และขับเคลื่อนโดยอุตสาหกรรม แต่ถูกสร้างขึ้นผ่าน API และ HTTP แทน
อย่างไรก็ตาม ตามที่ Richards อธิบาย ไมโครเซอร์วิส "ขาดความสามารถหลักบางประการที่ SOA มอบให้" สิ่งสำคัญคือ ยิ่งโครงสร้างพื้นฐานมีขนาดใหญ่เท่าใด SOA ก็จะยิ่งเหมาะสมมากขึ้นเท่านั้น เขาสรุปบางประเด็นที่ SOA แบบดั้งเดิมเต็มรูปแบบอาจให้บริการแอปพลิเคชันได้ดีกว่า:
การแยกส่วนสัญญา: การแยกส่วนสัญญาช่วยให้บริการและผู้บริโภคบริการสามารถพัฒนาแยกจากกัน แต่ยังคงรักษาสัญญาไว้ได้ "สิ่งต่างๆ มีแนวโน้มที่จะซับซ้อนขึ้นเล็กน้อยเมื่อข้อมูลที่ผู้ใช้บริการส่งไปแตกต่างจากข้อมูลที่คาดหวังจากบริการที่เกี่ยวข้อง" Richards กล่าว SOA เก็บข้อมูลให้สอดคล้องกัน “สถาปัตยกรรมไมโครเซอร์วิสไม่รองรับการแยกสัญญา ในขณะที่การแยกสัญญาเป็นหนึ่งในความสามารถหลักที่นำเสนอภายใน SOA” Richards กล่าว "หากคุณต้องการนามธรรมระดับนี้ในสถาปัตยกรรมของคุณ คุณจะต้องพิจารณาโซลูชัน SOA แทนที่จะเป็นไมโครเซอร์วิสสำหรับแอปพลิเคชันหรือระบบของคุณ"
การทำงานร่วมกันที่แตกต่างกัน: SOA เหมาะสมกว่าสำหรับการบูรณาการเข้ากับระบบและบริการที่ต่างกันหลากหลาย Richards กล่าว "รูปแบบสถาปัตยกรรมไมโครเซอร์วิสพยายามที่จะลดความซับซ้อนของรูปแบบสถาปัตยกรรมและการนำไปใช้งานที่เกี่ยวข้อง โดยลดจำนวนตัวเลือกในการรวมบริการ"
ขอบเขตการใช้งานระดับองค์กร:“SOA เหมาะอย่างยิ่งสำหรับระบบขนาดใหญ่ ซับซ้อน ทั่วทั้งองค์กร ที่ต้องการบูรณาการเข้ากับแอปพลิเคชันและบริการที่ต่างกันจำนวนมาก นอกจากนี้ยังเหมาะอย่างยิ่งสำหรับแอปพลิเคชันที่มีส่วนประกอบที่ใช้ร่วมกันจำนวนมาก โดยเฉพาะส่วนประกอบที่ใช้ร่วมกันทั่วทั้งองค์กร" ไมโครเซอร์วิสซึ่งไม่มีมิดเดิลแวร์การรับส่งข้อความนั้น "เหมาะสมกว่าสำหรับระบบบนเว็บที่มีขนาดเล็กและมีการแบ่งพาร์ติชันอย่างดีมากกว่าระบบขนาดใหญ่ ระบบทั่วทั้งองค์กร”