ว่าด้วยเรื่องของ Microservices

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

Microservices คืออะไร

ถ้าเราจะต้องออกแบบระบบ หรือไปสังเกตว่าระบบไหนเป็น Microservices สามารถสังเกตจากคุณลักษณะ 6 ข้อ ของมันได้ดังต่อไปนี้

A microservice is responsible for a single piece of functionality

มีหน้าที่ในทำงานเพียงแค่อย่างเดียว ซึ่งการจะเขียน Services เพื่อแบ่งหน้าที่การทำงานได้ จะต้องศึกษาถึงขอบเขตของ Services (Type of Capability) ว่าจะแบ่งด้วยหลักเกณฑ์ใด โดย หลักๆ มีสองประเภท คือ

  1. A Business Capabilitiy : แบ่งตามจุดมุ่งหมายของ Business เช่น ทำมาเพื่อคำนวณราคาสินค้า, ทำเพื่อเก็บข้อมูลลูกค้าที่ใช้งาน Shopping Cart เป็นต้น โดยการแบ่งตามนี้ มักใช้แนวทางของ DDD (Domain-Driven Development) เข้ามาช่วย
  2. A Technical Capability : แบ่งตาม Technology ที่ถูกกำหนดขึ้น เช่น มี Services อื่นต้องการใช้งานกับ Services ของเรา และมีข้อจำกัดบางอย่าง ดังน้ัน ต้องออกแบบ Services ให้ทำงานร่วมกันได้

A microservice is individually deployable

มีอิสระต่อกัน ไม่ผูกพันกับส่วนอื่นๆ สามารถอยู่ได้ด้วยตัวเอง ถ้า Service ตัวหนึ่งพัง หรือปิดลง ตัวอื่นจะต้องไม่พังตามไปด้วย ดังนั้นการ Deploy จะเป็นอิสระจากระบบอื่นๆ ด้วย

 (ภาพจากหนังสือ Microservices in .Net Core)

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

A microservice consists of one or more processes

ใน Microservices สามารถมีได้หลาย Process แต่ว่า จะต้องไม่ไปเกี่ยวกับ Process ของ Services ตัวอื่นๆ เช่น ระบบ Shopping Cart กับ Product Category จะต้องไม่มี Process การทำงานที่ไปเกี่ยวข้อง ดังนั้น ถ้ามันผูกกันอยู่ และเราต้องการ Deploy Shopping Cart ใหม่ เราจำเป็นต้อง Deploy Product Category ด้วย ทั้งๆที่มันไม่ได้ถูกแก้ไข

 (ภาพจากหนังสือ Microservices in .Net Core)

A microservice owns its own data store.

มีจัดเก็บข้อมูล (Data) เป็นของตนเอง ดังนั้น ถ้า Services แต่ละตัวต้องการใช้ข้อมูลของ Services อื่นๆ จะต้องเรียกผ่าน API ของ Services นั้น จะไม่เรียกตรงไปที่ Database เพราะ ถ้าในแต่ละ Microservices สามารถใช้เทคโนโลยี Database ต่างกันได้ และก็มีโอกาสที่จะเกิดเปลี่ยนแปลงภายหลังได้ ดังนั้น ถ้า Database มีการแก้ไขเกิดขึ้น ตัว API Service ที่เรียกใช้ จะต้องแก้ตามไปด้วย และอีกเหตุผลหนึ่งคือ ส่วนของ Database มักต้องควบคุมเรื่อง Performance และ Scalability ที่จะเกิดขึ้นได้ตลอดเวลา ดังนั้น ถ้ามีส่วนอื่นๆมาเกี่ยวข้องด้วย จะทำให้ควบคุมการใช้งานได้ยาก

 (ภาพจากหนังสือ Microservices in .Net Core)

A small team can maintain a handful of microservices.

ทีมเล็กๆ ก็สามารถดูแลรักษา Microservices ตัวหนึ่งๆได้ สามารถใช้ภาษาเขียนหรือเทคโนโลยีตามที่ทีมถนัดได้ เพราะแต่ละ Services แยกออกจากกัน

ถามว่าทีมเล็กๆที่ว่าควรเป็นเท่าไร คือ ประมาณ 5 คน

A microservice is replaceable.

จะต้องถูกออกแบบมาให้ทดแทนได้ เพราะบางที Requirement เปลี่ยน หรือมีเทคโนโลยีที่เหมาะสมใหม่เข้ามา เช่น ภาษาที่ใช้เขียน, Database ทีมที่พัฒนาจะใช้เวลาเท่าเดิมหรือเวลาที่เหมาะสม ในการพัฒนาใหม่ เพื่อนำไปใช้ทดแทนของเดิมได้ทันที

