Key Concepts of Microservices (แนวคิดหลักของ Microservices)

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

Independent Deployability (ความสามารถในการ Deploy อย่างอิสระ)

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

Tip (เคล็ดลับ)

หากคุณจะเก็บอะไรไว้เพียงอย่างเดียวจากหนังสือเล่มนี้และจากแนวคิดของ microservices โดยรวม ก็ควรเป็นสิ่งนี้: ยึดถือแนวคิดของ independent deployability ของ microservice ของคุณให้แน่วแน่ สร้างนิสัยในการ deploy และ release การเปลี่ยนแปลงให้ microservice เดียวขึ้น production โดยไม่ต้อง deploy อย่างอื่นเลย จากตรงนี้ สิ่งดีๆ จะตามมาอีกมากมาย

เพื่อให้แน่ใจว่า independent deployability เกิดขึ้นได้จริง เราต้องแน่ใจว่า microservice ของเรามี loosely coupled กัน นั่นคือ เราต้องสามารถเปลี่ยนแปลง service หนึ่งได้โดยไม่ต้องเปลี่ยนแปลงอย่างอื่นเลย นั่นหมายความว่าเรา ต้องการ contract ระหว่าง service ที่ชัดเจน กำหนดไว้อย่างดี และมั่นคง ตัวเลือกในการ implement บางแบบทำให้ สิ่งนี้ยากขึ้น—การแชร์ฐานข้อมูลเป็นตัวอย่างหนึ่งที่มีปัญหาเป็นพิเศษ

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

ความต้องการ service ที่ loosely coupled และมี interface ที่มั่นคง เป็นตัวชี้นำแนวคิดของเราว่าเราจะหา ขอบเขตของ microservice ได้อย่างไรตั้งแต่แรก

Modeled Around a Business Domain (ออกแบบโมเดลตาม Business Domain)

เทคนิคอย่าง domain-driven design ช่วยให้คุณจัดโครงสร้างโค้ดให้สะท้อน domain ของโลกจริงที่ซอฟต์แวร์ทำงาน อยู่ได้ดีขึ้น 3 ด้วยสถาปัตยกรรม microservice เราใช้แนวคิดเดียวกันนี้ในการกำหนดขอบเขตของ service เมื่อเราออกแบบโมเดล service ตาม business domain เราสามารถทำให้การเปิดตัวฟังก์ชันการทำงานใหม่และการรวม microservice ในรูปแบบ ต่างๆ เพื่อส่งมอบฟังก์ชันการทำงานใหม่ให้ผู้ใช้ของเราง่ายขึ้น

การเปิดตัวฟีเจอร์ที่ต้องเปลี่ยนแปลง microservice มากกว่าหนึ่งตัวมีต้นทุนสูง คุณต้องประสานงานกันในแต่ละ service (และอาจข้ามทีมที่แยกกัน) และบริหารจัดการลำดับการ deploy version ใหม่ของ service เหล่านี้อย่าง ระมัดระวัง นั่นใช้ความพยายามมากกว่าการทำการเปลี่ยนแปลงเดียวกันภายใน service เดียว (หรือภายใน monolith ก็เช่นกัน) ดังนั้นจึงตามมาด้วยว่าเราต้องการหาวิธีทำให้การเปลี่ยนแปลงข้าม service เกิดขึ้นน้อยที่สุด เท่าที่จะเป็นไปได้

ผมมักเห็นสถาปัตยกรรมแบบ layered ตามตัวอย่างของสถาปัตยกรรมสามชั้นใน Figure 1-2 ที่นี่ แต่ละ layer ในสถาปัตยกรรมแทนขอบเขต service ที่แตกต่างกัน โดยแต่ละขอบเขต service อิงตามฟังก์ชันการ ทำงานทางเทคนิคที่เกี่ยวข้องกัน หากผมต้องเปลี่ยนแปลงเฉพาะ presentation layer ในตัวอย่างนี้ ก็จะค่อนข้าง มีประสิทธิภาพ อย่างไรก็ตาม ประสบการณ์แสดงให้เห็นว่าการเปลี่ยนแปลงฟังก์ชันการทำงานมักครอบคลุมหลาย layer ในสถาปัตยกรรมประเภทนี้—ต้องเปลี่ยนแปลงทั้ง presentation, application และ data tier ปัญหานี้ยิ่งแย่ลงไปอีก ถ้าสถาปัตยกรรม layer มากกว่าตัวอย่างง่ายๆ ใน Figure 1-2 บ่อยครั้งแต่ละ tier ยังถูกแบ่งเป็น layer ย่อยลงไปอีก

