Skip links
View
Drag

EP.4 ระบบ APIGee

ระบบ APIGee เดิมอยู่บนระบบ Cloud และให้บริการในรูปแบบ Software as a Service (SaaS) ซึ่งมีการรับประกันประสิทธิภาพการคงอยู่ของระบบ และการให้บริการได้อย่างต่อเนื่อง ตามเงื่อนไขบริการ (Service Level Agreement)

คราวนี้ APIGee Hybrid จากเดิมอยู่บนระบบ Cloud มาอยู่ ณ On-premise ทำอย่างไร ที่จะรักษาคุณสมบัติเดิมทั้ง features และการรับประกันประสิทธิภาพของบริการ ให้เทียบเท่ากับการให้บริการบนระบบ Cloud

การจะรักษาคุณสมบัติที่ใกล้เคียงไว้ได้ จำเป็นจะต้องมีระบบโครงสร้างพื้นฐานและรากฐานเดียวกันกับ Cloud นั่นเอง ทางเจ้าของผลิตภัณฑ์จึงต้องออกแบบระบบโครงสร้างพื้นฐาน (Infra Platform) ให้สามารถนำมาติดตั้ง ใช้งานบน On-premise ได้ อย่างสะดวกต่อคนสาย IT อย่างเรามากที่สุด เพราะสร้างเสร็จ ต้องดูแลระบบดังกล่าวต่อ (Operation routine)

ที่สุด Infra platform ที่ว่า ก็ออกมาในชื่อ “Anthos” (แอน-ทอส) โดยเป็นการต่อยอด จาก “Kubernetes” ที่พวกเราคุ้นเคย เรียกว่าเป็นกลุ่ม Cluster management ที่ต่อยอดและออกแบบมาเพื่อให้สามารถติดตั้ง ได้ทุกที่ทั้ง On-premise, On-Cloud ต่าง ๆ ครอบคลุม brands หลัก ๆ และจะค่อย ๆ ครอบคลุมในทุก brands ต่อไปครับ

#รูปที่ผมเขียนนี้ เพื่อเป็นตัวเปรียบเปรยการทำหน้าที่ของ APIGee Hybrid กับหน้าที่ของ Anthos ครับ
APIGee ทำหน้าที่ของตัวเองได้อย่าง เต็มประสิทธิภาพ ตามที่ได้เขียนไว้ใน EP ก่อนหน้าครับ และที่เห็นเป็น สามเหลี่ยม สี ๆ นั้น คือ “Anthos” ครับเพื่อน ๆ ทำหน้าที่จัดการทุกอย่างอยู่เบื้องหลัง เหมือนเป็นโครงสร้างบ้าน ที่คอยจัดการน้ำหนักทีเพิ่มขึ้นของตัวบ้าน การขยายตัว การคงสภาวะของตัวบ้าน ให้ผู้อาศัยใช้งานได้อย่างปรกติที่สุด

Anthos มีความสามารถที่ต่อยอดจาก Cluster management เพิ่มความสามารถในการสะดวกสร้าง เหมือนบะหมี่กึ่งสำเร็จรูปรส #Anthos ที่หากเข้าใจการเติมน้ำร้อน รู้อุณหภูมิ และเวลาที่เหมาะสม ก็จะได้ Anthos พร้อมรับประทาน และวัตถุสี ๆ ที่อยู่ล้อมรอบ นั้น ก็เป็นเสมือน เครื่องเคียงต่าง ๆ ที่ หากต้องการใช้ ก็สามารถนำมาใช้งานร่วมกันได้ เช่น การจัดการแบบรวมศูนย์ การติดตั้งและสื่อสาร ระหว่าง Anthos ณ ที่ต่างๆ (on-premise, on-cloud) ตัวควบคุมการให้บริการ (Anthos Service Mesh)

จากหัวเรื่องของ EP นี้ที่ทำให้ APIGee Hybrid ดูคงสภาวะให้บริการได้อย่างต่อเนื่อง และเพิ่มลด ประสิทธิภาพ ในการให้บริการ ได้ตามความต้องการ (Scalability) เหล่านี้ เพราะตัวรากฐานมีความสามารถ ตั้งต้นมาจาก Cluster Management – Kubernetes ด้วยส่วนนึงและการออกแบบที่ทำงานประสานกัน ของ APIGee Hybrid + Anthos ที่คอยเฝ้าระวังกระตุ้น (Trigger) และฟื้นตัว (Recover) หากมี APIGee services ใดหยุดทำงานหรือทำงานใกล้เต็มประสิทธิภาพ ก็จะมีการทำงานที่ประสานกัน เพื่อให้ Anthos สร้าง APIGee services เพิ่ม หรือ ทดแทน ให้ระบบภาพรวมยังคงทำงานได้

APIGee จะมีตัวควบคุม (Control Plane) เป็นส่วนควบคุม ที่ไม่ได้อยู่บนระบบ Anthos แต่อยู่จากส่วนของ APIGee Cloud ที่จะเป็นตัวช่วยจัดการตัวบริการ APIGee services (Runtime Plane) ตรงนี้ จะอยู่บน Anthos ครับ

โดย Anthos เอง จะมีระบบจัดการ รักษาสภาพ และ ปรับเปลี่ยน APIGee services ให้รองรับโหลดของงาน ตามเงื่อนไข ที่ระบุ การสื่อสารตามที่กำหนดไว้ (เช่น กำหนด จาก Design, Dev portal เป็นต้น) และระบบฟื้นตัว (Recovery) กรณีที่ APIGee services เกิดหยุดทำงานหรือเสื่อมประสิทธิภาพ

จากตรงนี้จะเห็นว่า APIGee Hybrid มีการออกแบบให้สามารถคงสภาพได้เสมือนอยู่บน Cloud ด้วย APIGee Control Plan ที่อยู่บน APIGee Cloud เองและส่วนของ Anthos ที่คอยควบคุมดูแลอีกชั้น ทำให้มั่นใจได้ว่าการจะโซซัดโซเซหรือล้มลงของ APIGee Hybrid นั้นเป็นไปได้ยาก หรือหากเกิดขึ้นก็จะสามารถฟื้นตัวได้อย่างรวดเร็ว

ซึ่ง Anthos มีขีดความสามารถอีกมากสำหรับการทำงานร่วมกับ APIGee Hybrid เป็นเพียงหนึ่งความสามารถเท่านั้นครับ ขอบคุณที่ติดตามบทความนะครับ หากมีข้อสงสัย ข้อเสนอแนะหรืออยากให้เขียนส่วนไหนอะไรเพิ่มเติมทักผม (จริง ๆ คือพวกเราครับ มีทีมงานและผู้เชี่ยวชาญในส่วนต่าง ๆ พร้อมดูแลนะครับ) และจะนำมาเขียนบอกเล่าจากประสบการณ์ ให้เพื่อน ๆ นะครับ