Microservices เป็นสถาปัตยกรรมสไตล์ที่ได้รับความนิยมอย่างมากในช่วงหลายปีที่ผ่านมา ในบทนี้ เราจะพาไปดูภาพรวมของคุณลักษณะสำคัญที่ทำให้สถาปัตยกรรมนี้แตกต่างจากสไตล์อื่น ทั้งในแง่โทโพโลยีและปรัชญาการออกแบบ
สถาปัตยกรรมสไตล์ส่วนใหญ่มักถูกตั้งชื่อขึ้นหลังจากที่สถาปนิกสังเกตเห็นว่ารูปแบบหนึ่ง ๆ เกิดขึ้นซ้ำ ๆ ไม่มีกลุ่มลับของสถาปนิกที่คอยกำหนดว่ากระแสใหญ่ถัดไปจะเป็นอะไร—สถาปนิกเพียงแค่ตัดสินใจไปตามการเปลี่ยนแปลงของวงการซอฟต์แวร์ และในบรรดาวิธีรับมือกับการเปลี่ยนแปลงเหล่านั้นที่พบได้บ่อยที่สุด วิธีที่ได้ผลดีที่สุดก็ค่อย ๆ กลายเป็นสถาปัตยกรรมสไตล์ที่คนอื่นนำไปเลียนแบบ
Microservices ต่างออกไปตรงที่มันถูกตั้งชื่อตั้งแต่ช่วงต้น ๆ ของการใช้งาน Martin Fowler และ James Lewis ทำให้แนวคิดนี้เป็นที่รู้จักผ่าน บล็อกโพสต์ อันโด่งดังในปี 2014 ซึ่งพวกเขาระบุและอธิบายคุณลักษณะของสถาปัตยกรรมสไตล์ใหม่นี้ไว้อย่างชัดเจน บล็อกโพสต์นั้นได้กำหนดนิยามของสถาปัตยกรรมนี้และช่วยให้สถาปนิกที่สนใจเข้าใจปรัชญาเบื้องหลังของมัน
Microservices ได้รับแรงบันดาลใจอย่างมากจากแนวคิดใน domain-driven design (DDD) ซึ่งเป็นกระบวนการออกแบบเชิงตรรกะสำหรับโปรเจกต์ซอฟต์แวร์ แนวคิดหนึ่งจาก DDD ที่ส่งอิทธิพลต่อ microservices อย่างชัดเจนคือ bounded context แนวคิดเรื่อง bounded context คือรูปแบบการลดการผูกติดกัน (decoupling) แบบหนึ่ง (ตามที่กล่าวถึงไปแล้วใน "Domain-Driven Design's Bounded Context" ใน Chapter 7 ) ซึ่งเป็นเหตุผลที่ microservices บางครั้งถูกเรียกว่าสถาปัตยกรรมแบบ "share nothing"
เมื่อนักพัฒนากำหนดโดเมนหนึ่งขึ้นมา โดเมนนั้นจะประกอบด้วยเอนทิตีและพฤติกรรมจำนวนมาก ซึ่งปรากฏอยู่ในสิ่งต่าง ๆ เช่นโค้ดและสคีมาฐานข้อมูล ตัวอย่างเช่น แอปพลิเคชันหนึ่งอาจมีโดเมนชื่อ CatalogCheckout ที่ประกอบด้วยแนวคิดอย่างรายการสินค้า ลูกค้า และการชำระเงิน ในสถาปัตยกรรมแบบ monolithic ดั้งเดิม นักพัฒนามักจะแชร์แนวคิดเหล่านี้ร่วมกัน โดยสร้างคลาสที่ใช้ซ้ำได้และเชื่อมโยงฐานข้อมูลเข้าด้วยกัน แต่ภายใน bounded context หนึ่ง ๆ ส่วนประกอบภายใน เช่น โค้ดและสคีมาข้อมูล สามารถผูกติดกันเพื่อทำงานร่วมกันได้ แต่_ไม่มีวัน_ถูกผูกติดกับสิ่งใดนอก bounded context นั้น เช่น ฐานข้อมูลหรือนิยามคลาสจาก bounded context อื่น ซึ่งทำให้แต่ละ context นิยามเฉพาะสิ่งที่ตัวเองต้องการเท่านั้น โดยไม่ต้องรองรับส่วนอื่น ๆ จำกัดการใช้ซ้ำระหว่าง bounded context ต่าง ๆ
แม้การใช้ซ้ำโดยทั่วไปจะมีประโยชน์ แต่จำกฎข้อแรกของสถาปัตยกรรมซอฟต์แวร์ได้ไหม? ทุกอย่างล้วนเป็น trade-off ข้อเสียของการใช้ซ้ำคือมันมักต้องแลกมาด้วยการเพิ่ม coupling ของระบบ ไม่ว่าจะผ่านการสืบทอด (inheritance) หรือการประกอบ (composition)
หากเป้าหมายของสถาปนิกคือระบบที่ decouple กันสูงสุด—ซึ่งเป็นเป้าหมายหลักของ microservices—สถาปนิกก็จะเลือกความซ้ำซ้อน (duplication) มากกว่าการใช้ซ้ำ โดยจำลองแนวคิดเชิงตรรกะของ bounded context ให้เป็นรูปธรรม ให้แต่ละ service มีข้อมูลของตัวเองไปด้วย