- "Monolith > apps > services > microservices"
- อย่างแรก นี่ไม่ใช่กฎ แต่เป็นความเห็นของผม คนที่เคยสร้างระบบกระจายขนาดใหญ่จะรู้ว่ามันไม่ได้ทำงานตามทฤษฎีแบบเป๊ะ ๆ และต้องมีการปรับตัว
- อย่างที่สอง ลำดับขั้นสำคัญมาก
- ถ้าเป็นบริษัทขนาด 5-50 คน ก็ใช้ Monolith ไปเลย
- ถ้าเป็นบริษัทขนาด 10,000 คน ก็น่าจะมีครบทุกอย่างด้านบนอยู่แล้ว แต่ถ้าจะพูดถึงสิ่งที่ผมคิดต่างไปจากเมื่อก่อนคือ..
มาเริ่มจากนิยาม (Definition) กันก่อน
- monolith - xyz.com
- apps - abc.xyz.com
- services - รองรับแอป/โมโนลิท, โครงสร้างพื้นฐานหลัก, ฟังก์ชันด้าน compliance หลัก, และอาจไม่ใช่สิ่งที่ทีมแอปเป็นคนเขียนเองเสมอไป (อาจดูแลโดยทีมอินฟรา)
- microserivces - โค้ดไม่กี่ร้อยบรรทัด ส่วนใหญ่ใช้ครั้งเดียว และอาจ/ควรเป็นไลบรารีหรือ SDK มากกว่า
Why ? : โดยพื้นฐานแล้วเป็นเรื่องของ "Speed & Risk"
- #1 การที่ทั้งทีมพัฒนาทำงานอยู่บนบิ๊กแอปตัวเดียวกัน (ลองนึกว่าทั้งเว็บไซต์คือแอป Rails เดียว) นั้นง่ายกว่า
- #2 เมื่อเติบโตขึ้น ระบบกระจายที่ต้องมีอย่างหลีกเลี่ยงไม่ได้ก็ซับซ้อนจนยากจะทำความเข้าใจอยู่แล้ว แม้จะไม่มีไมโครเซอร์วิสที่เสี่ยงในตัวเองอีกหลายร้อยตัวก็ตาม
- #3 ถ้าไปทางไมโครเต็มตัว ก็ต้องนำแนวคิดใหม่ ๆ เข้ามาเพื่อรับมือกับการขยายตัวแบบไร้การควบคุม
- #4 บริการอินฟราที่ทำขึ้นเฉพาะทาง (Bespoke) หรือไมโครเซอร์วิส คือแนวคิดของหนี้ทางเทคนิคในรูปแบบสุดโต่ง โค้ดก็เป็นหนี้อยู่แล้ว แต่เซอร์วิสคือเวอร์ชันที่หนักยิ่งกว่า ลองคิดดูว่ามันหมายความว่าอย่างไร และทำให้มันเป็นจุดสร้างแรงทดแทน
- วิศวกรระบบกระจายไม่ชอบความซ้ำซ้อน ดังนั้นถ้าเห็นว่ามีบางอย่างถูกทำในหลายที่ ก็จะคิดว่า "แยกมันออกมาแล้วทำเป็นไมโครเซอร์วิสกันเถอะ"
- ในทางทฤษฎี นี่ถูกต้อง และถ้ามีสักสิบหรือยี่สิบตัวก็ยังพอไหว แต่พอเกินหลักหลายสิบ หรือถูกใช้ข้ามบริษัทขนาดใหญ่ มันจะไม่ใช่ปัญหาทางเทคนิคอีกต่อไป แต่เป็นปัญหาทางองค์กร
- สิ่งที่ผมพูดอาจฟังดูเหมือนการแบ่งขั้วแบบผิด ๆ แต่ในความเป็นจริง ไมโครเซอร์วิสมีทั้งความท้าทายทางเทคนิค และมีปัญหาทางองค์กรที่มากกว่านั้นอีก
สิ่งที่ผมกังวลคือ
- #1 (เว้นแต่จะมี CEO ที่มาจากสายไอทีเป็นผู้นำแบบชัดเจน) อินฟรามักถูกลดลำดับความสำคัญอยู่เสมอ
- #2 ถ้ามีเซอร์วิสมากเกินไป โดยทั่วไปจะเกิดปัญหาเรื่องความเป็นเจ้าของและขอบเขตความรับผิดชอบ
- #3 ต้องนำเครื่องมือเข้ามาเพิ่มเพื่อจัดการไมโครเซอร์วิสจำนวนมาก
- #4 ที่สำคัญที่สุดคือ ไมโครเซอร์วิสแต่ละตัวที่จริงควรเป็นไลบรารีหรือ SDK กลับกลายเป็นตัวสร้างความเสี่ยงต่อโปรดักชัน
โดยทั่วไป สิ่งที่ผมแนะนำคือ
- #1 ถ้าเป็นไปได้ ให้คง Monolith ไว้ให้นานที่สุด
- #2 ให้เริ่มสร้าง services จากสิ่งที่จำเป็นต่ออินฟรา ไม่ใช่เริ่มจากฝั่งพัฒนาแอป
- #3 ถ้าจำเป็นต้องแยก Mono ก็ให้แยกเป็นแอปใหญ่ ๆ ไม่ใช่บริการเล็ก ๆ
- #4 ให้มองว่าแต่ละแอปใหม่คือกำแพงเสมือนภายในบริษัท
- #5 ถ้าเป็นไปได้ ให้เลือกใช้ไลบรารีแทนไมโครเซอร์วิส
13 ความคิดเห็น
ผมเห็นด้วยกับช่วงท้ายที่พูดถึงความกังวลและคำแนะนำนะครับ
จริง ๆ แล้วทั้งขนาดบริษัทและขนาดบริการก็อยู่ในบริบทคล้ายกัน และคงจะมีช่วงเวลาที่หลีกเลี่ยงการแยกออกเป็นส่วนย่อยไม่ได้ เลยรู้สึกว่าจำเป็นต้องมีวิจารณญาณที่ยอดเยี่ยมในการเตรียมพร้อมรับมือเรื่องนั้นไว้ล่วงหน้า
มันไม่ควรขึ้นอยู่กับขนาดของระบบมากกว่าขนาดของบริษัทเหรอ? หรือว่าฉันเข้าใจ MSA ผิดมาตลอด?
สำหรับความเห็นข้างบน
ผมเห็นด้วยในเบื้องต้นกับความเห็นที่ว่า
ปัญหาอาจไม่ใช่ microservices แต่เป็นการขยายบริการอย่างไร้การควบคุมไม่ใช่หรือ?
และยิ่งบริษัทเติบโตขึ้น ปัญหาเรื่องการ deploy + การจัดการ branch รวมถึงข้อเสียของ monolith เองก็ยิ่งปรากฏชัดมาก ดังนั้นน่าจะต้องเลือกระหว่างต้นทุนกับผลิตภาพในแง่ของ trade-off ให้ดี
เป็นบทความที่ดีมากจริงๆ ครับ ขอบคุณครับ
น่าจะคล้ายกับประเด็นถกเถียงเรื่องความสำคัญของ design pattern นะครับ
design pattern ก็คือรูปแบบโค้ดที่สกัดออกมาจากกระบวนการแก้ปัญหาหลากหลายแบบ....
สุดท้ายแล้วก็ต้องประยุกต์และนำไปใช้ตามความจำเป็นให้เหมาะกับสถานการณ์อยู่ดี.....
แต่ก็มักจะมีคนที่มองว่า design pattern เป็นสิ่งจำเป็นและหมกมุ่นกับมัน ราวกับเป็นคำตอบมาตรฐาน...
ช่วงนี้เรื่อง MSA ก็ดูคล้ายกัน คือมีคนที่เป็นพวก "ต้อง MSA เท่านั้น" เพิ่มขึ้นเรื่อย ๆ เหมือนกันครับ.
มันฟังดูเหมือนคำถามแนวไก่กับไข่อะไรเกิดก่อนกันเลยนะ
ปัญหาอาจไม่ใช่ไมโครเซอร์วิส แต่เป็นการขยายบริการแบบไร้การควบคุมมากกว่าหรือเปล่า?
ผมคิดว่าการหาสมดุลที่เหมาะสมเป็นเรื่องสำคัญ
เมื่อเปลี่ยนไปใช้ไมโครเซอร์วิส ก็อาจลงเอยด้วยการที่ฟีเจอร์ใหม่ = ไมโครเซอร์วิสใหม่
เลยทำให้การจัดการยิ่งยากขึ้นเรื่อย ๆ หรือเปล่านะครับ
ทำให้นึกถึงบทความ
Goodbye Microservicesที่เคยลงในบล็อกเทคนิคของ Segment มาก่อนเลยครับSegment เองก็เป็น CDP ที่ต้องประมวลผลข้อมูลจำนวนมหาศาลแบบเรียลไทม์เช่นกัน แต่ถึงอย่างนั้นก็ยังเปลี่ยนจากโครงสร้าง Microservices กลับไปเป็น Monolith และได้สรุปเหตุผลต่าง ๆ ไว้ในบล็อก ผมคิดว่ามีหลายส่วนที่สอดคล้องกับบทความนี้เหมือนกัน :)
https://segment.com/blog/goodbye-microservices/
โดยรวมแล้วค่อนข้างตรงกับความคิดของผม
นักพัฒนาในบริษัทของเรามี 5 คน ดังนั้นตอนนี้ผมคิดว่ายังเหมาะที่จะมุ่งไปทาง monolith (RubyOnRails)
ถ้าโปรเจ็กต์กลายเป็นระดับที่มีคนมากกว่า 50 คนพัฒนาพร้อมกันแบบในบทความนั้น ตอนนั้นก็คงจะพัฒนา monolith ตัวที่สองกัน
ถ้าเป็นบริษัทขนาด 5-50 คน ก็ใช้ Monolith ไปเถอะ << ตรงนี้หมายถึงจำนวนพนักงานทั้งหมด ไม่ใช่จำนวนนักพัฒนาใช่ไหม?
น่าจะกำลังพูดถึงขนาดของบริษัทอยู่~
ถ้าเป็นไปได้ก็ควรรักษา Monolith ไว้ให้นานที่สุด < เห็นด้วยอย่างยิ่งครับ การแยกออกไปทำให้ค่าใช้จ่ายในการดูแลรักษาเพิ่มขึ้นมาก
ผมคิดว่านี่เป็นบทความที่มีความหมายในฐานะกระแสตีกลับต่อการที่ MSA กำลังกลายเป็นแนวคิดแบบด็อกมา และในแง่นั้นก็น่าสนใจครับ