ฉันจะมั่นใจได้ถึงความสอดคล้องระหว่างไมโครไซต์ใหม่ได้อย่างไร

องค์กรของฉันกำลังประสบกับการระเบิดของ microservices ขณะนี้เราไม่มีวิธีที่เป็นทางการในการเริ่มต้นโครงการใหม่ ฉันพบว่าทีมจะมาหาฉันพร้อมกับข้อบกพร่องในการปรับใช้หรือสร้างกระบวนการและฉันจะใช้เวลากับมันเท่านั้นที่จะตระหนักว่าฉันได้แก้ไขมันแล้วในโครงการอื่น นอกจากนี้ยังมีความไม่สอดคล้องกันระหว่างโครงการที่ฉันต้องการเห็นเป็นมาตรฐาน

การเปลี่ยนแปลงมักจะเกี่ยวข้องกับไฟล์เดียว (เช่น serverless.yml หรือ Makefile) ดังนั้นการแก้ปัญหาที่เกี่ยวข้องกับไลบรารีที่ใช้ร่วมกันเช่น submodules git ดูเหมือนจะไม่สามารถใช้งานได้ แต่ละโครงการจะมีชุดการกำหนดค่าของตัวเองที่จำเป็นต้องดูแลรักษาเช่น Dockerfiles หรือ serverless.yml ดังนั้นโซลูชันการจัดการการกำหนดค่าส่วนกลางสำหรับ VM จึงไม่สามารถใช้งานได้จริง

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

เวิร์กโฟลว์ปัจจุบันที่เรามีคือการถามคนที่อยู่ถัดจากคุณ "ฉันควรโคลนโครงการใดเพื่อใช้เป็นเทมเพลต" จากนั้นลบทุกสิ่งที่ไม่จำเป็นสำหรับโครงการนั้น

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

เพื่อแก้ไขปัญหาของการไม่มีฐานที่สอดคล้องกันในการสร้างโครงการสำหรับความคิดของฉันคือการสร้างพื้นที่เก็บข้อมูล (repositories?) ของ boilerplates / แม่แบบและใช้cookiecutterเป็นเครื่องมือในการกระจาย microservices ใหม่ ด้วยวิธีนี้แต่ละโครงการถูกสร้างขึ้นจากฐานมาตรฐานพร้อมบทเรียนทั้งหมดที่เราได้เรียนรู้ในฐานะองค์กรที่รวมเข้ากับมัน การเปลี่ยนแปลงใด ๆ ที่เราทำสามารถรวมเข้าไว้ในที่เก็บไอน้ำ ฉันคิดว่าเราจะมีเทมเพลตสำหรับภาพ Nodejs Docker, Serverless SPAs, Python lambdas เป็นต้น

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

ใช้การจัดการการกำหนดค่า / ระบบการปรับใช้อัตโนมัติ นี่คือสิ่งที่ถูกออกแบบมาสำหรับ สิ่งต่าง ๆ เช่น Kubernetes, Puppet, Chef, Ansible และ Salt Stack ได้รับการออกแบบมาเพื่อจุดประสงค์นี้และสามารถใช้กับเทมเพลต Golden Master, สคริปต์ kickstart, Amazon AMIs หรือเพียงแค่ Docker container สิ่งนี้ช่วยให้คุณใช้แม่แบบฐานเริ่มต้นแล้วเลเยอร์ในบทบาทเพิ่มเติม สิ่งนี้จะทำให้มั่นใจว่าบิลด์นั้นมีการบันทึกไว้อย่างสมบูรณ์ (เป็นรหัส) และมันจะรวดเร็วและง่ายต่อการปรับใช้กับการผลิตและจะถูกนำไปใช้งานเหมือนกับสิ่งที่ถูกออกแบบหรือปรับใช้อินสแตนซ์เพิ่มเติมเมื่อความต้องการ การเปลี่ยนแปลง / การอัพเดทสามารถรวมเข้าด้วยกันได้ เช่นเดียวกับที่คุณปล่อยการอัปเดตซอฟต์แวร์ คุณสามารถปล่อยการอัปเดตการกำหนดค่าของคุณและรหัสการกำหนดค่าสามารถจัดการได้เช่นเดียวกับรหัสซอฟต์แวร์ของคุณที่มีการจัดการ - ใน repos เดียวกันและมีเวิร์กโฟลว์เดียวกัน และเมื่อถึงเวลาอัพเกรดไม่มีสิ่งลึกลับที่สร้างขึ้นเพียงดูที่สคริปต์

