CTO Brief

March 2023 marks one of significant moments in AI development and real-life implementation. Only a few months after OpenAI launched ChatGPT, many people saw opportunities and noticed drastic changes in the way they work. Both Google and Microsoft also rushed in to catch up with the trend and announced the addition of AI capabilities to their services.  The massive changes in the way people work have happened multiple times since the 1980s. There was the introduction of the PC that enabled small businesses to use computers, which dramatically increased their work efficiency. There was the launch of smartphones which paved the way for new businesses such as application streaming, ride services, and food deliveries. Cloud services democratized access to high-quality infrastructure for all businesses when they began around 2000.  The launch of Microsoft 365 Copilot is a significant indication that the way we work with computers has changed forever. We have

Mr. Wason Liwlompaisan, Chief technology Officer at MFEC, shared his insights on technology trends in 2023 at National Coding Day 2023.   In the past few years, there have been significant changes in tech industry such as Chatbot AI that can understand human languages and convert them into computer readable data, frontend and backend developments that are the future of software development, accessibility, and many more. 1. Chatbot Chatbot is a currently a trending technology. Developers now use AI chatbot or language model for more than answering simple questions; they use AI for business management, writing emails, proofreading, and software development.   Many developers use AI to help with coding. For example, ChatGPT-3 is used to create commit messages. GPT-3 generates commit messages according to input Div from developers. Commit messages like “fix bug” or “new feature” will no longer be used in order to create a more effective commit message.     Large

During the COVID-19 crisis, business industry was in an urgent need of digital transformation. The traditional work process, which included paper documents and in-person authentication, became almost impossible. Although COVID-19 situations have gotten better enough for in-person process to take place as before, digital business operations continue to grow.   The biggest challenge of business industry is developing applications that respond to these changes in work process, which is still a difficult task. Many business processes require manual reviews, physical document transfers, and regulation inspection that is highly complicated and has a high risk of errors. Software development to tackle this issue has been insufficient due to a shortage of developers in recent years. This problem constantly occurs worldwide, and one of the solutions is low-code platforms that reduce software development time.   Nowadays, businesses share similar work process such as business process management, data management on database to gain business insights,

ช่วงปีที่ผ่านมาในโลกการเงินมีข่าวเกี่ยวกับเงินหยวนดิจิทัลกันมาก แม้ในช่วงแรกชื่อจะทำให้เข้าใจไปได้ว่าหยวนดิจิทัลเป็นเหมือนคริปโตเคอเรนซี่ที่มีมากมายหลายสกุลในโลกตอนนี้ แต่เมื่อรัฐบาลจีนเริ่มทดสอบหลายครั้งทำให้มีข้อมูลออกมาเพิ่มขึ้นว่าหยวนดิจิทัลนั้นคล้ายกับพร้อมเพย์ของไทยเป็นอย่างมากเนื่องจากเป็นแอปที่ผูกเงินเข้ากับบัญชีธนาคารโดยตรง เมื่อร้านค้ารับเงินจากลูกค้าแล้วก็จะได้รับเงินเข้าบัญชีธนาคารทันที แนวทางการใช้เงินอิเล็กทรอนิกส์ของจีนนั้นเริ่มต้นจากเอกชนเป็นหลัก โดยบริษัทเช่น Alipay และ WeChat สร้างระบบของตัวเองทั้งระบบ ไม่ว่าจะเป็นการออกแบบ QR ของตัวเอง กระบวนการโอนเงินระหว่างกันก็เป็นระบบภายใน หากต้องการโอนเงินกลับไปยังบัญชีธนาคารต้องเสียค่าธรรมเนียม แม้ว่าแนวทางนี้จะทำให้พัฒนาการเงินอิเล็กทรอนิกส์ในจีนเปลี่ยนแปลงอย่างรวดเร็ว แต่ก็สร้างความกังวลต่อการผูกขาดตลาดมากขึ้น ธนาคารกลางของจีนพยายามผลักดันหยวนดิจิทัล ด้วยการ “ทดสอบ” ระบบจากการแจกเงินคนละ 200 หยวน (ประมาณหนึ่งพันบาท) ซึ่งเป็นแนวทางเดียวกับบริษัทเอกชนที่เคยอาศัยการแจกเงินเพื่อให้คนทั่วไปหันมาใช้งานเหมือนกัน ในแง่เทคโนโลยี หยวนดิจิทัลมีความก้าวหน้ากว่าพร้อมเพย์ของไทยอยู่บ้างเพราะผู้ใช้สามารถจ่ายเงินได้แม้ไม่ได้เชื่อมต่ออินเทอร์เน็ต นับว่าน่าสนใจเพราะเราหลายคนคงเคยเจอปัญหากกันบ้างว่าจะจ่ายเงินผ่านพร้อมเพย์แต่แอปโหลดช้าเนื่องจากอยู่ในพื้นที่อินเทอร์เน็ตไม่ดีนัก สร้างความลำบากทั้งคนซื้อคนขายกันพอสมควร นอกจากนี้หยวนดิจิทัลยังใช้งานผ่านบัตรได้เช่นเดียวกับบัตรเดบิตในไทย หรือการใช้ผ่านแอปในโทรศัพท์เองก็รองรับการจ่ายผ่าน NFC ลดปัญหาการสแกน QR ไม่ติดไปอีกส่วน แม้จะน่าสนใจในแง่เทคโนโลยี แต่การดึงประชาชนและร้านค้าที่รองรับ Alipay และ WeChat Pay กันเป็นวงกว้างแล้วให้มาใช้งานหยวนดิจิทัลก็คงเป็นความท้าทายของธนาคารกลางจีนอีกมาก – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