หน้าตาของโครงสร้าง Microservices

ถ้าอธิบายด้วยรูป เทียบกับการออกแบบแบบเดิม กับ Microservices

 การออกแบบแบบเดิมตามชั้นการทำงาน (Traditional N-tier application architecture)
(ภาพจาก https://www.packtpub.com/)

การออกแบบแบบ Microservices
(ภาพจาก https://www.packtpub.com/)

ดังนั้น ถ้าสมมติว่าเราได้แตก Services ออกมา และมีหลาย Services เชื่อมโยงกัน ภาพจะได้ประมาณนี้


(ภาพจาก https://www.nginx.com/)

ทำไมเราต้องใช้ Microservices

พอเข้าใจและเห็นภาพของ Microservices กันบ้างแล้ว คำถามต่อมาคือ แล้วทำไมต้องใช้ หรือทำแล้วจะได้อะไร?

จาก คุณลักษณะ Microservices 6 ข้อ ข้างต้นที่ว่ามา จะทำให้เกิดผล 3 ข้อ ดังนี้

  • Malleable: พลิกแพลงระบบได้ง่าย (ระบบมี Flexible ยืดหยุ่น)
  • Scalable : สามารถขยายออกได้ (หรือมีความ Elastic หดเข้าขยายออกได้ง่าย )
  • Resilient : ตายไม่เป็น หรือเรียกกลับคืนได้ไว

ถ้ามองให้เห็นภาพว่า 3 ข้อดังกล่าว จะให้ประโยชน์อะไรกับเราได้บ้าง คือ

Enable continuous delivery

ไม่ใช่ว่าทำ CI/CD แล้วจะต้องทำ Microservices นะครับ แต่หมายถึง มันสอดคล้องกัน ทำให้เราสามารถใช้กระบวนการ CI/CD (Continuouse Integration/Continuouse Delivery) ได้ง่ายขึ้น เพราะ

  • พัฒนาระบบและแก้ไขได้ไว (ก็มันเล็กนี่นะ)
  • ทดสอบได้ด้วยการทำ automated tests (เพราะเล็ก ทดสอบการทำงานแค่อย่างเดียว ไม่ซับซ้อน)
  • Deploy ได้อย่างอิสระ
  • Operate ได้อย่างมีประสิทธิภาพ

ดังนั้นถ้าสอดคล้องกับการทำ CI/CD แล้ว สิ่งที่เป็นประโยชน์ตามมาในระดับ Business คือ

  • เพิ่มความเป็น Agility ให้เกิดขึ้น เพราะยืดหยุ่นและส่งมอบ product ได้ไวขึ้น
  • ทำให้ระบบน่าเชื่อถือขึ้น
  • ลดความเสี่ยง
  • และทำให้ product มีประสิทธิภาพมาขึ้น

High level of maintainability

มีสองมุมมองคือ

มุมมองของ Developer

  • ทำงานเพียงหนึ่งเดียว ง่ายต่อการพัฒนาและดูแล
  • เก็บข้อมูล (Data) ไว้ที่ตัวเอง และมีการกระทำจากแค่ภายใน Service ตนเอง ทำให้ง่ายต่อการเข้าใจระบบ
  • สามารถทำ Automated Test ได้ง่าย เพราะมี Process ทำงานเพียงเรื่องเดียว

อีกมุมคือ มุมมองของ Operatios

  • สามารถดูแลได้ด้วยทีมขนาดเล็ก
  • ง่ายต่อการ Monitor การทำงานของแต่ละ Service
  • มีการ Deploy ที่เป็นอิสระจากกัน

Robust and scalable

Microservices ง่ายต่อการขยาย เพราะเป็นอิสระต่อกัน ดังนั้น ถ้า Services ตัวใดต้องการขยายให้มีขนาดใหญ่ขึ้น(หรือเล็กลง) สามารถทำได้เฉพาะ Services นั้น ไม่จำเป็นต้องทำทั้งระบบ ประหยัดทรัพยากรได้ทางอ้อมด้วย

หลังจากได้รู้จัก Microservices ไปแล้ว ยังอยากทำอยู่หรือเปล่าครับ?

อ้างอิง

ตรวจสอบคุณภาพของ Code ด้วย SonarQube

โปรแกรมเมอร์ส่วนใหญ่จะมุ่งมั่นพัฒนา Software ให้เสร็จตามเวลาที่กำหนด จนบางทีก็ละเลยแบบตั้งใจและไม่ได้ตั้งใจ ที่จะทำให้ Source Code ที่เขียน มีคุณภาพหรืออย่างน้อยก็ได้ตามมาตรฐานที่มันควรจะเป็น

เรื่องเหล่านี้บางคนอาจไม่ค่อยอินเท่าไร หากทำงานคนเดียว หรืองานที่เร่งด่วนมากๆ (“งานร้อน” นั่นหละ) โดยเฉพาะงานทำครั้งเดียวเสร็จ ส่ง รับเงิน แล้วก็แยกย้าย.. แต่กับอีกหลายคนที่ต้องทำงานเป็นทีม หรือมี QA , CTO, Team Lead คอยเข้ามาตรวจสอบการทำงานของ Software และ Review Code อยู่สม่ำเสมอ ก็คงต้องปวดหัวกลับมาแก้งานรายชั่วโมง จนไม่ต้องทำมาหากิน

วันนี้เลยเอาเครื่องมือว้าวๆ ตัวหนึ่งชื่อ SonarQube มาให้ลอง มันเป็นตัวที่ช่วยตรวจสอบคุณภาพของ Source Code ให้เราได้แบบอัตโนมัติ  Continue reading “ตรวจสอบคุณภาพของ Code ด้วย SonarQube” »

เริ่มต้นทำ CI/CD – Automation Deployment ด้วย Git และ Jenkins (3 – จบ)

ความเดิมสองตอนก่อนคือ วิธีติดตั้ง Jenkin และ วิธีใช้ PHPUnit เพื่อทำ Automation Test ซึ่งเราก็ได้เห็นภาพของ CI (Continuous Integration) กันมาแล้ว มาบล็อกครั้งนี้เป็นตอนสุดท้ายของซีรี่ “เริ่มต้นทำ CI/CD” ก็คือ หลังจากเขียนโค้ดและทดสอบผ่านทั้งหมด เราจะให้ Jenkins นำโค้ดที่ทำเข้าสู่ Production Server ให้อัตโนมัติ (Automation Deployment) Continue reading “เริ่มต้นทำ CI/CD – Automation Deployment ด้วย Git และ Jenkins (3 – จบ)” »

เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)

บล็อกที่แล้วเขียนเรื่อง วิธีติดตั้ง Jenkin ไว้ เพื่อเตรียมทำ CI (Continuous Integration)
แต่ก่อนจะไปถึงตรงนั้น นอกจากต้องใช้ Version Control เป็นแล้ว ก็ต้องมีวิธีการทดสอบโค้ดที่เขียนก่อน

และคุณประโยชน์ที่เราจะไปใช้ Scrum เพื่อทำ Agile คือ การส่งมอบงาน หรือ Software ที่ใช้ได้ ให้ได้ไวๆ
ดังนั้น การส่งมอบให้ได้ไว คือการทำงานเป็นรอบ และการทำงานเป็นรอบ เราจะได้ผลตอบรับไว (fast feedback) ว่าใช่หรือไม่ใช่ ผิดหรือถูก

เช่นกัน Software ที่ใช้ได้และส่งมอบงานได้ไว ก็ต้องมี Automate Test ที่ทำงานได้แทนเรา และครอบคลุม หนึ่งในนั้นคือ Unit Test Continue reading “เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)” »

เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)

ตอนแรกว่าจะเขียนรวดเดียวจบถึงวิธีทำ CI/CD (Continuous Integration and Continuous Deployment) ด้วย Jenkins และ Bitbucket แต่พอเขียน Jenkins จบ รู้สึกว่ายาวไปหน่อย เลยขอตัดเอาเป็น Jenkins ก่อนก็แล้วกันนะ

Jenkins เป็น Automation Tools ที่เอาไว้ทำอะไรต่างๆแบบอัตโนมัติ ซึ่งในที่นี้เราเอามันไปใช้ทำ CI/CD เพื่อช่วยชีวิตนักพัฒนาอย่างเราให้สบายขึ้น อบย่างเช่น นักพัฒนาเพียงแค่เขียนโค้ด นำขึ้น Git แล้วให้ Jenkins ทำการทดสอบจากที่เราตั้งค่าไว้ ไม่ว่าจะ Robot Framework หรือ Test Unit ก็ตาม เมื่อผ่านเรียบร้อย ก็นำกลับไป Merge Code เข้า Git หรือจะ Deploy ต่อไปยัง Server ก็ว่ากันไป (ซึ่งผมจะเขียนบล็อกสอนทำตามนี้แหละ) Continue reading “เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)” »