ช่วงนี้ใช้ชีวิตอยู่กับการออกแบบระบบ Backend ที่จากเดิม หากต้องการจะทำระบบขึ้นมา จะเริ่มต้นด้วย
- ออกแบบฐานข้อมูล 1 ถัง
- Backend Service ที่ให้ Client เรียกใช้ 1 Service ถ้วน
- ออกแบบ application ฝั่ง client และเรียกใช้ Backend Service ที่มีหน้าที่คุยกับฐานข้อมูล ทั้งสร้าง แก้ไข อัพเดท และลบ
แต่พอเห็นคำว่า Microservice ขึ้นมา ใจก็สั่นระรี้ระริก อยากทำกับเค้าบ้าง จะทำยังไงดีน๊า……
เริ่มต้นด้วยการอ่าน อ่าน อ่าน และอ่าน โดยอย่างแรกที่ต้องเข้าใจเลยคือ
“Monolithic Architecture คือ อะไร?”
Monolithic Architecture คือ สถาปัตยกรรมการออกแบบ และพัฒนาซอฟต์แวร์ ระบบหรือบริการ (Service) ที่รวมทุกส่วนเอาไว้ในสภาพแวดล้อม (Environment) เดียวกัน ใช้ฐานข้อมูลเดียวกัน (Database) ตามรูปด้านล่าง
จากรูป จะเห็นได้ว่าการพัฒนาฟังก์ชันเข้าใช้งานระบบ (Sign In), ข้อมูลสินค้า,
ข้อมูลสินค้าลดราคา, การชำระเงิน, ติดต่อลูกค้า จะเป็นการพัฒนาโดยการเขียนชุดคำสั่ง (Code) ไว้ที่เดียวกัน และใช้ฐานข้อมูลที่เดียวกัน
ก็ดูเหมือนมันก็ง่ายดีนะ ทุกวันนี้พัฒนาระบบแบบนี้ก็มีความสุขดีนี่หน่า…จะดิ้นรนปรับปรุงไปทำไมหล่ะนั่น….แหมมม แต่ทุกสิ่งใดล้วนมีปัญหา และข้อเสียนะ เพราะฉะนั้น เรามาดูข้อเสียของการออกแบบ ในลักษณะ Monolithic กันเถอ
ปัญหา และข้อเสีย…. มีดังนี้
- การพัฒนาได้ช้า (Slow Development): เนื่องจากแอปพลิเคชัน ที่ออกแบบในลักษณะนี้ มักมีขนาดใหญ่ มีบรรทัดของชุดคำสั่ง (Code) จำนวนมาก
ส่งผลให้เครื่องมือที่ช่วยในการพัฒนาโปรแกรม (IDE: Integrated Development
Environment) จะทำการ Compile หรือ Run ได้ช้า รวมถึงการเข้าไปเพิ่มชุดคำสั่งใหม่ ๆ หากไม่มีการจัดการให้ดี จะมีความซับซ้อนเพิ่มมากขึ้น ส่งผลให้นักพัฒนาที่เพิ่งเข้ามาทำงานในโครงการ ทำความเข้าใจได้ช้า และไม่กล้าเข้าไปแก้ไข — ยิ่งน้องใหม่ Junior อย่าได้เข้าไปเฉียดเชียว ไล่ code อยู่ได้หลายวัน ฮ่าๆๆ - ไม่ยืดหยุ่น (Inflexible): การนำเทคโนโลยีใหม่ ๆ เข้ามาประยุกต์ใช้
หรือเลือกใช้เทคโนโลยีที่แตกต่างกันในแต่ละบริการ เป็นเรื่องยาก รวมถึง
หากต้องการเปลี่ยนแปลง เทคโนโลยีในแต่ละบริการ ก็ทำได้ยาก เช่นกัน - ขยายระบบได้ยาก (Unscalable): การขยาย Server เพื่อรองรับผู้ใช้งานที่มากขึ้น ทำได้ยาก เช่น การถ่ายทอดการแข่งขันฟุตบอลโลก หรือช่วงเวลาลดราคาสินค้า เนื่องจากทุก Stack ใน Monolithic มีขีดจำกัด ไม่สามารถปรับได้โดยอิสระออกจากกัน
- ยากต่อการพัฒนาอย่างต่อเนื่อง (Blocks Continuous Development): การ Deploy จำเป็นต้อง Deploy ระบบพร้อมกัน ไม่สามารถแยกส่วนการ Deploy ได้
ทำให้ไม่เกิดความคล่องตัวในการพัฒนา ยากต่อการทดสอบ โดยเฉพาะหาก Deploy แอปพลิเคชันขนาดใหญ่มาก ความเสี่ยงต่อระบบก็จะเพิ่มมากขึ้น
เนื่องจากอาจจะส่งผลกระทบต่อระบบงานอื่น หากกระบวนการทดสอบมีคุณภาพไม่เพียงพอ — กรณีนี้ถ้าใครเคยเจอ แบบเจอบัค 1 ตัว แก้ไปเสร็จ ใจตุ้มๆ ต่อม ว่าจะกระทบอะไรไหม ขนาดมีการควบคุม version code แล้วก็ยังใจ บ่ ดี เลยย - ขาดความน่าเชื่อถือ (Unreliable): ในกรณีที่มีบริการใด หรือฟังก์ชันใดขัดข้อง
ก็อาจจะส่งผลต่อทั้งระบบขัดข้องไปด้วย เนื่องจากระบบถูกวางไว้ในสภาพแวดล้อม (Environment) เดียวกัน ดังนั้น เมื่อเกิดความล้มเหลวขึ้นมาที่ส่วนใดส่วนหนึ่ง ก็จะส่งผลให้เกิดปัญหาส่งต่อกันไปทั้งหมด
เริ่มต้นรู้จักการออกแบบ และพัฒนาซอฟต์แวร์ แบบ Monolithic กันไปแล้ว แต่ก็ยังไม่เข้าใจอยู่ดีว่า การจะไปถึง Microservice จะทำได้อย่างไรนะ บทความถัด ๆ ไป เราจะเล่าถึง ว่า เราอ่านอะไรบ้าง ทีละลำดับ จนถึงขั้น Implement พร้อมทั้งบอกเล่าถึงปัญหา อุปสรรค ที่พบเจอกันทีละนิดๆ อย่างๆ ค่อย ๆ เป็น ค่อย ๆ ไป ฮึบๆๆ
2019–09–15
Eunhye
ลำดับถัดไป สิ่งที่คุณควรรู้ หากจะพาตัวเองไปยังโลกของ Microservice อยากรู้ Click เลยฮะ