การพัฒนาแอปพลิเคชั่นให้มีความปลอดภัยนั้นเป็นความท้าทายอย่างยิ่งในทุกวันนี้ ไม่ว่าโปรแกรมเมอร์แต่ละคนจะมีความเชี่ยวชาญเพียงใดก็มีโอกาสที่จะพลั้งเผลอเขียนโค้ดในรูปที่แม้จะทำงานได้ แต่มีโอกาสแสดงบั๊กเมื่อทำงานในโลกความเป็นจริง การตรวจสอบโค้ดด้วยเครื่องมือต่างๆ จึงเป็นเรื่องที่เราควรต้องทำเสมอ ทุกวันนี้ภาษาโปรแกรมส่วนมากมีโครงการตรวจสอบโค้ดที่เรียกว่า Lint อยู่ภาษาที่ได้รับความนิยมสูงๆ ก็จะมีโครงการในกลุ่มเดียวกันอยู่หลายตัวให้เลือกใช้⠀⠀⠀⠀แต่ Lint มักมีข้อจำกัดจากการวิเคราะห์โค้ดตามกฎตายตัวชุดหนึ่งเท่านั้น ไม่สามารถแนะนำแนวทางการเขียนโค้ดที่ซับซ้อนขึ้นไป เช่น การใช้ไลบรารีอย่างถูกวิธี ข้อจำกัดเช่นนี้ทำให้หลายโครงการมีเงื่อนไขให้นักพัฒนารีวิวโค้ดกันเองเป็นขั้นสุดท้ายก่อนรับโค้ดเข้าระบบ แต่หลายทีมก็อาจจะไม่พร้อมวางกระบวนการรีวิวโค้ดเช่นนั้น (และแม้แต่คนรีวิวเองหลายครั้งก็มองข้ามจุดผิดพลาดกันได้) การใช้เครื่องมือตรวจสอบโค้ดที่เก่งกาจขึ้นจึงเป็นทางเลือกที่ดีสำหรับหลายๆ คน⠀⠀⠀⠀ผู้ให้บริการคลาวด์รายใหญ่อย่าง AWS เปิดบริการ CodeGuru Reviewer ให้บริการตรวจสอบคุณภาพโค้ดในระดับลึก โดยเมื่อตอนเปิดตัวในปี 2019 นั้นรองรับเฉพาะโค้ดภาษา Java เท่านั้น แต่มาประกาศเพิ่มภาษา Python ในงาน re:Invent 2020 ที่ผ่านมา⠀⠀⠀⠀CodeGuru Reviewer อาศัยเทคโนโลยี machine learning เพื่อจับรูปแบบโค้ดที่ซับซ้อนขึ้นกว่าซอฟต์แวร์ Lint แบบเดิมๆ มันสามารถจับบั๊กที่พบบ่อยๆ เช่น เผลอว่าข้อมูลลับไว้ในโค้ด (credential), การใช้และคืนทรัพยากรไม่สมบูรณ์ (resource leak), ไปจนถึงการวิเคราะห์หา deadlock ในโค้ด⠀⠀⠀⠀ เงื่อนไขการใช้งาน Amazon CodeGuru:– เราต้องเก็บโค้ดไว้ใน git repository ที่ CodeGuru รองรับ– ได้แก่ AWS CodeCommit, Bitbucket, GitHub, และ GitHub Enterprise⠀⠀⠀⠀ เริ่มการทดลองใช้งาน Amazon CodeGuru:– เมื่อเชื่อมต่อ repository เข้ากับ CodeGuru แล้วเราสามารถเลือกรีวิวโค้ดได้สองแบบ คือการรีวิวโค้ดทั้งหมด (full repository) และการรีวิว pull request ที่อาจจะเหมาะกับการตรวจสอบโค้ดก่อนรวมเข้า branch หลัก– เมื่อสั่งรันการวิเคราะห์โค้ดแล้วก็ต้องรอให้ CodeGuru รันสักระยะหนึ่ง (โครงการที่ผมลองเป็นโค้ดเพียง 130 บรรทัด ใช้เวลาวิเคราะห์ประมาณ 5 นาที)– เมื่อรันเสร็จแล้ว CodeGuru Reviewer จะแสดงคำแนะนำ พร้อมบอกเหตุผลว่าทำไม CodeGuru จึงมองว่าโค้ดส่วนนี้มีปัญหา โครงการที่ผมใส่โค้ดเข้าตรวจสอบนี้ CodeGuru พบจุดที่แนะนำเพียงจุดเดียว⠀⠀⠀⠀ ผลลัพธ์จาก Amazon CodeGuru:– คำแนะนำของ CodeGuru แจ้งเตือนการเปิดและปิดไฟล์โดยใช้ฟังก์ชั่น open/close โดยชี้ให้เห็นว่าแม้โค้ดจะทำงานได้ดี แต่แนวทางการเขียนโค้ดเช่นนี้ไม่เป็นไปตาม best practice ที่โครงการ Python แนะนำ– หากมีความผิดพลาดในโค้ดอาจจะทำให้เกิดการเปิดไฟล์ค้างไว้กลายเป็น resource leak ทำให้ซอฟต์แวร์ทำงานช้ากว่าปกติ หรืออาจจะทำให้เซิร์ฟเวอร์ไม่เสถียรได้⠀⠀⠀⠀จะเห็นว่าการใช้งาน CodeGuru นั้นใช้งานได้ไม่ยาก และสามารถใช้งานแยกจากบริการอื่นๆ ได้แม้จะไม่ได้เห็นผู้ใช้บริการ AWS แต่เดิมก็ตาม โดยซอฟต์แวร์วิเคราะห์โค้ดนั้นหลายครั้งมีราคาค่อนข้างสูง แต่ CodeGuru คิดค่าใช้จ่ายตามจริงโดยไม่ต้องลงทุนก้อนใหญ่ก่อนเริ่มใช้งาน⠀⠀⠀⠀ การคิดค่าบริการ Amazon CodeGuru:โดยให้บริการฟรีเดือนละ 30,000 บรรทัด และเกินจากนั้นคิดค่าบริการ 0.5 ดอลลาร์ต่อ 100 บรรทัด (นับบรรทัดโค้ดตามการใช้งานจริง) และยังใช้งานได้ฟรีเดือนละ 30,000 บรรทัดต่อบัญชี  – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล

