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


การนำระบบ Platform Engineering เข้ามาใช้ในองค์กรจะสามารถช่วยเพิ่มขีดความสามารถและส่งเสริมให้มีการพัฒนาแอปพลิเคชันได้อย่างต่อเนื่อง ซึ่งในบทความนี้เราจะเน้นไปที่ Platform Engineering และแพลตฟอร์มสำหรับนักพัฒนาแอปพลิเคชัน (Internal Developer Platforms : IDP) ที่จะเข้ามามีบทบาทสำคัญกับผู้พัฒนาซอฟต์แวร์ โดยมุ่งเน้นไปที่การสร้างแอปพลิเคชันเพื่อใช้แก้ไขปัญหาการดำเนินงานทางธุรกิจ การเพิ่มรายได้ และการรักษาฐานลูกค้า

Platform Engineering คืออะไร?

Platform Engineering คือ การออกแบบและสร้างแพลตฟอร์มสำหรับนักพัฒนาแอปพลิเคชัน (Internal Developer Platforms : IDP) ชุดเครื่องมือการเขียนโปรแกรม (toolchains) และขั้นตอนการทำงาน (Workflows) โดยเปิดสิทธิ์ให้ทีมซอฟต์แวร์สามารถเข้ามาใช้เครื่องมือและทรัพยากรต่างๆ ได้ด้วยตนเอง (self-service) หรือกล่าวได้อีกนัยหนึ่งคือ Platform Engineering เป็นเรื่องเกี่ยวกับการปรับเปลี่ยนแนวทางปฏิบัติขององค์กรจากเดิมที่นักพัฒนาแอปพลิเคชันจะต้องสร้าง Ticket แต่ละงาน เช่น จัดเตรียมทรัพยากรหรืออุปกรณ์พื้นฐานด้านไอทีไปยังทีมปฏิบัติการ ซึ่งทีมปฏิบัติการก็จะต้องดำเนินการตามที่นักพัฒนาแอปพลิเคชันร้องขอ ทำให้เสียเวลาไปกับการทำงานซ้ำๆ จึงมีการปรับเปลี่ยนให้นักพัฒนาแอปพลิเคชันสามารถทำงานได้เองอย่างเต็มรูปแบบ (Self-Service) โดยที่นักพัฒนาแอปพลิเคชันสามารถใช้ Platform Engineering นี้ลดความซับซ้อนในเรื่องของสร้าง Ticket ออกไป และมุ่งเน้นไปที่การเขียนโค้ดแอปพลิเคชันของตัวเองเพียงอย่างเดียว

ทั้งนี้ ข้อตกลงของ Platform Engineering คือ การสร้างเส้นทางเฉพาะที่ทำให้นักพัฒนาแอปพลิเคชันสามารถดำเนินงานไปได้อย่างราบรื่น อาทิ องค์ประกอบของเทมเพลตในการเขียนโค้ด การสนับสนุนความสามารถในการเร่งให้เกิดการพัฒนาแอปพลิเคชันได้โดยเร็ว ซึ่งเส้นทางเฉพาะนักพัฒนาแอปพลิเคชันนี้จะต้องเริ่มต้นสอนให้กับนักพัฒนาใหม่ให้เข้าใจโดยเร็ว และต่อยอดไปที่เทมเพลต CI/CD pipeline เพื่อให้นักพัฒนาแอปพลิเคชันสามารถนำไปใช้โปรโมตโค้ดแอปพลิเคชันของตัวเองจากการพัฒนาไปสู่การนำไปใช้งานจริง

Kubernetes และ Platform Engineering