ด้วยการทำให้ service ของเราเป็นชิ้นส่วนของฟังก์ชันการทำงานทางธุรกิจแบบ end-to-end เรามั่นใจได้ว่าสถาปัตยกรรม ของเราถูกจัดวางให้การเปลี่ยนแปลงฟังก์ชันการทำงานทางธุรกิจมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้ อาจกล่าว ได้ว่าด้วย microservices เราตัดสินใจให้ความสำคัญกับ high cohesion ของฟังก์ชันการทำงานทางธุรกิจมากกว่า high cohesion ของฟังก์ชันการทำงานทางเทคนิค

Figure 1-2. A traditional three-tiered architecture (สถาปัตยกรรมสามชั้นแบบดั้งเดิม)

เราจะย้อนกลับมาพูดถึงปฏิสัมพันธ์ระหว่าง domain-driven design กับการออกแบบองค์กรอีกครั้งในบทนี้

Owning Their Own State (การเป็นเจ้าของ State ของตัวเอง)

สิ่งหนึ่งที่ผมเห็นว่าผู้คนมักจะรับมือได้ยากที่สุดคือแนวคิดที่ว่า microservices ควรหลีกเลี่ยงการใช้ shared database หาก microservice หนึ่งต้องการเข้าถึงข้อมูลที่ microservice อีกตัวถือไว้ มันควรไปขอข้อมูลนั้นจาก microservice ตัวที่สอง สิ่งนี้ทำให้ microservice มีความสามารถในการตัดสินใจว่าอะไรจะแชร์และอะไรจะซ่อน ซึ่ง ทำให้เราแยกฟังก์ชันการทำงานที่เปลี่ยนแปลงได้อย่างอิสระ (implementation ภายในของเรา) ออกจากฟังก์ชันการทำงาน ที่เราต้องการเปลี่ยนแปลงไม่บ่อย (external contract ที่ consumer ใช้) ได้อย่างชัดเจน

หากเราต้องการทำให้ independent deployability เป็นจริง เราต้องแน่ใจว่าเราจำกัดการเปลี่ยนแปลงที่ทำลาย backward compatibility ใน microservice ของเรา หากเราทำลาย compatibility กับ upstream consumer เราจะ บังคับให้พวกเขาต้องเปลี่ยนแปลงตามไปด้วย การมีเส้นแบ่งที่ชัดเจนระหว่างรายละเอียด implementation ภายในกับ external contract ของ microservice สามารถช่วยลดความจำเป็นในการเปลี่ยนแปลงที่ทำลาย backward compatibility ได้

การซ่อน internal state ใน microservice นั้นคล้ายกับแนวปฏิบัติของ encapsulation ใน object-oriented (OO) programming การ encapsulation ข้อมูลในระบบ OO เป็นตัวอย่างหนึ่งของ information hiding ในทางปฏิบัติ

Tip (เคล็ดลับ)

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

ดังที่กล่าวไว้ในหัวข้อก่อนหน้า เราต้องการมอง service ของเราเป็นชิ้นส่วนของฟังก์ชันการทำงานทางธุรกิจแบบ end-to-end ที่ห่อหุ้ม user interface (UI) business logic และข้อมูลไว้ตามความเหมาะสม นี่เป็นเพราะเรา ต้องการลดความพยายามที่ต้องใช้ในการเปลี่ยนแปลงฟังก์ชันการทำงานที่เกี่ยวข้องกับธุรกิจ การ encapsulation ข้อมูลและพฤติกรรมในลักษณะนี้ทำให้เรามี high cohesion ของฟังก์ชันการทำงานทางธุรกิจ ด้วยการซ่อนฐานข้อมูล ที่รองรับ service ของเรา เรายังมั่นใจได้ว่าเราลด coupling ลงด้วย เราจะกลับมาพูดถึง coupling และ cohesion อีกครั้งใน Chapter 2

Size (ขนาด)

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

คุณวัดขนาดอย่างไร? นับจำนวนบรรทัดโค้ดหรือ? นั่นไม่สมเหตุสมผลสำหรับผมเลย สิ่งที่อาจต้องใช้ 25 บรรทัดใน Java อาจเขียนได้ใน 10 บรรทัดของ Clojure นั่นไม่ได้หมายความว่า Clojure ดีกว่าหรือแย่กว่า Java บางภาษา เพียงแค่แสดงออกได้กระชับกว่าภาษาอื่นเท่านั้นเอง

