ในยุคสมัยใหม่การพัฒนาแอปพลิเคชันในรูปแบบของ Microservices ถือเป็นเรื่องที่จำเป็น เพื่อให้สอดคล้องกับศักยภาพของ Infrastructure ในหลากหลายรูปแบบไม่ว่าจะเป็น On-premise หรือ Cloud นอกจากนี้ยังเกิดการปฏิวัติวัฒนธรรมการทำงานเดิมที่มักแบ่งแยกกันชัดเจน ให้บูรณาการกันมากขึ้นหรือ DevSecOps อย่างไรก็ดีโครงสร้างพื้นฐานในงานดังกล่าวมักมีการอาศัยเทคโนโลยี Container เข้ามาเกี่ยวข้อง ด้วยเหตุนี้ VMware จึงได้จัดงานสัมมนาขึ้นเพื่อให้ความรู้เกี่ยวกับความสัมพันธ์พันเหล่านั้น พร้อมกับนำเสนอโซลูชันที่ช่วยให้การทำ Modernization ของท่านเป็นเรื่องง่ายขึ้น
DevSecOps คืออะไร?

DevSecOps เป็นคำที่เราเริ่มได้ยินกันหนาหูมากขึ้น โดยก่อนหน้านี้เรามักจะได้ยินคำว่า DevOps ซึ่งเป็นวัฒนธรรมของการทำงานที่ประสานความร่วมมือระหว่าง Developer และ Operation เช่นกัน DevSecOps ก็คือการโฟกัสเพิ่มส่วนของทีม Security เข้ามา หากฟังดูเผินๆ อาจดูไม่ได้ลึกซึ้งมากเท่าไหร่นัก แต่เรื่องราวน่ากังขามากขึ้นหากท่านตั้งคำถามว่าต้องเริ่มต้นอย่างไร ความร่วมมือนี้จึงเกิดขึ้นได้จริง เพื่อนำพาองค์กรไปสู่ยุคใหม่ของ Application หรือการออกแบบในรูปแบบ microservices
และเพื่อให้ทีมงานผู้เกี่ยวข้องทั้งหมดหรือทั้งองค์กรมองเห็นภาพเดียวกัน เราจะต้องเริ่มจากสิ่งที่เรียกว่า Framework ที่ระบุถึงแนวทางและกรอบปฏิบัติให้เกิดแนวทางที่ชัดเจนและเป็นรูปธรรม ซึ่งในการเริ่มต้นเรื่องของ DevSecOps ก้าวแรกที่องค์กรควรต้องทำคือกำหนดเป้าหมายให้ชัด ตัวอย่างเช่น
- Speed – พัฒนาเรื่องความรวดเร็วในการนำส่งซอฟต์แวร์จากการพัฒนาสู่ Production ดังนั้นภาพที่ชัดเจนคือเรื่องของการเพิ่มกลไกด้าน Automation
- Reliability – ต้องทำ Roll back หรือกู้คืนระบบได้รวดเร็ว ไม่มีจุดที่เป็น Single-point-of-failure
- Traceabillity – กำหนดเมกทริกซ์ (metric) เพื่อวัดประสิทธิภาพหรือเวลา ว่าช้าคือประมาณไหนอย่างไร
- Observabillity – เมื่อ Infrastructure กระจัดกระจายกันอยู่จะมองเห็นภาพรวมได้อย่างไร และต้องเจาะลึกข้อมูลลงในรายละเอียดได้
- Security & Compliance – ตอบโจทย์ข้อบังคับระดับองค์กร และความมั่นคงปลอดภัย
นี่เองคือโจทย์ที่องค์กรต้องตั้งเป้าให้ชัดเจนว่าสิ่งที่ตนเองต้องการนั้นคืออะไรกันแน่ ทั้งนี้ต้องเริ่มต้นที่การมองตัวเองก่อนว่าปัจจุบันท่านอยู่จุดไหน ในหลายแง่มุมเช่นเรื่องของ Infrastructure ปัจจุบันมีการใช้งาน Cloud, On-premise, Multi-cloud หรือ Virtualize เป็นต้น แต่สิ่งที่หลายองค์กรอาจตกหล่นไปแต่กลับเป็นเรื่องสำคัญที่สุดในการเปลี่ยนผ่านวัฒนธรรมการทำงานก็คือการสื่อสาร ดังนั้นอีกเรื่องที่พลาดไม่ได้เลยคือต้องไปศึกษาดูว่าปัจจุบันทีม Dev, Security และ Operation ทำงานร่วมกันอย่างไร สื่อสารช่องทางไหน เพียงพอหรือไม่