ปัจจุบันมีการนำ Kubernetes และ Cloud Native มาใช้ในการทำแอปพลิเคชันมากขึ้น ทำให้องค์กรสามารถใช้เครื่องมือที่เหมือนกันสร้างแอปพลิเคชันที่สอดคล้องกัน ช่วยลดความซับซ้อนในการสร้างแพลตฟอร์มให้กับนักพัฒนาแอปพลิเคชัน (IDP) ได้เป็นอย่างดี ซึ่งวิธีการนี้มีข้อดีดังต่อไปนี้

  • ความสอดคล้อง (Consistency)

    แทนที่ทีมดูแลแพลตฟอร์มจะต้องสร้างแพลตฟอร์มในแต่ละส่วนเองใหม่ (ดังรูปภาพที่แสดงด้านบน) พวกเขาสามารถนำเครื่องมือที่ได้รับการสนับสนุนจากกลุ่มสังคมออนไลน์ของนักพัฒนา (Community-supported) มาใช้ทำงานร่วมกับระบบขนาดใหญ่และโครงสร้างพื้นฐานด้านไอทีที่แตกต่างกันได้ โดยสามารถใช้เครื่องมือเดียวกับที่อยู่ในระบบคอนเทนเนอร์บริหารจัดการข้อมูลเฉพาะส่วนบุคคลหรือองค์กรที่มีความสำคัญและไม่สามารถเปิดเผยได้ (secrets management), การสร้าง CI/CD Pipeline และการดูแลติดตามหลังจากการติดตั้งเสร็จ เช่น การตรวจสอบและการสังเกตการณ์ในสภาพแวดล้อมของ cloud ที่แตกต่างกัน

  • การเข้าถึงการบริการใช้งานด้วยตัวเอง (Self-Service Access)

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

 
  • การหลีกเลี่ยงการผูกติดกับ Cloud (Avoiding Cloud Lock-In)

  • การนำ Kubernetes และ Cloud Native มาใช้ สามารถช่วยให้ทีมแพลตฟอร์ม (platform engineers) สามารถสร้างการทำงานร่วมกับ cloud หรือแบบ on-premises ได้แบบอัตโนมัติแทนการใช้เครื่องมือเฉพาะของ cloud แต่ละรายได้จากข้อดีและประโยชน์ต่างๆ ที่กล่าวมาข้างต้น ดูเหมือนว่าจะเป็นเรื่องที่ทำได้ง่าย แต่ก็ไม่ได้ง่ายซะทีเดียว โดยเริ่มจากส่วนของโครงสร้างพื้นฐานไอที ถึงแม้ว่าทีมดูแลแพลตฟอร์มจะสามารถใช้เครื่องมือต่างๆ อาทิ Crossplane, Terraform, หรือ OpenTofu ในการจัดเตรียม Kubernetes คลัสเตอร์ ให้ทีมแอปพลิเคชันใช้งาน แต่หากการส่งมอบนั้นไม่มีความต่อเนื่อง ก็ถือว่าเป็นการลดภาระให้กับผู้พัฒนาแอปพลิเคชั่นได้แบบไม่สมบูรณ์ หากผู้พัฒนาแอปพลิเคชันมีการย้ายไปใช้งานที่ Cloud Platform อื่น ก็จะเกิดปัญหาเรื่องความไม่สอดคล้องกันในการทำงาน เพราะ plugin-based อย่าง CSI หรือ CNI ของ Kubernetes ไม่สามารถทำงานร่วมกับ Cloud Platform อื่นได้ ทีมดูแลแพลตฟอร์มจะต้องแก้ไขสคริปเพื่อให้สามารถใช้งาน และทำงานร่วมกับ Storage และ Network ของแต่ละ cloud ที่แตกต่างกันได้ เราลองพิจารณาในประเด็นต่อไปนี้
  • คุณสมบัติของตัวจัดเก็บข้อมูลไม่มีความสอดคล้องกัน (Lack of Consistent Storage Features)

  • ผู้ให้บริการ cloud แต่ละรายมี Container Storage Interface (CSI plugin) ของตนเอง เพื่อให้ผู้ใช้บริการสามารถใช้บริการจัดเก็บข้อมูลสำหรับ Container Application เช่น ผู้ให้บริการ  AWS มีการตั้งค่าเริ่มต้นให้กับ EBS CSI plugin ให้ผู้พัฒนาแอปพลิเคชันใช้งาน block volumes เป็นแบบ ReadWriteOnce(RWO) หากต้องการใช้งานแบบ ReadWriteMany(RWX) จะมีขั้นตอนการติดตั้งเพิ่มเติมเพื่อเข้าถึง Amazon EFS แต่เมื่อเทียบกับผู้ให้บริการ Azure ที่มีการตั้งค่าตัวจัดเก็บข้อมูลให้ทั้งแบบ RWO และ RWX เป็นค่าเริ่มต้นไว้ให้เลย จึงเป็นสาเหตุทำให้ทีมปฏิบัติการหรือทีมดูแลโครงสร้างพื้นฐานไอทีต้องมีภาระการทำงานเพิ่มขึ้นในการสร้างสคริปขึ้นมาเอง เพื่อให้แน่ใจว่าทีมพัฒนาแอปพลิเคชันจะสามารถใช้งานคุณสมบัติของตัวจัดเก็บข้อมูลได้เทียบเท่ากันใน Kubernetes คลัสเตอร์ ไม่ว่าจะเลือก cloud จากผู้ให้บริการใดก็ตาม
  • การ Replication และการทำ High Availability

  • ผู้ให้บริการ cloud แต่ละรายต่างมีวิธีการ replicate และการทำ high availability ของตนเอง อาจจะดูเหมือนไม่เป็นปัญหากับแอปพลิเคชันที่ยังอยู่ในช่วงกำลังพัฒนาหรือกำลังทดสอบการทำงาน แต่เมื่อแอปพลิเคชันเหล่านี้ถูกนำไปใช้งานจริงอาจเกิดปัญหาที่คาดไม่ถึง ซึ่งเกิดจากสภาพแวดล้อมของผู้ให้บริการ Cloud ที่แตกต่างกันของทั้งสองคลัสเตอร์ ทำให้ทีมนักพัฒนาแอปพลิเคชันจะต้องเพิ่มความซับซ้อนในการเขียนโค้ด เพื่อสร้าง high availability ในระดับแอปพลิเคชัน ซึ่งเป็นการเพิ่มภาระงานให้กับทีมนักพัฒนาแอปพลิเคชันอีก
  • การดูแลการใช้งานหลังจากการติดตั้ง (Day 2 Operations)

  • ผู้ให้บริการ cloud แต่ละรายจะมีข้อแนะนำสำหรับการใช้งานที่เหมะสมและดีที่สุด (best practices) ให้แก่ผู้ใช้บริการ เช่น การป้องกันข้อมูลสูญหายและเสียหาย การกู้คืนข้อมูลจากภัยพิบัติหรือเหตุการณ์ที่ไม่คาดคิด (disaster recovery) และความสามารถในการฟื้นคืนสู่สภาวะปกติของคลัสเตอร์ระหว่างภูมิภาค (cross-region resillency) เป็นต้น ทำให้ทีมแพลตฟอร์มและทีมปฏิบัติการหรือทีมดูแลโครงสร้างพื้นฐานไอทีต้องมีการสร้างกระบวนการปฏิบัติงานเพิ่มเติมในกรณีที่ต้องการใช้บริการจากผู้ให้บริการ cloud หลายราย ซึ่งทีมพัฒนาแอปพลิเคชันส่วนใหญ่ไม่ต้องการที่จะต้องมากังวลเกี่ยวกับการใช้งานหลังจากที่ติดตั้งเสร็จ ตามแนวคิดที่ว่า “คุณสร้างมัน แล้วปล่อยให้มันทำงานเอง”  แต่ในทางกลับกันทีมพัฒนาแอปพลิเคชันและทีมปฏิบัติการหรือทีมดูแลโครงสร้างพื้นฐานด้านไอทีเองที่เกิดแรงกดดันที่จะต้องหาโซลูชันที่จะช่วยให้สามารถทำงานร่วมกันระหว่างผู้ให้บริการคลาวด์ที่ต่างกันได้