James Lewis ผู้อำนวยการฝ่ายเทคนิคของ Thoughtworks เคยพูดไว้ว่า "microservice ควรมีขนาดใหญ่เท่าหัวของผม" เมื่อได้ยินครั้งแรก ดูเหมือนจะไม่ค่อยมีประโยชน์เท่าไร ยังไงก็ตาม หัวของ James ใหญ่แค่ไหนกันแน่? เหตุผล เบื้องหลังคำพูดนี้คือ microservice ควรมีขนาดที่สามารถเข้าใจได้ง่าย ความท้าทายก็คือ ความสามารถในการเข้าใจ ของแต่ละคนไม่เท่ากันเสมอไป ดังนั้นคุณจึงต้องตัดสินใจด้วยตัวเองว่าขนาดไหนเหมาะกับคุณ ทีมที่มีประสบการณ์ อาจจัดการ codebase ขนาดใหญ่กว่าได้ดีกว่าทีมอื่น ดังนั้นบางทีควรอ่านคำพูดของ James ว่า "microservice ควร มีขนาดใหญ่เท่าหัวของ คุณ " มากกว่า

ผมคิดว่าสิ่งที่ใกล้เคียงที่สุดที่ทำให้ "ขนาด" มีความหมายในแง่ของ microservices คือสิ่งที่ Chris Richardson ผู้เขียน Microservice Patterns (Manning Publications) เคยพูดไว้—เป้าหมายของ microservices คือการมี "interface ที่เล็กที่สุดเท่าที่จะ เป็นไปได้" นั่นสอดคล้องกับแนวคิดของ information hiding อีกครั้ง แต่มันเป็นความพยายามหาความหมายในคำว่า "microservices" ที่ไม่มีอยู่ ตั้งแต่แรก เมื่อคำนี้ถูกใช้ครั้งแรกเพื่อนิยามสถาปัตยกรรมเหล่านี้ จุดโฟกัส อย่างน้อยก็ในตอนแรก ไม่ได้อยู่ที่ขนาดของ interface โดยเฉพาะ

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

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

Flexibility (ความยืดหยุ่น)

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

เราไม่รู้ว่าอนาคตจะเป็นอย่างไร ดังนั้นเราจึงอยากได้สถาปัตยกรรมที่ในทางทฤษฎีสามารถช่วยเราแก้ปัญหาที่เราอาจ เผชิญในอนาคตได้ การหาสมดุลระหว่างการเปิดตัวเลือกไว้กับการแบกรับต้นทุนของสถาปัตยกรรมแบบนี้อาจเป็นศิลปะ อย่างแท้จริง

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

Alignment of Architecture and Organization (ความสอดคล้องระหว่างสถาปัตยกรรมและองค์กร)

MusicCorp บริษัทอีคอมเมิร์ซที่ขาย CD ออนไลน์ ใช้สถาปัตยกรรมสามชั้นแบบง่ายๆ ที่แสดงไว้ก่อนหน้านี้ใน Figure 1-2 เราตัดสินใจที่จะพา MusicCorp เข้าสู่ศตวรรษที่ 21 แม้จะดิ้นรนขัดขืนก็ตาม และส่วนหนึ่งของการทำเช่นนั้น เรา กำลังประเมินสถาปัตยกรรมระบบที่มีอยู่ เรามี web-based UI, business logic layer ในรูปแบบของ monolithic backend และการจัดเก็บข้อมูลในฐานข้อมูลแบบดั้งเดิม layer เหล่านี้ อย่างที่พบเห็นได้ทั่วไป เป็นของทีมที่ แตกต่างกัน เราจะกลับมาพูดถึงความยากลำบากและอุปสรรคของ MusicCorp ตลอดทั้งเล่ม

เราต้องการอัปเดตฟังก์ชันการทำงานของเราแบบง่ายๆ นั่นคือ เราต้องการให้ลูกค้าของเราระบุแนวเพลงโปรดของตัวเอง ได้ การอัปเดตนี้ต้องการให้เราเปลี่ยนแปลง UI เพื่อแสดง UI สำหรับเลือกแนวเพลง เปลี่ยนแปลง backend service เพื่อให้แนวเพลงถูกแสดงบน UI และเปลี่ยนค่าได้ และเปลี่ยนแปลงฐานข้อมูลเพื่อรับการเปลี่ยนแปลงนี้ การเปลี่ยนแปลง เหล่านี้จำเป็นต้องบริหารจัดการโดยแต่ละทีมและ deploy ในลำดับที่ถูกต้อง ดังที่แสดงใน Figure 1-3

