MFEC

การที่จะพัฒนาซอฟต์แวร์หรือว่าการสร้างสรรค์ชิ้นงานขึ้นมา หน้าที่หลักของนักพัฒนาซอฟต์แวร์ก็จะเป็นเรื่องของการรับ Input เพื่อนำไป Process ตาม Requirements ที่มีอยู่เพื่อให้ได้ Output ออกมา ซึ่งสิ่งที่ควรคำนึงถึงนั่นก็คือช่วงที่มีการรับ Input จากมุมมองของคนทำงานด้าน Security “การตรวจสอบ Input ยิ่งถูกตรวจสอบน้อย ยิ่งเป็นเหมือนสนามเด็กเล่นของ Hacker” เพราะการไม่ตรวจสอบ Input มักจะทำให้เกิดปัญหาด้าน Security ตามมา ปัญหาที่พบได้บ่อย เช่น SQL Injection, Cross-site Scripting (XSS) และอื่น ๆ ทำให้สิ่งเล็ก ๆ อย่างเรื่องแรกที่อยากให้นักพัฒนาเว็บไซต์คำนึงถึงคือการตรวจสอบ Input ที่รับเข้ามา จะทำให้ลดความเสี่ยงไปได้เป็นอย่างมาก ปัญหาต่อมาคือเรื่องของการตรวจสอบสิทธิ์โดยไม่ได้รับอนุญาตที่มากเพียงพอ ตัวอย่างเช่น มีคนกรอก Username และ Password เข้ามา ตรงนี้จะถือเป็นเพียงการตรวจสอบว่าคนที่ทราบ Username และ Password แต่ไม่ได้มีการตรวจสอบสิทธิ์การเข้าถึงของเขา ดังนั้นจึงอยากให้ตระหนักว่าระหว่างที่เรากำลังพัฒนาซอฟต์แวร์ ก็ควรวางแผนในเรื่องของการทำ Authorization ให้ละเอียดมากพอ โดยเฉพาะอย่างยิ่งในปัจจุบันที่เรื่องของ Privacy เป็นเรื่องที่สำคัญมาก ปัจจุบันมีผู้ใช้งานซอฟต์แวร์หรือเว็บไซต์ต่าง ๆ เพิ่มขึ้นอย่างรวดเร็วผู้พัฒนาซอฟต์แวร์จะต้องมีการเตรียมรับมือ สำหรับการรองรับ Workload มหาศาลที่จะเข้ามา วิธีการรับมือกับสถานการณ์แบบนี้ทำได้ใน 2 มุม แบบแรก Scale up เป็นการขยายความสามารถของระบบโดยการเพิ่ม CPU เพิ่ม Memory เข้าไปให้รองรับ workload ได้ อีกวิธีจะเรียกว่า Scale out เป็นการขยายจำนวนระบบให้มีหลายเครื่องมากขึ้น ซึ่งแต่ละเครื่องก็จะทำงานสอดคล้องกัน ก็เป็นอีกวิธีที่ทำให้รองรับ workload ที่เพิ่มขึ้นได้ แต่บางครั้ง Scale out ก็ไม่ได้ดีกว่า Scale up ในกรณีที่ผู้ใช้ไม่ได้มีจำนวนมาก และมีจำนวนคงที่ ก็จะไม่จำเป็นต้องทำ Application ให้พร้อมกับ Scale out ในการพัฒนาระบบการคำนึงถึงการใช้ทรัพยากรก็เป็นเรื่องสำคัญ และมีบางปัจจัยที่อาจจะถูกมองข้ามเช่น Time Consuming การสิ้นเปลืองเวลาไปกับการขอข้อมูลจากคนนอกองค์กร จะต้องมีวิธีการจัดการอย่างไร? เรื่องของการเขียน Process ต้องมีการคำนึงถึง Algorithms ที่เลือกใช้พื้นที่ของ CPU ที่มีอยู่อย่างจำกัด และเรื่องของการใช้ Bandwidth Network บ่อยครั้งที่นึกอะไรไม่ออก Query อะไรมาได้ ก็จะขนส่งไปที่ฝั่ง Client ก่อน ส่งข้อมูลจำนวนมากเกินไป และให้ฝั่ง UX/UI ทำหน้าที่ในการเลือกใช้เองอยากให้ผู้พัฒนาซอฟต์แวร์สนใจเรื่องพวกนี้มากขึ้น หากพูดถึงปัญหาเรื่องการพัฒนาซอฟต์แวร์สำหรับขนาดหน้าจอที่แตกต่างกัน ต้องออกแบบการแสดงผลในหลายรูปแบบ ปัญหาเรื่อง Browser Compatibility ก็เป็นสิ่งสำคัญ ความแตกต่างของเว็บไซต์ เช่น Firefox, Safari, Microsoft edge, Google Chrome, และ Opera ดังนั้นนักพัฒนาจึงต้องเตรียมความพร้อมในการรับมือกับอุปกรณ์ และแพลตฟอร์มที่หลากหลายขึ้นด้วย สิ่งสำคัญที่ต้องคอยสังเกตนั่นก็คือเรื่องของ 3 A ได้แก่ 1. Authentication การพิสูจน์สิ่งใด ๆ