วิธีหนึ่งที่ระบบการจัดการการกำหนดค่าทำได้โดยใช้การสร้างเทมเพลตสำหรับไฟล์การกำหนดค่าของคุณอย่างหนัก ตัวอย่างเช่นโดยทั่วไปมีหลายบรรทัดที่จะเหมือนหรือคล้ายกันในสภาพแวดล้อมของคุณ SaltStack ใช้Jinjaแม่แบบและการใช้งานหุ่นฝังตัวแม่ทับทิม การใช้ AWS เป็นตัวอย่างคุณอาจต้องตั้งค่า, คีย์ api, บทบาท IAM, ภูมิภาค (หรือเลือกภูมิภาคจากรายการภูมิภาคแบบสุ่ม), VPC, ฯลฯ ที่เหมือนกันในทุกกรณี แต่คุณต้องมีฟังก์ชั่นและเอาต์พุตที่ไม่ซ้ำใคร หรือดีกว่านั้นคุณสามารถเขียนโมดูลหุ่นเชิดหรือสูตรเกลือซึ่งกำหนด "สัญญา" และใช้สัญญาเหล่านั้น (คำจำกัดความ api) สำหรับทั้งอินพุตและเอาต์พุตช่วยให้คุณประหยัดจากการกำหนดค่าไมโครไซต์ของคุณสองหรือสามแห่ง

SaltStack ตัวอย่างเช่นเมื่อเร็ว ๆ นี้มีการพบปะเพื่อหารือเกี่ยวกับเรื่องนี้สถานการณ์โดยเฉพาะอย่างยิ่ง นอกจากนี้ SaltStack ยังสามารถจัดการและปรับใช้คอนเทนเนอร์นักเทียบท่าได้ด้วย (หุ่นกระบอกนอกจากนี้ยังมีโมดูลสำหรับเทียบท่า ) ในทำนองเดียวกันเบิ้ลมี playbooks และเอกสารสำหรับการทำงานกับการใช้งาน serverlessและหาง ตู้คอนเทนเนอร์

นอกจากนี้หากคุณต้องการดำเนินการกับธีม / กระบวนทัศน์เซิร์ฟเวอร์หุ่นกระบอกAnsibleและSaltstackทั้งหมดของคุณจะไม่เป็นผู้เชี่ยวชาญหรือสนับสนุนโหมดที่ไม่เชี่ยวชาญหากคุณต้องการดำเนินการกับธีมนี้ต่อไป

คำถามนี้กว้างดังนั้นหากคำตอบของฉันเล็กน้อยนอกฐานสามารถเพิ่มบริบทและตัวอย่างเฉพาะเพื่อให้ฉันมีความเข้าใจที่ดีขึ้น

การใช้อิมเมจเครื่องเช่น AWS 'AMI จะช่วยให้คุณสร้างภาพฐานหรือสีทองซึ่งคุณสามารถรักษาและแจกจ่ายหรือนำไปใช้ในการจัดส่งต่อเนื่องของคุณ การใช้สถาปัตยกรรมนี้คุณจะมั่นใจได้ว่า microservice ทุกตัวจะถูกปรับใช้บนฮาร์ดแวร์ที่สอดคล้องกับการกำหนดค่าที่เหมือนกันดังนั้นปัญหาใด ๆ ที่คุณประสบเกี่ยวข้องกับการกำหนดค่า microservice / application

คุณสามารถเพิ่มเติมความไม่สามารถเปลี่ยนแปลงได้ด้วยการเพิ่มเครื่องมือกำหนดค่าเช่น Ansible และ Packer การใช้การจัดการการกำหนดค่าคุณสามารถจัดเตรียมอิมเมจเครื่องด้วยสิ่งที่คุณต้องการ (รวมถึงแอปพลิเคชัน) จากนั้น Packer จะอนุญาตให้คุณถ่ายภาพของอิมเมจเครื่องนั้นและการปรับใช้แต่ละครั้งจะเหมือนกัน

การใช้ตัวอย่างนี้คุณสามารถ 'อบ' AMI พื้นฐานด้วยแพ็คเกจที่ถูกต้องอัพเดตและกำหนดค่าที่ติดตั้งด้วยความช่วยเหลือของ Ansible และ Packer นอกจากนี้คุณสามารถดู 'Ansible-Pull' เพื่อทำการปรับใช้ให้สมบูรณ์โดยการดึงรหัสแอปพลิเคชันทำการเปลี่ยนแปลงใด ๆ และปรับใช้ microservice ที่ด้านบนของภาพฐานนั้น

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

ฉันอยู่กับสามองค์กรและเราใช้วิธีที่แตกต่างกันสามวิธี

โชคดี!