ความสำคัญของการพัฒนาบนแพลตฟอร์มคอนเทนเนอร์และระบบ orchrestration เช่น kubernetes เริ่มแสดงความสำคัญขึ้นอย่างมากในช่วงหลังที่องค์กรต้องการรูปแบบการพัฒนาที่รวดเร็ว แม้ว่า kubernetes จะเป็นซอฟต์แวร์โอเพนซอร์สที่ทุกคนสามารถดาวน์โหลดไปใช้งานได้ฟรี แต่ก็อาจจะขาดส่วนประกอบที่จำเป็นสำหรับโลกองค์กรหลายประการ โดยเฉพาะการรับประกันในระยะเวลาที่ยาวนาน และฟีเจอร์สำหรับองค์กรที่มีความซับซ้อนสูง

โอกาสนี้ Blognone ได้พูดคุยกับคุณสุพรรณี อํานาจมงคล Senior Solutions Architect ที่ทำงานกับองค์กรใหญ่ๆ ทั่วภูมิภาคอาเซียนมานานกว่าสิบปี ถึงความเปลี่ยนแปลงครั้งนี้

กระแสคอนเทนเนอร์เกิดในโครงการรุ่นใหม่ๆ แต่สำหรับโลกองค์กรที่มีซอฟต์แวร์ดั้งเดิม (legacy system) มากมาย อะไรเป็นความท้าทายที่สุดในการปรับตัว

ความท้าทายหลังคงมีด้วยกัน 3 ด้าน ได้แก่ บุคคลากร (People), วิธีการพัฒนาระบบงาน (Methodology) และ เทคโนโลยี (Technology)

ความท้าทายแรกเรื่องบุคคลากร องค์กรจะทำอย่างไรให้บุคคลากรไอทีที่มีอยู่ สามารถเรียนรู้และปรับตัวเข้าหาเทคโนโลยีรูปแบบใหม่ๆ ตลอดจนการปรับเปลี่ยนวิธีคิดให้ตามธุรกิจที่ต้องการการเปลี่ยนแปลงอย่างรวดเร็วได้ทัน นอกจากนี้การสร้างบุคคลกรรุ่นใหม่ๆขึ้นมาเพื่อรองรับการเติบโตของธุรกิจก็เป้นสิ่งที่ท้าทายด้านบุคคลกรอีกอย่างหนึ่ง

สำหรับความท้าทายที่สองคือวิธีการพัฒนาระบบงาน องค์กรต้องปรับเปลี่ยนวิธีการพัฒนาระบบงานจากรูปแบบ waterfall model ซึ่งพัฒนาระบบงานเป็นขั้นตอนตามลำดับที่ตายตัว ซึ่งมีปัญหาไม่สามารถรองรับการปรับเปลี่ยนความต้องการทางธุรกิจที่เกิดขึ้นได้อย่างรวดเร็ว องค์กรจะทำอย่างไรเพื่อปรับเปลี่ยนวิธีการพัฒนาระบบงานสู่รูปแบบ agile methodology

พร้อมๆ กันต้องปรับเปลี่ยนวัฒนธรรมองค์กรสู่ DevOps หรือ DevSecOps ซึ่งเป็นสิ่งที่หลายองค์กรเริ่มมองหาและพยายามนำมาประยุกต์ใช้งาน การสร้างวัฒนธรรมเหล่านี้เป็นสิ่งที่ยากและต้องการการสนับสนุนการขับเคลื่อนจากผู้บริหารขององค์กรอย่างจริงจัง

ความท้าทายสุดท้ายคือเทคโนโลยีที่จะเข้ามามีบทบาทสำคัญอย่างมากในเรื่องของการสร้างโครงสร้างพื้นฐานไอทีรูปแบบใหม่ โดยเฉพาะอย่างยิ่งการวางแพลตฟอร์มคอนเทนเนอร์ ซึ่งในอนาคตก็จะมีการปรับเปลี่ยนเป็นแพลตฟอร์มคอนเทนเนอร์แบบ next-gen อีกครั้ง