เมื่อทราบถึงสถานการณ์ของตน ประกอบกับมีเป้าหมายที่ชัดเจนแล้ว ต้องประเมินว่าจุดที่ท่านต้องการพัฒนานั้นเกี่ยวกับใคร กำหนดหน้าที่กันให้ชัดว่าใครรับผิดชอบอะไรอย่างไร เมื่อทัศนะเชิงความคิดลงตัวแล้ว สิ่งต่อมาที่ต้องมองต่อไปคือเรื่องของกระบวนการ Pipeline ของ Build-Run-Manage ซึ่งแต่ละองค์กรอาจมีไม่เหมือนกัน เช่น ในภาพประกอบมีการแบ่งได้ขั้นตอนย่อยลงไปอีกหลายส่วน ที่พูดถึงเรื่องภาระหน้าที่ของแต่ละฝ่าย Security และวิธีปฏิบัติแบบ Best practice เป็นต้น
ความท้าทายในทางปฏิบัติ
ในแง่ของการลงมือทำจริงคำถาม 4 ข้อที่มักเกิดขึ้นได้บ่อยในองค์กรคือ 1.) จะเปลี่ยนจากแอปพลิเคชันแบบ Legacy เป็น Modern Application ได้อย่างไร 2.) ยังไม่มี Pipeline จะเริ่มยังไงหรือถ้ามีแล้วจะพัฒนาให้ดีขึ้นอย่างไร 3.) ปรับองค์กรอย่างไรให้การทำ Transformation ไม่สะดุดและเกิดขึ้นได้สำเร็จ 4.) จะนำ Security เข้าสู่กระบวนการพัฒนาได้อย่างไร