Figure 1-3. Making a change across all three tiers is more involved (การเปลี่ยนแปลงข้ามทั้งสาม tier ต้องใช้ความพยายามมากกว่า)

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

กฎของ Conway ที่มีชื่อเสียงในปัจจุบันระบุไว้ดังนี้

องค์กรที่ออกแบบระบบ...ถูกจำกัดให้ผลิตการออกแบบที่เป็นสำเนาของโครงสร้างการสื่อสารขององค์กรเหล่านั้น

Melvin Conway, “How Do Committees Invent?”

สถาปัตยกรรมสามชั้นเป็นตัวอย่างที่ดีของกฎนี้ในทางปฏิบัติ ในอดีต วิธีหลักที่องค์กร IT จัดกลุ่มคนคือตาม ความเชี่ยวชาญหลัก database admin อยู่ในทีมเดียวกับ database admin คนอื่น นักพัฒนา Java อยู่ในทีมเดียวกับ นักพัฒนา Java คนอื่น และนักพัฒนา frontend (ที่สมัยนี้รู้เรื่องแปลกๆ อย่าง JavaScript และการพัฒนา native mobile application) อยู่ในอีกทีมหนึ่ง เราจัดกลุ่มคนตามความเชี่ยวชาญหลัก ดังนั้นเราจึงสร้างสินทรัพย์ IT ที่สอดคล้องกับทีมเหล่านั้น

นั่นอธิบายว่าทำไมสถาปัตยกรรมนี้จึงพบเห็นได้ทั่วไป มันไม่ได้แย่ มันแค่ถูกปรับให้เหมาะสมกับแรงชุดหนึ่ง—วิธี ที่เราจัดกลุ่มคนแบบดั้งเดิม ตามความคุ้นเคย แต่แรงเหล่านั้นเปลี่ยนไปแล้ว ความปรารถนาของเราเกี่ยวกับ ซอฟต์แวร์ของเราก็เปลี่ยนไป ตอนนี้เราจัดกลุ่มคนเป็นทีมที่มีทักษะหลากหลาย (poly-skilled) เพื่อลด handoff และ silo เราต้องการส่งมอบซอฟต์แวร์ให้เร็วกว่าที่เคย นั่นผลักดันให้เราตัดสินใจต่างออกไปเกี่ยวกับวิธีที่เรา จัดองค์กรทีมของเรา เพื่อให้เราจัดองค์กรทีมตามวิธีที่เราแยกระบบของเราออกจากกัน

การเปลี่ยนแปลงส่วนใหญ่ที่เราถูกขอให้ทำกับระบบของเราเกี่ยวข้องกับการเปลี่ยนแปลงฟังก์ชันการทำงานทางธุรกิจ แต่ใน Figure 1-3 ฟังก์ชันการทำงานทางธุรกิจของเรากระจายอยู่ทั่วทั้งสาม tier ซึ่งเพิ่มโอกาสที่การเปลี่ยนแปลงฟังก์ชันการทำงาน จะข้าม layer นี่คือสถาปัตยกรรมที่มี high cohesion ของเทคโนโลยีที่เกี่ยวข้องกัน แต่มี low cohesion ของ ฟังก์ชันการทำงานทางธุรกิจ หากเราต้องการทำให้การเปลี่ยนแปลงง่ายขึ้น เราต้องเปลี่ยนวิธีจัดกลุ่มโค้ด โดยเลือก cohesion ของฟังก์ชันการทำงานทางธุรกิจแทนที่จะเป็นเทคโนโลยี แต่ละ service อาจมีหรือไม่มีการผสมผสานของ สามชั้นนี้ก็ได้ แต่นั่นเป็นเรื่องที่เกี่ยวข้องกับการ implement service ในระดับท้องถิ่น

มาเปรียบเทียบสิ่งนี้กับสถาปัตยกรรมทางเลือกที่เป็นไปได้ ดังแสดงใน Figure 1-4 แทนที่จะเป็นสถาปัตยกรรมและองค์กรแบบ layer ในแนวนอน เราแยกองค์กรและสถาปัตยกรรมของเราออกตามสายธุรกิจใน แนวตั้งแทน ที่นี่เราเห็นทีมเฉพาะที่รับผิดชอบเต็มรูปแบบแบบ end-to-end ในการเปลี่ยนแปลงแง่มุมต่างๆ ของ customer profile ซึ่งทำให้ขอบเขตของการเปลี่ยนแปลงในตัวอย่างนี้จำกัดอยู่แค่ทีมเดียว