การวางระบบที่มีความสำคัญมากๆ มักมาพร้อมกับการวางแผนสำรองข้อมูลเป็นเรื่องปกติ แต่แผนสำรองข้อมูลส่วนมากกลับวางแผนไว้เพื่อเตรียมพร้อมกรณีฮาร์ดแวร์เสียหายเป็นหลัก เราจึงมักเห็นเซิร์ฟเวอร์แอปพลิเคชั่นต่างๆ ติดตั้งซอฟต์แวร์สำรองข้อมูลเอาไว้ เพื่อสำเนาข้อมูลไปยังที่ต่างๆ ทั้งไดร์ฟภายนอกและบริการคลาวด์ แนวทางนี้เรียกว่า push backup เป็นการส่งข้อมูลสำรองออกไปจากเครื่องหลัก ปัญหาของ push backup คือหากแอปพลิเคชั่นเซิร์ฟเวอร์ถูกแฮก หรือถูกโจมตีด้วยมัลแวร์ต่างๆ ในเซิร์ฟเวอร์มักมีรหัสผ่านหรือกุญแจสำหรับเข้าถึงเซิร์ฟเวอร์และสตอเรจต่างๆ ที่ใช้เก็บข้อมูลสำรองไปด้วย ในยุค ransomware เช่นทุกวันนี้ ตัวมัลแวร์เริ่มมีความสามารถมากขึ้นรวมถึงบางครั้งมีการทำงานร่วมกับแฮกเกอร์ที่สั่งการโดยตรง (human operated ransomware) ทำให้การทำ push backup ยังเหลือความเสี่ยงอยู่พอสมควร อีกแนวทางหนึ่งคือการทำ pull backup ที่ซอฟต์แวร์สำรองข้อมูลไปติดตั้งอยู่บนเครื่องเก็บข้อมูลสำรอง จากนั้นสร้าง user บนแอปพลิเคชั่นเซิร์ฟเวอร์เพื่อให้ซอฟต์แวร์สำรองข้อมูลสามารถเข้ามากวาดข้อมูลออกไปได้ แนวทางนี้มีข้อดีคือเราสามารถจำกัดสิทธิ์ของ user สำหรับสำรองข้อมูลให้เข้าถึงข้อมูลบนแอปพลิเคชั่นเซิร์ฟเวอร์ได้อย่างจำกัด เช่น สามารถอ่านได้อย่างเดียว ทำให้แม้เซิร์ฟเวอร์สำรองข้อมูลอาจจะถูกแฮก คนร้ายก็ไม่สามารถทำลายข้อมูลในแอปพลิเคชั่นเซิร์ฟเวอร์ได้ ซอฟต์แวร์สำรองข้อมูลจำนวนมากมีทั้งโหมด push และ pull สำหรับลินุกซ์ ผู้ดูแลระบบสามารถเขียนสคริปต์โดยใช้ rsync รวมกับ OpenSSH ได้ คำสั่งจะอยู่ในรูปแบบ rsync -avz backupagent@appserver:/localbackups/ /remotebackups/ จะเป็นการดึงข้อมูลจากแอปพลิเคชั่นเซิร์ฟเวอร์ ในโฟลเดอร์ `/localbackups` มายังเซิร์ฟเวอร์สำรองข้อมูล การออกแบบระบบสำรองข้อมูลมีความสำคัญ การออกแบบที่ดีลดความเสี่ยงกรณีต่างๆ ไปได้มาก นอกจากนั้นแล้วผู้ดูแลระบบควรพิจารณาซักซ้อมกู้คืนระบบเป็นระยะ รวมถึงอาจสำรองข้อมูลในสตอเรจที่แยกออกไปต่างหากไม่เชื่อมต่อกับเน็ตเวิร์คไว้อีกชั้น – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

