MFEC

ระบบ 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) เหล่านี้ เพราะตัวรากฐานมีความสามารถ

รูปนี้คือความสามารถที่ 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 (เข้าใจภาพใหญ่ก่อนลงมือ)เนื่องจากระบบมีความหลากหลาย

จากบทความที่แล้ว ได้พูดถึงคนกลางที่ชื่อ “API Gateway” มีหน้าที่บริหารจัดการทั้งการสื่อสาร การจัดการสิ่งที่ “Core Engine” แต่ละตัวต้องการแตกต่างกัน ให้สามารถเชื่อมต่อสื่อสารกันได้อย่างสมบูรณ์ ในพาร์ทนี้ จะบอกเล่าอีกขั้นของตัวกลางนั้นในชื่อว่า “API Management” โดยความสามารถจะทั้งเป็นตัวกลาง ตัวประสานงาน การจัดการด้านข้อกำหนดของการสื่อสาร จำนวนข้อความที่จะสื่อสารระหว่างกัน การซ่อนหรือการเพิ่มหรือแม้แต่การแก้ไขบางส่วน ก่อนส่งหรือรับกลับ สามารถจัดการได้ทั้งบน Cloud และ On-premise และผ่านตัวบริหารจัดการแบบรวมศูนย์ (Single pane of glass) APIGee Hybrid เป็นผลิตภัณฑ์หนึ่ง ที่มีความสามารถครอบคลุมที่ได้กล่าวมาข้างต้น ซึ่งนั้นเป็นแค่เพียงบางส่วนของความสามารถทั้งหมดครับ #APIGee เป็นผลิตภัณฑ์ กลุ่ม “API Managment” หากอ้างอิงตาม Gartner จะมีการกำหนดความสามารถในด้านต่าง ๆ ที่ใช้ในการประเมินดังนี้ 1. Devloper portals : ระบบบริการตนเอง (เหมือนเป็นพวก self-portal, self-services ครับ) ที่อำนวยความสะดวกให้ ผู้ใช้งาน (ไม่ว่าจะผู้ดูแลระบบ, developer ที่จะเข้ามาใช้งาน, หรือกลุ่มผู้ใช้งานต่าง ๆ) สามารถเข้ามาเพิ่มลด กำหนด ตั้งค่า ต่างๆ เพื่อใช้งาน API ที่ต้องการได้ มองทั้งความครบถ้วนของการกำหนด ค่าสำหรับ API – ความละเอียด ของการลงค่ากำหนด อย่างเหมาะสม (ไม่ซับซ้อน หรือ ละเอียดจนเกินจำเป็น แบบว่ามีไปก็เก๋ดี แต่ไม่ได้ใช้งาน เพราะบางระบบลงขนาดเหมือนให้เขียน code ส่วนนั้นเองไปเลยก็ fine gain ไปนิดส์) – ความไม่ซับซ้อน ของการกำหนดค่าต่างๆ เพราะบางที ทำ ๆ ไป งง ว่าทำถึงไหน เกี่ยวกับหน้าจอเมื่อครู่อย่างไร ทำไปทำมา ขอเริ่มทำใหม่ หรือ ไม่ก็ต้อง จดละเอียดมาก ๆ เพื่อให้การกำหนดค่า ทำได้ครบถ้วนไม่หลงทาง – ความชัดเจนของการกำหนด เงื่อนไขต่างๆ มี UI ที่บอกว่ากำหนดถึงขั้นตอนไหน (ลดความซับซ้อน จากที่กล่าวข้างต้น) และเงื่อนไขต่างๆ ไม่ขัดแย้งกันเอง ระหว่างการกำหนดค่าใช้งาน 2. API Gateways : มีระบบบริหารจัดการ ระบบประมวลผล (Runtime) รวมถึง ค่าความปลอดภัย และการใช้งานของ API ที่เราสร้างขึ้นมา เพื่อให้สามารถติดตาม ได้ว่าการทำงานเป็นไปตามที่ต้องการขณะประมวลผล (Runtime) และหากมีบางอย่างไม่ถูกต้อง ระบบสามารถสื่อสารกลับมาให้ผู้ใช้งานเข้าใจและ เข้าถึงเพื่อแก้ไข ได้สะดวกเพียงใด 3. Policy management and analytics : การกำหนดค่าต่างๆ เช่นค่าความปลอดภัยของ API (Security), API Mediation Layer (API ML) ที่มีความฉลาดในการจัดการ การสื่อสารเป็นตัวกลางที่ดีและปลอดภัยระหว่างกัน

