Microservices ถือเป็นเทคนิคหนึ่ง ในการพัฒนา Software ที่มีความน่าสนใจเพิ่มขึ้นเรื่อย ๆ ควบคู่ไปกับแนวโน้มอื่น ๆ อย่าง Cloud-Native, Agile Development ในช่วงทศวรรษที่ผ่านมา ที่โดดเด่นที่สุดคือ การใช้ Containers เป็นเครื่องมือในการ Deploy Software Components และในบทความนี้จะพูดถึงว่า Microservices คืออะไร และสำคัญอย่างไรต่อองค์กร
มีการใช้งาน Microservices เพิ่มขึ้นในช่วงหลายปีที่ผ่านมา จากผลการสำรวจโดย O’Reilly ในปี 2020 จากกว่า 1,500 องค์กร พบว่ามีเพียงประมาณ 1 ใน 4 เท่านั้น ที่ไม่ได้ใช้ Microservices จาก 75% ที่มีอยู่ และมีเพียง 10% ที่ใช้งาน Microservices มานานกว่า 5 ปี นั่นหมายความว่า องค์กรส่วนใหญ่เพิ่งเริ่มหันมาใช้ Microservices ในช่วงไม่กี่ปีที่ผ่านมา
Microservices ไม่ใช่เทคโนโลยีเฉพาะทาง แต่มันเป็นรูปแบบของ Software Architecture และแนวทางในการออกแบบ Applications และ Services แทนที่จะสร้าง Application เป็น Single Monolithic Entity แต่การทำแบบ Microservices คือ การแยก Function การทำงานที่จำเป็น ออกเป็นส่วนย่อยเล็ก ๆ และเป็น Services ที่สามารถ Deploy ได้อย่างอิสระ
วิธีการนี้มีข้อดีหลายประการ ซึ่งหนึ่งในนั้นก็คือ สามารถปรับขนาดได้ง่าย เนื่องจาก Components แต่ละส่วนสามารถปรับขนาดได้อย่างอิสระต่อกัน โดยเฉพาะส่วนของ Application ที่อาจประสบปัญหาเรื่องต้องมีการปรับเปลี่ยนอยู่เสมอ อย่างเช่น เมื่อจำเป็นต้องปรับขนาด Application โดยทั่วไปแล้วเรามักจะสร้าง Instances ใหม่ ๆ ของ Component นั้น เพื่อสร้าง Balance ของ Workload แทนที่จะปรับขนาดทั้ง Application
Microservices ยังช่วยในเรื่อง Agile Development Process เนื่องจาก Component Parts ที่มีขนาดเล็กลง จะช่วยทำให้การปรับปรุงอย่างต่อเนื่องนั้น ทำได้ง่ายขึ้น และช่วยให้ Update Code ได้เร็วยิ่งขึ้นด้วย นอกจากนี้ยังทำให้สามารถใช้ Programming Languages ต่าง ๆ กับ Components ต่าง ๆ ได้สะดวกขึ้น เนื่องจากบางภาษาอาจเหมาะกับงานบางประเภทมากกว่า เนื่องจากการที่ Component Parts มีขนาดเล็ก จึงช่วยให้ Developers สามารถเข้าใจ Code ได้ง่ายขึ้น ทำให้เพิ่มในเรื่อง Reliability มากขึ้น
ข้อดีอีกประการหนึ่งก็คือ เพิ่มศักยภาพในการลด Downtime จาก Fault Isolation หากมี Microservice Instance ตัวใดตัวหนึ่งล้มเหลว ก็มีโอกาสน้อยที่จะทำให้ Application และ Service ทั้งหมดล่ม
ข้อเสียที่อาจเกิดขึ้น
แม้ว่า Microservices จะมีข้อดีหลายข้อ แต่ก็มีข้อเสียบางอย่างที่องค์กรต้องให้ความสำคัญ อย่างเช่น แม้ว่าการพัฒนาแต่ละ Microservice Component อาจจะไม่ยากอะไรนัก แต่เมื่อพูดถึง Application และ Service ทั้งหมด อาจมีความซับซ้อนในการจัดการที่มากขึ้น
โดยเฉพาะอย่างยิ่งเมื่อมีการ Deploy ในขนาดต่าง ๆ ซึ่งอาจเกี่ยวข้องกับ Instances ของ Microservice Components ที่แตกต่างกันนับหลายสิบหรือหลายร้อย Components ความซับซ้อนอาจไม่ได้มาจากการจัดการเรื่อง Communication ระหว่าง Instances ที่แยกจากกันทั้งหมดเท่านั้น แต่ยังต้องตรวจสอบแต่ละรายการเพื่อให้แน่ใจว่า พวกมันกำลังทำงานภายใต้ Parameters ที่ต้องการ และจะต้องไม่ใช้ Resource เกินกว่าที่กำหนดไว้ ซึ่งจะช่วยบ่งชี้ได้ง่ายกว่า ว่ามันมีปัญหาอยู่ตรงไหน
การ Test และ Debug ก็อาจกลายเป็นสิ่งที่ท้าทายมากขึ้นด้วย Microservices เพราะ การหาแหล่งที่มาของ Bug อาจทำได้ยากกว่า ในท่ามกลาง Web ของ Microservice Instances โดยแต่ละรายการจะมีกลุ่ม Logs ของตัวมันเอง ซึ่งการ Test Application ทั้งหมด อาจทำได้ยากเช่นกัน เนื่องจาก Microservice แต่ละรายการจะสามารถูก Test ได้อย่างถูกต้องก็ต่อเมื่อ Services ที่เกี่ยวข้องทั้งหมดได้รับการ Test แล้ว
โดยเฉพาะอย่างยิ่ง การ Monitor นั้นมีความสำคัญมากใน Microservice Deployment แต่ด้วยธรรมชาติของ Components ที่อยู่กระจายกัน ทำให้เกิดความซับซ้อนกว่า Application แบบเดิม ในการ Monitor System จะต้องทำงานที่ Level ของ Microservice Instance แต่ละอัน ในขณะเดียวกันจะต้องคอยจับตาดู Web ของ Dependencies ระหว่าง Components ต่าง ๆ ด้วย
วิธีการทำงานของ Microservices ก็มีผลกระทบต่อ Infrastructure ขององค์กรด้วยเช่นกัน การรองรับการปรับขนาดแบบอัตโนมัติ เพื่อตอบสนองความต้องการที่เพิ่มขึ้น ก็เป็นการบอกเป็นนัย ๆ ว่า ทรัพยากรสำหรับ Microservice Instances ใหม่ จะต้องมีความสามารถในการจัดเตรียมเผื่อไว้ล่วงหน้าด้วยการเรียก Application Programming Interface (API) ซึ่งหมายถึง Infrastructure ที่ถูกกำหนดด้วย Software นั้น จะมีความเหมือนกับ Cloud ในระดับหนึ่ง
Data ก็อาจเป็นอีกหนึ่งปัญหาที่สร้างความยุ่งยาก เมื่อสร้าง Applications หรือ Services ตาม Microservices Architecture หรือเพื่อให้แม่นยำมากขึ้น ควรหาว่าจะจัดเก็บ Data ไว้ที่ใด เนื่องจาก Microservice Instance แต่ละรายการควรจะมีที่เก็บ Data เป็นของตัวเอง แต่บาง Applications อาจต้องการความสามารถในการเข้าถึง Shared Repository การมี Services ที่แตกต่างกันนั้น จะมีข้อกำหนดในการจัดเก็บ Data ที่แตกต่างกันไปด้วย ซึ่งบางคนก็มีความเห็นว่า NoSQL Database ดูจะเหมาะสมที่สุด ในขณะที่คนอื่น ๆ สนับสนุนให้เกาะติดกับ SQL ไว้ หากนั่นคือ สิ่งที่องค์กรได้มีการ Deploy แล้ว
มีความคิดเห็นอื่นที่แตกต่างกันในประเด็นนี้ โดยผู้เชี่ยวชาญบางคนก็แนะนำว่า Single Database (แต่อาจไม่ใช่ Single Schema) ที่ใช้ Services ต่าง ๆ ร่วมกัน ดูจะเป็นแนวทางที่ดีที่สุด เพราะ มันจะช่วยให้องค์กรสามารถนำ Procedures ที่มีอยู่ กลับมาใช้งานใหม่สำหรับการ Backup และ Restore Database แต่บางคนก็ไม่เห็นด้วยกับสิ่งนี้ เพราะมันอาจจะสร้าง Single Point of Failure (SPOF: หากมีส่วนใดส่วนหนึ่งของระบบล้มเหลว จะทำให้ระบบทั้งหมด หยุดทำงานโดยสิ้นเชิง) ซึ่งมันขัดต่อหลักการของ Microservices
ควรวางแผนอย่างรอบคอบ
สรุปคือ แม้ว่า Microservices Architecture อาจไม่เหมาะกับทุกองค์กร หรือ Application ทุกประเภทก็ตาม แต่ เหตุผลที่มันถูกนำไปใช้งานเพิ่มขึ้นก็คือ Microservices ทำให้ง่ายมากขึ้นต่อการ Implement แบบ Agile ในการ Deploy Services ซึ่งเป็นสิ่งที่หลายองค์กรกำลังมองหา
“องค์กรต่าง ๆ ที่หันมาใช้งาน Microservices มักจะมีความล้ำหน้ามากกว่าองค์กรอื่น ๆ” Clive Longbottom, Independent Analyst กล่าว “ด้วยเหตุนี้ พวกเขามักจะเปิดกว้างมากขึ้นในการคิดเกี่ยวกับ การย้ายไปสู่ Architectural Topology Needs แบบใหม่ ซึ่งในอดีตแล้วการเปลี่ยนแปลงส่วนใหญ่จะเป็นแบบค่อย ๆ เป็น ค่อย ๆ ไป: Microservices Architectures ที่ประสบความสำเร็จนั้น เป็นแบบค่อย ๆ เป็น ค่อย ๆ ไป ซึ่งต้องมีการคิดใหม่ทั้งหมดเกี่ยวกับสิ่งที่กำลังทำอยู่”
กล่าวอีกนัยหนึ่ง, Microservices อาจเหมาะกับ “Green Field” Deployment ซึ่งเป็นการทำใหม่ทั้งหมดตั้งแต่เริ่มต้น มากกว่าที่จะทำกับ องค์กรที่กำลังพยายาม Refactor หรือต้องการ Update Application ที่มีอยู่
ตามที่ได้กล่าวไว้, Software Containers ที่เป็นแบบ Docker เป็นเทคโนโลยีที่เกี่ยวข้องกับ Microservices แม้ว่ามันจะเป็นเพียงวิธีหนึ่งในการปรับใช้ Distributed Deployment อย่าง Microservices ส่วนวิธีอื่น ๆ ซึ่งอาจรวมถึง Lightweight Virtual Machines หรือแม้แต่การใช้ Microservice Instances เป็น Non-Virtualised Code ที่ทำงานใน Server Environment เช่นเดียวกับ Application ใช้กันอยู่ทั่วไป Serverless Computing Functions อาจจะเป็นอีกหนึ่งวิธีในการนำ Microservices ไปใช้
บางที Containers อาจมีความเหมาะสมมากกว่า Virtual Machines เนื่องจากใช้ Resource น้อยกว่า และสร้าง Container Instance ใหม่ได้เร็วกว่าการสร้าง Virtual Machine ใหม่ Containers เป็นเทคโนโลยีที่ได้รับการพัฒนามานานแล้ว ด้วย Ecosystem ขนาดใหญ่ของ Tools เพื่อรองรับ Orchestration (เช่น Kubernetes), Communications (เช่น Istio) และการ Monitor
และอีกสิ่งที่น่าสนใจคือ จากการสำรวจของ O’Reilly พบว่าสัดส่วนที่สูงกว่าค่าเฉลี่ยของผู้ตอบแบบสอบถามที่ประสบความสำเร็ใจในการใช้ Microservices เลือกที่จะใช้ Containers ในขณะที่ผู้ตอบแบบสอบถามอีกส่วนหนึ่ง บอกว่า ที่ความพยายามในการใช้ Microservices ของพวกเขาไม่ประสบความสำเร็จนั้น ก็เป็นเพราะ พวกเขาไม่ได้ใช้ Containers
นี่อาจเป็นข้อแนะนำว่า Containers ดูจะเป็นตัวเลือกที่มีความเสี่ยงน้อยกว่าเมื่อใช้ Microservices แต่อย่างไรก็ตาม สิ่งที่สำคัญที่สุดคือ การเลือกใช้เทคโนโลยีที่เหมาะสมสำหรับ Applications และ Requirements ของแต่ละองค์กร
การสร้าง Microservices ถือว่ามีความซับซ้อนในอีกรูปแบบหนึ่ง ซึ่งแตกต่างจากรูปแบบของ Application แบบดั้งเดิมแบบ Monolithic ด้วยเหตุผลนี้จึงอาจถือได้ว่า มันดูเหมือนจะเป็นเทคโนโลยีที่เหมาะสมมากกว่าสำหรับ Cloud-Native Applications สมัยใหม่ที่ถูกสร้างขึ้นใหม่ทั้งหมด หรือสำหรับองค์กรที่ต้องการเปลี่ยนระบบไอทีของพวกเขา ซึ่งเป็นส่วนหนึ่งของ Digital Transformation Process
ทั้งหมดนี้คือเหตุผลที่ว่า Microservices คืออะไร และสำคัญอย่างไรต่อองค์กร และหากคุณเป็นคนไอทีและยังชอบความท้าทายของโลกไอที สามารถติดต่อ ISM Technology Recruitment และส่ง Resume ของคุณมาได้ที่ https://www.ismtech.net/submit-your-resume เพื่อให้เราช่วยหางานที่ใช่สำหรับคุณ
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการมากว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
Source: https://www.computerweekly.com/