ปี 2020 หากไม่เกิด COVID เสียก่อน เราอาจจะได้เห็นธีมเทคโนโลยีของปีนี้ว่าเป็นปีแห่ง Kubernetes ของโลกองค์กร ความนิยมในเทคโนโลยี Kubernetes ที่องค์กรจำนวนมากมองว่าเป็นโอกาสที่จะรวมแพลตฟอร์มที่กระจัดกระจายเข้าเป็นแพลตฟอร์มมาตรฐาน แม้จะใช้ Kubernetes หลากหลายยี่ห้อก็มีโอกาสจัดการได้ด้วยเครื่องมือชุดเดียวกัน ผู้เล่นรายใหญ่อย่าง IBM ซื้อ Red Hat แทบจะเรียกได้ว่าซื้อ OpenShift แถม Linux เพราะสิ่งที่ IBM น่าจะมองเห็นจริงๆ คือโลกองค์กรทั้งหมดในอนาคตจะย้ายโหลดงานขึ้นไปอยู่บน Kubernetes แทบทั้งสิ้น การใช้ Kubernetes ทำให้การสร้าง deploy แอปพลิเคชั่นไม่ว่าจะเป็น on-premise หรือคลาวด์ใดๆ สามารถใช้คอนฟิกชุดเดียวกันได้เสมอ ปีนี้ VMware กำลังลงมาเล่นตลาดนี้เต็มตัวด้วย Tanzu บริษัทซอฟต์แวร์สำหรับองค์กรรายใหญ่ล้วนกำลังก้าวไปยัง Kubernetes ทั้งสิ้น Elasticsearch นั้นรองรับ Elastic Cloud ตั้งแต่ปีที่แล้ว ผมเองได้ลองใช้งานแล้วก็ต้องยอมรับว่าสะดวกกว่าเซ็ตอัพเองมาก แม้กระบวนการอัพเกรดซอฟต์แวร์ที่ลองแล้วยังมีปัญหาอัพเกรดแล้วค้างไปกลางทาง คำถามคือในโลกองค์กรที่เราเห็นเริ่มใช้ Kubernetes กันเรื่อยๆ แล้วยังมีตลาดอีกมากแค่ไหน โพลล์ของ Red Hat แสดงให้เห็นโลกความเป็นจริงว่าตลาด Kubenetes เกิดการแบ่งฝั่ง ระหว่างกลุ่มผู้ใช้และกลุ่มที่ยังไม่ใช้ โลกของสตาร์ตอัพหรือองค์กรที่มีความพร้อมสูงอาจจะสามารถย้ายโหลดงานทั้งหมดขึ้นไปยัง Kubernetes ได้อย่างรวดเร็ว โดยเฉพาะองค์กรที่ย้ายโหลดไปเป็นคอนเทนเนอร์มาก่อนหน้านี้แล้ว อีกด้านองค์กรที่ยังตามไปไม่ทัน โหลดงานแทบทั้งหมดยังเป็น Virtual Machine (หรือแม้แต่เซิร์ฟเวอร์จริงๆ!) องค์กรเหล่านี้อาจจะไม่พร้อมแม้กระทั่งการย้ายโหลดงานขึ้นคลาวด์หรือการแปลงโหลดงานเป็นคอนเทนเนอร์ ยังคงเป็นตลาดที่ Kubernetes สามารถขยายตัวเข้าไปได้อีกมาก กระแสตอนนี้ค่อนข้างชัดเจนว่า Kubernetes กำลังจะกลายเป็นระบบจัดการโหลดไม่ว่าจะเป็นคอนเทนเนอร์หรือ VM ก็ตามจากการที่ OpenShift รองรับ VM เมื่อต้นปีที่ผ่านมา ความเป็นไปได้คือองค์กรที่โหลดยังเป็น VM อยู่บางองค์กร อาจจะย้ายแอปของตัวเองเข้า Kubernetes ไปเลยทีเดียว โดยใช้แนวทางว่าส่วนไหนทำเป็นคอนเทนเนอร์ได้ก็ทำ ส่วนไหนทำไม่ได้ก็ย้ายเข้า Kubernetes ไปทั้ง VM เลยทีเดียว – – – โดยวสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC

