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