เพื่อเป็นการตอบคำถามแรก ก่อนอื่นต้องเข้าใจตรงกันก่อนว่า Modernize Application คือเป้าหมายในการเปลี่ยนแอปพลิเคชันให้ใช้ความสามารถของคลาวด์ (Cloud Native) ซึ่งมักพ่วงกับเรื่องของ Container ส่วนอีกคำคือเรื่องของ Modernize Application Delivery คือการทำยังไงให้กระบวนการนำส่งโค้ดจาก Dev สู่ Production เกิดขึ้นได้รวดเร็วที่สุด
ทั้งนี้คำว่า Modernize ทั้งสองตัวมีสิ่งที่คล้ายๆกันในทางปฏิบัติ คือต้องแบ่งย่อยกระบวนการเป็นส่วนๆ ข้อดีก็คือสามารถวัดผลสำเร็จหรือล้มเหลวได้อย่างชัดเจน หากผิดพลาดก็เสียเวลาไม่มากนัก เช่นกันสุดท้ายแล้วองค์กรก็ต้องประเมินตัวเองด้วยว่า คนและวัฒนธรรมปัจจุบันนั้นจะนำพาให้ท่านไปถึงเป้าหมายได้หรือไม่ รวมไปถึงจะทำอย่างไรให้ตอบโจทย์ด้าน Security ไปพร้อมๆกัน
กลยุทธ์ในการทำ Modernize Application
หลักการที่องค์กรสามารถนำมาประยุกต์ใช้เพื่อประเมินแอปพลิเคชันที่ใช้อยู่ มีด้วยกัน 6 ขั้นดังนี้
1.) Retain – ไม่มีความจำเป็นต้องเปลี่ยนแปลงแอปพลิเคชัน คงไว้สภาพเดิม
2.) Rehost – ย้ายไปรันบนคลาวด์
3.) Re-platform – แอปบนระบบ VM ที่มีสามารถย้ายไปรันด้วย Container ได้หรือไม่
4.) Refactoring/Rearchitecting – การเปลี่ยนรูปแบบทำได้ไม่สะดวกนัก ต้องมีการเปลี่ยนแปลงแก้ไขโค้ดค่อนข้างเยอะ
5.) Replace – เปลี่ยนความเป็นเจ้าของจากการพัฒนาแอปเอง ไปซื้อใช้แทนเช่น SaaS เป็นต้น
6.) Retire – ยกเลิกการใช้แอปพลิเคชันเหล่านั้น
กล่าวได้ว่าขั้นตอนแรกของการทำ Modernize Application ก็คือการประยุกต์ใช้งาน Container และ Kubernetes เพื่อเปลี่ยนแปลงมุมมองของ Infrastructure ให้เกิดขึ้นได้อย่างไร้รอยต่อ ตามมาด้วยขั้นที่สองคือทำการ Lift&Shift บางส่วนของแอปพลิเคชันให้ย้ายไปบน Container ซึ่งทั้งสองขั้นตอนนี้เป็นเพียงการนำพาไปสู่เรื่องของความสเถียรและความยืดหยุ่นที่เพิ่มขึ้นเท่านั้น แต่กระบวนการหลักๆของแอปพลิเคชันยังคงเดิม
ด้วยเหตุสุดท้ายแล้วจำเป็นต้อง Refactor แอปพลิเคชันให้มีการทำงานผ่าน API โดยผู้พัฒนาแอปพลิเคชันจะต้องออกแบบ เพื่อควบคุมว่าแอปของท่านจะให้ข้อมูลอะไรกับเครื่องมือ เช่น มีการส่ง Log ออกไปหรือ สามารถรับคำสั่งเข้ามาคอนฟิคการทำงานของแอปได้ แทนที่จะให้เครื่องมือเข้ามาวุ่นวายภายในแอปเพื่อหาข้อมูลเอง ที่อาจลดทอนประสิทธิภาพการทำงานของแอปพลิเคชัน นอกจากนี้ยังต้องมองการออกแบบให้เป็น Service ที่ทำงานได้แยกขาดกัน และไม่มีผลกระทบต่อกันในการเปลี่ยนแปลงอัปเดตใดๆ
ลงมือปฏิบัติทำ CI/CD
เมื่อพูดถึง Modernize Application Delivery ก่อนที่จะคำนึงถึงเรื่องเครื่องมือหรือการทำสคริปต์ กระดุมเม็ดแรกที่ควรติดคือเรื่องของแนวคิดที่เรียกว่า Agile เพื่อสร้างเส้นทางการดำเนินงานที่เหมาะสม โดย Mindset ตรงนี้คือการโฟกัสไปที่เรื่องการนำส่งโค้ดของซอฟต์แวร์ แล้วค่อยพิจารณาถึงเรื่องเครื่องมือช่วยเหลือที่ต้องเปิดให้สามารถทำ Automation ได้
การกำหนดหน้าที่และกระบวนการของผู้เกี่ยวข้องก็เป็นสิ่งที่สำคัญที่สุดในเรื่องของ Agile เช่นกัน แต่หากพูดถึงเรื่อง Security ตั้งแต่ระหว่างการผลิตจนเกิดผลสำเร็จ มักมีกลยุทธ์ 2 ส่วนที่ต้องทำควบคู่กันคือ
- Buttom Up หรือการใส่ใจเรื่อง Security จากระดับล่างสู่ระดับสูง หรือตั้งแต่ทีม Infrastructure, Virtualize, Platform และ Developer
- Left to right ในมุมของการพัฒนาโค้ดต้องมีการตระหนักถึงเรื่อง Security ตั้งแต่วันแรกของการพัฒนา หาความเป็นไปได้ของช่องโหว่ในโค้ด หรือติดตามส่วนประกอบของแพ็กเกจจาก Third-party

