
สถาปัตยกรรมไอทีมีการเปลี่ยนแปลงไปอย่างมากในช่วงหลายปีที่ผ่านมา ส่วนหนึ่งเป็นผลพวงจากเทคโนโลยีที่ได้รับการพัฒนาให้ดี มีประสิทธิภาพ และเป็นไปตามแนวคิดใหม่ๆ มากขึ้น และอีกส่วนหนึ่งก็เนื่องมาจากปัญหาและข้อผิดพลาดที่วิศวกรได้เรียนรู้และแก้ไขจากการออกแบบสถาปัตยกรรมแบบเดิมๆ หนึ่งในตัวอย่างที่เราเห็นได้ชัด คือ การเปลี่ยนผ่านจากระแบบแบบ Monolithic ไปเป็นระบบแบบ Microservices ที่ประกอบด้วยองค์ประกอบที่ต่างมีหน้าที่เป็นของตัวเองไม่พึ่งพาส่วนอื่นๆ

Monolithic คืออะไร ทำไมถึงกลายเป็น Microservices?
ในการจะสร้างระบบหรือแอปพลิเคชันขึ้นมาใช้สักตัว ย่อมมีองค์ประกอบหลายส่วน ไม่ว่าจะเป็นหน้าตาของแอปพลิเคชัน ฐานข้อมูล ส่วนที่ทำการให้เหตุผล คำนวณ ตัดสินใจ หรือส่วนประกอบอื่นๆ โดยในยุคแรกๆ ส่วนประกอบนี้ถูกพัฒนาไปด้วยกันเป็นชิ้นเดียว เพื่อให้ทำงานร่วมกันได้อย่างสมบูรณ์
แต่ปัญหาที่เกิดขึ้นคือ เวลา เมื่อเวลาผ่านไป อาจมีส่วนประกอบที่เราต้องการเพิ่มลงไปในระบบมากขึ้น เมื่อเวลาผ่านไป อาจมีส่วนหนึ่งที่เราอยากหยิบยกไปใช้ในระบบใหม่ เมื่อเวลาผ่านไป อาจมีส่วนหนึ่งที่อยากเปลี่ยนเทคโนโลยี แต่ในเมื่อทั้งหมดเป็นเนื้อเดียวกัน การจะเข้าไปแก้ไข เปลี่ยน หรือเพิ่มอะไรบางอย่างก็ย่อมซับซ้อน เพราะนักพัฒนาจะต้องเข้าไปศึกษาทั้งระบบและแยกออกมาให้ได้ว่าโค้ดส่วนไหนคือส่วนที่ต้องแก้ และการแก้นั้นจะส่งผลกระทบกับโค้ดอื่นๆ ในส่วนใดอีก
Microservices เป็นแนวคิดที่เริ่มต้นจากการที่องค์กรขนาดใหญ่ต้องการนำ Service บางส่วนของระบบ Monolithic ออกมาแยกเป็น Service เดี่ยวเพื่อให้ระบบอื่นสามารถเข้ามาใช้ Service นี้ร่วมกันได้ในรูปแบบที่เรียกว่า Service-Oriented Architecture และต่อมาแนวคิด Microservices ก็เริ่มแพร่หลายในช่วงปี 2000 ต้นๆ จากการเข้ามาของ Web Services ซึ่งตลอดช่วงเวลาที่ผ่านมาก็มีการพัฒนาแนวคิด แนวทางปฏิบัติ และการนำแนวคิดดังกล่าวไปใช้ในการออกแบบระบบและแอปพลิเคชันมากมาย

