- วิศวกรรมแพลตฟอร์มสร้างชั้นของนามธรรมโดยใช้ IDP เพื่อลดภาระทางความคิดของนักพัฒนา
- แนวคิดนี้ตั้งอยู่บนพื้นฐานแนวทางของผลิตภัณฑ์ โดยนำเสนอโครงสร้างพื้นฐานในรูปแบบมาตรฐานและบริการตนเอง
- เป้าหมายคือการเพิ่มประสิทธิภาพวงจรการส่งมอบซอฟต์แวร์โดยใช้เส้นทางที่เหมาะสมที่สุดหรือเส้นทางทองคำ (Golden Paths)
คุณคงสังเกตเห็นแล้วว่าคำว่า "วิศวกรรมแพลตฟอร์ม" ปรากฏขึ้นมากมายในแวดวงเทคโนโลยี ในช่วงนี้นี่ไม่ใช่เรื่องบังเอิญ เรากำลังเห็นบริษัทต่างๆ พยายามแก้ไขความวุ่นวายที่บางครั้งเกิดจากการเติบโตอย่างควบคุมไม่ได้ของคลาวด์และไมโครเซอร์วิส โดยมองหาวิธีที่จะช่วยให้นักพัฒนาไม่ต้องเป็นผู้เชี่ยวชาญในทุกๆ เรื่องเพียงเพื่อที่จะนำการเปลี่ยนแปลงไปใช้งานจริง
โดยพื้นฐานแล้ว เรากำลังพูดถึงสาขาวิชาด้านสังคมและเทคนิคที่มุ่งเน้นการออกแบบและบำรุงรักษาแพลตฟอร์มซอฟต์แวร์ภายในองค์กรแนวคิดนั้นเรียบง่ายแต่ทรงพลัง: คือการสร้างสภาพแวดล้อมที่ทีมพัฒนาได้รับทุกสิ่งที่พวกเขาต้องการอย่างพร้อมใช้งาน ทำงานได้อย่างอิสระ โดยไม่ต้องเปิดตั๋วและรอหลายวันให้ฝ่ายปฏิบัติการสร้างเซิร์ฟเวอร์หรือ S3 bucket ให้พวกเขา
งานวิศวกรรมแพลตฟอร์มเกี่ยวข้องกับอะไรบ้างกันแน่?
แตกต่างจากแนวทางอื่นๆ สาขาวิชานี้มุ่งเน้นไปที่การสร้างแพลตฟอร์มสำหรับนักพัฒนาภายใน (Internal Developer Platform หรือ IDP)ลองนึกภาพว่าเป็นเหมือน "เครื่องจำหน่าย" โครงสร้างพื้นฐาน แทนที่จะต้องดิ้นรนกับไฟล์การกำหนดค่าที่ไม่มีที่สิ้นสุด นักพัฒนาสามารถเข้าถึงพอร์ทัลที่พวกเขาสามารถใช้งานและปรับใช้บริการของตนได้ตามมาตรฐานที่ได้รับการอนุมัติล่วงหน้า
โมเดลนี้ไม่ได้เกิดขึ้นจากความว่างเปล่า มันคือวิวัฒนาการตามธรรมชาติของ DevOpsในขณะที่ DevOps ให้ปรัชญาเรื่องการทำงานร่วมกันและการทำงานอัตโนมัติ วิศวกรรมแพลตฟอร์ม (Platform Engineering) แปลแนวคิดเหล่านั้นให้เป็นเครื่องมือที่เป็นรูปธรรม เป้าหมายหลักคือการลดภาระทางความคิด (cognitive load ) ซึ่งเป็นความรู้สึกที่หนักหน่วงที่เกิดขึ้นเมื่อโปรแกรมเมอร์ต้องจัดการทั้งโค้ด ความปลอดภัย การตรวจสอบ และโครงสร้างพื้นฐานไปพร้อมๆ กัน
เสาหลักที่สนับสนุนแนวทางนี้
- แนวคิดเกี่ยวกับผลิตภัณฑ์: นี่คือประเด็นสำคัญ แพลตฟอร์มนี้ไม่ใช่โครงการที่มีวันสิ้นสุดตายตัว แต่เป็นผลิตภัณฑ์ที่มีชีวิต นักพัฒนาคือลูกค้า และทีมพัฒนาแพลตฟอร์มต้องรับฟังข้อร้องเรียนและความต้องการของพวกเขาเพื่อปรับปรุงอย่างต่อเนื่อง
- บริการตนเอง: เป้าหมายคือการกำจัด "TicketOps" ที่เป็นปัญหาออกไป โดยมีเป้าหมายให้ทีมพัฒนาสามารถ... แบบพอเพียงการเข้าถึงทรัพยากรผ่าน API หรือเว็บพอร์ทัลโดยไม่ต้องพึ่งพาตัวกลาง
- เส้นทางทองคำ: นี่คือเส้นทางการปรับใช้ที่กำหนดไว้ล่วงหน้าและปรับให้เหมาะสมที่สุด หากนักพัฒนาปฏิบัติตามมาตรฐานสูงสุด พวกเขาก็จะมั่นใจได้ว่าแอปพลิเคชันของตนตรงตามข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบโดยปริยาย แม้ว่าพวกเขาจะได้รับอนุญาตให้เบี่ยงเบนจากมาตรฐานดังกล่าวได้ในกรณีพิเศษบางกรณีก็ตาม
เหตุใดจึงมีความจำเป็นอย่างยิ่งในปัจจุบัน?
ระบบนิเวศในปัจจุบันเปรียบเสมือนป่าแห่งเครื่องมือ ระหว่าง Kubernetes, Terraform, คลาวด์แบบไฮบริด และกฎระเบียบด้านความปลอดภัย การหลงทางจึงเป็นเรื่องง่าย วิศวกรรมแพลตฟอร์มช่วยจัดการความซับซ้อนนี้โดยการแยกรายละเอียดทางเทคนิคที่ซับซ้อนที่สุดออกมา เพื่อให้ทีมสามารถมุ่งเน้นไปที่สิ่งที่สำคัญอย่างแท้จริง นั่นคือการสร้างมูลค่าทางธุรกิจ
นอกจากนี้ ในภาคส่วนที่มีการควบคุมอย่างเข้มงวด การรับรองการปฏิบัติตามกฎระเบียบและความปลอดภัยเป็นเรื่องที่ยุ่งยากมาก การบูรณาการกฎเหล่านี้เข้ากับแพลตฟอร์มโดยตรงจะทำให้การปฏิบัติตามกฎระเบียบเป็นไปโดยอัตโนมัติ นักพัฒนาไม่จำเป็นต้องอ่านคู่มือความปลอดภัย 100 หน้า แพลตฟอร์มจะป้องกันไม่ให้พวกเขานำสิ่งใดก็ตามที่มีช่องโหว่ไปใช้งาน
ส่งผลกระทบอย่างแท้จริงต่อองค์กร
เมื่อเรานำสิ่งนี้ไปใช้อย่างถูกต้อง ประโยชน์ที่ได้รับจะส่งผลดีในทุกระดับ ในระดับองค์กร ต้นทุนการดำเนินงานจะลดลงและกระบวนการต่างๆ จะเป็นมาตรฐานเดียวกันป้องกันไม่ให้แต่ละทีมต้องคิดค้นสิ่งใหม่ๆ ขึ้นมาเอง สำหรับทีมงานแล้ว นั่นหมายถึงความขัดแย้งที่ลดลงและการประสานงานที่ราบรื่นยิ่งขึ้นระหว่างส่วนงานต่างๆ
สำหรับนักพัฒนาแล้ว ประสบการณ์นี้เปลี่ยนแปลงชีวิตพวกเขาไปอย่างสิ้นเชิง พวกเขารู้สึกมีอำนาจมากขึ้นเพราะไม่ต้องรอคนอื่น และสามารถสร้างผลลัพธ์ที่มีประสิทธิภาพได้เร็วขึ้น การใช้เวลาน้อยลงกับการจัดการไฟล์ YAML ของ Kubernetes หมายความว่าจะมีเวลามากขึ้นในการเขียนโค้ดตรรกะทางธุรกิจ และลดความเสี่ยงที่จะเกิดภาวะหมดไฟจากความซับซ้อนในการดำเนินงานที่มากเกินไป
ความแตกต่างที่สำคัญระหว่าง SRE และ DevOps
เป็นเรื่องปกติมากที่จะสับสนระหว่างสองแนวคิดนี้ แต่จริงๆ แล้วทั้งสองมีภารกิจที่แตกต่างกันDevOps คือปรัชญาทั่วไปที่ทำลายกำแพงกั้นระหว่างการพัฒนาและการปฏิบัติงาน ในทางกลับกันวิศวกรรมความน่าเชื่อถือของระบบ (Site Reliability Engineering หรือ SRE)มุ่งเน้นไปที่ความเสถียรของระบบ การจัดการความพร้อมใช้งานและประสิทธิภาพผ่านขีดจำกัดการโหลดมาตรฐาน (Standard Load Limits หรือ SLOs) และงบประมาณข้อผิดพลาด
ในทางกลับกัน ฝ่ายวิศวกรรมแพลตฟอร์มมีหน้าที่สร้างเครื่องมือ (IDP) ที่ช่วยให้ทุกสิ่งที่กล่าวมาข้างต้นเกิดขึ้นได้อย่างมีประสิทธิภาพ ในขณะที่ SRE มุ่งเน้นไปที่ความเสถียรของระบบการผลิต ฝ่ายวิศวกรแพลตฟอร์มจะมุ่งเน้นไปที่ประสบการณ์ของนักพัฒนา (DevEx)เพื่อให้แน่ใจว่าเส้นทางจากแล็ปท็อปของโปรแกรมเมอร์ไปยังคลาวด์นั้นสั้นและปลอดภัยที่สุดเท่าที่จะเป็นไปได้
วิธีการจัดตั้งทีมวิศวกรรมแพลตฟอร์ม
การพยายามปรับใช้ระบบขนาดใหญ่ในชั่วข้ามคืนนั้นไม่แนะนำ ทางที่ดีควรเริ่มต้นด้วย แพลตฟอร์มที่ใช้งานได้จริงและมีขนาดเล็กที่สุด (Thinnest Viable Platform)ซึ่งเป็นเวอร์ชันขั้นต่ำที่ตอบสนองความต้องการเร่งด่วนที่สุดของทีม คุณสามารถใช้ประโยชน์จากความสามารถภายในของทีม SRE หรือ CloudOps ได้ แต่สิ่งสำคัญคือพวกเขาต้องมีทัศนคติที่มุ่งเน้นผลิตภัณฑ์
ภายในทีม บทบาทเฉพาะต่างๆ มักจะโดดเด่นออกมาผู้จัดการผลิตภัณฑ์แพลตฟอร์มจะคัดกรองความต้องการของผู้ใช้และจัดลำดับความสำคัญของแผนงานวิศวกร DevExจะมุ่งเน้นไปที่การทำให้ส่วนติดต่อผู้ใช้และขั้นตอนการทำงานใช้งานง่าย ในขณะที่วิศวกรโครงสร้างพื้นฐานจะสร้างกลไกภายในเพื่อให้มั่นใจว่าแพลตฟอร์มสามารถขยายขนาดได้และมีความแข็งแกร่ง
เครื่องมือและเทคโนโลยีทั่วไป
การสร้างระบบนิเวศนี้โดยทั่วไปเกี่ยวข้องกับการผสมผสานส่วนประกอบหลายอย่าง เข้าด้วยกัน โครงสร้างพื้นฐานในรูปแบบโค้ด (Infrastructure as Code หรือ IaC)เป็นพื้นฐานสำคัญสำหรับการสร้างสภาพแวดล้อมโดยอัตโนมัติ ตัวจัดการคอนเทนเนอร์อย่าง Kubernetes และเครื่องมือ CI/CD ที่ช่วยให้การส่งมอบอย่างต่อเนื่องเป็นไปอย่างราบรื่นก็มีบทบาทสำคัญเช่นกัน
โดยทั่วไปแล้ว ส่วนสำคัญที่แสดงผลคือInternal Developer Portal (IDP)ซึ่งทำหน้าที่เป็นชั้นการแสดงผลและการตรวจสอบสิทธิ์ เครื่องมือเหล่านี้ช่วยให้การกำกับดูแลโปร่งใสและรับประกันว่ามาตรฐานของบริษัทจะถูกนำไปใช้อย่างแนบเนียนแต่มีประสิทธิภาพในทุกการใช้งาน
การนำแนวทางนี้มาใช้ถือเป็นการเปลี่ยนแปลงกระบวนทัศน์ครั้งสำคัญ โดยโครงสร้างพื้นฐานจะไม่ใช่อุปสรรคอีกต่อไป แต่จะกลายเป็นตัวเร่งความเร็ว ด้วยการมุ่งเน้นไปที่การลดอุปสรรคทางเทคนิคและส่งเสริมความเป็นอิสระผ่านการบริการตนเอง บริษัทต่างๆ ไม่เพียงแต่จะปรับปรุงความเร็วในการส่งมอบงานเท่านั้น แต่ยังสร้างสภาพแวดล้อมการทำงานที่น่าดึงดูดและดีต่อสุขภาพมากขึ้นสำหรับบุคลากรด้านเทคนิค ทำให้มั่นใจได้ว่าเทคโนโลยีจะเป็นเพียงเครื่องมือในการบรรลุเป้าหมายทางธุรกิจ ไม่ใช่เป้าหมายสุดท้ายในตัวเอง