ทำไมการปรับโครงการพื้นฐานไอทีในองค์กรจึงต้องเป็นการใช้คอนเทนเนอร์

เพราะคอนเทนเนอร์เป็นจุดเปลี่ยนสำคัญของแนวคิดเรื่องการแพ็กเกจ (package) และการดีพลอย (deploy) แอปพลิเคชั่นต่างๆ

เดิมกระบวนการเหล่านี้จะมองในรูปแบบ virtualization ทำให้ต้องมองระบบเต็มรูปแบบ คือระบบปฎิบัติการ, มิดเดิลแวร์, ไลบรารี, และตัวโค้ดแอปพลิเคชั่นเอง การมองรูปแบบนี้ทำให้แพ็กเกจทั้งก้อนมีขนาดใหญ่ การขยายระบบ (scale) เพื่อรองรับโหลดที่เปลี่ยนไปทำได้ยาก และต่อให้ทำได้ก็ไม่สามารถทำได้ในเวลาอันสั้น

การแพ็กเกจแอปพลิเคชั่นเป็นคอนเทนเนอร์ จะรวมเอาส่วนต่างๆ ที่เกี่ยวข้องกับแอปพลิเคชั่นโดยตรงไว้ในแพ็กเกจโดยไม่มีระบบปฎิบัติการ ขนาดของคอนเทนเนอร์มีขนาดเล็ก เหมาะกับการขยายระบบในเวลาอันสั้น ขณะเดียวกันการแพ็กเกจที่สมบูรณ์ในตัวของคอนเทนเนอร์ก็ยังให้อิสระกับนักพัฒนา ให้สามารถเลือกภาษาโปรแกรมหรือเฟรมเวิร์คที่ต้องการได้

การแบ่งความรับผิดชอบในรูปแบบนี้ทำให้ตัวผู้ดูแลระบบ (operator) ไม่ต้องเข้าใจภาษาโปรแกรมที่ทีมพัฒนาเลือกใช้งาน แต่มุ่งไปที่การวางระบบให้มีประสิทธิภาพ ตอบสนองต่อโหลดที่เข้ามาได้

คอนเทนเนอร์โดยรวมจึงตอบโจทย์ในยุคที่โหลดของระบบมีความเปลี่ยนแปลงสูง ทำให้นักพัฒนาและผู้ดูแลระบบเห็นภาพร่วมกันและทำงานร่วมกันได้พอดี

คิดว่าทำไม kubernetes จึงกลายเป็นมาตรฐานจนกระทั่ง OpenShift ต้องเปลี่ยนมาใช้งาน

ในโลกองค์กรการเปลี่ยนมาใช้คอนเทนเนอร์นั้นมีความซับซ้อนสูง อาจจะถึงระดับนับร้อยหรือนับพันคอนเทนเนอร์ ผู้ดูแลระบบเริ่มมีความลำบากในการจัดการคอนเทนเนอร์จำนวนมากเหล่านี้ ตลอดจนคอนเทนเนอร์ที่เราบอกสามารถขยายระบบได้ง่ายนั้น ต้องมีการดูแลเพื่อให้ระบบขยายได้ตามโหลดจริง

kubernetes มีความได้เปรียบจากการพิสูจน์ตัวด้วยการจัดการโหลดภายในขององค์กรขนาดใหญ่อย่างกูเกิล ทำให้แน่ว่ารองรับความซับซ้อนได้ ลูกค้าของ Red Hat มีความต้องการตรงกัน คือมักเป็นระบบระดับองค์กรที่ซับซ้อนสูง ทาง Red Hat จึงเลือกปรับมาใช้ kubernetes ตั้งแต่ OpenShift 3.0 ในปี 2015

ช่วงแรกหลายองค์กรมองว่า kubernetes นั้นซับซ้อนเกินไป แต่เวลาเพียงไม่กี่ปีมันก็พิสูจน์ตัวว่าสามารถตอบโจทย์แพลตฟอร์มคอนเทนเนอร์สำหรับองค์กรได้เป็นอย่างดี

