• Facebook
• Twitter
• Line

Source: miro.medium.com

จริง ๆ Monolithic เป็นคำที่เกิดขึ้นในยุคใหม่ๆ ที่ใช้เรียกลักษณะการออกแบบระบบในรูปแบบดั้งเดิม ที่ใช้กันมาหลายปี ถ้ายังมองไม่เห็นภาพ ขออธิบายย้อนกลับไปนิดนึงครับ เราจะคุ้นชินกับ Framework ที่เป็นรูปแบบ Pattern การเขียนโปรแกรมให้เขียนออกมาในแนวเดียวกัน Dev 3-4 คนก็จะเขียนรูปแบบเดียวกัน

เราอาจเคยได้ยิน MVC Framework ที่เป็นการแยกส่วนของ Software ออกเป็นสัดส่วนชัดเจน แต่ Framework จะกล่าวถึงรูปแบบการวางโครงสร้างในการเขียนโปรแกรม แต่สำหรับ Monolithic มันคือ Architecture มันคือแผนผังภาพใหญ่ว่าจะให้ระบบเรานั้น วางแบบไหน ไม่ใช่แค่เขียนแบบไหน

Monolithic Architecture ภาพคุ้นชินที่มีมานาน ?

Monolithic  คือการเขียน Software ที่รวมทุกอย่างไว้ที่จุดจุดเดียว อาจเป็นระบบก้อนเดียว หรือ Server เครื่องเดียว จะเขียนด้วย Framework อะไรก็แล้วแต่ แต่สุดท้ายคือ รวมไว้ที่เดียวกัน มี Model Service Database ข้อดีของแบบนี้คือมันเขียนง่าย คนเดียวก็เขียนได้ ไม่มีความซับซ้อน และตรงไปตรงมา ดูแลในระยะสั้นง่าย เหมาะกับระบบที่ไม่ซับซ้อน หรือมีแผนการพัฒนาในระยะยาววางไว้แล้ว

ข้อดีคือ

1. ทำระบบได้เร็วเพราะ Dev คุมทุกส่วนอยู่แล้ว
2. วาง Structure ง่ายเพราะ เราควบคุมได้ทุกส่วนเราสามารถปรับแก้ได้ทั้งหมด

ข้อจำกัดสำคัญ ๆ ที่เราอาจพบได้คือ

1. แม้เราพยายามใช้ Framework เดียวกัน แต่ในรายละเอียดปลีกย่อยต่างๆ Dev ต่างทีม ต่างบริษัทก็จะมีวิธีแก้ปัญหาต่างกัน ซึ่งเมื่อมีการเปลี่ยนมือ หรือแม้กระทั่งทีมเดิมเข้ามาดู Code ที่เคยเขียนไปหลายๆปี ยังไงซะก็ต้องมานั่งไล่ดู Code ดูการทำงานเดิมอยู่ดี ว่าเราจะ Enhance จุดนี้ต้องทำปรับที่ไหนบ้าง ต้องเรา Code ไปเสียบไปแทรกที่ไหนบ้าง
2. ทุกภาษาต่างมีสิ่งที่ทำเก่งต่างกัน ทีนี้เมื่อเราต้องทำฟังชันที่ภาษาที่ใช้ในปัจจุบันไม่เก่ง เราก็ต้อง “ดันทุรัง” ทำทุกวิธีให้ทำให้ได้ สุดท้ายก็ลงเอยด้วยวิธี Tricky ต่าง บางครั้งแปลกๆ ซึ่ง Tricky มากเท่าไหร่มันไม่ดีแน่ในการดูแลระยะยาว นั่นคือความเสถียรในระบบนั้นก็จะลดลงตาม
3. เปลืองตัง (อันนี้พูดจริงไม่ได้พูดเล่น) สมมุติว่าระบบของเรามี function นึงที่ทำงานหนักมาก หนักจนหน่วงไปทั้ง server สิ่งที่เราแก้ได้คือ ไม่ไป Optimize Code (ใช้เวลา) ก็มีวิธีเอาแบบบ้านๆคือ ซื้อเครื่องใหญ่ขึ้น พอมีอีก function นึ่งเพิ่มมาแม้จะไม่ได้เกี่ยวข้องกับ function แรกเลย ก็ซื้อใหญ่ขึ้น เรื่อยๆ วนไป (โอโหสายเปย์)
4. Deploy Version ใหม่ทีต้องโยกขึ้นไปทั้งก้อน ลองนึกภาพว่าแก้ 1 File ถ้วน ถ้าเป็นตระกูล PHP ไม่ค่อยเท่าไหร่ แต่ถ้า .net นี่คือต้อง Build Publish แล้วโยกทั้งก้อน แล้วถ้ารีบๆเทสไม่ดีนี่ อาจไปกระทบส่วนอื่นและล่มทั้งระบบได้
5. มันอาจเกิดเหตุการณ์ แก้แล้วกระทบส่วนอื่นๆได้เพราะเราสามารถแก้ปรับเทสได้ทุกส่วนทำให้ขาดการ ควบคุม Input Output ในแต่ละ Module

