این روزا واژه‌ی میکروسرویس رو خیلی می‌شنویم. برای توسعه‌ی هرچیزی بدون شاید حتی ذره‌ای تفکر به خودمون می‌گیم این رویکرد معجزه میکنه. اما واقعیت اینه که میکروسرویس‌ها اونطوری که اکثر برنامه‌نویس‌ها و حتی مدیرها می‌بینن نیست.
اون‌ها قرار نیست همه‌ی مشکلات ساختاری و حتی فنی شما رو یکباره حل کنن. اما خب خیلی‌ها کورکورانه از این روش پیروی می‌کنن (شاید به امید معجزه. چیزی که خیلی از ما ها عادت کردیم بهش امید داشته باشیم). دقیقا مثل داستان‌های دیروزی که همه‌جا صحبت از Agile بود، امروز همه‌جا صحبت از میکروسرویس‌ها هست. اما خب تا سواد کافی نداشته باشیم، این‌ها راه حل نیستن، بلکه مشکلات ما رو دارن بیشتر می‌کنن.
هیچکس نمی‌تونه ادعا کنه میکروسرویس‌ها رویکرد بدی هستن. تا زمانی که درک کنیم قرار هست چه مشکلی رو حل کنن و اصلا چرا به وجود اومدن. طبیعتا با بررسی این جوانب (و شاید عواقب) می‌تونه راهکار خیلی خوبی هم باشه. هر معماری یک سری مزایا و طبیعتا یک سری پیامدهایی هم برای ما داره. ما بسته به نیازمون، با تجزیه و تحلیل موارد مربوط به سیستم خود و با همکاری سایر توسعه دهنده‌های تیم، معماری مورد نظرمون رو انتخاب می‌کنیم.
در خیلی از شرکت‌ها دیدگاه مدیریت این هست که وقتی یه سیستم بزرگ یکپارچه رو تکه تکه کنیم و اون رو تبدیل به تعدادی میکروسرویس کنیم، همه‌ی مشکلات توسعه، سرعت سیستم، کمبود بودجه‌ی شرکت، افزایش قیمت ارز و … به طور ناگهانی حل میشه و همه خوشحال می‌شن.
اما حقیقت اینه که چنین سطحی از انتزاع خیلی از پیامدها رو داره از دید ما پنهون میکنه. متاسفانه مدیران اکثر شرکت‌ها مفاهیم فنی رو درک نمی‌کنن و همچنین خیلی از ما برنامه نویسا هم توانایی توضیح مسائل فنی رو به یک غیر متخصص نداریم. از طرفی هم اکثر برنامه نویس‌ها بجای اینکه برای مشکلات فعلی راه حلی ارائه بدن، فقط علاقه دارن یه چیز جدید رو یاد بگیرن. بدون هیچ دلیلی سراغ یه تکنولوژی جدید میرن و تصور می‌کنن با کمک اون می‌تونن مشکلات سیستم رو رفع کنن. کاملا قبول دارم خیلی از مشکلات به مدیریت برمی‌گرده اما بهتره اول به خودمون هم نگاه کنیم.
همه‌ی ما گاها در چنین موقعیت‌هایی بودیم و تصورات غلطی داشتیم (من هم مستثنا نیستم).
مدیرها مستطیل‌های کوچیک میکروسرویس رو دوس دارن وقتی می‌بینن ما با چندتا خط اونارو به هم وصل می‌کنیم و داریم نحوه‌ی کارکرد سیستم رو بهشون توضیح می‌دیم. لبخندشون رو همه‌ی ما دیدیم. لبخندی که از هیچی سر در نمیاره. شب‌ها اون مستطیل ها رو خواب میبینه که قراره شرکتش رو نجات بدن…
نمیشه اونارو سرزنش کرد. نتیجه‌ی پیروی کورکورانه همینه. تیم فنی ماه‌ها تلاش میکنه تا اون میکروسرویس‌ها رو ایجاد کنن و در نهایت به مشکلاتی برخورد می‌کنن که اصلا انتظارش رو نداشتن.
سرویس‌های یکپارچه (monolith) ذاتا بد نیستن. میکروسرویس‌ها هم هیچوقت قرار نیست معجزه کنن.
چه زمانی نباید از میکروسرویس‌ها استفاده کنیم؟
اولین چیزی که باید یادمون بمونه اینه که اصلی ترین هدف استفاده از میکروسرویس‌ها سرعت تغییر و بروز رسانی هست.
دومین نکته اینه که میکروسرویس‌ها در واقع سیستم‌ها توزیع شده‌ای هستن که هرکدوم بخشی از وظایف یک بیزینس بزرگ رو دارن انجام میدن. پس مثل هر سیستم توزیع شده‌ی دیگه‌ای دارای معایبی مثل پیچیدگی، تاخیر شبکه (network latency)، خرابی احتمالی شبکه، کمبود احتمالی سرعت کارایی کل سیستم و … هم هست. هر کدوم از اینا یک مشکل نیستن. این‌ها رو در تعداد میکروسریس‌هاتون ضرب کنید تا به یک عدد دقیق تر برسید!
اگه سرعت تغییر برای شما مهم نیست، پیشنهاد میشه سراغ میکروسرویس‌ها نرید.
در دنیای مهندسی نرم افزار چیزای مهم تری وجود دارن. در مورد مفاهیم بخونید. برای استفاده از هر تکنولوژی دلیل قانع کننده‌ای داشته باشید. شما با یک سیستم یکپارچه هم می‌تونید سرعت کارایی برنامتون رو افزایش بدین. وقتی توانایی این رو ندارین که اون سیستم یکپارچه رو بهبود بدین و مدیریت کنید، لطفا دیگه حرفی از میکروسرویس‌ها نزنید.
آیا به الگوهای رایج معماری نرم افزار و میکروسرویس‌ها مسلط هستین؟ آیا شرکت شما توانایی استخدام افراد با تجربه در این زمینه رو داره؟ نه؟ پس از میکروسرویس‌ها استفاده نکنید!
با مدیریت صحبت کنین و پیامدهای احتمالی رو از نظر تجاری به اون‌ها توضیح بدین. اگه هزینه‌ی میزبانی (hosting) چندین میکروسرویس دو یا سه برابر هزینه‌ی فعلی بشه، آیا مدیریت بازهم سرعت تغییر براش مهمه؟ مدیریت مجموعه واقعا توانایی استخدام افراد جدید و با تجربه با حقوق بالا رو داره؟ بعد از این صحبت‌ها طبیعتا اون لبخند رضایت رو دیگه رو صورت مدیرتون نمی‌بینید.
نکته‌ی کلیدی مهم در اینجا بازگشت سرمایه (ROI) هست. یک کسب و کار روی پول، زمان، افراد و منابع سرمایه گذاری میکنه و انتظار داره در قبالش چیزی بدست بیاره (طبیعتا پول). این یعنی بیزینس.
بدون در نظر گرفتن چنین مواردی، باید انتظار ورشکستگی یک کسب و کار رو داشته باشیم.
ما به عنوان برنامه نویس، اکثرا این موارد رو فراموش می‌کنیم (یا حتی اصلا به چشممون نمیاد). تنها فکر ما کدهایی هست که می‌نویسیم. اینکه چطور کیفیت کد رو بالاتر ببریم؟ کد کدوم همکارمون بو میده؟ از چه دیزاین پترنی استفاده کنیم؟ جدیدترین فریم ورکی که اومده چیه؟ با خودمون می‌گیم تنها چیزی که مهمه تکنولوژیه. تیم مدیریت، بازاریابی، فروش و … از هیچی سر در نمیارن و فقط یه مشت احمقن.
فراموش می‌کنیم که بدون وجود یک کسب و کار در واقع کد هم مهم نیست. اداره‌ی یک کسب و کار چیزی فراتر از کدهایی هست که ما می‌نویسیم.
وظیفه‌ی ما به عنوان یک توسعه دهنده یا برنامه نویس (یا هرچیز دیگه‌ای که می‌خوایید اسمش رو بذارید)، ایجاد سیستم‌هایی هست که نیاز یک کسب و کار رو رفع کنه. بخشی از این وظیفه‌ی ما، انتخاب راه حل مناسب برای شرایط خاصی است که با اون روبرو هستیم.
هیچ راه حل کامل و بی نقصی برای تمام مشکلات نرم افزاری وجود نداره. پس همیشه بررسی‌های دقیقی حول یک مسئله انجام بدین و در نهایت راه حلی رو ارائه بدین که برای شرکت مفیده؛ نه فقط برای حس کنجکاوی شما! اگه نتیجه‌ی بررسی هاتون استفاده از میکروسرویس‌ها هست، خب به سراغش برید، کسی جلوتون رو نمی‌گیره.
کلام آخر اینکه، حرف مادرتون رو یادتون نره: «اگه همه‌ی دوستات بخوان بپرن تو چاه، تو هم میپری؟»