นาทีนี้หากจะมีองค์กรใดวางระบบไอที หากเป็นไปได้องค์กรเหล่านั้นมักวางระบบบนคลาวด์แทบทั้งหมด ด้วยเหตุผลสำคัญจากการลดระยะเวลาการพัฒนาบริการใหม่ๆ ที่องค์กรไม่ต้องเสียเวลาจัดซื้อเซิร์ฟเวอร์, วางโครงสร้างเน็ตเวิร์ค และการประเมินความเสี่ยงในระยะยาวอื่นๆ ที่ผ่านมาบริการคลาวด์เหล่านี้กระทบรายผู้ให้บริการวางระบบไอทีไปไม่น้อย จากเดิมที่องค์กรต่างๆ มักต้องวางระบบไอทีด้วยตัวเอง มีการจัดซื้อฮาร์ดแวร์และซอฟต์แวร์จำนวนมาก มาเป็นการซื้อสร้างเซิร์ฟเวอร์ทีละน้อยๆ และขยายตามโหลดที่จำเป็นต่อการใช้งานได้ทันที การวางระบบขนาดใหญ่ๆ เพื่อรองรับการใช้งานทีละ 3-5 ปีข้างหน้าจึงหายไปในกลุ่มองค์กรที่ใช้งานคลาวด์ไปแล้ว Naver Cloud Platform คลาวด์จากเกาหลีใต้ที่ประกาศว่าจะเข้าไทย ก็ประกาศให้บริการ On-Premise Cloud แล้ว อีกจุดสำคัญของธุรกิจคลาวด์คือการทำให้สินค้าสำหรับองค์กรกลายเป็นสินค้าสำหรับผู้บริโภคทั่วไปได้อย่างน่าทึ่ง กระบวนการ “ทำราคา” ที่ออกแบบราคาสำหรับลูกค้าแต่ละรายตามขนาดการสั่งซื้อกลายเป็นการนำเสนอราคาอย่างเปิดเผย ทุกวันนี้เราสามารถดูราคาของเซิร์ฟเวอร์ใน AWS, Azure, หรือ Google Cloud ได้ทั้งหมด ไม่ว่าจะเป็นเครื่องเริ่มต้นเดือนละร้อยกว่าบาท หรือเครื่องขนาดใหญ่เดือนละหลายแสนบาทก็ตามที การเปิดเผยราคาเช่นนี้ทำให้ผู้ให้บริการคลาวด์ทุกรายต้องทำราคาแข่งกันอย่างหนัก เมื่อผู้ให้บริการรายหนึ่งประกาศปรับราคาสินค้าตัวใดลง รายอื่นๆ ก็มักจะประกาศปรับราคาให้เท่าๆ กันภายในไม่กี่วัน ไม่นับว่าบริการเหล่านี้พยายามทำตลาดอย่างหนักด้วยการให้โควต้าใช้งานฟรีจำนวนมาก การแข่งขันกันเช่นนี้บีบให้ส่วนแบ่งของตัวแทนจำหน่ายบริการคลาวด์ทุกรายต่ำกว่าการขายสินค้า On-Premise เดิมๆ ไม่ว่าจะเป็นเซิร์ฟเวอร์, สตอเรจ, หรือระบบเน็ตเวิร์คอื่นๆ แต่องค์กรจำนวนมากก็ยังคงต้องรักษาระบบในองค์กรเอาไว้จากความจำเป็นด้านความปลอดภัย, กฎหมาย, หรือเงื่อนไขอื่นๆ ทำให้ที่ผ่านมาธุรกิจ SI ยังคงสามารถทำกำไรจากลูกค้ากลุ่มนี้ได้ แต่ในช่วงปีที่ผ่านมา ผู้ให้บริการคลาวด์หลายรายเปิดบริการคลาวด์แบบติดตั้งในศูนย์ข้อมูลขององค์กรกันมากขึ้นเรื่อยๆ โดยอาศัยชื่อเสียงและความเชี่ยวชาญที่สร้างจากการให้บริการคลาวด์ขนาดใหญ่ ออกแบบระบบขนาดเล็กลงโดยอาจจะเหลือเพียงตู้เซิร์ฟเวอร์เดียว แล้วนำไปติดตั้งในศูนย์ข้อมูลขององค์กร ที่เข้ามาทำตลาดในไทยก่อนเพื่อน เช่น Cloud@Customer ของ Oracle และตอนนี้ก็ยังมี AWS Outpost เพิ่มเริ่มเข้ามาทำตลาดในไทย แนวทางที่โลกระบบไอทีองค์กรอาจจะไม่เคยเห็นนัก คือการเปิดเผยราคาบนเว็บ แม้แต่เซิร์ฟเวอร์ตู้ละ 50 ล้านบาท คลาวด์ในองค์กรลดข้อได้เปรียบสำคัญของคลาวด์คือการเริ่มจากระบบขนาดเล็กๆ ไป การติดตั้งคลาวด์ในองค์กรทำให้มองค์กรมีภาระผูกพันว่าต้องใช้งานตามขนาดเครื่องที่ซื้อมา เช่น AWS Outpost นั้นเริ่มต้นที่ราคาประมาณ 8 ล้านบาท ขึ้นไปจนถึง 50 ล้านบาท แม้จะมีทางเลือกให้จ่ายรายเดือนได้ตลอดระยะเวลาสามปี แต่ทั้งหมดแล้วองค์กรก็ยังคงมีภาระผูกพันในการจ่ายค่าเซิร์ฟเวอรตามขนาดที่เลือกมาแล้วอยู่ดี ไม่สามารถลดขนาดได้แม้โหลดจะต่ำลงก็ตาม อย่างไรก็ดีองค์กรจำนวนมากกลับให้ความสนใจกับ On-Premise Cloud เหล่านี้ด้วยชื่อเสียงของผู้ให้บริการคลาวด์ที่สามารถรักษาเสถียรภาพของบริการได้ค่อนข้างดี อีกทั้งการใช้ On Premise Cloud เหล่านี้ยังสามารถเข้าถึงซอฟต์แวร์และบริการบางตัวแบบจ่ายเงินตามการใช้งานจริง เช่น บริการระบบฐานข้อมูลสำเร็จรูป RDS, หรือบริการ Kubernetes ทำให้แม้องค์กรจะเสียเงินค่าฮาร์ดแวร์เป็นก้อนใหญ่ แต่ค่าซอฟต์แวร์เฉพาะก็ยังจ่ายเงินตามการใช้งานจริงต่อไป ตัวอย่างเช่น Amazon EKS นั้นคิดค่าบริการ 0.1 ดอลลาร์ต่อคลัสเตอร์ต่อชั่วโมง โดยไม่ต้องซื้อไลเซนส์ราคาแพงล่วงหน้า หรือ Amazon RDS เองก็คิดค่าบริการตามขนาดเซิร์ฟเวอร์ฐานข้อมูล โดยไม่ต้องมีสัญญาการใช้งานซอฟต์แวร์ขั้นต่ำ ธุรกิจ SI กำลังพบความท้าทายจากผู้ให้บริการรายใหญ่เหล่านี้ หากทุกอย่างเป็นไปตามที่ผู้ให้บริการคลาวด์โฆษณาไว้ เซิร์ฟเวอร์เหล่านี้จะซ่อมบำรุงตรงจากผู้ให้บริการคลาวด์รายใหญ่แทบทั้งหมด การทำกำไรจากการติดตั้งฮาร์ดแวร์และซอฟต์แวร์น่าจะทำได้ลำบากขึ้นในอนาคต แม้แต่บริการซัพพอร์ต AWS Outpost เองก็บังคับขายพร้อมกับบริการ AWS Enterprise Support ของตัวเอง ธุรกิจ SI จะอยู่เดินหน้าได้อย่างไร ในยุคที่ Cloud กำลังครอบครองทุกพื้นที่แม้แต่ในศูนย์ข้อมูลลูกค้า เช่นนี้ ความเป็นไปได้อย่างหนึ่งคือการให้บริการที่ระดับสูงขึ้นไป การ Optimize โครงสร้างพื้นฐานเพื่อให้รองรับ peak load ได้ทุกช่วงเวลาอย่างแท้จริง ขณะเดียวกันก็สามารถออกแบบระบบให้ใช้งานทรัพยากรได้เต็มที่จนอาจจะลดต้นทุน กรณี On-Premise Cloud อาจจะต้องวิเคราะห์ได้ว่า

