Summary (สรุป)

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

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

ผมหวังว่าบทนี้ได้ทำหน้าที่เป็นการแนะนำที่ดีสำหรับหัวข้อเหล่านี้ ต่อไป เราจะดูว่าเรากำหนดขอบเขต microservice อย่างไร โดยสำรวจหัวข้อของ structured programming และ domain-driven design ไปพร้อมกัน

1 แนวคิดนี้ถูกอธิบายไว้เป็นครั้งแรกโดย David Parnas ใน “Information Distribution Aspects of Design Methodology” , Information Processing: Proceedings of the IFIP Congress 1971 (Amsterdam: North-Holland, 1972), 1:339–44.

2 Alistair Cockburn, “Hexagonal Architecture,” January 4, 2005, https://oreil.ly/NfvTP .

3 สำหรับการแนะนำ domain-driven design อย่างละเอียด ดูที่ Domain-Driven Design โดย Eric Evans (Addison-Wesley)—หรือสำหรับภาพรวมแบบย่อ ดูที่ Domain-Driven Design Distilled โดย Vaughn Vernon (Addison-Wesley)

4 Matthew Skelton and Manuel Pais, Team Topologies (Portland, OR: IT Revolution, 2019).

5 David Heinemeier Hansson, “The Majestic Monolith,” Signal v. Noise, February 29, 2016, https://oreil.ly/WwG1C .

6 สำหรับข้อคิดเห็นที่เป็นประโยชน์เกี่ยวกับแนวคิดเบื้องหลังการใช้ modular monolith ของ Shopify แทนที่จะเป็น microservices ดูที่ “Deconstructing the Monolith” โดย Kirsten Westeinde.

7 Leslie Lamport, email message ถึง DEC SRC bulletin board เวลา 12:23:29 PDT วันที่ 28 พฤษภาคม 1987.

8 Microsoft Research ได้ทำการศึกษาในพื้นที่นี้ และผมแนะนำให้อ่านทั้งหมด แต่เป็นจุดเริ่มต้น ผมขอแนะนำ “Don’t Touch My Code! Examining the Effects of Ownership on Software Quality” โดย Christian Bird et al.