احتمالا بسیاری از شما نام معماری Micro Service را شنیده‌اید. در این یادداشت کوتاه این عبارت را خدمت‌های کوچک ترجمه کردم. البته به ذهنم رسید که شاید خدمت‌های کوچک به هم پیوسته هم ترجمه بامزه‌تری باشد اما در نهایت این یکی مختصرتر بود.
مساله‌ای که می‌خواهم راجع به آن صحبت کنم نه در مورد مفاهیم مربوط به معماری مبتنی بر خدمت‌های کوچک است و نه مزایا و معایب آن. در مورد این موارد با یک جستجوی ساده در اینترنت می‌توانید دانش خود را افزایش دهید. موضوع درباره‌ی این است که چه زمانی بهتر است از این روش برای توسعه نرم‌افزار و ارائه خدمت بهره ببریم.
با توجه به اینکه سرعت رشد نرم‌افزار در جهان فعلی به شدت بالا است، به طور معمول توسعه‌دهنده‌های نرم‌افزار در مقابل اصطلاحات و روش‌های جدید، هیجان‌زده می‌شوند و همین باعث استفاده‌های بی‌حاصل و غیرضروری از روش‌های جدید توسعه و انتشار نرم‌افزارها شود. نمونه قابل لمس این موضوع را می‌توان در فضای توسعه روساخت وب مشاهده کرد. هر روز تکنولوژی‌ها و چهارچوب‌های توسعه‌ی جدیدی ارائه می‌شوند و توسعه‌دهندگان، هیجان‌زده از این ابزارها، از شاخه‌ای به شاخه‌ی دیگر در حال حرکت هستند.
در ادامه به اختصار تجربه‌ی اندک خودم را در حوزه شاخص‌هایی که باید در زمان انتخاب معماری خدمت‌های کوچک جلوی چشم داشته باشیم، با شما به اشتراک می‌گذارم.
بسیار پیش می‌آید که توسعه‌دهنده‌ها و معماران نرم‌افزار بدون توجه به مقیاس محصول، یک معماری آرمانی برای محصول نهایی را پیشنهاد می‌دهند. دقت کنید که معماری مبتنی بر خدمت‌های کوچک زمانی بهینه است که شما یک محصول با مشتری مقیاس متوسط یا بزرگتر از آن را پیش رو داشته باشید. در صورتی که مقیاس مشتری و به طبع آن محصول در حال توسعه، کوچک باشد، استفاده از معماری مبتنی بر خدمت‌های کوچک تنها هزینه تولید و به ثمر رساندن محصول را بیشتر می‌کند و از قضا در مواقعی ممکن است سرعت به روزرسانی و رفع نیازمندی‌های مشتری را نیز به نسبت یک معماری تک خدمتی، کندتر کند.
این موضوع از جمله‌ی مواردی است که باید در زمان استفاده از معماری‌های مبتنی بر خدمت‌های کوچک به خوبی تحلیل و ارزیابی شده باشد. معماری مبتنی بر خدمت‌های کوچک، دانش گسترده‌ای در حوزه‌ی ابزارهای مختلف برای مکانیزم‌های ارتباط بین خدمت‌ها، راه‌اندازی، انتشار، بروزرسانی و ... را نیاز دارد. اگر خودتان و یا تیم‌تان چندان تجربه‌ای در این حوزه ندارید، استفاده از این روش برای شما سردرد بسیاری خواهد داشت. چه آن‌که محصول نهایی نیز با آسیب‌پذیری‌های عملکردی و غیرعملکردی بسیار زیادی نیز مواجه خواهد شد.
معماری مبتنی بر خدمت‌های کوچک در ذات خود همراه با انجام کارهای بیشتر در زمان انتشار نسخه‌ی اولیه است. اگر صاحبان سرمایه‌ی محصول حوصله‌ی کمی برای انتشار نسخه‌ی اول محصول را دارند، این معماری به احتمال خوبی شما را با شکست مواجه می‌کند. شاید بهتر باشد نسخه‌ی اولیه را در قالب یک اثبات ادعا، با معماری ساده‌تری آماده کرده و در نسخه‌های بعدی نسبت به تغییر گام به گام معماری اقدام کنید.
تیم‌های توسعه نرم‌فزار، خاصه جوان‌ترها، معمولا دنبال کسب تجربه‌های جدید و بهبود رزومه کاری خود هستند. اما یک تفکر بالغ، از فرصت‌های پیش آمده در مسیر کاری خود، همزمان برای کسب تجربه و البته ارائه‌ی بهینه و کم‌هزینه محصول به مشتری استفاده می‌کند. پس پیش از آن‌که نگاهتان به رزومه کاری خودتان باشد، راه درست و بهینه برای توسعه محصول مورد نظر را پیدا کنید. مطمئن باشید که فرصت کسب تجربه در زمان مناسب و روی محصول مناسب را کسب خواهید کرد.
اگر تمامی موارد ذکر شده در بالا، که البته هر کدام را می‌توان ساعت‌ها بسط و نشر داد، را بررسی کردید و همچنان خدمت‌های کوچک را مناسب‌ترین گزینه برای توسعه محصول نهایی ارزیابی کردید، حالا وقت آن است که دست به کار شوید. ابزارهای توسعه‌ی اشتراکی را راه بیاندازید، مکانیزم‌های یکپارچه‌سازی و انتشار مداوم را مستحکم کنید. فرآیند‌های بهینه برای توسعه‌ی اشتراکی نرم‌افزار را با تیم‌تان قرارداد کنید و کار را شروع کنید.
پی‌نوشت
این یادداشت قبل‌تر در لینکداین منتشر شده بود و ترجیح دادم در اینجا هم برای ماندگاری بیشتر ذخیره‌اش کنم.
