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

ประสบการณ์ของฉัน

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

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

ไม่เกี่ยวกับ Monolith หรือ Microservices

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

ไม่ควรมีองค์กรใดเห็นคุณค่าความจำเป็นในการจัดการทีมที่มีผู้คนน้อยเกินไป นำคำสั่งบางอย่างมาสู่มัน ระบบอัตโนมัติ การทดสอบ การให้อิสระและความยืดหยุ่นแก่ทีมในการเลือกเครื่องมือ และยังรักษาระเบียบวินัยและอีกมากมาย

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

ฉันจะแนะนำอะไร

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

1. คุณต้องมีกระบวนการที่มีประสิทธิภาพ (อัตโนมัติหรือไม่ก็ได้) เพื่อพัฒนาและปรับใช้แอปพลิเคชันของคุณในสภาพแวดล้อมต่างๆ และสามารถย้ายเวอร์ชันไปมาระหว่างกันได้
2. คุณต้องมีกระบวนการที่มีประสิทธิภาพเพื่อติดตามการเปลี่ยนแปลงซอร์สโค้ดของคุณกับสิ่งที่ถูกปรับใช้ในการผลิต
3. สุดท้ายและที่สำคัญที่สุด เมื่อเกิดปัญหาขึ้น คุณจะสามารถติดตามและติดตามสิ่งที่เกิดขึ้น ค้นหาส่วนประกอบที่เป็นสาเหตุของปัญหา แก้ไขจุดบกพร่องและทำความเข้าใจต้นตอได้อย่างมีประสิทธิภาพ จากนั้นมีกระบวนการที่จะเปิดตัว การเปลี่ยนแปลงเพื่อบรรเทาผลกระทบต่อผู้ใช้

ตอนนี้หากสถาปัตยกรรมแบบ monoliths และ/หรือ microservices สามารถช่วยจัดการปัญหาดังกล่าวได้ เมื่อพิจารณาจากข้อจำกัดขององค์กร ก็ดำเนินการตามนั้น คุณไม่ใช่ Google, Facebook, Microsoft, Amazon และพวกเขาไม่ใช่คุณ คุณไม่จำเป็นต้องเปรียบเทียบตัวเองกับองค์กรอื่นๆ ทันที ว่าใครฉลาดกว่า คล่องตัวกว่า หรือมีลักษณะใดลักษณะหนึ่งเหล่านี้

สิ่งที่คุณต้องทำคือการสร้างวัฒนธรรมที่ดีในองค์กรของคุณซึ่งเปิดกว้างสำหรับการสนทนาและเริ่มวัดผลสิ่งที่DORAแนะนำ:

• เวลาในการคืนค่าบริการ
• เปลี่ยนอัตราความล้มเหลว
• เวลานำสำหรับการเปลี่ยนแปลง
• ความถี่ในการปรับใช้

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