Which Deployment Option Is Right for You? (ตัวเลือกการ Deploy ไหนเหมาะกับคุณ?)
โอ้โห นั่นเรามีตัวเลือกมากมายเลยใช่ไหม? และผมก็คงไม่ได้ช่วยอะไรมากนักด้วยการพยายามแชร์ข้อดีข้อเสียมากมายสำหรับแต่ละแนวทาง ถ้าคุณอ่านมาถึงจุดนี้ คุณอาจรู้สึกงุนงงเล็กน้อยว่าคุณควรทำอะไร
Tip
ก่อนที่ผมจะพูดต่อไป ผมหวังว่ามันไม่จำเป็นต้องพูดว่า ถ้าสิ่งที่คุณกำลังทำอยู่ตอนนี้ใช้ได้ผลกับคุณ ก็ ทำต่อไป! อย่าให้ fashion มากำหนดการตัดสินใจทางเทคนิคของคุณ
ถ้าคุณคิดว่าคุณจำเป็นต้องเปลี่ยนวิธีที่คุณ deploy microservices ให้ผมลองกลั่นกรองสิ่งที่เราได้พูดคุยกันไปแล้วและมาสรุปเป็นแนวทางที่มีประโยชน์
กลับมาทบทวนหลักการของการ deploy microservice ของเรา หนึ่งในแง่มุมที่สำคัญที่สุดที่เรามุ่งเน้นคือการทำให้แน่ใจถึง isolation ของ microservices ของเรา แต่การใช้สิ่งนี้เพียงอย่างเดียวเป็นหลักการชี้นำอาจนำเราไปสู่การใช้เครื่อง physical เฉพาะสำหรับแต่ละ microservice instance! แน่นอนว่านั่นน่าจะมีค่าใช้จ่ายสูงมาก และอย่างที่เราได้พูดคุยกันไปแล้ว มีเครื่องมือที่ทรงพลังมากบางอย่างที่เราจะไม่สามารถใช้ได้ถ้าเราเดินตามเส้นทางนี้
Trade-off มีอยู่มากมายตรงนี้ การสร้างสมดุลระหว่างต้นทุนกับความง่ายในการใช้งาน, isolation, ความคุ้นเคย…มันอาจกลายเป็นเรื่องที่ท่วมท้นได้ ดังนั้นมาทบทวนชุดกฎที่ผมชอบเรียกว่า Sam's Really Basic Rules of Thumb for Working Out Where to Deploy Stuff กัน:
-
ถ้ามันไม่พัง ก็อย่าไปซ่อมมัน 4
-
ยอมสละการควบคุมเท่าที่คุณรู้สึกสบายใจ แล้วสละไปอีกนิดหน่อย ถ้าคุณสามารถ offload งานทั้งหมดของคุณไปยัง PaaS ที่ดีอย่าง Heroku (หรือ FaaS platform) ได้ ก็ทำเลยและมีความสุขไปกับมัน คุณจำเป็นต้องปรับแต่งการตั้งค่าทุกอย่างจริง ๆ หรือ?
-
การ containerize microservices ของคุณไม่ใช่เรื่องที่ปราศจากความเจ็บปวด แต่เป็นการประนีประนอมที่ดีมากในเรื่องต้นทุนของ isolation และมีประโยชน์อันยอดเยี่ยมสำหรับการพัฒนาในเครื่อง ในขณะที่ยังคงให้คุณควบคุมได้ในระดับหนึ่งว่าเกิดอะไรขึ้น คาดหวัง Kubernetes ในอนาคตของคุณได้เลย
หลายคนประกาศว่า "Kubernetes หรือไม่ก็เจ๊ง!" ซึ่งผมรู้สึกว่ามันไม่ค่อยมีประโยชน์นัก ถ้าคุณอยู่บน public cloud และปัญหาของคุณเข้ากับ FaaS เป็น deployment model ก็ทำแบบนั้นแทนและข้าม Kubernetes ไปเลย นักพัฒนาของคุณน่าจะมี productivity มากขึ้นมาก อย่างที่เราจะพูดคุยเพิ่มเติมใน Chapter 16 อย่าให้ความกลัวเรื่อง lock-in ทำให้คุณติดอยู่ในความยุ่งเหยิงที่คุณสร้างขึ้นเอง
เจอ PaaS ที่ยอดเยี่ยมอย่าง Heroku หรือ Zeit และมีแอปพลิเคชันที่เข้ากับข้อจำกัดของ platform หรือไม่? ผลักดันงานทั้งหมดไปยัง platform และใช้เวลามากขึ้นในการทำงานกับผลิตภัณฑ์ของคุณ ทั้ง Heroku และ Zeit เป็น platform ที่ยอดเยี่ยมมากพร้อม usability ที่ดีเยี่ยมจากมุมมองของนักพัฒนา นักพัฒนาของคุณไม่สมควรมีความสุขบ้างหรือ?
สำหรับพวกคุณที่เหลือ containerization คือหนทางที่จะไป ซึ่งหมายความว่าเราต้องพูดคุยเกี่ยวกับ Kubernetes
Role for Puppet, Chef, and Other Tools? (บทบาทของ Puppet, Chef และเครื่องมืออื่น ๆ?)
บทนี้เปลี่ยนแปลงไปอย่างมากตั้งแต่ฉบับพิมพ์ครั้งแรก ส่วนหนึ่งเป็นเพราะอุตสาหกรรมโดยรวมมีการพัฒนา แต่ก็เป็นเพราะเทคโนโลยีใหม่ที่มีประโยชน์มากขึ้นเรื่อย ๆ ด้วย การเกิดขึ้นของเทคโนโลยีใหม่ยังนำไปสู่บทบาทที่ลดลงสำหรับเทคโนโลยีอื่น—และนั่นทำให้เราเห็นเครื่องมืออย่าง Puppet, Chef, Ansible และ Salt มีบทบาทน้อยลงมากในการ deploy สถาปัตยกรรม microservice เมื่อเทียบกับที่เราเคยเห็นในปี 2014
เหตุผลหลักสำหรับเรื่องนี้คือการเติบโตของ container โดยพื้นฐาน พลังของเครื่องมืออย่าง Puppet และ Chef คือมันให้วิธีนำเครื่องไปสู่ desired state โดยที่ desired state นั้นถูกกำหนดในรูปแบบโค้ดบางอย่าง คุณสามารถกำหนดว่า runtime ไหนที่คุณต้องการ, configuration file ต้องอยู่ที่ไหน และอื่น ๆ ในลักษณะที่สามารถถูกรันได้อย่าง deterministic ซ้ำแล้วซ้ำเล่าบนเครื่องเดียวกัน เพื่อให้แน่ใจว่ามันสามารถถูกนำไปสู่สถานะเดียวกันได้เสมอ
วิธีที่คนส่วนใหญ่สร้าง container คือการกำหนด Dockerfile สิ่งนี้ช่วยให้คุณกำหนดข้อกำหนดเดียวกันกับที่คุณจะทำกับ Puppet หรือ Chef พร้อมกับความแตกต่างบางอย่าง Container จะถูกทำลายเมื่อ redeploy ดังนั้นการสร้าง container แต่ละครั้งจึงทำจากศูนย์ (ผมกำลังทำให้เรื่องง่ายขึ้นเล็กน้อยตรงนี้) นี่หมายความว่าความซับซ้อนจำนวนมากที่มีอยู่ใน Puppet และ Chef เพื่อจัดการกับการที่เครื่องมือเหล่านั้นถูกรันซ้ำแล้วซ้ำเล่าบนเครื่องเดียวกันนั้นไม่จำเป็นอีกต่อไป
Puppet, Chef และเครื่องมือที่คล้ายกันยังคงมีประโยชน์อย่างเหลือเชื่อ แต่บทบาทของพวกมันตอนนี้ถูกผลักออกจาก container และลงไปลึกกว่าใน stack ผู้คนใช้เครื่องมือแบบนี้สำหรับจัดการแอปพลิเคชันและ infrastructure แบบ legacy หรือสำหรับสร้าง cluster ที่ container workload รันอยู่บนตอนนี้ แต่นักพัฒนามีแนวโน้มน้อยลงที่จะได้สัมผัสกับเครื่องมือเหล่านี้มากกว่าในอดีต
แนวคิดของ infrastructure as code ยังคงสำคัญมากอย่างยิ่ง เพียงแต่ประเภทของเครื่องมือที่นักพัฒนามีแนวโน้มจะใช้เปลี่ยนไป สำหรับผู้ที่ทำงานกับ cloud ตัวอย่างเช่น สิ่งอย่าง Terraform สามารถมีประโยชน์มากสำหรับการ provision cloud infrastructure เมื่อไม่นานมานี้ ผมกลายเป็นแฟนตัวยงของ Pulumi ซึ่งหลีกเลี่ยงการใช้ domain-specific language (DSL) โดยหันไปใช้ภาษาโปรแกรมปกติเพื่อช่วยนักพัฒนาจัดการ cloud infrastructure ของพวกเขาแทน ผมเห็นสิ่งใหญ่ ๆ รออยู่ข้างหน้าสำหรับ Pulumi เมื่อ delivery team รับเอาความเป็นเจ้าของโลก operational มากขึ้นเรื่อย ๆ และผมสงสัยว่า Puppet, Chef และเครื่องมือที่คล้ายกัน แม้พวกมันจะยังคงมีบทบาทที่มีประโยชน์ใน operations ต่อไป มีแนวโน้มที่จะเคลื่อนออกจากกิจกรรมการพัฒนาประจำวันมากขึ้นเรื่อย ๆ