Microservices เข้ามาช่วยแก้ไขจุดอ่อนของระบบแบบ Monolithic ที่ทุกส่วนควบรวมเป็นเนื้อเดียวกัน มีความซับซ้อนคาบเกี่ยวพึ่งพากันสูง และสเกลได้ไม่ดีนัก ด้วยการแบ่งแยกระบบหรือแอปพลิเคชันออกเป็นองค์ประกอบย่อยๆ ที่ต่างมีหน้าที่แยกส่วนแต่ทำงานร่วมกัน ความซับซ้อนในแต่ละส่วนก็น้อยลง หากส่วนใดส่วนหนึ่งชำรุดชั่วคราวส่วนอื่น ๆก็ยังสามารถทำงานต่อไปได้ การดูแลรักษา หรือนำส่วนประกอบออกไปใช้กับงานอื่นๆ ก็ง่ายขึ้น อีกทั้งยังสามารถเลือกสเกลแต่ละ Service ได้อย่างมีประสิทธิภาพตามทรัพยากรที่ส่วนนั้นๆ ต้องการ
ความแพร่หลายของ Microservices นี้นำไปสู่ความจำเป็นในการใช้ API ซึ่งเรียกได้ว่าเป็นช่องทางในการสื่อสารระหว่าง Service ต่างๆใ นระบบแบบ Microservices โดย API มักถูกพัฒนาขึ้นเพื่อเป็นช่องทางในการเชื่อมต่อกับฟังก์ชันของ Service ที่เปิดให้บุคคลภายนอกใช้ โดยผู้ที่เข้ามาเชื่อมต่อไม่จำเป็นจะต้องเข้าใจถึงกลไกการทำงานและความซับซ้อนที่ซ่อนอยู่ข้างใน เมื่อมี API การพัฒนาให้ Service ต่างๆ ในระบบสื่อสารกันได้ก็ย่อมสะดวกและรวดเร็วขึ้น โดยในปัจจุบัน API ที่นิยมใช้งานกันมากทื่สุดคือ RESTful API ซึ่งสื่อสารกันผ่าน HTTP และมีโครงสร้างของข้อความเป็น JSON หรือ XML

จาก API สู่ API Gateway
แน่นอนว่าการเชื่อมต่อระหว่าง Service ต่างๆ นั้นจะขาดการรักษาความมั่นคงปลอดภัยไปเสียไม่ได้ และเมื่อ API เป็นประตูเชื่อมต่อ ก็ย่อมต้องมีตัวล็อคประตูตามไป ทว่าระบบแบบ Microservices นั้นไม่เหมือน Monolithic ที่การไขกุญแจเข้าบ้านหนึ่งครั้งเท่ากับการเชื่อมต่อกับทุกอย่างในระบบ เพราะ API และ Service แต่ละตัว ก็จำเป็นจะต้องมีการรักษาความมั่นคงปลอดภัยให้กับ API ของตัวเอง ดังนั้น แปลว่าหากต้องการเชื่อมต่อกับ Service ใดผ่าน API ก็ต้องมีการพิสูจน์ตัวตน (Authentication) ด้วย
อย่างไรก็ตาม หากลองนึกภาพว่าในการจะเชื่อมต่อ Service แต่ละครั้ง นักพัฒนาต้องผ่านขั้นตอน Authentication ด้วย Credential (เช่น API Key) ที่แตกต่างกันออกไป เมื่อต้องเชื่อมต่อหลาย Service เข้า จำนวนครั้งที่ต้องยืนยันตัวและกุญแจไขประตูที่ต้องเก็บก็ยิ่งเยอะตามไปด้วย การทำเช่นนี้นั้นทั้งเสียเวลาและมีความเสี่ยงที่จะถูกขโมยกุญแจไป ในระบบสมัยใหม่จึงมีสิ่งที่เรียกว่า API Gateway เข้ามาช่วยทำหน้าที่จัดการความมั่นคงปลอดภัยและการเข้าถึง Service แต่ละตัว
จากภาพประกอบด้านล่าง นักพัฒนาอาจนำ API Gateway เข้ามาช่วยเป็นระบบรักษาความมั่นคงปลอดภัยแบบ Heavy (เช่นการล็อคอินด้วย Username และ Password) ซึ่งจะช่วยยืนยันตัวตน และส่งต่อความมั่นคงปลอดภัยแบบ Light (เช่น Access Token) ไปยัง API ของ Service ภายในระบบ การทำเช่นนี้ API Gateway ก็จะรับหน้าที่ผู้จัดการความมั่นคงปลอดภัย ช่วยให้นักพัฒนาไม่ต้องสร้างหรือเก็บ Credential สำหรับ API แต่ละตัวด้วยตัวเอง ในขณะที่ก็ยังรักษาความมั่นคงปลอดภัยของ API ของแต่ละ Service ไว้ได้อย่างแน่นหนา