Portworx จะมาช่วยแก้ปัญหาได้

อย่าละทิ้งเป้าหมายที่จะสร้าง Platform Engineering ของคุณไปเสียก่อน ในขณะที่ Kubernetes ได้ส่งมอบส่วนที่ใช้ในการประสานการทำงานที่สอดคล้องร่วมกันสำหรับคอนเทนเนอร์ ส่วนการติดตั้งและการขยายขนาดแอปพลิเคชันนั้น Portworx จะเป็นตัวจัดการในส่วนของตัวจัดเก็บข้อมูลที่อยู่บน Kubernetes ให้อยู่ในรูปแบบเดียวกัน เพื่อส่งมอบคุณสมบัติให้แอปพลิเคชันสามารถทำงานร่วมกันบนสภาพแวดล้อมของผู้ให้บริการคลาวด์ที่ต่างกันแบบ muti-cloud ได้ ซึ่งการนำ Portworx เข้ามาใช้จะมีประโยชน์ต่อทั้งผู้ดูแลแพลตฟอร์มและนักพัฒนาแอปพลิเคชัน ดังต่อไปนี้

  • ประสบการณ์การจัดเก็บข้อมูลที่สอดคล้องกัน (Consistent Storage Experience)

  • Portworx เป็นโซลูชั่นการจัดเก็บข้อมูลในรูปแบบ Cloud Native ที่สามารถทำงานบน Kubernetes คลัสเตอร์ใดก็ได้ และสามารถใช้พื้นที่จัดเก็บพื้นฐานในรูปแบบบล็อกได้ นั่นหมายความว่า ทีมแพลตฟอร์มหรือทีมแอปพลิเคชันสามารถเรียกใช้ Portworx บน Amazon EKS หรือ Azure AKS และส่งมอบชุดคุณสมบัติของการจัดเก็บข้อมูลที่เหมือนกัน ทั้งๆ ที่มีรายละเอียดของการตั้งค่าพื้นที่จัดเก็บข้อมูลที่ต่างกันระหว่างผู้ให้บริการคลาวด์ต่างๆ ซึ่ง Portworx จะเข้ามาช่วยให้นักพัฒนาแอปพลิเคชันมั่นใจได้ว่าส่วนประกอบโครงสร้างพื้นฐานของพวกเขายังสามารถจัดสร้างโวลลุ่มถาวรแบบ RWO หรือ RWX ได้โดยอัตโนมัติ และแอปพลิเคชันของพวกเขาสามารถเลือกประเภทของโวลลุ่มได้ตามต้องการ
  • ความยืดหยุ่นและความน่าเชื่อถือ (Resiliency and Reliability)

  • Portworx สามารถทำชุดสำเนาข้อมูลภายในคลัสเตอร์ และ High Availability ที่มีความสามารถในการกู้คืนได้เร็วในระดับคลัสเตอร์ นอกจากนี้ยังสามารถทำโซลูชั่นการกู้คืนข้อมูลที่เกิดจากภัยพิบัติระหว่างภูมิภาค (cross-region) ระหว่างคลัสเตอร์ได้อย่างยืดหยุ่น ทั้ง แบบ asynchronous และ synchronous ซึ่งสิ่งเหล่านี้จะช่วยให้กลุ่มผู้พัฒนาแอปพลิเคชันมุ่งเน้นไปที่การพัฒนาโค้ดแอปพลิเคชันที่สนับสนุนการเพิ่มรายได้และการดำเนินธุรกิจของพวกเขาได้อย่างเต็มที่ โดยมอบความไว้วางใจให้ Portworx และ Kubernetes ในการจัดการข้อมูลและทำ HA ของแอพพลิเคชันให้
  • เส้นทางสายใหม่สำหรับนักพัฒนา (New Golden Paths)

  • เมื่อผู้ดูแลแพลตฟอร์มใช้งาน Portworx จะสามารถสร้าง Kubernetes คลัสเตอร์ ซึ่งเป็นเส้นทางสายใหม่ให้แก่ทีมพัฒนาแอปพลิเคชัน โดยที่พวกเขาสามารถทดสอบการกู้คืนแอปพลิเคชันจากภัยพิบัติหรือเหตุการณ์ที่ไม่คาดคิดต่างๆ  รวมถึงการตรวจสอบความถูกต้องก่อนจะปล่อยให้แอปพลิเคชันถูกนำไปใช้งานจริง นอกจากนี้ Portworx ยังช่วยให้ทีมพัฒนาแอปพลิเคชันทำสำเนาข้อมูลและทดสอบการทำงานของแอปพลิเคชันโดยเทียบกับข้อมูลที่แท้จริงก่อนที่จะอัพเดทการเปลี่ยนแปลงของแอปพลิเคชันไปใช้งานจริง ส่วนที่ดีและเป็นประโยชน์ที่สุดของ Portworx คือ สามารถทำงานร่วมกับเฟรมเวิร์คการพัฒนาอย่างต่อเนื่องได้ อย่างเช่น Flux หรือ ArgoCD  ทำให้เกิดกระบวนการทำงานที่เป็นอัตโนมัติอย่างเต็มรูปแบบ
  • การบริการเรียกใช้ระบบฐานข้อมูล (Database As A Service)

  • Portworx ช่วยให้ทีมดูแลแพลตฟอร์มสามารถยกระดับแพลตฟอร์มระบบฐานข้อมูลให้เป็นแบบการบริการเรียกใช้บริการ (Portworx Data Services: PDS) และประสานรวม PDS เข้าไปใน IDPs ของพวกเขาได้ ซึ่งจะช่วยลดกระบวนการตรวจสอบ การเรียนรู้ และการติดตั้ง open-source operators หลายๆ ตัว เพื่อนำไปปรับใช้กับระบบฐานข้อมูลแต่ละตัว การจัดเรียงลำดับการเข้า-ออกของข้อความที่ส่งมา (messaging queue) หรือ การบริการข้อมูลอื่นๆ ลงได้ ซึ่งการใช้งาน Portworx Data Services ทำให้ทีมดูแลแพลตฟอร์มสามารถนำเสนอระบบฐานข้อมูลที่มีความหลากหลายในรูปแบบการบริการเรียกใช้ตามความต้องการให้แก่ทีมพัฒนาแอปพลิเคชันไม่ว่าจะใช้ Kubernetes และ Cloud Platform จากผู้ให้บริการรายไหนก็ตาม
  • การย้ายแอพพลิเคชั่น (Application Migration)

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