ปัญหาการสื่อสารมีแม้ในระบบไอที หากมีคนกลางที่ดี ระบบไอทีจะกลายเป็น innovation อย่างก้าวกระโดด 1. ในระบบไอทีที่เราเคยมีมา ล้วนเป็นระบบที่มีคุณประโยชน์อย่างมาก และ เป็นส่วนหนึ่งในชีวิตประจำวันสำหรับคนทั่วไป เช่น- ระบบโอนเงินต่างธนาคาร ที่ต้องมีความถูกต้องแม่นยำ และเกี่ยวข้องกับการเงิน- ระบบข้อมูลตลาดหลักทรัพย์ ที่มีนักลงทุนจำนวนมหาศาลใช้งาน ระบบจึงต้องตอบสนองได้เป็นปัจจุบัน เพราะข้อมูลที่ล่าช้าเพียงไม่กี่วินาที อาจหมายถึง มูลค่าของกำไร/ขาดทุน ที่จะส่งผลให้นักลงทุน หมดความเชื่อถือ- ระบบทางการแพทย์ ที่ต้องเข้าถึงข้อมูลบุคคล ตรวจสอบประวัติไข้ การประกันสุขภาพและประกันชีวิต เพื่อ ให้การรักษาแม่นยำ และ ผู้ป่วยมีการช่วยเหลือด้านค่าใช้จ่าย อย่างถูกต้องตามเงื่อนไขที่ระบุ ระบบเหล่านี้เป็นเพียงบางส่วน ที่มีแก่นของการประมวลผลสำคัญ ผมจะขอเรียกว่า “Core engine” นะครับ โดยมีต้นกำเนิดจากความต้องการของธุรกิจตั้งต้น และเติมความสามารถต่าง ๆ เฉพาะทางเพิ่มขึ้นเรื่อย ๆ ทำให้ “Core engine” เหล่านั้น มีความเฉพาะตัว และ ยากต่อการสื่อสาร ไปยัง ระบบอื่น ๆ ที่ไม่ได้อยู่ใน ธุรกิจของตนเอง แต่ในปัจจุบัน การก้าวกระโดดทางความต้องการของผู้บริโภค วิ่งไปข้างหน้าอย่างรวดเร็ว ซึ่งเทคโนโลยีที่หลากหลาย ก็ออกมาเพื่อรองรับความต้องการเหล่านั้น 2. #ระบบคลาวน์ (Cloud computing) ที่มีเทคโนโลยี พร้อมใช้ ต่าง ๆ ทั้งระบบประมวลผล ที่จัดเก็บข้อมูลหลายประเภท ระบบพร้อมใช้งานทันที เรียกว่า พร้อมเหมือนจะทาน บะหมี่กึ่งสำเร็จรูป รสชาติ ต่าง ๆ เลยครับ #การจัดการผ่านระบบคลาวด์คอนโซล (Cloud console) จะสะดวกสบาย มือไม่เจ็บ (สมัยนั้น ต้องแกะ ถอด ประกอบ ใส่ บางทีก็มีงับมือ บาดมือกันบ้าง ครับ •^^) เพราะเป็นการกดเลือกผ่าน web application จาก Cloud console ที่เป็น Web application จะไปสั่งการผ่านตัวกลาง เหมือนเป็นคนสักคน ให้ไปถอดประกอบคอม ให้เราตามที่เราระบุค่าไว้ โดยตัวกลางนั้นเราเรียกว่า “#API (Application Programming Interface)” เอิ่มมม ผมขอเรียกว่า API เลยละกันนะครับ และเดี๋ยวผม พากลับเข้าเรื่อง ของ “Core Engine” ว่ามาเกี่ยวพันกับ “API” ได้ยังไงกันน๊า ที่ผมพา มาจุดนี้ เพียงเพราะอยากให้เห็นถึงความ ยาก จากการสั่งงานผ่าน Web application วิ่งไปยัง โครงสร้างพื้นฐานของระบบไอที เบื้องหลัง อาจจะมีทั้ง Virtualization, Container management, Multi-type of storage, Software define network และ อื่น ๆ ที่แต่ละชื่อ คือระบบที่ ทำหน้าที่ของตนเองเป็นหลัก แต่ไม่สามารถ รู้จัก ระบบข้างเคียงได้โดยง่าย