รู้จักกับ VMware Tanzu
เมื่อองค์กรตัดสินใจได้แล้วถึงการย้ายแอปพลิเคชันในรูปแบบเดิม สู่การประยุกต์ใช้เทคโนโลยี Container และบริหารจัดการด้วย Kubernetes หนึ่งในโซลูชันที่ VMware นำเสนอคือเรื่องของ VMware Tanzu โดยเราขอพาไปชมรายละเอียดกันอีกสักนิดครับว่า Tanzu Kubernetes Grid (TKG) นั้นน่าสนใจอย่างไร
อย่างที่เราทราบกันดีกว่า Container Orchrestrator ที่ชื่อ Kubernetes นั้นถือกำเนิดจากที่ทีมงานของ Google และถูกปล่อยในเวอร์ชันโอเพ่นซอร์ส ด้วยเหตุนี้เองจะเห็นได้ว่ามี Vendor หลายค่ายได้นำไปต่อยอดพัฒนาต่อในรูปแบบของตัวเอง หนึ่งในนั้นก็คือ VMware TKG โดยความน่าสนใจก็คือเมื่อ Vendor หลายค่ายจะพัฒนาต่อยอดโดยยึดเอาโครงสร้างเดิมของ Kubernetes ไว้ ดังนั้นกล่าวได้ว่า TKG จะสามารถรองรับการย้าย Workload ไปยังโซลูชัน Kubernetes ค่ายอื่นได้ เช่น VMware Cloud on AWS, Kubernetes on-premise และ Public Cloud

หากเจาะลึกเข้าไปถึงไอเดียภายในจริงๆ แล้วสิ่งที่ VMware ทำก็คือรักษาตัว Kubernetes ตามแบบฉบับเดิมเอาไว้ และใช้ช่องทางที่ Custom Resource Definition(CRD) ซึ่งเป็นสิ่งที่ Kubernetes เปิดทางให้ผู้สนใจสามารถต่อยอดความสามารถของตนได้ โดยตัวอย่างจากภาพประกอบด้านบน MachineSet ก็คือการสร้างกลุ่ม VM เป็นต้น

อีกหนึ่งแนวคิดที่ VMware ได้หยิบยื่นให้ผู้ใช้งานคือแนวคิดของ Platform Manage หรือการที่แพลตฟอร์มได้ถูกสร้างไว้อย่างครอบคลุมการทำงานในระดับองค์กรแล้ว ซึ่งยังช่วยลดการเขียนสคิร์ปต์ที่ซับซ้อนยุ่งยาก ที่แอดมินส่วนใหญ่พบเจอในการทำงานทุกวันนี้ โดยขอเพียงแอดมินหรือ Dev กำหนดสถานะปลายทางที่ต้องการ แพลตฟอร์มของ VMware ก็จะทำงานตามนั้น ทั้งยังตอบโจทย์ในมุมของ Dev ที่เน้นความรวดเร็วเป็นสำคัญประหนึ่งว่าทำงานกับคลาวด์ รวมถึงยังใช้คำสั่ง Kubectl ที่ใช้บน Kubernetes ปกติได้ด้วย ในอีกด้านผู้ดูแล vSphere ก็สามารถใช้เครื่องมือหน้าตาเดิมๆเพื่อจัดการ TKG ได้ด้วย เพียงแต่จะมีคอนเซปต์เรื่องของ Namespace ขึ้นมา ที่มองทรัพยากรอย่างเป็นกลุ่มก้อนและส่งต่อในนักพัฒนานำไปจัดการต่อได้ด้วยตัวเอง
โซลูชันจาก VMware ที่ช่วยอุดรอยรั่วในขั้นตอน CI/CD