ทางด้าน Red Hat เองหลังจากเลือก kubernetes แล้วก็เข้าไปร่วมพัฒนาอย่างต่อเนื่อง ตอนนี้บริษัทเป็นผู้ส่งโค้ดเข้าชุมชนอันดับสองรองจากกูเกิลเท่านั้น ทีมพัฒนาที่แข็งแกร่งใน Red Hat ทำให้บริษัทสามารถนำโค้ดจาก kubernetes มาพัฒนาต่อตามแนวทางของ Red Hat เอง ตั้งแต่การเพิ่มความแข็งแกร่งด้านความปลอดภัย (hardening), แก้บั๊กต่างๆ, และทดสอบเพิ่มเติมกับส่วนประกอบอื่น ทั้งหมดนี้ใช้เวลาเพียง 1-3 เดือนก็จะออกเป็น OpenShift เวอร์ชั่นใหม่ได้

แนวทางเช่นนี้ทำให้ลูกค้าที่ใช้ OpenShift ไม่ต้องตามหลังเทคโนโลยีในโลกโอเพนซอร์สนาน แต่ยังได้รับความมั่นใจจากการทดสอบต่างๆ ตามความต้องการของตลาดองค์กร

OpenShift เองมีฟีเจอร์เพิ่มจาก kubernetes จำนวนมาก คิดว่าฟีเจอร์อะไรสำคัญที่สุด

ชิ้นส่วนที่ Red Hat เพิ่มเติมเข้าไปใน OpenShift มีส่วนสำคัญหลายส่วน ได้แก่ การรองรับผู้ใช้หลายส่วน (multi-tenancy), การจัดการล็อก, ระบบมอนิเตอร์ระบบ, การจัดการคอนฟิกของระบบ และยังมีฟีเจอร์อื่นๆ อีก เช่น การทำงานร่วมกับเครื่องมือระดับองค์กรตัวอื่นๆ ที่องค์กรอาจมีใช้งานอยู่แล้ว เพื่อให้เป็นโซลูชั่นสำหรับองค์กรที่พร้อมใช้

นอกจากนี้ยังเพิ่ม Application Lifecycle Management ที่เป็นชุดของฟีเจอร์สำหรับการพัฒนาไปจนถึงการดีพลอยในชั้นเดียว

แต่สิ่งที่สำคัญที่สุดคือ Red Hat Enterprise Linux (RHEL) ที่เสถียรและน่าเชื่อถือมายาวนาน การใช้ OpenShift เป็นการนำ RHEL เข้ามาอยู่ในคอนเทนเนอร์แพลตฟอร์มทำให้มั่นใจได้ว่าแพลตฟอร์มไม่มีรูรั่ว

เท่าที่สัมผัสลูกค้ามาตอนนี้ลูกค้าเลือกใช้แพลตฟอร์มคอนเทนเนอร์ OpenShift อย่างไร และทำไมจึงเลือกแบบนั้น

ตอนนี้ลูกค้ามักใช้ OpenShift เป็นแพลตฟอร์มคอนเทนเนอร์สำหรับการดีพลอยในองค์กร (on-premise) เป็นหลัก เนื่องจากนโยบายองค์กรยังจำกัดการใช้คลาวด์อยู่บ้าง และงานที่ใช้ตอนนี้ก็มักเป็นงานที่ใช้เป็นการภายในเอง

แต่เราเริ่มเห็นองค์กรจำนวนมากเพิ่มพิจารณาย้ายโหลดงานไปอยู่บนคลาวด์มากขึ้นเรื่อยๆ โดยเฉพาะงานที่ไม่ได้รันตลอดเวลา เพราะงานประเภทนี้เมื่อใช้คลาวด์จะลดค่าใช้จ่ายได้มาก

การใช้ OpenShift ทำให้ลูกค้ามีอิสระในการเลือกว่าจะรันงานที่ใดเพราะรองรับทั้งแบบ on-premise และการรันบนคลาวด์สาธารณะ การย้ายงานขึ้นมาบน OpenShift จึงกลายเป็นการลงทุนเพื่อเตรียมความพร้อมไปในตัว