บทสรุป

Platform Engineering เป็นสิ่งสำคัญในการเสริมสร้างประสบการณ์ และสร้างเส้นทางใหม่สำหรับนักพัฒนาแอปพลิเคชันด้วยการปรับกระบวนการจัดเตรียมอุปกรณ์พื้นฐานไอที และการติดตั้งเพื่อการใช้งาน ให้มีความง่าย และรวดเร็วมากขึ้น อีกทั้งเป็นการส่งมอบการบริการที่สะดวกให้กับนักพัฒนาแอปพลิเคชันสามารถนำไปใช้สร้าง หรือทดสอบการใช้งานแอปพลิเคชันเองได้อย่างเต็มที่ และสร้างแอปพลิเคชันที่ใช้งานจริงได้อย่างหลากหลายและมีประสิทธิภาพ

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

สอบถามข้อมูลเพิ่มเติม บริษัท คอมพิวเตอร์ยูเนี่ยน จำกัด โทร.02-311-6881 ต่อ 7151, 7158 หรือ Emai. cu_mkt@cu.co.th

ข้อมูลอ้างอิง
– https://portworx.com/blog/unlocking-the-power-of-platform-engineering-build-once-port-anywhere-run-everywhere/
– https://tag-app-delivery.cncf.io/whitepapers/platforms/