Security นั้นเป็นเรื่องสำคัญที่ต้องคำนึงถึงตั้งแต่เริ่มแรกในระดับการเขียนโค้ด แต่ถ้าพูดถึงการพัฒนาแแอปพลิเคชันด้วย Kubernetes ในรูปแบบของ Microservices เชื่อแน่ว่าแอปพลิเคชันแต่ละตัวมักประกอบด้วย Service อีกหลายตัว ซึ่งโดยทั่วไปแล้วองค์กรมักมีแอปพลิเคชันอีกมายมาก ทำให้นำมาสู่ปัญหาในด้านการจัดการ ตรงนี้เอง VMware Tanzu Mission Control จึงเข้ามาช่วยรวมศูนย์การบริหารจัดการ Kubernetes Cluster ไม่ว่า Cluster จะอยู่บน Kubernetes แบบ On-premise หรือ Public Cloud โดย Tanzu Mission Control สามารถบริหารจัดการ Cluster Lifecycle ได้อย่างครบวงจรเช่น Create, Update, Delete, Start&Stop รวมถึงสามารถทำ Policy และ Backup&Restore
ปัจจุบันนี้เราสามารถเลือกหา image ตั้งต้นเพื่อนำมาใช้เป็นพื้นฐานของแอปพลิเคชันได้จากแหล่งต่างๆ อย่างไรก็ดีมี image เกิดขึ้นใหม่มากมาย อาจจะเกิดขึ้นตามลักษณะงานและเวอร์ชันที่แตกต่างกันของแพ็กเกจที่ใส่มา ดังนั้นจะมั่นใจได้อย่างไรว่า image นั้นปลอดภัย ซึ่ง VMware Application Catalog คือแหล่งรวบรวม Opensource image ที่ผ่านการตรวจสอบจาก VMware แล้วว่า image นั้นปลอดภัยให้องค์กรสามารถนำไปใช้ต่อได้อย่างมั่นใจ

อีกหนึ่งอุปสรรคสำคัญคือการแก้ไขช่องโหว่ในแอปพลิเคชันที่มักทำได้ล่าช้า เพราะเมื่อพบช่องโหว่แล้ว ขั้นตอนในการอัปเดตโค้ดนั้นค่อนข้างยาก โดยเมื่อพิจารณาจากงานใน Pipeline แล้ว จะเห็นได้ว่าหากไร้เครื่องมือช่วยเหลือในการทำขั้นตอนเดิมๆซ้ำๆ คงไม่ดีแน่ ดังนั้นจึงเป็นที่มาของโซลูชัน Tanzu Build Service ที่จะช่วยเข้ามาจัดการกระบวนการซ้ำซ้อนอย่างอัตโนมัติ ด้วยเหตุนี้การอัปเดตแพตช์โค้ดช่องโหว่จึงมิใช่เรื่องยากอีกต่อไป
จะเห็นได้ว่าโซลูชัน VMware Tanzu ในส่วนประกอบต่างๆสามารถตอบโจทย์ในเรื่องเทคโนโลยีที่ช่วยผลักดันการพัฒนาแอปพลิเคชัน หรือยกระดับการทำงานที่สามารถตอบโจทย์การทำงานได้ทั้งทีม Dev, Sec และ Ops ให้เป็นไปได้อย่างดี โดย Dev ก็ยังทำงานด้วยเครื่องมือเดิมผ่านคำสั่งของ Kubernetes แต่จัดการได้อย่างสะดวกมากขึ้น และเมื่อทีม Security พบปัญหาแจ้งกลับไปยัง Dev การอัปเดตนั้นก็จะไม่ล่าช้า ส่วนทีม Operation ก็ยังทำหน้าควบคุม จัดสรรทรัพยากรในภาพรวมได้ไม่ว่าจะเป็น VM หรือ Container ด้วยเครื่องมือที่คุ้นเคย เรียกได้ว่าเป็นความกลมกล่อมที่ VMware นำเสนอเพื่อช่วยองค์กรให้ก้าวเข้าสู่ยุคใหม่ของแอปพลิเคชันครับ