سخنران: Ian Cooper
رویداد: GOTO Copenhagen 2024
لینک ویدئو: https://www.youtube.com/watch?v=j2AQ9eTZ3-0
اگر در ده سال گذشته در صنعت نرمافزار کار کرده باشید، تقریباً غیرممکن است که با موج میکروسرویسها برخورد نکرده باشید؛ موجی که با وعده استقلال تیمها، استقرار مستقل و مقیاسپذیری بیپایان شروع شد و در بسیاری از سازمانها به سیستمهایی پیچیده، کند و شکننده ختم شد. یان کوپر در این سخنرانی سراغ سوالی میرود که خیلی از ما جرئت پرسیدنش را نداشتیم: کجای راه را اشتباه رفتیم؟ نکته جذاب این است که کوپر مخالف میکروسرویس نیست؛ او مدافع نسخه «درست» این ایده است و دقیقاً به همین دلیل نقدش شنیدنی از آب درآمده است.
کوپر بحث را با تاریخچه شروع میکند و نشان میدهد میکروسرویسها از خلأ نیامدهاند؛ ریشه آنها در SOA، در ایده Bounded Context از طراحی دامنهمحور (DDD) و در نیاز سازمانهای بزرگی مثل آمازون و نتفلیکس به مقیاسدادن «سازمان» است، نه صرفاً نرمافزار. تعریف کلاسیک جیمز لوئیس و مارتین فاولر هم همین را میگوید: سرویسهایی که حول قابلیتهای کسبوکار شکل میگیرند و بهطور مستقل قابل استقرارند. مشکل از جایی شروع شد که صنعت این «چرا» را فراموش کرد و فقط «چطور» را کپی کرد.
به روایت کوپر، بزرگترین خطای رایج، تفسیر واژه «میکرو» بهمعنای «هرچه کوچکتر بهتر» بود. تیمها بهجای تقسیم سیستم بر اساس مرزهای دامنه، آن را بر اساس موجودیتهای دادهای (Entity Service) خرد کردند: سرویس مشتری، سرویس سفارش، سرویس محصول؛ سرویسهایی بیرفتار و صرفاً CRUD که برای انجام هر کار معناداری باید با هم صحبت کنند. نتیجه این کار همان چیزی است که کوپر و دیگران «مونولیت توزیعشده» مینامند: سیستمی که همه اتصالات و وابستگیهای یک مونولیت را دارد، اما بهجای فراخوانی تابع در حافظه، از شبکه با همه خطاها، تأخیرها و پیچیدگیهایش عبور میکند. به تعبیر خود او، ما پیچیدگی را حذف نکردیم؛ فقط آن را از داخل کد به بین سرویسها منتقل کردیم، جایی که دیدن و دیباگکردنش بهمراتب سختتر است.
نکته کلیدی دیگر سخنرانی، هزینه عملیاتی این سبک معماری است: زیرساخت مشاهدهپذیری، ردیابی توزیعشده، سازگاری نهایی (Eventual Consistency)، تراکنشهای توزیعشده و بار شناختی سنگینی که روی تیمها میگذارد. راهحل پیشنهادی کوپر بازگشت به اصول است: سرویسها را حول Bounded Contextها طراحی کنید، از دانهبندی درشتتر شروع کنید و اگر مقیاس سازمانیتان ایجاب نمیکند، اصلاً با یک مونولیت ماژولار شروع کنید که مرزهای داخلی تمیزی دارد و در آینده قابل تفکیک است.
چیزی که این سخنرانی را برای من متمایز میکند، صداقت تاریخی آن است. کوپر نمیگوید میکروسرویس بد است، بلکه میگوید میکروسرویس پاسخ به یک مسئله مشخص است: وقتی تعداد تیمها آنقدر زیاد شده که هماهنگی برای استقرار مشترک، گلوگاه سازمان شده است. اگر این مسئله را ندارید، دارید هزینه راهحل مسئله دیگران را میپردازید. به نظرم عمیقترین درس سخنرانی این است که معماری پیش از آنکه تصمیمی فنی باشد، تصمیمی سازمانی است؛ همان چیزی که قانون کانوی سالهاست به ما یادآوری میکند. تجربه خودم هم همین را تأیید میکند: تیمهای پنجنفرهای که بیست سرویس را نگهداری میکنند، عملاً بیشتر وقتشان صرف زیرساخت میشود تا ارزش کسبوکار.
این سخنرانی برای دو گروه کاربرد مستقیم دارد. گروه اول تیمهایی هستند که در آستانه شروع پروژه جدیدند: پیش از انتخاب میکروسرویس، صادقانه بپرسید چند تیم دارید، چند بار در روز نیاز به استقرار مستقل دارید و آیا زیرساخت مشاهدهپذیری و CI/CD بالغی دارید یا نه. اگر پاسخها منفی است، مونولیت ماژولار با مرزهای دامنهای روشن (مثلاً بهکمک تفکیک ماژولها و قراردادهای داخلی صریح) انتخاب عاقلانهتری است. گروه دوم سازمانهایی هستند که الان در باتلاق مونولیت توزیعشده گیر کردهاند: مسیر پیشنهادی، ادغام سرویسهای ریز و پرگفتوگو در واحدهای درشتتر همراستا با دامنه است؛ حرکتی که برخلاف تصور، معمولاً هم کارایی را بهتر میکند و هم سرعت توسعه را.
«Microservices, Where Did It All Go Wrong» یک تسویهحساب صادقانه با پرهیاهوترین ترند معماری دههٔ اخیر است. درسهای کلیدی آن روشناند: میکروسرویس ابزار مقیاسدادن سازمان است نه مد روز؛ مرز سرویس باید مرز دامنه باشد نه مرز جدول پایگاه داده؛ و کوچکبودن بهخودیخود فضیلت نیست، استقلال در تغییر و استقرار فضیلت است. اگر فقط یک ویدیو دربارهٔ میکروسرویس میخواهید ببینید، بگذارید همین باشد؛ چون بهجای فروختن رؤیا، به شما یاد میدهد چه سؤالهایی بپرسید.
اين مطلب، بخشی از تمرينهای درس معماری نرمافزار در دانشگاه شهيد بهشتی است.
