หลังจากที่ทำการศึกษาและพัฒนาระบบด้วยแนวคิด Microservice
แล้วพบว่าแต่ละคนจะมีการถกเถียงว่าความหมายว่าคืออะไรกันแน่
และทำไมจึงมีความสำคัญอย่างไร ?
ดังนั้นจึงลองสรุปเกี่ยวกับ Microservice ออกมาดูบ้างว่าเป็นอย่างไร
เริ่มที่ความหมายของ Microservice
โดยให้ความหมายไว้ดังนี้
- มีขอบเขตของปัญหาที่เล็ก
- สามารถ build และ deploy ได้ด้วยตัวเอง
- สามารถทำงานอยู่บน process ของตัวเอง
- สามารถ integrate กับส่วนอื่นๆ ผ่าน interfaceท ที่กำหนด
- มีที่เก็บข้อมูลของตัวเอง
อธิบายเพิ่มเติม
1. มีขอบเขตของปัญหาที่เล็ก
ยิ่งเล็กยิ่งดี แต่เล็กเท่าไรดีล่ะ
ถ้าจะให้ดี ต้องทำงานเรื่องใดเรื่องหนึ่งเลยเท่านั้น
เช่นระบบการฝากเงินก็ทำแต่ฝากเงินเท่านั้น ส่วนการถอน โอน ก็แยกออกไปอีก
ส่งผลทำให้จำนวนบรรทัดของ code น้อยลงไปด้วยเช่นกัน
ซึ่งถ้าจำนวนบรรทัดประมาณ 500-1,000 บรรทัดแล้ว
ก็ควรที่จะต้องแยกออกเป็น service ย่อยๆ แล้วนะ !!
2. สามารถ build และ deploy ได้ด้วยตัวเอง
แต่ละ Microservice ควรจะเป็นแบบ standalone นะ
สามารถ build, deploy และทำงาน อย่างอิสระ ไม่ขึ้นอยู่กับใคร
ส่งผลให้ service นั้นๆ ทดสอบได้ง่าย integrate ได้ง่าย
และแน่นอนว่า ช่วยลดความซับซ้อนของระบบ
รวมทั้งการเปลี่ยนแปลงบน production server นั้นจะทำการแก้ไขเล็ก ในแต่ละ service
ทำให้รูปแบบการ deploy เปลี่ยนไปคือ เป็นการ deploy service เล็กๆ หลาย service แทน
ส่งผลให้ความเสี่ยงเรื่องการ deploy ลดลงไป
3. สามารถทำงานอยู่บน process ของตัวเอง
เนื่องจากมันทำงานแบบ standalone ทำให้เราสามารถเปลี่ยนแปลงเทคโนโลยีการพัฒนาได้ง่าย
แต่ละ service สามารถด้วยภาษาโปรแกรมที่ต่างกันตามความเหมาะสมได้
สามารถทำงานแยกกันตาม server หรือ VM ก็ได้
4. สามารถ integrate กับส่วนอื่นๆ ผ่าน interface ที่กำหนด
แต่ละ Microservice นั้นทำงานแบบแยกกันชัดเจน
ติดต่อสื่อสารกันผ่าน interface
ส่วนใหญ่จะทำงานอยู่บน HTTP protocol
แต่ไม่ใช่ว่าจะต้องผ่าน protocol นี้เสมอนะครับ เช่น Thrift RPC, Java RMI และ Protocol Buffer เป็นต้น
หรืออาจจะผ่าน messaging queue และ notification service ก็ได้
ทำให้การทดสอบระดับ integration สามารถใชวิธีการ mock และ stub
ในการทดสอบ service ต่างๆ ได้
5. มีที่เก็บข้อมูลของตัวเอง
ถ้าระบบของเราทำการแยกเป็น Microservice แล้ว
แต่ที่เก็บข้อมูลหรือ database ยังอยู่ที่เดียวกัน
นั้นเป็นแนวทางที่แย่มากๆ
เนื่องจากมันทำให้ Microservice ไม่เป็นอิสระจากข้อมูล
รวมไปถึงโครงสร้าง และที่จัดเก็บข้อมูลนั่นเอง
และทำให้ระบบมันผูกติดกันมาก จนเกิดความซับซ้อนในที่สุด
ดังนั้น Microservice ควรที่จะเป็นที่จัดเก็บข้อมูลของมันเอง
โดยไม่กระทบกับระบบอื่นๆ เลย จะสนใจเพียงระบบภายในเท่านั้น
ดังนั้น ถ้าคุณบอกว่าว่าคุณกำลังพัฒนาระบบตามแนวคิด Microservice แล้ว
ลองตรวจสอบว่าคุณทำครบทั้ง 5 ข้อหรือไม่นะ ??
ตัวอย่างของสิ่งที่ไม่ใช่ Microservice ( แต่ก่อนผมเข้าใจว่ามันใช่ !! )
- service ที่ดูแลเรื่องการจัดเก็บข้อมูลอย่างเดียว
- service ที่ต้องการข้อมูลจาก service อื่นๆ แล้วนำมาแสดงผล
ทำไมเราต้องมาพูดถึง Microservice กันด้วย
เมื่อประมาณ 15 ปีที่แล้วเรารู้จักกับคำว่า SOA ( Service Oriented Architecture ) กัน
ซึ่งพอจำได้ว่า WebService มันคือสถาปัตยกรรมแห่งอนาคต โดย Microsoft มั้ง
แต่ในปัจจุบันวันเวลาและสิ่งต่างๆ ได้เปลี่ยนแปลงไปอย่างมาก
ทั้งแนวคิดเรื่องของ architecture
ทั้งในเรื่องของการติดต่อสื่อสารระหว่างระบบ
กล่าวคือ
น่าจะเคยอ่านหนังสือเรื่อง Domain Driven Design ( DDD )
ช่วยทำให้เราชาวเทคโนโลยีรู้ว่า จะสร้าง business process ใน software ที่ดีขึ้นได้อย่างไร
ซึ่งเป็นแนวทางที่ดีมาก สำหรับการแยก domain ต่างๆ ออกมาเป็น Microservice
ต่อมาก็เรื่องของ
REST ที่เปลี่ยนรูปแบบของ interface ของ service ต่างๆ
JSON ที่เข้ามาเปลี่ยนรูปแบบของข้อมูลที่ใช้ติดต่อสื่อสารหรือแลกเปลี่ยนกัน
ทั้งสองอย่างที่เข้ามา ทำให้การเชื่อมต่อระหว่าง service เป็นอะไรที่เรียบง่าย และ สร้างได้อย่างรวดเร็ว
กว่าที่เคยเป็นมา …
ในปัจจุบันจะเห็นว่ามี Micro web framework ถูกพัฒนาออกมาอย่างมากมาย เช่น
- Sinatra
- Flask
- Spark
- Dropwizard
- Springboot
- Silex
มันทำให้การสร้าง service นั้นง่าย และ เร็ว อย่างไม่เคยเกิดขึ้นมาก่อน
แล้วข้อเสียของ Microservice ล่ะมีอะไรบ้าง ?
แน่นอนว่า ทุกสิ่งทุกอย่างมันมีข้อดี ก็ต้องมีข้อเสียเสมอ
ยิ่งในโลกของ architecture แล้วยิ่งสามารถหยิบยกมาพูดคุยกันได้เยอะแยะ
ก่อนที่จะเลือกใช้อะไรนั้น เราต้องศึกษาทั้งข้อดีและข้อเสีย
เพื่อนำมาตัดสินใจว่าจะเลือกแนวทางใด
ตัวอย่างของข้อเสีย เช่น
Cascading failure คือ เมื่อระบใดระบบหนึ่งล่มไป อาจจะทำให้ระบบรอบข้างทั้งหมดล่มไปด้วย
ซึ่งแน่นอนว่า มันสามารถเกิดได้กับทุกๆ ระบบ
แต่ดชคดีหน่อยที่ปัญหานี้ มันมีรูปแบบที่ชัดเจน
ทำให้เราต้องให้ความสำคัญเรื่องนี้ตอนออกแบบ Microservice
เรื่องการเปลี่ยนแปลง requirement อาจจะทำให้เราไม่สนใจเรื่องการแก้ไข service
แต่เราจะสร้าง service ใหม่ๆ ขึ้นมา หรืออาจจะสร้างใหม่มา 3 service
เพื่อทำมาแทนที่ service เก่า ทำให้ service มันเยอะมากๆ
แต่เมื่อย้อนกลับไปดูความหมายของ Microservice จะพบว่ามันจะเล็ก
ดังนั้นมันเอื้อให้เราแก้ไขมากกว่าการสร้างใหม่ เนื่องจากมันเล็กๆ นะ
ทีมพัฒนา Microservice ควรเป็นอย่างไร
ในแนวทางของผมควรที่จะยึดแนวปฏิบัติ Devops ไว้เสมอ
เนื่องจาก Microservice มันเล็ก ดังนั้นในการจะแก้ไข หรือ เปลี่ยนแปลง
ทั้งบน development และ production จะเกิดขึ้นบ่อยครั้งมากๆ
ดังนั้น ทีมต้องมันใจได้ว่า ตัวเองสามารถบริหารจัดการ service ได้ด้วยตัวเอง
ส่วนตัวผมเชื่อว่า ทีมพัฒนาควรที่จะเป็นทีมที่เล็กพอ
เท่าที่สามารถบริหารจัดการ service ได้เอง หมายถึงการติดตั้งและ support ด้วยนะ
โดยสมาชิกในทีมแต่ละคนจะมีความสามารถหลักมากกว่าหนึ่งเสมอ
แต่ถ้าถามว่าไม่ต้องมี Devops หรือแนวปฏิบัติแบบนี้หรอก จะทำให้สามารถพัฒนา Microservice ได้ไหม
ผมก็ตอบว่า ได้ แต่จำเป็นต้องนำกลุ่มคนที่มีความรู้ด้วย technology เข้ามา
รวมทั้งต้องเปลี่ยนเจ้าของ deployment process
เปลี่ยนจัดการ production server ใหม่ล่ะ
เพื่อทำให้ system administrator เข้ามาเป้นส่วนหนึ่งของทีมพัฒนา
แล้วมันจะทำให้เห็นถึงประโยชน์ของ Microservice นะครับ
มาถึงตรงนี้พอจะทำให้เห้นถึงความสำคัญของ Microservice บ้างไหม ?
ลองถามตัวเองว่า มีเหตุผลอะไรบ้างที่คุณจะไม่ยอมลงทุนลงแรงกับ Microservice ?
Reference Website
http://www.brunton-spall.co.uk/post/2014/05/21/what-is-a-microservice-and-why-does-it-matter/
