میکروسرویسها ابزار سازمانیان، نه فنی
خلاصهٔ کاملتر
نویسنده با یه تناقض ساده شروع میکنه: تقریباً هیچ بحثی دربارهٔ معماری نرمافزار بدون حرف زدن از میکروسرویس تموم نمیشه، ولی با اینکه همه یه میکروسرویس رو وقتی میبینن تشخیص میدن، تقریباً هیچکس نمیتونه توضیح بده چی یه چیزی رو میکروسرویس میکنه. «میکرو» چقدر کوچیکه؟ یه سرویس باید فقط یه کار بکنه؟ سقف تعداد خط کد چقدره؟ به گفتهٔ نویسنده جواب قانعکنندهای وجود نداره، چون اصلاً جوابی وجود نداره.
نکتهٔ اصلی مقاله همینه: میکروسرویس در درجهٔ اول یه انتزاع فنی نیست. دلایلی که معمولاً برای فرار از مونولیت میارن — دیپلوی کند، تست طولانی، بیلد دردناک — مشکلات واقعیان، ولی هیچکدومشون به میکروسرویس نیاز ندارن و همهشون رو میشه همون داخل مونولیت بهتر کرد. پس چرا سازمانها مهاجرت میکنن؟ چون گلوگاه معمولاً فنی نیست، سازمانیه: دهها یا صدها مهندس باید مستقل کار کنن، مالکیت داشته باشن و بدون هماهنگی دائم با همه ریلیز بدن. میکروسرویسها مرزهایی میسازن که آینهٔ مرزهای سازمانیان.
هر سودی هم صورتحساب خودش رو داره. خودمختاری میگیری و تمرکز رو از دست میدی: تو مونولیت جواب دادن به سؤالایی مثل «چه وابستگیهایی داریم میفرستیم؟» یا «این تیکه کد هنوز استفاده میشه؟» با تحلیل استاتیک راحته، ولی وقتی کد بین دهها سرویس مستقل پخش شد، همون جوابها خیلی سختتر به دست میان. فراخوانی تابع تبدیل میشه به درخواست HTTP، خطای کامپایل تبدیل میشه به خطای زمان اجرا، و لتنسی و ریترای و شکست جزئی و ناسازگاری داده یکدفعه بخشی از اپلیکیشن خودت میشن.
یه هزینهٔ پنهانتر هم هست که نویسنده روش تأکید میکنه: فقط APIها با هم حرف نمیزنن، تیمها هم باید حرف بزنن. عوض کردن یه API دیگه ریفکتور نیست، مذاکرهست؛ مصرفکنندهها باید از قبل خبردار بشن، ورژنبندی لازم میشه و نسخههای قدیمی باید زنده بمونن تا همه مهاجرت کنن. به نظر نویسنده این حرف علیه میکروسرویس نیست — انتخاب درستی تو محیط درسته — ولی اگه مشکلت صرفاً فنیه، اول ببین سراغ راهحلی نرفتی که خیلی بزرگتر از خود مسئلهست.
نکات کلیدی:
- هیچ تعریف فنی روشنی برای «میکرو» بودن یه سرویس وجود نداره و تلاش برای پیدا کردنش بینتیجه بوده
- ارزش واقعی میکروسرویسها مقیاسپذیری سازمانیه: استقلال تیمها و ریلیز بدون هماهنگی
- دیپلوی کند و تست طولانی رو داخل مونولیت هم میشه حل کرد و به تنهایی دلیل مهاجرت نیستن
- با توزیعشدن کد، همهٔ مسائل سیستمهای توزیعشده وارد اپلیکیشن میشن
- تصمیمگیری هم توزیع میشه؛ تغییر API میشه یه مذاکرهٔ بینتیمی، نه یه کامیت ساده