แนวทางการวางระบบไอทีในองค์กรคงมีขั้นตอนหนึ่งคือการประเมินการใช้ทรัพยากรของแอปพลิเคชันใหม่ที่เรากำลังติดตั้งว่าต้องใช้ซีพียู แรม หรือเน็ตเวิร์คมากน้อยแค่ไหน ซึ่งการประเมินให้ถูกต้องเป็นเรื่องที่แทบเป็นไปไม่ได้ องค์กรต่างๆ จึงมักมีทรัพยากรเหลือๆ ไม่ได้ใช้งานจำนวนมาก หรือแอปพลิเคชันบางส่วนทำงานแค่บางช่วงเวลาก็มักถูกกันทรัพยากรเตรียมไว้ให้ โดยที่ไม่มีแอปพลิเคชันอื่นมาใช้งานได้ การใช้งานคลาวด์ช่วยให้การจัดสรรทรัพยากรทำได้สะดวกขึ้นในช่วงหลังเนื่องจากองค์กรไม่ต้องซื้อฮาร์ดแวร์มาเตรียมการไว้ล่วงหน้า แต่สั่งใช้งานเพิ่มได้ทันทีที่ต้องการ แต่กระนั้นหากแอปพลิเคชันไม่ได้ออกแบบให้เตรียมพร้อมสำหรับการขยายตามโหลดที่ใช้งานจริง องค์กรก็มักต้องเสียค่าใช้จ่ายทรัพยากรสิ้นเปลืองไปเป็นปกติแม้จะใช้คลาวด์ก็ตาม แนวทางการพัฒนาแบบ Serverless จึงเริ่มเป็นที่น่าสนใจสำหรับองค์กรขึ้นเรื่อยๆ ในช่วงหลัง โดยแนวทางนี้คือการที่โค้ดถูกเก็บไว้บนเซิร์ฟเวอร์รอที่จะรัน โดยไม่ต้องจองทรัพยากรใดๆ ล่วงหน้า หากมีเหตุการณ์ (event) ที่เกี่ยวข้องกับโค้ดนั้น เช่น การเรียกใช้งานเว็บ ตัวโค้ดจึงถูกเรียกขึ้นมา จองแรมและซีพียู และประมวลผลข้อมูลเพื่อตอบกลับ บริการคลาวด์ส่วนมากมีบริการ Serverless ให้บริการ เช่น AWS Lambda หรือ Google Cloud Run โดยบริการเหล่านี้คิดค่าใช้งานอย่างละเอียด เช่น การใช้ซีพียูและแรมเป็นวินาที แม้ว่าราคาอาจจะดูแพงหากคิดการเปิดเซิร์ฟเวอร์ตลอดเวลา แต่หากไม่มี event เรียกใช้งานโค้ดเลยก็จะแทบไม่มีค่าใช้จ่ายใดๆ ในองค์กรเอง การใช้เฟรมเวิร์ค เช่น KNative มาสร้างบริการ Serverless ภายในองค์กรเริ่มเป็นตัวเลือกที่น่าสนใจ เพราะการที่ไม่มีแอปพลิเคชันจองทรัพยากรไว้ไม่ว่าจะใช้งานหรือไม่ ทำให้องค์กรสามารถประหยัดทรัพยากรโดยรวมลงได้ อัตราการใช้งานเซิร์ฟเวอร์คุ้มค่ามากขึ้น ข้อจำกัดของ Serverless คือแอปพลิเคชันที่มีอยู่เดิมอาจจะต้องปรับแก้เยอะหรือบางกรณีอาจจะต้องพัฒนาใหม่แต่ต้น และการใช้งานหลายครั้งก็ผูกติดกับผู้ให้บริการคลาวด์อย่างแนบแน่น อาจจะทำให้การย้ายแอปพลิเคชันออกไปยังคลาวด์อื่นทำได้ยาก นับเป็นความท้าทายในการตัดสินใจแนวทางการพัฒนาต่อไป – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC

ภัยไซเบอร์กลายเป็นความเสี่ยงทางธุรกิจอย่างมากในช่วงหลายปีมานี้ หลายคนอาจจะคิดว่าการโจมตีไซเบอร์นั้นแฮกเกอร์ต้องสร้างโปรแกรมพิเศษมาเจาะเข้าเครือข่าย เข้าถึงข้อมูลในเซิร์ฟเวอร์ ไปจนถึงแอบดูข้อมูลทุกอย่างในเครื่องเราได้ แต่การโจมตีส่วนใหญ่แล้วมาจากการส่งเมลหลอก หรือฟิชชิ่ง (phishing) ที่ไม่จำเป็นต้องอาศัยความรู้ทางเทคนิคอะไรมากมายนัก แต่อาศัยการปรับแต่งอีเมลและสร้างเว็บให้แนบเนียน เพื่อหลอกเอาข้อมูลเท่านั้น ฟิชชิ่งสมัยก่อนนั้นมักอาศัยการส่งอีเมลหว่าน โดยปลอมตัวว่าเป็นอีเมลจากบริการยอดนิยม ไม่ว่าจะเป็นเฟซบุ๊ก, ทวิตเตอร์, อีเมลฟรี, หรือธนาคารดัง เพื่อหลอกให้ผู้ใช้ยอมใส่รหัสผ่าน และแม้แต่ OTP ที่ส่งมาทาง SMS ก็ตาม ผู้ใช้อินเทอร์เน็ตในช่วงหลายปีมานี้เริ่มปรับตัวกันมากขึ้น และผู้ใช้ก็ไม่ค่อยตกเป็นเหยื่ออีเมลฟิชชิ่งกันบ่อยนัก แต่คนร้ายก็ปรับตัวไป โดยมุ่งเป้าไปที่การส่งอีเมลปลอมอย่างเจาะจงมากยิ่งขึ้น ทำให้อีเมลหลอกมักอยู่ในรูปแบบที่น่าเชื่อถือ บางทีเป็นการพูดคุยต่อเนื่องกับบทสนทนาของตัวจริง เรียกการโจมตีแบบนี้ว่า spear phishing เปรียบกับการจับปลาแบบใช้หอกพุ่งตรงไปยังตัวปลาแทนที่จะหว่านแหไป ตัวอย่างของการโจมตี เช่น คนร้ายปลอมตัวเป็นซัพพลายเออร์ที่บริษัทซื้อสินค้าอยู่เป็นประจำ ส่งอีเมลแจ้งเรียกเก็บเงินเหมือนทุกครั้งที่ผ่านมา พร้อมกับโน้ตสั้นๆ ว่าขอเปลี่ยนหมายเลขบัญชีรับเงิน เจ้าหน้าที่ฝ่ายจัดซื้อก็อาจจะพลาดยอมโอนเงินไปยังบัญชีของคนร้ายโดยไม่รู้ตัว การปลอมตัวอาจจะใช้ข้อมูลที่หาได้โดยง่าย เช่น ชื่อของพนักงานที่ทำหน้าที่เรียกเก็บเงินแล้วสร้างอีเมลใหม่ปลอมชื่อ หรือบางครั้งอาจจะผสมกับการแฮกอีเมลพนักงานจริงแล้วใช้ส่งอีเมลหลอกเพิ่มความแนบเนียนไปอีกขั้น การโจมตีคล้ายๆ กันนี้เราอาจจะพบเรื่อยๆ เช่นการแฮกเฟซบุ๊กแล้วส่งข้อความไปยังเพื่อนของเหยื่อเพื่อขอยืมเงิน แต่การแฮกเฟซบุ๊กนั้นคนร้ายอาจจะได้เงินไปปริมาณไม่มากนัก แต่ละครั้งอาจจะหลายพันหรือหลายหมื่นบาท ในกรณี Spear Phishing กับองค์กรความเสียหายอาจจะหลายล้านบาทเลยทีเดียว การป้องกันการโจมตีเช่นนี้มีตั้งแต่มาตรการทางเทคนิค เช่น การเตือนผู้ใช้ว่ากำลังส่งข้อความหรืออีเมลหาใครอยู่ ให้แยกให้ออกอย่างชัดเจนแม้ชื่ออีเมลจะดูคล้ายกัน, ติดตั้งระบบคัดกรองและแจ้งเตือนอีเมลมุ่งร้าย ตลอดจนวางนโยบายการทำงานให้รัดกุมความเปลี่ยนแปลงบางอย่าง เช่น การเปลี่ยนเลขบัญชีจ่ายเงินออก ต้องมีการตรวจสอบข้อมูลเพิ่มเติม เป็นต้น – – –โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาลChief Technology Officer, MFEC