admin 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

กระบวนการพัฒนาซอฟต์แวร์แบบเดิมๆ นั้นหากมีการควบคุมคุณภาพ เราก็มักจะรวบรวมฟีเจอร์ต่างๆ จากทีมพัฒนาเข้ามารวมกันเป็นรอบๆ แล้วส่งทีมควบคุมคุณภาพเพื่อทดสอบและหาบั๊กในโค้ดที่กำลังพัฒนาต่อไป กระบวนการเช่นนี้ทำให้โปรแกรมเมอร์อาจจะต้องรอเป็นเวลานาน กว่าจะรับรู้ว่าฟีเจอร์ที่ตัวเองพัฒนาไปนั้นไปสร้างบั๊กให้กับโครงการโดยรวมในจุดอื่นๆ หรือไม่ ทำให้แนวทาง Continuous Integration (CI) ได้รับความสนใจขึ้นมามากในช่วงหลัง แนวทาง CI คือการสร้างระบบที่รวบรวมโค้ดจากนักพัฒนาเข้ามาเป็นชุดเดียวกันอย่างต่อเนื่อง โดยไม่ปล่อยให้โค้ดที่อยู่ในมือนักพัฒนาแต่ละคนต่างกันนานเกินไป แนวทางนี้มักรวบเข้ากันกระบวนการทดสอบซอฟต์แวร์โดยอัตโนมัติ (automated test) ที่ทำให้โค้ดที่ถูกรวมเข้าไปถูกทดสอบว่าสามารถทำงานตามเงื่อนไขได้อย่างถูกต้อง ซอฟต์แวร์ CI มักเชื่อมต่อกับระบบเก็บซอร์สโค้ด เมื่อมีการส่งโค้ดเข้าโครงการ เช่น นักพัฒนาคนหนึ่งส่ง pull request เข้ามาเพื่อส่งฟีเจอร์ใหม่ ระบบจะนำโค้ดนั้นไปคอมไพล์และรันทดสอบว่าผ่านดีหรือไม่โดยอัตโนมัติ ผู้ดูแลโครงการสามารถเห็นรายงานเบื้องต้นว่าคุณภาพโค้ดยอมรับได้ ตัวซอฟต์แวร์ที่ทำงานเช่นนี้มีหลายตัวในตลาด ระบบจัดเก็บซอร์สโค้ดอย่าง GitLab นั้นมีฟีเจอร์ CI ในตัว หรือบริการคลาวด์หลายตัวก็เริ่มให้บริการ CI บ้างแล้ว เช่น Azure Pipelines หรือแพลตฟอร์ม Kubernetes อย่าง OpenShift ก็มีฟีเจอร์ OpenShift Pipelines การจัดหาซอฟต์แวร์ที่เหมาะสมก็เป็นความท้าทายอย่างหนึ่ง แต่การพัฒนาซอฟต์แวร์ที่จะใช้ประโยชน์จากแนวทาง CI ได้อาจจะต้องปรับตัวกันตั้งแต่กระบวนการออกแบบซอฟต์แวร์ที่เปิดให้สร้างระบบทดสอบอัตโนมัติได้โดยง่าย และหน้าที่ของคนในทีมที่ต้องทำงานโดยมองระบบอัตโนมัติเป็นสำคัญ – – – โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล Chief Technology Officer, MFEC