Microservice Architecture รูปแบบใหม่ที่มีการนำมาใช้

 Microservice คือการเขียนแยก ฟันชันที่อยู่ในกลุ่มเดียวกันออกจากกัน และเรียกกลุ่มของฟังชันนั้นว่า “Service” เช่น

• Authantication Service ก็จะมีหน้าที่แค่เฉพาะการทำงานที่เกี่ยวกับการ ลงชื่อเข้าใช้ การ Handle Session
• Member Service ก็จะรับหน้าที่ดูแลข้อมูลสมาชิกการสมัคร การลืม การทำ PDPA
• CMS Service ทำหน้าที่บริหารจัดการข้อมูลภายใน Website

ซึ่งการแยก Service เราเขียนมันแยกกันแบบ 100%  เลยนะนั่นหมายถึงแยกทั้ง Database MVC ข้อมูลต่างๆแยกกันเรียกได้ว่าเหมือนเขียนแยกเครื่องกันเลยโดยชัดเจน การสื่อสารกันระหว่าง Service ก็จะมีการสื่อสารตั้งแต่ Curl (โหดสุด) ธรรมดาไปจนถึง TCP หรือ Message queue

ซึ่งพอระบบทุกอย่างแยกจากกันแบบนี้แล้วมีข้อดีกว่าแบบเดิมคือ

1. ระบบมันเขียนมาแยกกัน เราสามารถเอาเทคโนโลยีอะไร ภาษาอะไรมาใช้ก็ได้
2. เราสามารถเลือก Update ระบบเฉพาะส่วนที่เราต้องการได้
3. เราสามารถสำรองข้อมูลเฉพาะระบบที่เราต้องการได้
4. เนื่องด้วยเราใช้ Docker ในการบริหารจัดการเราสามารถใช้ Feature ตระกูล Docker Orchestration มา Enhance ความปลอดภัย ความเสถียรระบบได้
5. ถูกลง คือมันไม่เชิง ถูกลงไปซะทีเดียวแต่มันสามารถ ซื้อ Resource แยกส่วนได้ไม่ต้องซื้อเผื่อ node อื่นๆในอนาคต
6. เวลาล่มมันมักจะล่มเป็นจุดๆ ไม่ได้ลากระบบเดี้ยงทั้งหมด
7. ด้วยความที่เราใช้ Docker ทำให้การ Revert Emergency case ต่างๆทำได้แบบเป็นจุดๆ ไม่ต้องลากระบบทั้งหมด Down ลงมา

แต่ข้อจำกัดมันก็จำกัดคือ

1. ถ้าโปรเจ็คเล็กมากๆ มันก็ไม่เหมาะสม เพราะเวลาในการตั้งต้นวางแผนแยกแต่ละส่วนต้องใช้เวลาวางแผนมากกว่าปกติเพราะเราต้อง แยก DB แยกแต่ละ Services
2. การส่งข้อมูลกันระหว่าง Service ถ้าไม่ช้ Tools ที่ดีจะทำให้ Application เราช้าลงได้
3. ถ้าจะให้ได้ผลที่ดีต้องมีความรู้ Docker และ Tools ที่ใช้ บริหารจัดการมัน
4. อาจจะแพงในระยะสั้น (ใช่ครับแพงในระยะสั้น) เพราะเราจะต้องเสียเวลา Config มากหน่อยช่วงแรกแต่ถ้าทุกอย่างสมบูรณ์ ก็รันกันยาวๆ

ทั้งนี้การคำนึงที่สำคัญคือ Project ของเรานั้นอนาคตมันจะซับซ้อนขนาดไหน ถ้าไม่ซับซ้อนมาก Monolithic  ก็ไม่ได้แย่ซะทีเดียว แต่ถ้า Project เราซับซ้อนมากๆต้องรับโหลดสูงๆ  ทุก Service มีความสำคัญต้องการ SLA ที่สูงการเลือกใช้ Microservice ก็เป็นเรื่องที่น่าสนใจครับ

อยากให้ทุกท่านได้ลองเทคโนโลยีใหม่กันเยอะๆนะครับโลกเรามันเปลี่ยนไปใวมากสิ่งใหม่ๆ มีการพัฒนาอย่างไม่หยุดครับ สำหรับท่านที่สนใจบริการของ Cloud HM สามารถติดต่อเราได้ผ่านช่องทางนี้นะครับ ขอบคุณครับ

Image Credit: https://medium.com/hengky-sanjaya-blog/monolith-vs-microservices-b3953650dfd

— Cloud HM