การที่เราจะเลือก Software สิ่งที่เราควรคำนึงคือ Open Source ทุกตัวไม่ได้เท่ากัน ประการแรกที่เราควรมอง คือ ความนิยม เช่น จำนวนดาวใน GitHub ที่เวลาใครเข้าไปดูโครงการ Open Source ต่าง ๆ ก็จะมีจำนวนดาวให้ดู แล้วปริมาณดาวบ่งบอกอะไร ? ปริมาณดาวจะบ่งบอกถึงความสนใจของชุมชนโดยรวมต่อโครงการนั้น ๆ ซึ่งหากมีคนกดดาวเยอะก็แปลว่าอาจมีคนสนใจหรือใช้งานโครงการนั้น ๆ จำนวนมาก แต่ปัญหาอย่างหนึ่งคือ จำนวนดาวของ GitHub เป็นสิ่งที่จะสะสมไปเรื่อย ๆ เพราะฉะนั้นหมายความว่า บางโครงการอาจจะเคยดังเมื่อนานมาแล้ว ตอนเปิดตัวบริษัทอาจจะไม่มีคู่แข่งจึงทำให้มีผู้ที่เข้ามาใช้บริการจำนวนมาก แต่เมื่อเวลาผ่านไปเริ่มมีคู่แข่งเพิ่มมากขึ้น ทำให้โครงการนั้น ๆ มีผู้ใช้บริการที่น้อยลงส่งผลให้ในบางกรณีดาวก็ไม่สามารถวัดผลได้ แต่การใช้งานดาวนี้ก็เป็นที่ยอมรับในระดับเบื้องต้น เช่น CNCF ที่เป็นองค์กรดูแลโครงการต่าง ๆ เกี่ยวกับ Kubernetes นั้นมีเกณฑ์ว่าโครงการที่จะเข้าสู่แผนภาพ landscape ของ CNCF จะต้องมีดาวบน GitHub อย่างน้อย 300 ดาว ปัจจัยที่สองที่เราสามารถพิจารณาโครงการ Open Source ได้ คือ รูปแบบการอนุญาตใช้งาน แม้โครงการจะเป็น Open Source เหมือนกัน แต่แต่ละโครงการก็มีรูปแบบการอนุญาตที่แตกต่างกันออกไป บางโครงการอาจจะเปิด Source ไว้ให้ตรวจสอบเท่านั้นแต่ไม่อนุญาตให้ใช้งานเลย ซึ่งบางนิยามก็จะไม่เรียกโครงการเหล่านี้ว่าเป็น Open Source ขณะที่บางโครงการอาจจะมีข้อจำกัดบ้าง เช่น บังคับว่าผู้ที่นำ Software ไปแก้ไข ต้องเปิด Software ออกมาเป็น Open Source ด้วย หรือบางโครงการก็ขอเพียงให้เครดิตผู้พัฒนาเท่านั้น ปัจจัยที่สามคือรูปแบบการพัฒนาโครงการ แม้หลายโครงการจะมีความนิยมสูง และเปิดให้ใช้งานได้อิสระเพียงพอ แต่รูปแบบการพัฒนาอาจจะผูกกับบุคคลหรือองค์กรใดองค์กรหนึ่ง ซึ่งก็จะมีความเสี่ยง เช่น บริษัทมีแนวทางการทำธุรกิจที่เปลี่ยนไป ทำให้อาจจะหยุดพัฒนาบางฟีเจอร์ หรือเลิกพัฒนา Software เป็น Open Source ไปเลยก็มี หรือบางครั้งเจ้าของโครงการอาจจะไม่มีเวลามาดูแลโครงการแล้ว ทำให้หยุดพัฒนาไปเสียเฉย ๆ โครงการ Open Source ที่มีความแข็งแกร่ง (mature) มักจะดำเนินการในลักษณะชุมชนร่วมกันตัดสินใจอย่างเปิดเผย เช่น CNCF นั้นระบุว่าโครงการที่จะอยู่ในระดับ Graduated ต้องมีองค์กรร่วมกันดูแลอย่างน้อยสององค์กร

ระบบ 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) ที่มีความฉลาดในการจัดการ การสื่อสารเป็นตัวกลางที่ดีและปลอดภัยระหว่างกัน