โดยนอกจากประโยชน์ด้านความมั่นคงปลอดภัยแล้ว API Gateway ยังมีประโยชน์ต่อระบบ Microservices ในด้านอื่นๆ เช่น การเปิด API ให้กับ Client, การจัดการส่งต่อ Request ที่วิ่งเข้ามาจากช่องทางที่แตกต่าง (เช่น โทรศัพท์ หรือ Desktop) ให้ไปยัง Service ที่เหมาะสม, และการแปลง Protocol ในการสื่อสาร เป็นต้น
เมื่อความมั่นคงปลอดภัยไม่ได้มีแค่ 1 เลเวล
แอปพลิเคชันในปัจจุบันนั้นมีความซับซ้อนและมี Scope ที่กว้างขึ้นเรื่อยๆ การรักษาความมั่นคงปลอดภัยจึงซับซ้อนตามขึ้นไปด้วย ผู้ใช้รายหนึ่งอาจสามารถเข้าถึงข้อมูลได้น้อยกว่าผู้ใช้อีกรายหนึ่ง ความมั่นคงปลอดภัยที่เราพูดถึงกันในทุกวันนี้เป็นความมั่นคงปลอดภัยที่เฉพาะเจาะจงกับบริบทของผู้ใช้มากกว่าที่เคยเป็นมา
การสื่อสารให้ทั้งระบบรู้โดยทั่วกันว่าบริบทของความมั่นคงปลอดภัยและสิทธิ์ของผู้ใช้แต่ละรายมีมากน้อยแค่ไหนนั้นเป็นใจความสำคัญของสิ่งที่เรียกกันว่า End-to-end (E2E) Trust การสร้าง E2E Trust ขึ้นในระบบจะช่วยให้ Service แต่ละตัวรู้บทบาทของตนว่าทำได้แค่ไหน ให้ข้อมูลได้มากเท่าไหร่ และส่งต่อความเชื่อใจนี้ให้ Service อื่นใดในระบบได้บ้าง ซึ่งช่วยเสริมความมั่นคงปลอดภัยให้กับระบบ และทำให้การขโมยข้อมูลเป็นไปได้ยาก
การทำ E2E Trust ในระบบ Microservices นั้นทำได้ 2 แบบ วิธีแรกคือการใช้ Token-exchange Service เพื่อส่งต่อ Token ซึ่งเป็นตัวแทนของความเชื่อใจให้กับ Service อื่นๆ ตามลำดับ เช่นหากผู้ใช้ต้องการทำธุรกรรมหนึ่งซึ่งประกอบไปด้วยการใช้ Service A, B และ C ขั้นตอนในการทำงานก็คือระบบจะนำ Token ที่ผู้ใช้ได้จากการล็อคอิน ไปแลกเป็น Token เพื่อใช้งาน Service A และจาก Service A ไปแลกเพื่อใช้งาน Service B ตามลำดับ การแลกเปลี่ยนเช่นนี้บังคับทั้งตัวตนและแหล่งที่มาของความมั่นคงปลอดภัย
วิธีที่สอง คือการใช้ Token ที่ได้รับมาในการล็อคอินครั้งแรกไปใช้กับ Service ต่างๆ ภายในระบบทั้งหมด เมื่อผู้ใช้ทำการล็อคอิน ระบบจะตรวจสอบสิทธิ์และสร้าง Token ตามความมั่นคงปลอดภัยที่พึงได้ ซึ่งสามารถนำไปใช้กับ Service ตามสิทธิ์กำหนดโดยไม่ต้องเสียเวลาแลกเปลี่ยน Token อย่างในแบบแรก อย่างไรก็ตามการสร้าง E2E Trust ด้วยวิธีนี้ระบบจะต้องมีขอบเขตและ Protocol ในรูปแบบเดียวกัน แต่ความยืดหยุ่นในระบบก็จะน้อยกว่าระบบแลกเปลี่ยน Token

คำแนะนำ: ใช้ API Gateway เมื่อเป็นไปได้
เมื่อก้าวเข้าสู่ยุคของ Microservices แล้ว การศึกษาทำความเข้าใจเกี่ยวกับ API และเทคโนโลยีที่เกี่ยวข้องนั้นสำคัญเป็นอย่างยิ่ง เพราะจะช่วยให้นักพัฒนาสามารถออกแบบระบบที่มีทั้งประสิทธิภาพ ความมั่นคงปลอดภัย และใช้ประโยชน์จากแนวคิด Microservices ได้เต็มที่
API Gateway เป็นเทคโนโลยีที่จะช่วยบังคับใช้นโยบายความมั่นคงปลอดภัยและสร้างกลไกส่งต่อความมั่นคงปลอดภัย End-to-end Trust ให้กับระบบและการเข้าใช้ Service ต่างๆ ที่อยู่เบื้องหลัง นอกจากนี้ ยังช่วยในการจัดการการสื่อสารกับ API ทั้งจาก Request ภายนอก และการส่งต่อไปยัง Service ภายในอีกด้วย
รายละเอียดเพิ่มเติม: https://developer.ibm.com/technologies/api/articles/securing-modern-api-and-microservices-apps-1
>> อ่านต่อ Part 2 <<
สนใจสอบถามข้อมูลเพิ่มเติมได้ที่ตัวแทนฝ่ายขายหรือฝ่ายผลิตภัณฑ์ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด: TH-IBM@ingrammicro.com
