‘Monolithic Commerce’ ในวันที่กำลังจะกลายเป็นเสาหินล้าสมัย

ในช่วงหลายปีก่อนหน้านี้ Monolithic Architecture เป็นสถาปัตยกรรมการออกแบบและพัฒนาระบบ ซอฟท์แวร์ และเว็บ Application ที่ได้รับความนิยมอย่างกว้างขวางในองค์กรต่าง ๆ ในการนำไปพัฒนาสร้างแพลตฟอร์มร้านค้าออนไลน์ จนประสบความสำเร็จเป็นจำนวนมาก

กระทั่งระยะ 2-3 ปีให้หลัง ที่เริ่มมีกระแสการเข้ามาของ Cloud Native และโดยเฉพาะ Microservice ที่หลายคนมองว่า สามารถใช้เป็นทางเลือกในการนำมาพัฒนา Web Application ที่ทรงประสิทธิภาพได้มากกว่า

• Monolithic กำลังจะกลายเป็นสถาปัตยกรรมที่ “OUT” ไปแล้วหรือไม่?

นี่น่าจะเป็นคำถามสำคัญที่ไม่ใช่แค่นักพัฒนาระบบเท่านั้นที่ต้องหาคำตอบ แต่ยังอาจหมายถึงองค์กรทุกแห่งที่ต้องเตรียมการลงทุนเพื่อสร้างหรือพัฒนาระบบใน Digital Business ก็จำเป็นที่จะต้องรู้ด้วยเช่นกัน

เพราะการกำหนดสถาปัตยกรรมที่ถูกต้อง ย่อมมีผลต่อการพัฒนาแพลตฟอร์มที่เสถียร และสามารถนำไปต่อยอดพัฒนาในระยะยาวต่อไปได้อย่างมีประสิทธิภาพ

สำหรับภาพรวมความต่างระหว่าง Monolithic กับ Microservice ถ้าจะให้สรุปแบบสั้นๆ คือ Monolithic เป็นการพัฒนาโดยรวมเอาทุก Service ไว้ใน Environment เดียวกัน และใช้ Database เดียวกัน หรือพูดง่ายๆ ก็คือ รวมทุกอย่างมาวางไว้ใน Application เดียวกันนั่นเอง

ขณะที่ Microservice จะแยก Service แต่ละอย่างออกเป็น Application ย่อย ๆ ตามวัตถุประสงค์ของการใช้งาน โดยแต่ละ Service จะทำงานบน Process และ Data Base ของตัวเอง แต่จะสามารถคุยหรือติดต่อกับ Service อื่น ๆ ผ่าน REST API และเมื่อ Data Base ของ Service ไหนล่ม ก็จะไม่กระทบกับ Service อื่น ๆ ที่ยังสามารถทำงานต่อไปได้

และต่อไปนี้คือส่วนหนึ่งของคำตอบว่า เหตุใด Monolithic จึงอาจกำลังกลายเป็นสถาปัตยกรรมที่ล้าสมัยไปแล้ว!

