Microservices
Technology

3 รูปแบบการย้ายระบบไปเป็น Microservices จากเอกสารเรื่อง Blowing Up the Monolith

3 รูปแบบการย้ายระบบไปเป็น Microservices จากเอกสารเรื่อง Blowing Up the Monolith | Skooldio Blog

จากเอกสารเรื่อง Blowing Up the Monolith: Adopting a Microservices-Based Architecture 
ทาง KongHQ ทำการอธิบายเกี่ยวกับการนำแนวคิด Microservices มาปรับใช้สำหรับการปรับปรุงระบบเดิมที่มีลักษณะแบบ Monolith ให้ดีขึ้น ว่าควรพิจารณาในเรื่องใดบ้าง
รวมทั้งควรมี strategy ในเรื่องต่าง ๆ ที่ชัดเจน หนึ่งในนั้นคือ Transition strategy

จากเอกสารอธิบายไว้ว่า 

Transition strategy คือรูปแบบในการนำแนวคิดมาปรับใช้กับองค์กรและระบบงาน
โดยแบ่งออกเป็น 3 รูปแบบคือ

  1. Ice Cream Scoop
  2. Lego
  3. Nuclear Option

มาดูรายละเอียดรวมทั้งข้อดีข้อเสียกันนิดหน่อย

รูปแบบที่ 1 Ice Cream Scoop

เป็นรูปแบบการแยกส่วนการทำงานออกมาจากระบบเดิม โดยค่อย ๆ แยกออกมา เหมือนกับการตัก Ice cream มาทีละ scoop

ข้อดีคือ เป็นการทำงานแบบค่อยเป็นค่อยไป ดังนั้นผลกระทบจากการเปลี่ยนแปลงจะน้อยหรือไม่มีเลย ผู้ใช้งานยังใช้งานเช่นเดิมเช่นเดิม ไม่มีผลกระทบหรือน้อยมาก ๆ แต่กว่าจะแยกออกมาหมดก็ต้องใช้เวลามากเช่นกัน !!

รูปแบบที่ 2 Lego

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

ดังนั้น ถ้าต้องการสร้างหรือเพิ่ม feature ใหม่ ๆ จึงไม่ให้เพิ่มในระบบเดิม แต่ให้แยกออกมาเป็น service ใหม่แทน แน่นอนว่า ข้อดีคือ ทำการพัฒนาได้อย่างรวดเร็ว เพราะว่า ไม่ต้องไปแก้ไขของเก่า แต่ปัญหาที่ตามมาคือ ทั้งสองระบบต้องสร้างส่วนที่แลกเปลี่ยนข้อมูลกันด้วย ยกตัวอย่างเช่น API ขึ้นมา รวมทั้งระบบเดิม ก็ยังคงมีปัญหาเดิมต่อไป

รูปแบบที่ 3 Nuclear option

เป็นรูปแบบที่ใช้น้อยมาก ๆ นั่นคือ สร้างระบบใหม่ขึ้นมาเลย ออกแนวทาง ทุบหม้อข้าวหม้อแกงก่อนออกรบนั่นเอง หรืออาจยังคง support ระบบเดิม

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

จากรูปแบบการย้ายไป Microservices ทั้ง 3 แบบ

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

You may also like

Business

Burnout in Tech: Is it real? คุยกับ 5 Developer ไทย กับปัญหาสุขภาพจิตในวงการ Tech

Burnout in tech น่าจะเป็นประเด็นที่คนในวงการหลายคนอาจคุ้นชิน แต่กับนอกนั้นเขาอาจเพียงเคยจินตนาการว่า Programmer และ Developer ส่วนใหญ่เริ่มต้นวันใหม่ของพวกเขาในการทำงานอย่างไร กาแฟสดใหม่ พร้อมกับโปรเจกต์ที่น่าตื่นเต้นที่รอพวกเขาแก้ไข หรือทำให้สำเร็จอยู่หรือเปล่า  ซึ่งทุกอย่างนั้นมี 2 ด้านเสมอ ...
Progressive Web App คืออะไร
Technology

Progressive Web Apps คืออะไร?

แค่เขียน Apps อย่างเดียวคงไม่พอ! เมื่อ Users เลือกดาวน์โหลด Apps เท่าที่จำเป็นเพื่อประหยัดพื้นที่ใช้งาน จากสถิติการใช้งานของ Users ที่ “ไม่ตัดสินใจติดตั้ง Apps” เพราะขั้นตอนที่ยุ่งยากและเลือกติดตั้งเฉพาะ Apps ...

More in:Technology

Data

Apache Airflow คืออะไร แล้วทำไมองค์กรชั้นนำส่วนใหญ่ถึงเลือกใช้

Apache Airflow คือ 1 ใน Workflow Management ที่ได้รับความนิยม และองค์กรชั้นนำระดับโลกหลายๆ องค์กรเลือกใช้ โดยเฉพาะอย่างยิ่งในการสร้าง Data Pipelines เพื่อจัดการกับข้อมูลจำนวนมหาศาล ส่วนหนึ่งเพราะองค์กรต่าง ...
8 เหตุผลทำไมควรเขียน Scala Technology

8 เหตุผลที่ Dev ควรลองเขียนภาษา Scala ตั้งแต่ตอนนี้

เราเคยเกริ่นถึงภาษา Scala ไปบ้างแล้วจากบทความ ภาษา Scala มีจุดเด่นอะไร? ทำไมกำลังมาแรงในสาย Developer และ Data Engineer แต่ในกลุ่มนักพัฒนาหลายคนยังสงสัยว่าภาษา Scala มีความเหมาะไปใช้ในงานแบบไหน? ทำไมถึงต้องหันมาศึกษา ...
ภาษา Scala คืออะไร Technology

ภาษา Scala มีจุดเด่นอะไร? ทำไมกำลังมาแรงในสาย Developer และ Data Engineer

Scala คือ ภาษา Programming ที่กำลังมาแรงและเริ่มมีความนิยมใช้กันขึ้นเรื่อย ๆ จุดเริ่มต้นภาษา Scala เรียกได้ว่าเป็นลูกอีกคนหนึ่งของภาษา Java เช่นเดียวกับภาษา Kotlin ที่พัฒนาต่อยอดมาเพื่อแก้ไขข้อบกพร่องบางอย่างของภาษา Java ในจุดประสงค์ที่แตกต่างกัน ...
Software Architecture Technology

3 Software Architecture Design ที่นิยมใช้พัฒนาระบบซอฟต์แวร์ขนาดใหญ่

ในการออกแบบซอฟต์แวร์ขนาดใหญ่ในองค์กร มักจะมีการทำงานร่วมกันโดยคนจำนวนมาก หากเราต่างคนต่างเขียนซอฟต์แวร์ไปในทางที่ตัวเองเห็นว่าดี ซอฟต์แวร์ที่แต่ละคนทำก็อาจจะทำงานร่วมกันไม่ได้หรือมีปัญหาตอนที่ Integrate เป็น Solution ใหญ่ ดังนั้น การทำซอฟต์แวร์ในระดับนั้นจึงจำเป็นต้องมีการแบ่งสันปันส่วน และมีการออกแบบ Software Architecture เพื่อให้ทำงานร่วมกันได้ดีและมองเห็นภาพรวมไปในทางเดียวกัน ทั้งระหว่างนักพัฒนาในทีมพัฒนากันเอง ...

Comments are closed.