รูปนี้คือความสามารถที่ APIGee มีครับ สื่อภาพออกมาเหมือนพื้นที่บ้าน(บริษัท) ที่มีการจัดวางสัดส่วนใช้สอยและสิทธิ์การเข้าถึงในพื้นที่ต่าง ๆ
เริ่มตั้งแต่จุดเข้าของ ผู้ใช้งาน (User, Partner) ที่จะเข้ามาใช้คุณสมบัติต่างๆ ของ “Core Engine” ผ่าน การออกแบบของ “Design API” ควบคุมความปลอดภัย เงื่อนไขข้อกำหนดต่าง ๆ โดย “Secure API” เพื่อผ่านเงื่อนไขจะเข้ามาพูดคุยกับผู้บริการ (API ที่เราเปิด Publish) โดยนับตั้งแต่ผู้ใช้งานก้าวเข้ามาในพื้นที่จะมีการติดตามดูแลเพื่อวิเคราะห์พฤติกรรม ประสิทธิภาพการให้บริการโดย “Analysis API” และ “Monitor API” จากนั้น หากเป็นการให้บริการแบบมีเงื่อนไข ค่าใช้จ่าย จะมีส่วนงาน ที่คอยควบคุมการคิดเงิน การให้เข้าถึงตามสิทธิ์ที่ได้ตกลงกันไว้ โดย “Monetize API” ประมาณว่าคนนี้ VIP ก็แบบ บริการรวดเร็วทันใจไวเว่อร์ แต่หากเป็นผู้ใช้ทั่วไปอย่างผม ก็เข้าคิวรอเรียกรับบริการ API ตามหน้างานไป แบบนี้ครับ
จากรูปนี้จะเห็นว่าบริษัทนี้เป็นบริษัทที่มี “Core Engine” (I) หลากหลาย เนื่องด้วยความเติบโตจากความต้องการของตลาดโดยแต่ละ “Core Engine” ต้องเร็ว ต้องทันตลาด จึงมีการพัฒนาแบบแยกส่วน ต่างต้องเสร็จ ให้รองรับ Business direction ที่กำกับลงมา ดังนั้น “Core Engine” จึงแยกกันเติบโต และ โดดเดี่ยว (โห..ดูเหงา แต่เรื่องจริงครับ) คำว่าแยกกัน จึงทำให้การสื่อสารระหว่างกันนั้นมีได้เพียงการสื่อสารผ่าน การเขียนถึงกัน (File) และจะคุยกันได้เป็นรอบ ๆ (Batch) จึงทำให้ แต่ละระบบ ต้องมานัดกันว่า จะมีการ สรุปข้อมูลที่ต้องการ ในช่วงเวลาใด และ ต้องปิดระบบ เพื่อมาเขียนไฟล์ ให้ข้อมูลคงที่อย่างไร
มาถึงตรงนี้ หากเปรียบเทียบความเป็นจริงในงานผู้ดูแล (Product owner) หรือคนที่รู้เกี่ยวกับระบบตัวเองทุกระบบต้องมาคุยกันในช่วงเวลาที่เหมาะสมต่อการเขียน เพื่อสื่อสารแบบครบถ้วนเพราะบางระบบต้องหยุดเพื่อเขียนสรุป (ไม่อย่างนั้นจะเขียนข้อมูลใหม่ไปเรื่อยๆ เป็นต้น) จึงต้องมีการคุยรอบของการส่งข้อมูลระหว่างกันที่มีความละเอียดอ่อนและต้องระมัดระวัง
ส่วนของการเปิดให้บุคคลภายนอก เช่น ผู้ใช้งานหรือลูกค้า (User, Client) คู่ค้า (Partner) ก็ยิ่งเป็นเรื่องยากเพราะการสื่อสารผ่านการเขียน (File) ใช้ไม่ได้ในทุกกรณี แต่กรณีในบ้าน พอกำหนดข้อตกลงบนข้อจำกัดได้ การเปิดให้บุคคลภายนอกได้เข้าใช้งานจะช่วยให้ธุรกิจก้าวกระโดดอย่างมากเนื่องจาก “Core Engine” เป็นระบบที่คู่ค้าสร้างเองไม่ได้หรือสร้างได้ก็ลงทุนมหาศาล แถมประสบการณ์ไม่เท่ากับคนที่อยู่ในสายธุรกิจนี้มายาวนาน การแลกเปลี่ยนความสามารถที่เกื้อกูลกัน ก็จะทำให้ธุรกิจเติบโตได้ดีและตอบโจทย์ความต้องการของปัจจุบันได้อย่างมาก
การจะให้บุคคลภายนอกมาติดต่อโดยตรง ความปลอดภัยและการติดตามว่าใช้งานอะไร รวมถึงดูแลคุณภาพการให้บริการที่ดีเยี่ยมตามเงื่อนไขบริการ (SLA) เป็นสิ่งที่เติมเต็มให้กับระบบ “Core Engine” ได้ยาก เพราะการจะปรับปรุงพัฒนาอาจส่งผลกระทบหรือใช้ทั้งเวลาและเงินทุนมหาศาล
ข้างต้นนั้น คือความวุ่นวายและความยากของระบบ “Core Engine” (หรือบางที่เรียก Legacy system) จากปัญหาเหล่านั้น ลูกค้ารายนี้เลือก APIGee ในรูปแบบ “APIGee Hybrid” เพื่อมาตอบโจทย์ทั้งการบริหารจัดการ/ให้บริการภายในและการให้บริการภายนอก โดยมีหลักการอย่างไรบ้าง มาติดตามกันต่อเลยครับ
#Business understanding (เข้าใจภาพใหญ่ก่อนลงมือ)เนื่องจากระบบมีความหลากหลาย และในปัจจุบันมี business model ที่ระบบเหล่านั้นตอบโจทย์ แต่ ระบบดันไม่ทำงานอย่างสัมพันธ์กันมากพอ หากระบบทำงานสัมพันธ์กันมากพอ จะทำให้ business model นั้นเป็นจริงและทันเวลาที่จะนำออกสู่ตลาด รวมถึง ในอีกระยะ หากได้รับความนิยมต้องการขยายกำลังและอาณาเขตบริการ โดยมีการคิดค่าใช้จ่ายที่แตกต่างกันตามที่ business owner ได้ออกแบบและ กำหนดลงมา
#Discovery (เป็นนักสำรวจกัน)เริ่มที่ (I) โดยนำข้อมูลของความซับซ้อน ที่มีอยู่ภายในมากางออกและบอกความต้องการไปบนงานที่มีอยู่เหล่านั้น (มองข้ามข้อจำกัดปัจจุบันไปก่อน เพราะเรากำลังหาทางข้ามข้อจำกัดเหล่านั้น) และเอา Business direction มาวางประกอบ เพื่อดูว่า เราทำอะไรกับ (I) ได้บ้าง การคุยกันภายในของ “Core Engine” อยากให้มีอิสระและคุยผ่าน Services ได้เพราะ “Core Engine” มากกว่า 80% คุยผ่าน Services ได้ โดยมีทั้งแบบ Client Server ก้อนใหญ่ๆ และ Microservices การให้บริการภายนอก “Core Engine” ปรับเติมเติมอะไรเข้าไปไม่ได้แล้ว ในการคุยคือ ตัดสินใจอย่างนี้ เพราะเอาเงินและเวลาที่จะต้องนำมาปรับปรุงไปสร้างระบบตัวกลางและค่าใช้จ่ายของระบบตัวกลางเหมาะสมกว่าทั้งด้านเวลาและ เงินลงทุน
จากที่ว่า เริ่มที่ (I) Core Engine เรารวมถึงระบบแวดล้อมทั้งหมดที่เกี่ยวข้องกับ “Core Engine” ด้วยนะครับ พวกเส้นวิ่งเข้าออก เชื่อมต่อผ่านอุปกรณ์ ความปลอดภัยส่วนไหนอย่างไร มีระบบตรวจสอบตรวจจับอะไรบ้าง และมีเทคโนโลยีที่ใช้อะไรบ้าง ทีมทำงานส่วนงานต่าง ๆ เพื่อวางแนวทางของงาน operation ไว้แต่เนิ่น ๆ ทั้ง operation ส่วน API, System, Infra, Security และที่จะเกี่ยวข้องทั้งหมด ประมาณนี้ครับ
#Design approach (ออกแบบและวางแนวทาง)จากการสำรวจ นำมาออกแบบ เพื่อรองรับ ความต้องการต่าง ๆ และ เริ่ม Workshop กับส่วนงานที่เกี่ยวข้อง เริ่มให้เห็นการเข้าใช้งานระบบที่ออกแบบนี้
> การใช้งานภายในออกแบบผ่าน (J) Manage Microservice เพื่อให้การสื่อสารผ่าน Services ระหว่างกันมากที่สุด โดยไม่ไปแก้งาน Batch operation routine เดิมเนื่องจากมีระบบอื่น ๆ และตามกฎข้อกำหนดต่าง ๆ ที่ได้สรุปไว้ก่อนหน้าแล้วว่าไฟล์เหล่านั้น กิจกรรมเหล่านั้นต้องคงอยู่ การทำงานของ (J) จะครอบคลุมงานที่จะต่อยอดขึ้นมาหรือทำซ้ำเพื่อนำมาเป็นทางเลือกและวางแผนเสนอยกเลิก Batch operation routine บางส่วน หากทดแทนกันได้ โดยตัวระบบ APIGee Hybrid เองมี (H) Design API, (K) Developer Portal และ (B) Secure ช่วยในการออกแบบการสื่อสารส่วนของ (J) ให้เป็นไปตามต้องการ ทั้งวิธีการสื่อสารเติมความสามารถต่าง ๆ เข้าไปเพิ่มโดยไม่ต้องไปแก้ไข (I)
สามารถติดตามกิจกรรมวิเคราห์ระบบผ่าน (D) Analysis, (E) Monitor ได้โดยดูควบคู่กับ Monitoring system ที่มีอยู่เดิมของ (I) ได้อย่างมีประสิทธิภาพเพราะ (D), (E) เป็นตัวช่วยที่เกิดมาเพื่อ วิเคราะห์ การสื่อสาร เช่น ระบบมีการสื่อสารที่ล่าช้า (Delay) หรือหยุดชะงัก (Suspend) จะสามารถดูได้ว่าช้าที่จุดใดที่ (I) ส่วนใด เพื่อให้การเข้าแก้ไขปัญหาที่ต้นเหตุทำได้รวดเร็วยิ่งขึ้น
> การให้บริการภายนอก จะเป็นการออกแบบ Service flow ผ่าน (H), (K) เพื่อวางเส้นทางการเข้าใช้งาน ออกแบบข้อกำหนดเงื่อนไขความปลอดภัย โดย (B) แต่ก่อนจะเปิดให้ บุคคลภายนอกเข้าใช้งาน เราสามารถทดสอบการใช้งานผ่าน (H) ได้เป็นการทดสอบการสื่อสารเส้นวิ่งเงื่อนไขความปลอดภัยต่าง ๆ ว่าเป็นไปตามที่ออกแบบหรือไม่ เมื่อพร้อมเปิดให้บุคคลภายนอกเข้าใช้งานเราจะเปิด (C) Publish API เมื่อมีคำขอเข้ามาจะถูกตรวจสอบและพาให้บริการ ตามที่กำหนด (C) ก็จะแบ่งตัว (แบบคาถาเงา พันร่าง แบบนั้นเลยครับ) มารับงาน และเข้าไปในบริเวณ staff only คือ บุคคลภายนอกรอรับของด้านนอก จากนั้น (C) ก็จะวิ่งเข้าไปในเขาวงกต แต่สำหรับ (C) ที่รู้เส้นทางและเงื่อนไข การผ่านแต่ละด่าน แต่ละส่วนก็จะไปยัง (J) หรือตรงไปหา (I) ได้อย่างไม่มีปัญหา
จากนั้น เช่นคำขอของจาก Mr. Rectangle กับ Mr. Circle โดยขอให้ประมวลผลตามเงื่อนไข ก่อนส่งกลับให้ (A) ตัวแทนของ (A) คือ (C) ก็จะประสานงาน Mr. R, Mr. C และประมวลผลเสร็จสรรพจากนั้น (C) ก็วิ่งกลับมาส่งผลลัพธ์ตามที่ (A) ขออย่างครบถ้วน ในขณะเดียวกันตั้งแต่ (A) เข้ามาในพื้นที่ (D), (E), (F) จะติดตามพฤติกรรมว่า (A) ผ่าน (B) มาหา (C) และ (C) ทำอะไร นำอะไรกลับมา ใช้เวลาเท่าไหร่ ข้อมูลขนาดเท่าใดและอื่น ๆ อีกมาก เพื่อเป็นข้อมูลเชิงวิเคราะห์บอกสถานการณ์ว่าคำขอนั้น เหมาะสมตามข้อกำหนดหรือผิดแปลกไปจากที่ระบุ เป็นต้น
#Implement and rollout (สร้างและปูพรม)เมื่อ Design approach และแนวทางของงาน ครบถ้วนก็ดำเนินการสร้างระบบและเริ่มไล่เรียงพาแต่ละเส้น API ที่ต้องการมาออกแบบบน APIGee Hybrid ในการ Implement APIGee Hybrid เป็นการสร้างบนภาคพื้นดิน (on-premise) ซึ่งมีระบบที่มีความสามารถในการเพิ่มลดกำลังการประมวลผล (Scalability), รักษาความมั่นคงของการเข้าถึงระบบ (Stability and Durability) แบบเข้าได้ตลอด ไม่ตายง่าย ๆ ประมาณนั้นครับ รวมถึงจะต้องรองรับความสามารถในการปรับแต่งกำหนดค่าของ API Flow ต่าง ๆ ตามความต้องการ ของ APIGee ได้ เพราะจะเป็นการสร้าง microservice แยกตาม API Flow นั้น ๆ ตัวระบบที่รองรับ จึงต้องมีความสามารถที่เรียกว่า Container Management, Cluster Management ได้อย่างดี
#Evaluate and operation (ติดตามประเมินผล และ ดูแล)เมื่อการใช้งานผ่านไประยะเวลานึงจะต้องมีการติดตาม ประเมินผลดูว่าจุดใดที่ต้องปรับปรุงเพื่อให้เข้าใกล้ ความต้องการของลูกค้ามากที่สุดและทันต่อปัจจุบันอย่างต่อเนื่อง (เพราะทุกอย่างพัฒนาไปข้างหน้าตลอดเวลาทั้ง Business, Technology) ส่วนของ Operation เป็นการคงสภาพ และรักษาคุณภาพบริการให้ตรงตามข้อตกลงระบบ Monitoring ของ APIGee Hybrid และการใช้งานจะเป็น Web portal แบบเดียวกันกับ APIGee SaaS ซึ่งทำให้ผู้ดูแลระบบ ไม่ต้องเรียนรู้ความต่างมากนักและ ส่วนของระบบที่เป็นพื้นฐานให้ APIGee Hybrid ก็มี Monitoring dashboard แบบเดียวกันกับ Cloud platform ที่ผู้ดูแลระบบคุ้นเคย
ที่ได้เล่ามาทั้งหมดนี้ หากเพื่อน ๆ มีข้อแนะนำ ข้อสงสัย สามารถสอบถามมาได้เลยนะครับ และ EP หน้า จะมาเล่าถึง ใครกันน๊า ที่ทำให้ “APIGee Hybrid” ดูอมตะ ได้เหมือนอยู่บน Cloud แบบ APIGee SaaS เลย ขอแง้มว่า เขาชื่อ #Anthos ครับ •^^
