مونورپو یا پولیرپو؛ معماری کد در غولهای تکنولوژی
کمتر موضوعی در دنیای مهندسی نرمافزار اینقدر بحثبرانگیز است که جدال مونورپو در برابر پولیرپو باشد و بخش بزرگی از این حساسیتها بیمورد است. شواهد موجود از بزرگترین بازیگران صنعت، این موضوع را اثبات میکند: گوگل یکی از بزرگترین مونورپوهای جهان را اداره میکند و متا نیز از مونورپوهای عظیمی استفاده میکند، در حالی که آمازون، نتفلیکس و اسپاتیفای به محیطهای بسیار خدمتگرا و چندمخزنی معروف هستند. تمامی این شرکتها نرمافزارهای فوقالعادهای را در مقیاسهای عظیم عرضه میکنند. چیدمان مخزن کد به ندرت عامل اصلی موفقیت یا شکست یک تیم است.
انتخاب میان نگهداری تمام کدها در یک مخزن یا تقسیم آنها در مخازن جداگانه برای هر سرویس، همچنان یکی از سرنوشتسازترین تصمیماتی است که یک سازمان در آغاز پروژه میتواند بگیرد. این انتخاب، تجربه توسعهدهنده، پیچیدگی ادغام و تحویل مداوم، مقیاسپذیری و نحوه همکاری تیمها را شکل میدهد. تغییر رویکرد در مراحل بعدی معمولاً به معنای بازسازیهای پرهزینه و دردسرساز است. درک اینکه چرا غولهایی مانند گوگل و متا به فلسفه مونورپو متعهد شدند و چرا دیگران آگاهانه این کار را نکردند، بهترین راه برای درک این است که هر رویکرد واقعاً چه مشکلی را حل میکند.
تعریف دو فلسفه اصلی
مونورپو چیست؟
مونورپو یک مخزن کنترل نسخه واحد است که شامل چندین پروژه، سرویس یا کتابخانه است و تمام کدها از یک تاریخچه کامیت واحد استفاده میکنند. ویژگی تعیینکننده آن، اندازه نیست؛ بلکه این است که یک کامیت میتواند کد را در چندین پروژه بهصورت اتمیک تغییر دهد. وقتی شما یک کتابخانه مشترک را بهروزرسانی میکنید و تمام مصرفکنندگان آن در همان کامیت تغییر میکنند، این قدرت اصلی مونورپو است بر اساس تعاریف رایج مهندسی نرمافزار.
در عمل، یک مونورپو کدهای فرانتاند، سرویسهای بکاند، کتابخانههای کامپوننت مشترک، تنظیمات زیرساختی و مستندات تمام برنامههای شما را در یک ساختار مخزنی واحد جمع میکند. این کار یک مقصد واحد برای دسترسی به تمام بخشهای کد سازمان ایجاد میکند که کارهایی مانند استقرار تیمها و بهروزرسانی زنجیره ابزار را ساده میکند. البته مقیاس عظیم یک مونورپوی فعال میتواند فرآیندهای بیلد را کند کرده و پیچیدگی سیستمهای ادغام و تحویل مداوم را افزایش دهد.
پولیرپو چیست؟
پولیرپو کدبیس را به مخازن مستقل بسیاری تقسیم میکند که معمولاً برای هر سرویس، کتابخانه یا تیم یک مخزن در نظر گرفته میشود. هر مخزن تاریخچه، خط لوله ادغام و تحویل مداوم و اغلب کنترلهای دسترسی و قراردادهای خاص خود را دارد. این همچنین معماری پیشفرضی است که سازمانها بهصورت تصادفی به آن میرسند؛ هر بار که تیمی یک سرویس جدید راهاندازی میکند و فرمان ایجاد مخزن جدید را اجرا میکند، سازمان بیشتر به سمت پولیرپو حرکت میکند.
ویژگی تعیینکننده پولیرپو، استقلال تیمهاست. یک تیم میتواند ابزارهای خود را انتخاب کند، طبق زمانبندی خود نسخه جدید منتشر کند و بدون افشای هیچ بخش دیگری، دسترسی به مخزن خود را مدیریت کند. توسعه پولیرپو بهطور طبیعی با معماری میکروسرویس همسو است، جایی که توسعهدهندگان بدون تأثیرگذاری بر اجزای همسایه، بهطور مستقل روی هر سرویس کار میکنند.
رفع ابهام در اصطلاحات فنی
دو سردرگمی همواره تیمها را به بیراهه میبرد. اول اینکه، مونولیت با مونورپو کاملاً متفاوت است. مونولیت یک معماری نرمافزاری است؛ یک واحد قابل استقرار که در آن ماژولها از یک زماناجرای مشترک استفاده کرده و با هم عرضه میشوند. مونورپو یک چیدمان کنترل منبع است. شما میتوانید بسیاری از میکروسرویسها را در یک مونورپو اجرا کنید و یک مونولیت میتواند در چندین مخزن تقسیم شود. تفاوت اصلی در جفتشدگی زماناجرا و استقرار در مقابل سازماندهی کد و گردش کار است.
دوم اینکه، پولیرپو و مالتیرپو معمولاً به یک معنا هستند؛ کدبیسی که در چندین مخزن تقسیم شده است. عبارت پولیرپو بر تعداد زیادی مخزن کوچک با نسخهبندی مستقل تأکید دارد، در حالی که مالتیرپو برچسبی کلی برای هر تنظیمی است که بیش از یک مخزن دارد.
فلسفه مونورپوی گوگل و متا؛ مطالعه موردی استاندارد
گوگل نمونه شاخص معماری مونورپو در افراطیترین حالت آن است. این شرکت میلیاردها خط کد را در یک مخزن واحد ذخیره میکند که توسط دهها هزار توسعهدهنده استفاده میشود. این فقط یک تصمیم ذخیرهسازی نیست. این یک فلسفه معماری است که حول چندین باور اصلی ساخته شده است. تغییرات اتمیک و سراسری در این ساختار امکان بهروزرسانی یک رابط برنامهنویسی و اعمال همزمان آن در تمام سیستمهای وابسته را فراهم میکند. ابزارهای ساخت و تست اختصاصی گوگل اجازه میدهند تا تغییرات در مقیاس عظیم بدون توقف سرویسها اجرا شود.
متا نیز مسیری مشابه را در پیش گرفته است. با رشد سریع محصولات اجتماعی، متا به سرعت دریافت که مدیریت صدها مخزن جداگانه، کندی در انتقال تغییرات امنیتی و بهینهسازی مشترک، کاسه صبر تیمها را لبریز میکند. جمعآوری کدها در یک مخزن واحد، کشف و استفاده مجدد از کدهای بهینه را تسریع کرد. این شرکت نیز ابزارهای داخلی قدرتمندی برای مدیریت ادغام و تحویل مداوم در این محیط متمرکز توسعه داده است.
چرایی انتخاب پولیرپو در برخی غولهای تکنولوژی
با وجود موفقیت گوگل و متا، شرکتهایی مانند آمازون، نتفلیکس و اسپاتیفای عمدتاً از معماریهای چندمخزنی یا خدمتگرا استفاده میکنند. دلیل این انتخاب اغلب به تاریخچه شکلگیری سازمانها و استراتژی جذب و رشد برمیگردد. آمازون با استراتژی تفویض اختیار به تیمهای کوچک، از دههها پیش تیمهای مستقل را تشویق میکرد تا سرویسهای خود را با ابزارهای دلخواهشان توسعه دهند. این فرهنگ استقلال تیمی، به مرور منجر به ایجاد صدها مخزن مجزا شد.
نتفلیکس نیز با تمرکز بر پلتفرمهای ابری و میکروسرویسهایی که بهطور مستقل deploy میشوند، پولیرپو را به عنوان بستر طبیعی رشد انتخاب کرد. در این محیط، هر تیم مسئول نگهداری، تست و استقرار سرویس خود است. این مدل اگرچه هزینهی هماهنگی بینتیمی را بالا میبرد، اما سرعت انتشار سرویسها را در سطح جهانی افزایش میدهد. انتخاب بین این دو رویکرد، صرفاً یک بحث فنی نیست؛ بلکه بازتابی از فرهنگ سازمانی، مدل کسبوکار و استراتژیهای بلندمدت هر شرکت است.
نگاهی به آینده؛ معماری کد در سازمانهای مقیاسپذیر
مرزهای بین مونورپو و پولیرپو در سالهای اخیر بهوضوح کمرنگ شدهاند. سازمانهای هوشمند به جای چسبیدن به یک ایدئولوژی سختگیرانه، از ترکیبی از این دو رویکرد استفاده میکنند. استفاده از زیرساختهای ابری مدرن، کانتینرها و ابزارهای Orchestration امکان میدهد تا تیمها مستقل عمل کنند، در حالی که هستههای مشترک کد و کتابخانههای پایه در یک مخزن مرکزی مدیریت شوند.
آینده توسعه نرمافزار احتمالاً به سمت مونورپوهای پویا یا پولیرپوهای یکپارچه حرکت میکند؛ جایی که انتخاب معماری بر اساس نیازهای واقعی پروژه، نه ترند روز، صورت میگیرد. تیمهایی که امروز شروع به کار میکنند، باید به جای پرسیدن اینکه کدام مخزن مدرنتر است، بپرسند کدام مدل گردش کار را برای رشد 5 سال آیندهشان هموار میکند. انتخاب آگاهانه، تضمینکننده بقا و رشد پایدار هر کدبیسای خواهد بود.