1. เนื่องจากทุกอย่างถูกรวมอยู่ในระบบเดียวกัน ทำให้ Application ที่ออกแบบโดยใช้สถาปัตยกรรม Monolithic มักมีขนาดใหญ่ มีโค้ดมากถึง 5-10 ล้านบรรทัด และส่วนใหญ่ต้องมีการติดตั้งซอฟต์แวร์สนับสนุนเพิ่มเติม เช่น โปรแกรมสำหรับเซิร์ฟเวอร์และฐานข้อมูล ซึ่งหลายโปรแกรมมีราคาแพงและยากที่จะนำมาปรับใช้ โดยเฉพาะเมื่อนำมาเปรียบเทียบกับ Open Sources และ Microservice ที่มีโค้ดเพียงแค่หลักหมื่นบรรทัดเท่านั้น
2. การปรับปรุงระบบหรืออัพเดตโปรแกรมไม่ได้ทำง่ายๆ เพราะการใช้ Environment เดียวกัน ทำให้การเปลี่ยนแปลงใน Monolithic Application จะส่งผลเชื่อมโยงหากัน เช่น ERP, CRM, WMS, ESB เป็นต้น การเปลี่ยนแปลงที่ดูไม่น่าจะมีผลเสียต่อส่วนหนึ่ง แต่อาจมีผลเสียอย่างร้ายแรงต่ออีกส่วนหนึ่ง จึงต้องใช้เวลาในการทดสอบและเกิดความยุ่งยากนำไปปรับใช้ค่อนข้างมาก
3. เป็นไปได้ยากที่จะนำแนวคิด Agile Methodology มาพัฒนา Monolithic Application เนื่องจากการพัฒนาซอฟต์แวร์ต้องทำตามลำดับขั้น โดยนักพัฒนาต้องเขียนโค้ดและตรวจสอบในเวลาเดียวกัน จากนั้นจึงนำโค้ดไป Deploy ทั้งนี้แม้ในบางกรณี Monolithic  จะสามารถแยกพัฒนาแต่ละส่วนได้ แต่จะเกิดความซับซ้อนในการทำงานเพิ่มขึ้นมาก ขณะที่ Microservice ทำได้ เนื่องจากมีการแบ่ง Service ออกเป็นส่วนเล็ก ๆ ที่เชื่อมต่อกันออย่างหลวม ๆ แต่ก็จัดเรียงกันอย่างมีประสิทธิภาพ ซึ่งเหมาะกับ Agile Methodology
4. Monolithic ไม่เอื้อต่อการปรับ Scale เพื่อรองรับปริมาณการใช้งานบางช่วงที่มี Traffic จำนวนมาก เช่น การถ่ายทอดการแข่งขันฟุตบอลโลก หรือช่วงเวลาลดราคาสินค้า เนื่องจากทุก Stack ใน Monolithic มีขีดจำกัดไม่สามารถปรับ Scale อย่างไม่จำกัด และไม่สามารถปรับได้โดยอิสระจากกัน แม้ปัจจุบันจะมีโปรแกรมมาช่วยเหลือ แต่ก็ทำได้ไม่เต็มที่ ขณะที่ Microservice ซึ่งเป็นการแบ่ง Application ออกเป็นชิ้นส่วนเล็ก ๆ  จึงสามารถปรับ Scale แต่ละ Stack ได้อย่างอิสระ
5. แต่ละส่วนของ Monolithic Application ไม่สามารถปรับ Scale ได้โดยอิสระจากกัน และการปรับแบบอัตโนมัติก็ทำได้ยาก เนื่องจากมักใช้เวลาหลายสิบนาทีในการเปิดเซิร์ฟเวอร์และรัน Application ซึ่งมีขนาดใหญ่ รวมถึงการโหลด Libraries ขณะที่ Microservices ขนาดเล็กสามารถเปิดได้ใน 1-2 วินาที ซึ่งช่วยให้สามารถตอบสนองต่อจำนวนผู้เข้าใช้ (customer traffic) แบบ real-time ได้ดีกว่า
6. แพลตฟอร์มการค้าแบบ Monolithic เช่น Demandware, ATG, WebSphere, Commerce ต้องอาศัยความเป็นเจ้าของข้อมูลการค้าทั้งหมด ประกอบด้วย ผลิตภัณฑ์ ลูกค้า คำสั่งซื้อ เป็นต้น ตัวอย่างเช่น เราไม่สามารถสร้างคำสั่งซื้อได้ด้วยตนเอง แพลตฟอร์มจะต้องมีข้อมูลทั้งหมดนี้ ทำให้ต้องพึ่งพาฟังก์ชันและแผนงานของแพลตฟอร์ม มิเช่นนั้นก็จะทำอะไรไม่ได้เลย
7. เป็นเรื่องยากที่จะใช้งาน Monolithic Application มากกว่าหนึ่งเวอร์ชั่น เช่น 1, 1.2 และ 2.0 ในเวลาเดียวกัน เนื่องจากการที่ Application ทั้งหมดพยายามอ่านและเขียนข้อมูลเดียวกันโดยใช้โค้ดคนละเวอร์ชั่น จะทำให้เกิดปัญหาเกี่ยวกับ Clients ที่ใช้ติดต่อสื่อสารกับลูกค้าที่มีอยู่หลายช่องทาง (Omnichannel Clients) การมี Clients จำนวนมากเข้าใช้ช่องทางเชื่อมต่อหรือ APIs เดียวกัน ซึ่งหมายความว่าจะต้องมีการอัพเกรด Clients ทั้งหมด อาทิ Web, Mobile, IoT, POS เป็นต้น ขณะที่ Microservices สามารถอัพเกรด Clients จำนวนมากได้อย่างอิสระ
8. ใน Monolithic ถ้ามี Service ใดขัดข้อง ก็อาจมีผลเท่ากับระบบทั้งหมดขัดข้อง เนื่องจากทุกอย่างถูกวางอยู่ไว้ใน Environment เดียวกัน ดังนั้นเมื่อเกิดความล้มเหลวขึ้นมาในส่วนใดส่วนหนึ่ง ก็จะเกิดปัญหาส่งต่อกันไปทั้งหมด ขณะที่ Microservice แม้จะมี Service บางจุดขัดข้อง แต่ระบบโดยรวมจะจัดการกับความขัดข้องดังกล่าวได้ดีและยังสามารถเดินหน้าต่อไปได้หากเกิดปัญหาขึ้น
9. การรักษาความปลอดภัยใน Monolithic Application ทำได้ยากกว่า เช่น หากมีช่องโหว่ใน SQL Injection บนหน้าเพจของผลิตภัณฑ์ บุคคลอื่นจะสามารถเข้าถึงข้อมูลของลูกค้าได้เช่นกัน เนื่องจากมีเพียงฐานข้อมูลเดียว แต่หากมีคนเจาะเข้าไปในฐานข้อมูล Microservice ของผลิตภัณฑ์ ก็จะเข้าถึงได้เพียงแค่ฐานข้อมูลของผลิตภัณฑ์นั้น ๆ เท่านั้น
10. การพัฒนาโดย Outsource สำหรับ Monolithic ถือเป็นเรื่องทำได้ยาก เนื่องจากฟรีแลนซ์และ System Integrator จะต้องเป็นส่วนหนึ่งของทีมพัฒนาที่สามารถเข้าถึงระบบต่าง ๆ ที่เกี่ยวข้องได้ทั้งหมด ขณะที่ Microservices เราสามารถระบุสเปกของ API และส่งไปยังบุคคลที่สามให้ทำการสร้างได้โดยลำพัง โดยที่เขาไม่จำเป็นต้องรู้เกี่ยวกับส่วนอื่น ๆ ของระบบ หรือวิธีที่เราสร้างสร้างซอฟต์แวร์ เพียงแค่ส่งโค้ดที่สอดคล้องกับ API ที่ระบุเอาไว้ตั้งแต่แรกก็จบแล้ว
11. Monolithic Application มักยากต่อการ Deploy เนื่องจาก Application มักมีขนาดใหญ่และซับซ้อน มีพารามิเตอร์การตั้งค่าจำนวนมาก รวมถึงมีตัวแปรที่แวดล้อมอยู่มากมาย ความซับซ้อนจะยิ่งเพิ่มขึ้นเนื่องจากนักพัฒนามักไม่ใช่ผู้ที่นำ Application ไปปรับใช้ ทำให้เกิดปัญหาในการบูรณาการ และมักเกิดปัญหาด้านความพร้อมในการผลิต โดยจะง่ายกว่ามาก หากนักพัฒนาแต่ละคนสามารถสร้าง Application ของตนเองได้ในไม่กี่วินาที และทำการรัน Application ในสถานที่นั้นๆ
12. Monolithic Application มักประสบปัญหาเกี่ยวกับการทำให้เทคโนโลยีเป็นอันหนึ่งอันเดียวกัน แม้โดยทั่วไปเราจะใช้เทคโนโลยีหนึ่งในแต่ละ Layer เช่น ใช้ Java สำหรับ Middle-tier แต่เนื่องจากมีนวัตกรรมใหม่ๆ เกิดขึ้นทุกวัน หากทุกคนถูกบังคับให้ใช้เทคโนโลยีเดียวกันในแต่ละ Layer องค์กรก็จะไม่มีโอกาสที่จะสร้างนวัตกรรมหรือได้ทดลองสิ่งต่างๆ เช่น หากทีมมีความสามารถในภาษา Go แล้วทำไมจึงไม่ให้สร้าง Microservice ใหม่โดยใช้ “Go”หากมันได้ผล ก็ควรใช้ภาษานี้เป็นภาษาหลักในการเขียนโปรแกรม แต่หากทุกคนถูกบังคับให้ใช้เพียง Java ก็จะไม่มีช่องว่างสำหรับการทดลองใช้ภาษาอื่นๆ
13. นักพัฒนาที่เพิ่งเริ่มทำงานจะถูกท้าทาย เนื่องจาก Monolithic Application จะมีความซับซ้อนอย่างมากขณะที่เมื่อเวลาผ่านไป อาจต้องใช้คอมพิวเตอร์เสมือน (VM) 5– 10 เครื่อง ในการสร้างสภาพแวดล้อมในการพัฒนา ระบบการบันทึกข้อมูลและการส่งข้อความเป็นระบบที่ซับซ้อน โดยใน Application อาจมีระบบ Object-Relational Mapping ที่สามารถกำหนดได้เองเพื่อการเข้าถึงข้อมูล เนื่องจาก Monolithic Application โดยส่วนใหญ่มีโค้ดหลายล้านบรรทัด สิ่งต่างๆ จึงเกิดความซับซ้อนอย่างรวดเร็ว การจ้างนักพัฒนาใหม่อาจใช้เวลาหลายเดือน และก่อให้เกิดความไม่พอใจกับผู้ที่เกี่ยวข้อง
14. Monolithic Application มีความซับซ้อนภายในเป็นอย่างมาก แต่มีการเปิดเผยข้อมูลเกี่ยวกับ APIs ให้กับโลกภายนอกเพียงเล็กน้อย APIs มักถูกกำหนดขึ้นในภายหลัง เนื่องจาก Application นั้นเกี่ยวข้องกับตรรกะทางธุรกิจ เป็นเรื่องยากมากที่ APIs จะถูกกำหนดขึ้นก่อน หลังจากนั้นจึงสร้างโค้ดที่ใช้ APIs ที่ถูกกำหนดเอาไว้อย่างดี จึงเป็นเรื่องยากที่ Client จะใช้ APIs ซึ่งต่างจาก Microservices ที่ส่วนใหญ่เริ่มจากการกำหนด API และดำเนินการโดยยึดเสปกที่กำหนดไว้ตั้งแต่ต้น
15. การปรับปรุงการออกแบบ หรือ Refactoring ของ Monolithic Application ให้ดีขึ้น กลายเป็นสิ่งท้าทาย เนื่องจากการปรับปรุงโค้ดส่วนหนึ่งของ Application อาจมีผลกระทบเชิงลบที่ไม่ตั้งใจอย่างมากต่อส่วนอื่น ๆ ใน Application นอกจากนี้เมื่อเวลาผ่านไป โค้ดเหล่านั้นจะยิ่งมีความซับซ้อนมากขึ้น จึงแทบจะเป็นไปไม่ได้เมื่อเวลาผ่านไป เนื่องจากมีความซับซ้อนเพิ่มขึ้น

สิ่งที่กล่าวมานี้ไม่ได้หมายความว่า Cloud Native และ Microservices นั้นเป็นวิธีที่สมบูรณ์แบบ แต่เห็นได้ชัดว่า Monolithic Application มีปัญหาหลายประการที่ไม่อาจเพิกเฉยได้ ขณะที่ในตลาดเอง ก็ยังมีทางเลือกอื่นๆ ที่น่าตื่นเต้นให้เหล่านักพัฒนาสามารถเลือกเทคโนโลยีนำไปใช้ได้

นั่นจึงอาจกล่าวได้ว่า ช่วงเวลานี้ของสถาปัตยกรรม Monolithic อาจเป็นช่วงเวลาแห่งการก้าวเข้าสู่เส้นทางแห่งความล้าสมัยมากขึ้นไปทุกที!