- ปรับใช้แนวคิดที่มุ่งเน้นผลิตภัณฑ์ โดยเน้นการแก้ปัญหาที่ผู้ใช้ใช้งานจริง แทนที่จะเน้นแค่การนำเสนอวิธีแก้ปัญหาทางเทคนิคเพียงอย่างเดียว
- การนำสถาปัตยกรรมคลาวด์เนทีฟที่ใช้ไมโครเซอร์วิส คอนเทนเนอร์ และมาตรฐาน Twelve-Factor App มาใช้เพื่อเพิ่มความคล่องตัวและความสามารถในการขยายขนาด
- ระบบอัตโนมัติแบบครบวงจรผ่าน Infrastructure as Code (IaC) และกระบวนการ CI/CD เพื่อลดข้อผิดพลาดและเร่งการส่งมอบมูลค่า
หากคุณทำงานด้านโครงสร้างพื้นฐาน คุณคงตระหนักดีว่าการตั้งค่าคลัสเตอร์และการปรับใช้บริการเพียงอย่างเดียวไม่เพียงพอที่จะรับประกันความสำเร็จของระบบ เรามักมุ่งเน้นไปที่เทคโนโลยีล้ำสมัยมากเกินไปจนลืมไปว่าใครจะเป็นผู้ใช้งานแพลตฟอร์มนั้นจริง ๆ และปัญหาในโลกแห่งความเป็นจริงที่เราพยายามแก้ไขในแต่ละวันคืออะไร
เพื่อหยุดการคลำทางในความมืด แนวคิดที่เรียกว่า Product Thinking จึงถือกำเนิดขึ้น ซึ่งโดยพื้นฐานแล้วประกอบด้วยการเลิกคิดว่าโครงสร้างพื้นฐานเป็นโครงการที่มีวันสิ้นสุด และเริ่มมองว่ามันเป็นผลิตภัณฑ์ที่มีชีวิตและพัฒนาอย่างต่อเนื่องมันไม่ใช่แค่การติดตั้งเครื่องมือ แต่เป็นการเปลี่ยนความคิดเพื่อให้วิศวกรที่ใช้แพลตฟอร์มของเรา รู้สึกว่าเรากำลังทำให้ชีวิตของพวกเขาง่ายขึ้น ไม่ใช่ซับซ้อนขึ้น
แนวคิดการคิดเชิงผลิตภัณฑ์ (Product Thinking) ที่นำมาประยุกต์ใช้ในงานวิศวกรรม
โดยพื้นฐานแล้ว Product Thinking คือกระบวนการระบุและจัดลำดับความสำคัญของปัญหาที่ ลูกค้า เผชิญ เพื่อสร้างมูลค่าโดยการแก้ไขปัญหาเหล่านั้น จุดสำคัญคือ: ควรเน้นที่ปัญหาโดยตรง ไม่ใช่ฟังก์ชันการทำงานหรือคุณสมบัติทางเทคนิค เมื่อวิศวกรเริ่มออกแบบโซลูชันโดยไม่เข้าใจสาเหตุที่แท้จริง พวกเขามีความเสี่ยงที่จะเสียเวลาและเงินไปกับสิ่งที่ไม่ก่อให้เกิดประโยชน์หรือไม่ได้แก้ปัญหาที่แท้จริงในท้ายที่สุด
เพื่อหลีกเลี่ยงปัญหานี้ สิ่งสำคัญคือเราต้องหลงรักปัญหา ไม่ใช่ทางแก้ปัญหา หากเราหมกมุ่นอยู่กับเครื่องมือ เราจะปิดประตูสู่การสำรวจสิ่งใหม่ๆ ในทางกลับกัน หากเราพูดคุยกับผู้ใช้และพัฒนาความเข้าใจเราจะสามารถตรวจสอบสมมติฐานก่อนที่จะเขียนโค้ดแม้แต่บรรทัดเดียว ซึ่งจะช่วยลดความเสี่ยงในการสร้างระบบที่กลายเป็นภาระในการดำเนินงาน หรือส่งเสริมให้เกิดระบบไอทีที่ไม่เป็นทางการ (Shadow IT)ที่ผู้ใช้ต้องไปหาทางเลือกอื่นด้วยตนเอง
แตกต่างจากการบริหารจัดการโครงการแบบดั้งเดิม ซึ่งเกี่ยวข้องกับการรวบรวมข้อกำหนด การดำเนินการ และการใช้งาน แนวทางการพัฒนาผลิตภัณฑ์นั้นเป็นไปอย่างต่อเนื่องและเป็นวัฏจักรโดยมุ่งเน้นที่การรักษาช่องทางการสื่อสารที่เปิดกว้างกับผู้ใช้เพื่อส่งมอบคุณค่าอย่างสม่ำเสมอ วัฏจักรนี้ส่งเสริมความสัมพันธ์ที่ไว้วางใจได้ ซึ่งช่วยให้แพลตฟอร์มเติบโตอย่างเป็นธรรมชาติและกลายเป็นตัวทวีคูณประสิทธิภาพสำหรับองค์กรโดยรวม
ทำความเข้าใจระบบนิเวศ Cloud Native
ในการนำแนวคิดนี้ไปใช้ เราต้องเข้าใจก่อนว่าการเป็นแอปพลิเคชันบนคลาวด์ (cloud-native) หมายถึงอะไร มันไม่ใช่แค่การอัปโหลดเครื่องเสมือนไปยังคลาวด์ แต่เป็นการออกแบบแอปพลิเคชันที่ใช้ประโยชน์จากโมเดลการประมวลผลแบบยืดหยุ่น ได้อย่างเต็มที่ ซึ่งเกี่ยวข้องกับการสร้างระบบที่มีความยืดหยุ่น ปรับขนาดได้ และตรวจสอบได้ ที่อนุญาตให้มีการเปลี่ยนแปลงบ่อยครั้งโดยมีความเสี่ยงน้อยที่สุด โดยใช้ส่วนประกอบต่างๆ เช่นคอนเทนเนอร์ เซอร์วิสเมช และ API แบบประกาศ (declarative API )
ความคล่องตัวของโมเดลนี้ขึ้นอยู่กับเสาหลักหลายประการ ประการแรกคือระบบคลาวด์เอง ซึ่งเราเปลี่ยนจากแนวคิดของ "สัตว์เลี้ยง" (เซิร์ฟเวอร์ที่มีชื่อและได้รับการดูแลเป็นรายบุคคล) ไปสู่แนวคิดของ"ปศุสัตว์" หรือสินค้าโภคภัณฑ์ (อินสแตนซ์ที่เหมือนกันและสามารถทิ้งได้) ภายใต้ระบบนี้ หากเซิร์ฟเวอร์ล้มเหลว มันจะไม่ได้รับการซ่อมแซม แต่จะถูกทำลายและมีการตั้งค่าเซิร์ฟเวอร์ใหม่ขึ้นโดยอัตโนมัติโดยใช้โครงสร้างพื้นฐานที่ไม่สามารถเปลี่ยนแปลงได้
หลักการของการออกแบบและสถาปัตยกรรมสมัยใหม่
เพื่อให้แอปพลิเคชันเป็นแอปพลิเคชันที่ทำงานบนคลาวด์ได้อย่างแท้จริง โดยทั่วไปจะใช้ระเบียบวิธี Twelve-Factor Appชุดกฎนี้มีจุดมุ่งหมายเพื่อเพิ่มประสิทธิภาพในการพกพาและการทำงานอัตโนมัติ ประเด็นสำคัญได้แก่ ไมโครเซอร์วิสแต่ละตัวต้องมีโค้ดเบสของตัวเองและมีการพึ่งพาที่แยกต่างหาก และการกำหนดค่าต้องถูกแยกออกจากกันเพื่อให้สามารถย้ายไบนารีเดียวกันระหว่างสภาพแวดล้อม QA และสภาพแวดล้อมการผลิตได้โดยไม่ต้องเปลี่ยนแปลง
- กระบวนการและความพร้อมกัน: แต่ละบริการควรทำงานในกระบวนการของตนเองและขยายขนาดในแนวนอน โดยหลีกเลี่ยงการขยายขนาดในแนวตั้งอย่างมหาศาล
- ใช้แล้วทิ้ง: อินสแตนซ์จำเป็นต้องเริ่มต้นทำงานอย่างรวดเร็วและปิดตัวลงอย่างราบรื่น ซึ่งคอนเทนเนอร์สามารถจัดการได้อย่างสมบูรณ์แบบ
- ความเท่าเทียมด้านสิ่งแวดล้อม: สภาพแวดล้อมการพัฒนาควรมีความคล้ายคลึงกับสภาพแวดล้อมการใช้งานจริงให้มากที่สุด เพื่อหลีกเลี่ยงปัญหาที่ไม่คาดคิดระหว่างการใช้งานจริง
- ระบบส่งข้อมูลทางไกลและ API: การออกแบบโดยคำนึงถึง API เป็นอันดับแรกและการรวบรวมข้อมูลด้านสุขภาพและประสิทธิภาพตั้งแต่เริ่มต้นนั้นมีความสำคัญอย่างยิ่ง
นอกจากนี้ เฟรมเวิร์กต่างๆ เช่นWell-Architected Framework ของ Microsoft ยังช่วยรับประกันคุณภาพบนพื้นฐานของ 5 เสาหลัก ได้แก่ การจัดการต้นทุน (จ่ายเฉพาะสิ่งที่คุณใช้) ความเป็นเลิศในการดำเนินงาน (การทำให้ทุกอย่างเป็นระบบอัตโนมัติ) ประสิทธิภาพการทำงาน ความน่าเชื่อถือ (ความสามารถในการกู้คืนจากข้อผิดพลาด) และแน่นอนความปลอดภัยที่บูรณาการตลอดวงจรชีวิตทั้งหมด
ไมโครเซอร์วิสและการจัดการความซับซ้อน
หัวใจสำคัญของโซลูชันคลาวด์เนทีฟอยู่ที่ไมโครเซอร์วิส การแบ่งแอปพลิเคชันขนาดใหญ่แบบโมโนลิธออกเป็นบริการขนาดเล็กที่ทำงานได้อย่างอิสระ ทำให้เรามีความคล่องตัวอย่างเหลือเชื่อเราสามารถอัปเดตฟังก์ชันการทำงานเฉพาะโดยไม่ต้องรีสตาร์ทระบบทั้งหมด และปรับขนาดเฉพาะส่วนที่มีความต้องการสูงสุดเท่านั้น ซึ่งจะช่วยเพิ่มประสิทธิภาพต้นทุนการดำเนินงาน
อย่างไรก็ตาม สิ่งนี้ก็ก่อให้เกิดความท้าทาย การสื่อสารระหว่างบริการต่างๆ กลายเป็นเรื่องซับซ้อน และจำเป็นต้องจัดการความยืดหยุ่น (จะเกิดอะไรขึ้นหากบริการ B หยุดทำงาน?) และข้อมูลแบบกระจาย เครื่องมืออย่างDaprช่วยลดความซับซ้อนเหล่านี้โดยการจัดเตรียมส่วนประกอบสำเร็จรูปที่ทำหน้าที่เป็นตัวเชื่อมประสานแบบไดนามิก ช่วยให้นักพัฒนาสามารถมุ่งเน้นไปที่ตรรกะทางธุรกิจมากกว่ารายละเอียดด้านโครงสร้างพื้นฐาน
คอนเทนเนอร์ การจัดการระบบ และบริการสำรองข้อมูล
คอนเทนเนอร์เป็นหัวใจสำคัญของโมเดลนี้ โดยการบรรจุโค้ดและส่วนประกอบต่างๆ ลงในอิมเมจ เราจึงมั่นใจได้ว่าแอปพลิเคชันจะทำงานได้เหมือนกันทั้งบนแล็ปท็อปของนักพัฒนาและบนเซิร์ฟเวอร์ที่ใช้งานจริง ในการจัดการคอนเทนเนอร์จำนวนหลายพันตัว เราจำเป็นต้องมีตัวจัดการระบบ และในส่วนนี้Kubernetesได้สร้างมาตรฐานที่เป็นที่ยอมรับอย่างกว้างขวาง โดยทำหน้าที่จัดการการจัดตารางเวลา การตรวจสอบสถานะ และ การ ปรับขนาดอัตโนมัติ
เพื่อหลีกเลี่ยงความยุ่งยาก วิธีแก้ปัญหาที่ดีที่สุดคือการมอบหมายการจัดการทรัพยากรเสริม (ฐานข้อมูล คิวข้อความ บันทึก) ให้กับบริการสำรองข้อมูลแบบจัดการโดยผู้ให้บริการคลาวด์ ด้วยวิธีนี้ เราจะลดภาระเรื่องใบอนุญาตและการบำรุงรักษา โดยจัดการบริการเหล่านี้เป็นทรัพยากรที่เกี่ยวข้องซึ่งเชื่อมโยงผ่าน URL และข้อมูลรับรองภายนอก ทำให้โค้ดแยกส่วนและมีความยืดหยุ่น
ระบบอัตโนมัติเต็มรูปแบบ: เส้นทางสู่ CI/CD
ระบบทั้งหมดนี้จะทำงานไม่ได้เลยหากปราศจากระบบอัตโนมัติที่แข็งแกร่งInfrastructure as Code (IaC) ช่วยให้คุณสามารถกำหนดเครือข่ายและเซิร์ฟเวอร์โดยใช้สคริปต์แบบประกาศ (เช่น Terraform หรือ Bicep) ทำให้การปรับใช้ทำซ้ำได้และปราศจากข้อผิดพลาดจากมนุษย์ ซึ่งเสริมด้วย เวิร์กโฟลว์Continuous Integration and Continuous Delivery (CI/CD )
ในเวิร์กโฟลว์สมัยใหม่ นักพัฒนาจะอัปโหลดโค้ดของตนไปยังที่เก็บโค้ด ซึ่งจะกระตุ้นขั้นตอนการสร้างและทดสอบอัตโนมัติ จากนั้นจะสร้าง เวอร์ชันที่ไม่สามารถเปลี่ยนแปลงได้และนำไปใช้งานในสภาพแวดล้อมเป้าหมาย เครื่องมืออย่าง Google Cloud Build หรือ GitHub Actions ทำให้กระบวนการนี้โปร่งใสยิ่งขึ้น แม้กระทั่งอำนวยความสะดวกในการนำGitOps มาใช้ ซึ่งสถานะของคลัสเตอร์ที่ต้องการจะถูกอธิบายโดยตรงในไฟล์ Git
การเปลี่ยนผ่านไปสู่โมเดลนี้ไม่ได้ต้องการเพียงแค่เครื่องมือเท่านั้น แต่ยังต้องมีการเปลี่ยนแปลงทางวัฒนธรรมด้วย ทีมต้องทำงานร่วมกันได้หลายด้าน ทำลายกำแพงกั้นระหว่างฝ่ายพัฒนาและฝ่ายปฏิบัติการ เพื่อให้เกิดความคิดแบบรับผิดชอบร่วมกัน การผสานพลังทางเทคนิคของ Kubernetes และคลาวด์เข้ากับกลยุทธ์ที่เน้นผู้ใช้เป็นศูนย์กลางจะช่วยให้องค์กรสามารถเปลี่ยนโครงสร้างพื้นฐานให้เป็นเครื่องยนต์ขับเคลื่อนธุรกิจ ที่ผลักดันนวัตกรรมอย่างต่อเนื่องและประสิทธิภาพในการดำเนินงาน
