โมเดล DevOps ที่กำหนด
DevOps คือการผสมผสานแนวความคิดเชิงวัฒนธรรม แนวทางปฏิบัติ และเครื่องมือต่างๆ ที่ช่วยเพิ่มความสามารถขององค์กรในการส่งมอบแอปพลิเคชันและบริการอย่างรวดเร็ว โดยพัฒนาและปรับปรุงผลิตภัณฑ์ต่างๆ ให้เร็วกว่ากระบวนการการพัฒนาซอฟต์แวร์และการจัดการโครงสร้างพื้นฐานแบบดั้งเดิม ความรวดเร็วนี้ช่วยให้องค์กรสามารถส่งมอบบริการแก่ลูกค้าของตนได้และสามารถแข่งขันได้อย่างมีประสิทธิภาพมากขึ้นในตลาด
DevOps ทำงานอย่างไร
สำหรับโมเดล DevOps ทีมพัฒนาและทีมปฏิบัติการจะไม่ทำงานแบบ “ต่างคนต่างทำ” อีกต่อไป บางครั้ง ทั้งสองทีมจะจับมือร่วมงานเป็นทีมเดียวกันซึ่งเหล่าวิศวกรจะทำงานครอบคลุมทั้งวงจรของแอปพลิเคชัน ตั้งแต่การพัฒนาและการทดสอบ ไปจนถึงการปรับใช้และการดำเนินการ และคอยพัฒนาขอบเขตความสามารถไม่ให้จำกัดอยู่เพียงแค่ฟังก์ชันเดียว
ในบางโมเดลของ DevOps ทีมประกันคุณภาพและทีมรักษาความปลอดภัยอาจทำงานรวมกับทีมพัฒนาและทีมปฏิบัติการอย่างใกล้ชิดยิ่งขึ้นตลอดวงจรการทำงานของแอปพลิเคชัน หากการรักษาความปลอดภัยเป็นจุดสำคัญของทุกคนในทีม DevOps เราจะเรียกว่า DevSecOps
ทีมต่างๆ ใช้ข้อปฏิบัติในการเปลี่ยนกระบวนการต่างๆ ที่เคยทำงานแบบแมนนวลและเชื่องช้าให้ทำงานอัตโนมัติ พวกเขาใช้ชุดเทคโนโลยีและเครื่องมือต่างๆ ที่ช่วยให้พวกเขาดำเนินการและพัฒนาแอปพลิเคชันได้อย่างรวดเร็วและเชื่อถือได้ นอกจากนั้น เครื่องมือเหล่านี้ยังช่วยเหล่าวิศวกรให้ทำงานได้อย่างอิสระ (เช่น การปรับใช้โค้ด หรือการจัดเตรียมโครงสร้างพื้นฐาน) ที่โดยปกติแล้วจำเป็นต้องได้รับความช่วยเหลือจากทีมอื่น พร้อมทั้งยังช่วยเพิ่มความรวดเร็วของการทำงานของทีมอีกด้วย
ประโยชน์ของ DevOps
ความเร็ว
การส่งมอบอย่างรวดเร็ว
ความเชื่อถือได้
ขนาด
การทำงานร่วมกันที่ได้รับการปรับปรุง
ความปลอดภัย
เหตุใด DevOps จึงมีความสำคัญ
ซอฟต์แวร์และอินเทอร์เน็ตได้เปลี่ยนโลกและอุตสาหกรรมต่างๆ ตั้งแต่การช้อปปิ้งและความบันเทิงไปจนถึงการธนาคาร ซอฟต์แวร์ไม่ได้เพียงแค่สนับสนุนธุรกิจเท่านั้น แต่ยังเป็นองค์ประกอบสำคัญในทุกภาคส่วนของธุรกิจ บริษัทต่างๆ มีปฏิสัมพันธ์กับลูกค้าของตนผ่านทางซอฟต์แวร์ที่ให้บริการหรือมีแอปพลิเคชันทางออนไลน์บนอุปกรณ์ทุกชนิด นอกจากนั้นยังใช้ซอฟต์แวร์เพื่อเพิ่มประสิทธิภาพการทำงานโดยเปลี่ยนแปลงทุกส่วนของห่วงโซ่คุณค่า เช่น โลจิสติกส์ การสื่อสาร และการปฏิบัติการ ในทำนองเดียวกันกับบริษัทที่จำหน่ายสินค้าซึ่งได้เปลี่ยนแปลงวิธีการออกแบบ ผลิต และส่งมอบผลิตภัณฑ์โดยใช้ระบบอัตโนมัติทางอุตสาหกรรมตลอดทั้งศตวรรษที่ 20 บริษัทในปัจจุบันจึงต้องเปลี่ยนแปลงวิธีการผลิตและส่งมอบซอฟต์แวร์เช่นกัน
วิธีปรับใช้โมเดล DevOps
ปรัชญาวัฒนธรรม DevOps
การเปลี่ยนมาเป็น DevOps ต้องมีการเปลี่ยนแปลงทั้งในเชิงวัฒนธรรมและแนวคิด พูดให้ง่ายที่สุดก็คือ DevOps เป็นการขจัดกำแพงกั้นระหว่างทีมพัฒนาและทีมปฏิบัติการที่ปกติต่างคนต่างทำงาน ในบางองค์กร อาจไม่มีการแบ่งแยกทีมพัฒนาและทีมปฏิบัติการเลย วิศวกรอาจทำทั้งสองงาน สำหรับ DevOps ทั้งสองทีมจะทำงานด้วยกันเพื่อปรับให้อัตราผลผลิตของนักพัฒนาและความเชื่อถือได้ของทีมปฏิบัติการอยู่ในระดับที่เหมาะสม ทั้งสองทีมจะต้องพยายามสื่อสารกันบ่อยครั้ง เพิ่มประสิทธิภาพ และปรับปรุงคุณภาพของบริการที่มอบให้แก่ลูกค้า โดยทั้งสองทีมมีสิทธิ์ควบคุมในบริการของตนโดยสมบูรณ์ ซึ่งมักเกินกว่าบทบาทหรือตำแหน่งของตนที่ระบุไว้ซึ่งถูกกำหนดขอบเขตเอาไว้โดยกรอบความคิดในส่วนความต้องการของลูกค้าและวิธีที่ตนสามารถช่วยดำเนินการส่งมอบความต้องการเหล่านั้น ทีมประกันคุณภาพและทีมรักษาความปลอดภัยยังอาจบูรณาการอย่างใกล้ชิดกับทีมดังกล่าวอีกด้วย องค์กรที่ใช้โมเดล DevOps ซึ่งไม่คำนึงถึงโครงสร้างองค์กร จะมีทีมงานที่คอยตรวจดูวงจรการพัฒนาและโครงสร้างพื้นฐานทั้งหมดตามที่เป็นส่วนหนึ่งในภาระรับผิดชอบของตน
หลักปฏิบัติของ DevOps ที่อธิบาย
มีข้อปฏิบัติสำคัญไม่กี่ข้อที่จะช่วยให้องค์กรสร้างสรรค์นวัตกรรมได้รวดเร็วยิ่งขึ้น โดยการปรับปรุงขั้นตอนและเปลี่ยนกระบวนการพัฒนาซอฟต์แวร์และจัดการโครงสร้างพื้นฐานให้ทำงานอัตโนมัติ หลักปฏิบัติส่วนใหญ่ต้องดำเนินการโดยใช้เครื่องมือที่เหมาะสม
ข้อปฏิบัติพื้นฐานข้อหนึ่งคือ การอัปเดตบ่อยๆ ทีละเล็กน้อย วิธีจะทำให้องค์กรสร้างสรรค์นวัตกรรมให้แก่ลูกค้าได้เร็วยิ่งขึ้น โดยทั่วไปแล้ว อัปเดตเหล่านี้มีลักษณะเป็นส่วนเพิ่มมากกว่าอัปเดตเป็นครั้งคราวที่ทำภายใต้ข้อปฏิบัติในการออกอัปเดตแบบเดิมๆ การอัปเดตบ่อยๆ ทีละเล็กน้อยจะทำให้การปรับใช้ในแต่ละครั้งมีความเสี่ยงลดลง โดยจะช่วยให้ทีมแก้ไขจุดบกพร่องได้เร็วขึ้น เนื่องจากทีมสามารถระบุการปรับใช้ครั้งสุดท้ายที่ทำให้เกิดปัญหาได้ แม้ว่าระยะเวลาและขนาดของการอัปเดตจะแตกต่างกัน แต่องค์การที่ใช้โมเดล DevOps สามารถปรับใช้การอัปเดตได้บ่อยครั้งมากกว่าองค์กรที่ใช้หลักปฏิบัติในการพัฒนาซอฟต์แวร์แบบเดิม
องค์กรยังอาจต้องใช้สถาปัตยกรรมไมโครเซอร์วิสอีกด้วย เพื่อทำให้แอปพลิเคชันมีความยืดหยุ่นมากขึ้นและสามารถสร้างสรรค์นวัตกรรมได้เร็วขึ้น สถาปัตยกรรมไมโครเซอร์วิสจะแยกระบบขนาดใหญ่ที่มีความซับซ้อนออกเป็นโปรเจ็กต์ง่ายๆ ที่ทำงานอิสระ แอปพลิเคชันจะถูกแบ่งออกเป็นแต่ละส่วนประกอบ (บริการ) จำนวนมาก โดยแต่ละบริการจะถูกกำหนดขอบเขตให้มีจุดประสงค์เดียวหรือการทำงานอย่างเดียว และทำงานโดยอิสระจากทั้งบริการในระดับเดียวกันและแอปพลิเคชันโดยรวม การออกแบบดังกล่าวนี้ช่วยลดค่าใช้จ่ายในการประสานงานของการอัปเดตแอปพลิเคชัน และหากแต่ละบริการถูกมอบหมายให้กับทีมงานขนาดเล็กที่มีความคล่องแคล่วว่องไวซึ่งครอบครองสิทธิ์ควบคุมแต่ละบริการ องค์กรจะสามารถดำเนินการได้รวดเร็วมากยิ่งขึ้น
อย่างไรก็ตาม การนำไมโครเซอร์วิสมารวมเข้ากับการออกอัปเดตในความถี่ที่เพิ่มขึ้นนั้น อาจนำไปสู่การปรับใช้งานมากขึ้นอย่างมีนัยสำคัญ ซึ่งอาจก่อให้เกิดความท้าทายในการปฏิบัติงานได้ ด้วยเหตุนี้ ข้อปฏิบัติของ DevOps อย่างเช่น การบูรณาการอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง จึงช่วยแก้ไขปัญหาดังกล่าวได้ และช่วยให้องค์กรส่งมอบได้อย่างรวดเร็วในลักษณะที่ปลอดภัยและเชื่อถือได้ ข้อปฏิบัติสำหรับการทำงานอัตโนมัติของโครงสร้างพื้นฐาน เช่น โครงสร้างพื้นฐานเป็นโค้ดและการจัดการการกำหนดค่า จะช่วยให้ทรัพยากรในการประมวลผลมีความยืดหยุ่นและตอบสนองต่อการเปลี่ยนแปลงที่บ่อยครั้ง นอกจากนั้น การใช้งานการตรวจสอบและการบันทึกช่วยให้วิศวกรสามารถติดตามประสิทธิภาพการทำงานของแอปพลิเคชันและโครงสร้างพื้นฐานได้ เพื่อให้วิศวกรสามารถตอบสนองต่อปัญหาได้โดยเร็ว
ข้อปฏิบัติเหล่านี้ร่วมกันช่วยให้องค์กรสามารถส่งมอบอัปเดตที่เร็วขึ้นและเชื่อถือได้มากยิ่งขึ้นให้แก่ลูกค้า ภาพรวมของหลักปฏิบัติของ DevOps ที่สำคัญ มีดังนี้
การบูรณาการอย่างต่อเนื่อง
การบูรณาการอย่างต่อเนื่อง คือข้อปฏิบัติในการพัฒนาซอฟต์แวร์โดยที่นักพัฒนานำการเปลี่ยนแปลงโค้ดของตนมารวมอยู่ในพื้นที่เก็บข้อมูลส่วนกลางอย่างสม่ำเสมอ ซึ่งหลังจากนั้นจะดำเนินการสร้างและทดสอบโดยอัตโนมัติ เป้าหมายสำคัญของการบูรณาการอย่างต่อเนื่องคือ เพื่อค้นหาและแก้ไขข้อผิดพลาดโดยเร็ว เพื่อพัฒนาคุณภาพของซอฟต์แวร์ และเพื่อลดเวลาที่ใช้ในการตรวจสอบและปล่อยการอัปเดตซอฟต์แวร์เวอร์ชันใหม่
การส่งมอบอย่างต่อเนื่อง
การส่งมอบอย่างต่อเนื่อง คือข้อปฏิบัติในการพัฒนาซอฟต์แวร์โดยที่การเปลี่ยนแปลงโค้ดถูกสร้างขึ้น ทดสอบ และจัดเตรียมสำหรับการออกสู่การใช้งานจริงโดยอัตโนมัติ ซึ่งจะขยายตามการบูรณาการอย่างต่อเนื่องโดยนำการเปลี่ยนแปลงโค้ดทั้งหมดมาปรับใช้กับสภาพแวดล้อมการทดสอบและ/หรือสภาพแวดล้อมการใช้งานจริงภายหลังขั้นตอนการสร้าง หากการส่งมอบอย่างต่อเนื่องถูกนำไปใช่อย่างเหมาะสมแล้ว ทีมพัฒนาจะมีวัตถุพร้อมใช้งานที่ผ่านกระบวนการทดสอบที่ได้รับการจัดมาตรฐานแล้ว
เรียนรู้เพิ่มเติมเกี่ยวกับการส่งมอบอย่างต่อเนื่องและ AWS CodePipeline
ไมโครเซอร์วิส
สถาปัตยกรรมไมโครเซอร์วิส คือแนวทางการออกแบบในการสร้างแอปพลิเคชันเดียวโดยเป็นชุดของบริการขนาดเล็ก แต่ละบริการจะทำงานตามกระบวนการของตนและสื่อสารกับบริการอื่นผ่านอินเทอร์เฟซที่กำหนดไว้เป็นอย่างดีโดยใช้กลไกน้ำหนักเบา ซึ่งโดยทั่วไปจะเป็นอินเทอร์เฟซการเขียนโปรแกรมบน HTTP (API) ไมโครเซอร์วิสถูกสร้างขึ้นตามขีดความสามารถของธุรกิจ โดยแต่ละบริการจะถูกกำหนดขอบเขตสำหรับจุดประสงค์เดียว คุณสามารถใช้งานเฟรมเวิร์คหรือภาษาการเขียนโปรแกรมต่างๆ ในการเขียนไมโครเซอร์วิสได้และสามารถปรับใช้เป็นแบบบริการเดี่ยวหรือแบบบริการกลุ่มได้อย่างอิสระ
เรียนรู้เพิ่มเติมเกี่ยวกับ Amazon Container Service (Amazon ECS)
เรียนรู้เพิ่มเติมเกี่ยวกับ AWS Lambda
โครงสร้างพื้นฐานเป็นโค้ด
โครงสร้างพื้นฐานเป็นโค้ด คือข้อปฏิบัติโดยที่โครงสร้างพื้นฐานได้รับการจัดเตรียมและจัดการโดยใช้โค้ดและเทคนิคการพัฒนาซอฟต์แวร์ เช่น การควบคุมเวอร์ชัน และการบูรณาการอย่างต่อเนื่อง โมเดลที่ขับเคลื่อนด้วย API ของคลาวด์ทำให้นักพัฒนาและผู้ดูแลระบบสามารถตอบโต้กับโครงสร้างพื้นฐานได้ในทางโปรแกรมในขนาดต่างๆ แทนที่จะต้องมาตั้งค่าและกำหนดค่าทรัพยากรด้วยตนเอง ด้วยเหตุนี้ วิศวกรจึงสามารถใช้เครื่องมือที่ใช้โค้ดในการสื่อสารกับโครงสร้างพื้นฐานได้ และทำงานกับโครงสร้างพื้นฐานได้ในลักษณะเดียวกับที่ทำงานกับโค้ดของแอปพลิเคชัน เนื่องจากโครงสร้างพื้นฐานดังกล่าวถูกกำหนดโดยใช้โค้ด โครงสร้างพื้นฐานและบริการต่างๆ จึงสามารถนำไปปรับใช้ได้อย่างรวดเร็วโดยใช้รูปแบบที่ผ่านมาตรฐาน สามารถดำเนินการอัปเดตเป็นเวอร์ชันล่าสุดได้ หรือสามารถทำสำเนาซื้อได้
เรียนรู้วิธีจัดการกับโครงสร้างพื้นฐานเป็นโค้ดด้วย AWS CloudFormation
การจัดการการกำหนดค่า
นักพัฒนาและผู้ดูแลระบบใช้โค้ดเพื่อทำให้ระบบปฏิบัติการ การกำหนดค่าโฮสต์ งานในปฏิบัติการ และอื่นๆ ทำงานอัตโนมัติ การใช้โค้ดทำให้การเปลี่ยนแปลงการกำหนดค่าสามารถทำซ้ำได้และเป็นมาตรฐาน ซึ่งช่วยปลดปล่อยทีมพัฒนาและผู้ดูแลระบบจากการกำหนดค่าระบบปฏิบัติการ แอปพลิเคชันระบบ หรือซอฟต์แวร์เซิร์ฟเวอร์ด้วยตนเอง
เรียนรู้วิธีกำหนดค่าและจัดการ Amazon EC2 และระบบในองค์กรด้วย Amazon EC2 Systems Manager
เรียนรู้วิธีการใช้การจัดการการกำหนดค่าด้วย AWS OpsWorks
นโยบายแบบเป็นโค้ด
องค์กรสามารถตรวจสอบและบังคับใช้การปฏิบัติตามกฎระเบียบแบบไดนามิกในขนาดต่างๆ ได้ด้วยโครงสร้างพื้นฐานและการกำหนดค่าที่เขียนโค้ดขึ้นด้วยคลาวด์ ด้วยเหตุนี้ จึงสามารถติดตาม ตรวจสอบความถูกต้อง และกำหนดค่าซ้ำโครงสร้างพื้นฐานที่กำหนดด้วยโค้ดได้โดยอัตโนมัติ ซึ่งทำให้องค์กรควบคุมการเปลี่ยนแปลงต่อทรัพยากรได้ง่ายขึ้น และช่วยให้แน่ใจได้ว่ามีการบังคับใช้มาตรการรักษาความปลอดภัยอย่างเหมาะสมในลักษณะกระจาย (เช่น การรักษาความปลอดภัยข้อมูล หรือการปฏิบัติตาม PCI-DSS หรือ HIPAA) โดยช่วยให้ทีมงานภายในองค์กรสามารถดำเนินการได้อย่างรวดเร็ว เนื่องจากสามารถติดตามทรัพยากรที่ไม่สอดคล้องกันสำหรับการตรวจสอบได้โดยอัตโนมัติ หรือแม้แต่การนำกลับมาทำให้สอดคล้อง
การตรวจสอบและการบันทึก
องค์กรจะตรวจสอบตัวชี้วัดและบันทึกต่างๆ เพื่อดูว่าประสิทธิภาพของแอปพลิเคชันและโครงสร้างพื้นฐานมีผลกระทบต่อประสบการณ์ของผู้ใช้ผลิตภัณฑ์ในขั้นปลายอย่างไร การรวบรวม จำแนกประเภท และวิเคราะห์ข้อมูลและบันทึกที่สร้างโดยแอปพลิเคชันและโครงสร้างพื้นฐาน จะทำให้องค์กรสามารถเข้าใจว่าการเปลี่ยนแปลงหรืออัปเดตมีผลกระทบต่อใช้อย่างไร โดยทำให้มองเห็นข้อมูลเชิงลึกถึงสาเหตุหลักของปัญหาหรือการเปลี่ยนแปลงที่ไม่คาดคิด การตรวจสอบอย่างจริงจังมีความสำคัญเพิ่มขึ้นเรื่อยๆ ในขณะที่บริการต้องพร้อมใช้งาน 24 ชั่วโมงทุกวัน และในขณะที่แอปพลิเคชันและโครงสร้างพื้นฐานมีอัปเดตในความถี่เพิ่มขึ้น นอกจากนั้น การสร้างการแจ้งเตือนหรือการดำเนินการวิเคราะห์ข้อมูลตามเวลาจริงยังช่วยให้องค์กรสามารถตรวจสอบบริการของตนได้อย่างสม่ำเสมออีกด้วย
เรียนรู้วิธีการใช้ Amazon CloudWatch เพื่อตรวจสอบตัวชี้วัดและบันทึกของโครงสร้างพื้นฐาน
เรียนรู้วิธีการใช้ AWS CloudTrail เพื่อบันทึกและเก็บการเรียกใช้ API ของ AWS ลงในไฟล์บันทึก
การสื่อสารและการทำงานร่วมกัน
การสื่อสารและการทำงานร่วมกันที่เพิ่มขึ้นในองค์กรเป็นประเด็นเชิงวัฒนธรรมข้อหนึ่งของ DevOps การใช้เครื่องมือ DevOps และการทำงานอัตโนมัติของกระบวนการส่งมอบซอฟต์แวร์ก่อให้เกิดการทำงานร่วมกันโดยนำลำดับการทำงานและความรับผิดชอบของฝ่ายพัฒนาและฝ่ายปฏิบัติการเข้ามาอยู่ด้วยกัน จากนั้น ทีมเหล่านี้ก็จะกำหนดบรรทัดฐานเชิงวัฒนธรรมที่เข้มแข็งเกี่ยวกับการแบ่งปันข้อมูลและการอำนวยความสะดวกในการสื่อสารผ่านการใช้แอปพลิเคชันการสนทนา ระบบติดตามปัญหาหรือโครงการ และ Wiki ซึ่งช่วยเพิ่มความเร็วในการสื่อสารระหว่างทีมพัฒนาและทีมดำเนินการ ตลอดจนทีมอื่นๆ เช่น ทีมการตลาด หรือทีมการขาย โดยช่วยให้ทุกภาคส่วนขององค์กรสามารถดำเนินการให้สอดคล้องกับเป้าหมายและโครงการมากขึ้น
เครื่องมือ DevOps
โมเดล DevOps อาศัยเครื่องมือที่มีประสิทธิผล เพื่อช่วยให้ทีมต่างๆ ปรับใช้และสร้างสรรค์นวัตกรรมให้แก่ลูกค้าได้อย่างรวดเร็วและเชื่อถือได้ เครื่องมือเหล่านี้ทำให้งานที่ต้องดำเนินการด้วยตนเองทำงานอัตโนมัติ ช่วยทีมต่างๆ ในการจัดการสภาพแวดล้อมที่ซับซ้อนได้ในขนาดต่างๆ และช่วยให้วิศวกรสามารถควบคุมความเร็วสูงที่ DevOps ทำให้เกิดขึ้น AWS ให้บริการที่ได้รับการออกแบบสำหรับ DevOps และสร้างขึ้นครั้งแรกเพื่อการใช้งานกับ AWS Cloud บริการเหล่านี้ช่วยให้คุณสามารถใช้งานตามหลักปฏิบัติของ DevOps ตามที่อธิบายไว้ด้านบน
เรียนรู้เกี่ยวกับบริการ AWS DevOps
เรียนรู้เกี่ยวกับโซลูชันพาร์ทเนอร์ AWS