Tech Talk

การที่จะพัฒนาซอฟต์แวร์หรือว่าการสร้างสรรค์ชิ้นงานขึ้นมา หน้าที่หลักของนักพัฒนาซอฟต์แวร์ก็จะเป็นเรื่องของการรับ 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) ที่มีความฉลาดในการจัดการ การสื่อสารเป็นตัวกลางที่ดีและปลอดภัยระหว่างกัน

ปัญหาการสื่อสารมีแม้ในระบบไอที หากมีคนกลางที่ดี ระบบไอทีจะกลายเป็น 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 และ อื่น ๆ ที่แต่ละชื่อ คือระบบที่ ทำหน้าที่ของตนเองเป็นหลัก แต่ไม่สามารถ รู้จัก ระบบข้างเคียงได้โดยง่าย

เหตุการณ์สงครามระหว่างรัสเซียและยูเครน นับเป็นการปะทะกันที่รุนแรงที่สุดในทวีปยุโรปนับแต่สงครามโลกครั้งที่สอง นอกจากความสูญเสียที่เกิดขึ้นแล้ว ในส่วนของมาตรการต่างๆ ยังแสดงให้เห็นว่าบริการไอทีกลายเป็นตัวแปรสำคัญเมื่อเกิดเหตุระดับประเทศ บริษัทในรัสเซียตอนนี้ถูกตัดการให้บริการไอทีเป็นจำนวนมาก ไม่ว่าจะเป็น Software-as-a-Service, Platform-as-a-Service, หรือ Infrastructure-as-a-Service การที่โครงสร้างจำนวนมากหายไปในเวลาสั้น ๆ ธุรกิจที่ได้รับผลกระทบอาจจะต้องใช้เวลานานกว่าจะกู้คืนให้ธุรกิจเดินต่อไปได้ ส่วนสำคัญที่สุดของธุรกิจคงเป็นตัวข้อมูลธุรกิจเอง ที่หากเสียข้อมูลไปแล้วแทบไม่สามารถกู้บริการกลับมาได้เลยไม่ว่าจะใช้เวลานานเพียงใด การเตรียมรับมือเหตุการณ์เช่นนี้ น่าจะทำให้หลายองค์กรวางแผนให้อย่างน้อยที่สุดยังคงมีตัวข้อมูลหลักของธุรกิจอยู่กับตัวองค์กรเอง แม้จริง ๆ แล้วจะใช้บริการคลาวด์ก็ตาม สิ่งที่เราควรตระหนักคือ แม้บริการจะเป็น Software-as-a-Service ที่ผูกกับตัวบริการอย่างแนบแน่นก็ตาม บริการระดับองค์กรก็มักเปิดทางให้ลูกค้าสามารถดึงข้อมูลออกไปสำรองไว้ที่อื่นได้ อย่างที่เราเห็นกันบ่อย ๆ เช่น การดาวน์โหลดภาพจากจากบริการฝากภาพต่าง ๆ หรือบริการอีเมลที่มักมีให้ดาวน์โหลดอีเมลออกมาเก็บไว้ ซึ่งหากองค์กรมีข้อมูลอยู่กับตัวแม้จะถูกตัดบริการซอฟต์แวร์ไป ก็ยังมีความหวังได้ว่าจะสามารถนำข้อมูลไปใช้กับบริการอื่น ๆ ต่อได้ นอกจากตัวข้อมูลแล้วการตระหนักว่าธุรกิจของเราต้องเดินต่อไปได้แม้จะถูกผู้ให้บริการบางรายตัดบริการไปก็สำคัญเช่นกัน สำหรับบริการแบบ IaaS นั้นมีการพูดมานานแล้วว่าธุรกิจควรมองถึงแนวทาง Multi-Cloud ให้ใช้งานได้หลากหลายตามความความเหมาะสม ทั้งในแง่ของราคาและเทคโนโลยีที่ผู้ให้บริการแต่ละรายมีจุดเด่นต่างกัน การเตรียมพร้อมเพื่อให้มั่นใจว่าธุรกิจยังเดินหน้าต่อไปได้แม้เกิดเหตุในระดับประเทศเช่นนี้ก็ อาจจะต้องเตรียมความพร้อมด้วยบริการคลาวด์ในประเทศ หรือแม้แต่การใช้คลาวด์ในองค์กร (on-premise cloud) บางส่วน เผื่อกรณีที่แย่ที่สุดก็ยังสามารถดำเนินธุรกิจต่อไปได้ Content curator : Wason Liwlompaisan, CTO – MFEC