ในฐานะการ implement สิ่งนี้อาจทำได้ผ่าน microservice ตัวเดียวที่ทีม profile เป็นเจ้าของ ซึ่งเปิดเผย UI ให้ลูกค้าอัปเดตข้อมูลของตัวเอง โดยมี state ของลูกค้าถูกจัดเก็บไว้ใน microservice ตัวนี้ด้วย การเลือก แนวเพลงโปรดผูกอยู่กับลูกค้าแต่ละคน ดังนั้นการเปลี่ยนแปลงนี้จึงมีขอบเขตที่จำกัดกว่ามาก ใน Figure 1-5 เรายังแสดงรายการแนวเพลงที่มีอยู่ถูกดึงมาจาก microservice Catalog ซึ่งน่าจะมีอยู่แล้ว เรายังเห็น microservice Recommendation ตัวใหม่ที่เข้าถึงข้อมูลแนวเพลงโปรดของเรา ซึ่งสามารถตามมาได้ง่ายในการ release ครั้งถัดไป

Figure 1-4. The UI is broken apart and is owned by a team that also manages the serverside functionality that supports the UI (UI ถูกแยกส่วนและเป็นเจ้าของโดยทีมที่ดูแลฟังก์ชันการทำงานฝั่ง server ที่รองรับ UI ด้วย)

Figure 1-5. A dedicated Customer microservice can make it much easier to record the favorite musical genre for a customer (microservice ของ Customer เฉพาะทางสามารถทำให้การบันทึกแนวเพลงโปรดของลูกค้าง่ายขึ้นมาก)

ในสถานการณ์เช่นนี้ microservice Customer ของเราห่อหุ้มชิ้นส่วนบางๆ ของแต่ละสามชั้น—มันมี UI นิดหน่อย application logic นิดหน่อย และการจัดเก็บ ข้อมูลนิดหน่อย business domain ของเรากลายเป็นแรงหลักที่ขับเคลื่อนสถาปัตยกรรมระบบของเรา ซึ่งหวังว่าจะทำให้ การเปลี่ยนแปลงง่ายขึ้น รวมถึงทำให้เราจัดทีมของเราให้สอดคล้องกับสายธุรกิจภายในองค์กรได้ง่ายขึ้นด้วย

บ่อยครั้ง UI ไม่ได้ถูกมอบให้โดย microservice โดยตรง แต่แม้ในกรณีนี้ เราก็คาดหวังว่าส่วนของ UI ที่เกี่ยวข้อง กับฟังก์ชันการทำงานนี้ยังคงเป็นของ Customer Profile Team ดังที่ Figure 1-4 บ่งชี้ แนวคิดที่ทีมเป็นเจ้าของชิ้นส่วนฟังก์ชันการทำงานที่ผู้ใช้มองเห็นแบบ end-to-end กำลังได้รับความนิยม มากขึ้น หนังสือ Team Topologies 4 แนะนำแนวคิดของ stream-aligned team ซึ่งเป็นตัวแทนของแนวคิดนี้

stream-aligned team คือทีมที่ปรับให้สอดคล้องกับสายงานที่มีคุณค่าเดียว...ทีมได้รับอำนาจในการสร้างและ ส่งมอบคุณค่าให้ลูกค้าหรือผู้ใช้ได้อย่างรวดเร็ว ปลอดภัย และเป็นอิสระที่สุดเท่าที่จะเป็นไปได้ โดยไม่ต้อง ส่งต่องานให้ทีมอื่นมาทำบางส่วนของงาน

ทีมที่แสดงใน Figure 1-4 จะเป็น stream-aligned team ซึ่งเป็นแนวคิดที่เราจะสำรวจเพิ่มเติมใน Chapter 14 และ 15 รวมถึงวิธีที่โครงสร้างองค์กรประเภทนี้ทำงานในทางปฏิบัติ และวิธีที่มันสอดคล้องกับ microservices

A Note on “Fake” Companies (หมายเหตุเกี่ยวกับบริษัท “สมมติ”)

ตลอดทั้งเล่ม ในหลายช่วง เราจะได้พบกับ MusicCorp, FinanceCo, FoodCo, AdvertCo และ PaymentCo

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

ในทางกลับกัน MusicCorp เป็นบริษัทสมมติที่ผสมผสานจากหลายองค์กรที่ผมเคยทำงานด้วย เรื่องราวที่ผมแบ่งปัน เกี่ยวกับ MusicCorp เป็นภาพสะท้อนของสิ่งจริงที่ผมเคยเห็น แต่ไม่ได้เกิดขึ้นกับบริษัทเดียวกันทั้งหมด!