عنوان سخنرانی: Architecture Isn’t Kubernetes
سخنران: Diana Montalion
رویداد: همایش بینالمللی GOTO 2024
:لینک ویدیو http://www.youtube.com/watch?v=v50oJao8W1Y
مقدمه:
در سیستم پرشتاب توسعه نرمافزار مدرن، ظهور ابزارهای قدرتمند زیرساختی و دواپس تحولات شگرفی در نحوه استقرار و نگهداری سیستمها ایجاد کرده است. با این حال، این پیشرفت ابزاری منجر به شکلگیری یک خطای شناختی بزرگ در میان تیمهای مهندسی شده است و آن هم این است که تقلیل دادن مفهوم پیچیده معماری نرمافزار به پیکربندی زیرساخت ابری.
دایانا مونتالیون در سخنرانی خود در همایش GOTO 2024، با انتخاب عنوان معماری کوبرنتیز نیست، به نقد این جریان فکری میپردازد. او استدلال میکند که استقرار کدهای درهمتنیده بر روی کلاسترهای توزیعشده، مشکلات ساختاری سیستم را حل نمیکند، بلکه صرفاً آنها را از سطح کد به سطح شبکه منتقل میسازد. در این توضیح، به کالبدشکافی استدلالهای مطرح شده در این سخنرانی پرداخته و تفاوتهای بنیادین میان طراحی سیستم و مدیریت زیرساخت را از منظر تفکر سیستمی تحلیل خواهیم کرد.
توهم معماری از طریق ابزارگرایی - The Illusion of Architecture Through Tooling
نقطه آغاز و محور اصلی این سخنرانی، نقد پدیدهای است که میتوان آن را سندرم گلوله نقرهای زیرساخت نامید. زمانی که سازمانها با مشکلاتی نظیر کاهش کارایی، سختی در افزودن ویژگیهای جدید یا کندی در فرآیند استقرار مواجه میشوند، اغلب به جای بازنگری در طراحی دامنه و مرزبندیهای منطقی کدهای خود، به ابزارهایی مثل کوبرنتیز پناه میبرند.
سخنران واضحا میگوید که کوبرنتیز یک پلتفرم ارکستریشن کانتینر فوقالعاده است، اما وظیفه آن حل مشکلات مربوط به محل و نحوه اجرای کد است، نه منطق و نحوه تعامل اجزای نرمافزار. اگر ما یک معماری مونولیت بدساخت با وابستگیهای شدید متقابل یا به اصطلاح Tight Coupling داشته باشیم و آن را درون کانتینرهای داکر قرار داده باشیم و با کوبرنتیز مدیریت کنیم، ما یک معماری میکروسرویس خلق نکردهایم؛ بلکه یک مونولیت توزیعشده (Distributed Monolith) ساختهایم. این رویکرد نه تنها مشکلات قبلی را برطرف نمیکند، بلکه چالشهای جدیدی مثل تاخیر شبکه، پیچیدگی در ردیابی خطاها و سربار ارتباطات بینسرویسی را نیز به سیستم تحمیل میکند.
تقابل تفکر خطی با تفکر سیستمی - Linear vs Systems Thinking
بخش عمیقتر این ارائه، ریشهیابی این خطای شناختی در الگوهای تفکر مهندسان است. مونتالیون تفاوت میان تفکر خطی و تفکر سیستمی را به عنوان مرز جداکننده برنامهنویسان و معماران معرفی میکند. در تفکر خطی، سیستم به عنوان مجموعهای از قطعات مجزا دیده میشود که به صورت ترتیبی کار میکنند یعنی الف باعث ب میشود، ب باعث ج میشود. در این دیدگاه، اگر قطعهای کند باشد، راهکار خطی این است که منابع سختافزاری آن مثل CPU یا RAM از طریق ابزارهایی مثل کوبرنتیز افزایش پیدا کند.
اما در مقابل، تفکر سیستمی تأکید دارد که ویژگیهای کلیدی یک سیستم مثل مقیاسپذیری و تابآوری از درون تعاملات بین اجزا نشأت میگیرد، نه از خود اجزا به تنهایی. معماری نرمافزار علم طراحی این تعاملات است. اگر ماژول ثبت سفارش برای انجام کار خود به شدت نیازمند فراخوانی همزمان ماژولهای انبار و پرداخت باشد، اضافه کردن pods جدید در کوبرنتیز مشکل گلوگاه گلوگاه ارتباطی را حل نخواهد کرد. معمار باید با تفکر سیستمی، جریان اطلاعات و تعاملات ناهمگام را طراحی کند تا وابستگیها در سطح منطقی کاهش یابند.
جریان دانش و مرزبندیهای دامنه - Knowledge Flow and Domain Boundaries
یکی دیگر از مفاهیم کلیدی مطرح شده در این سخنرانی، اولویت دادن به جریان دانش بر جریان داده است. طراحی نرمافزار باید بازتابی از نحوه جریان یافتن قوانین کسبوکار در سازمان باشد. سخنران با ارجاع به مفاهیم طراحی دامنه-محور (DDD)، تأکید میکند که معماری اصیل زمانی شکل میگیرد که مرزهای مشخصی بین حوزههای مختلف سیستم تعریف شود.
در نبود مرزبندیهای منطقی صحیح، دادهها در سراسر سیستم نشت میکنند و سرویسها برای انجام سادهترین وظایف به دادههای یکدیگر وابسته میشوند. در چنین سناریویی، ابزارهای مدیریت استقرار کاملاً ناتوان هستند. معماری واقعی نیازمند کشف مفاهیم پنهان در کسبوکار، تفکیک مسئولیتها و تعیین استراتژیهای ارتباطی است. کوبرنتیز تنها زمانی میتواند ارزش واقعی خود را نشان دهد که بر روی یک بستر معماری شده و منطقاً تفکیک شده، مستقر گردد.
بحران بار شناختی برای تیمهای توسعه - Cognitive Load Crisis
بخش پایانی سخنرانی به تأثیرات مخرب ابزارگرایی بر روی بهرهوری تیمهای مهندسی میپردازد. زمانی که مرز بین معماری سیستم و زیرساخت محو میشود، توسعهدهندگان نرمافزار مجبور میشوند برای نوشتن یک قابلیت ساده تجاری، با مفاهیم پیچیده شبکهسازی، فایلهای حجیم YAML، و تنظیمات ارکستریشن درگیر شوند.
این امر منجر به افزایش شدید بار شناختی یا همان Cognitive Load میشود. توسعهدهنده به جای تمرکز بر روی حل مسئله کسبوکار و بهبود کیفیت کد، انرژی ذهنی خود را صرف یادگیری و رفع خطای ابزارهای زیرساختی میکند. مونتالیون استدلال میکند که یک معماری خوب باید زیرساخت را از دید برنامهنویس پنهان کند تا تیمها بتوانند با حداکثر سرعت، ارزش تجاری تولید کنند.
برداشت و تحلیل من از مباحث سخنرانی
تحلیل عمیق و منطقی استدلالهای مطرح شده در این ارائه، حقایق مهمی را درباره بلوغ مهندسی نرمافزار آشکار میکند.
اولین استدلال من این است که فناوریها و ابزارهای استقرار هرگز نمیتوانند جبرانکننده ضعف در طراحی مفهومی باشند. وقتی سازمانی تلاش میکند با استفاده از کوبرنتیز، سیستمی با وابستگیهای منطقی بالا را مقیاسپذیر کند، در واقع در حال درمان Symptoms است، نه خود بیماری. بیماری اصلی در لایه معماری منطقی و نحوه تفکیک دامنهها نهفته است.
دومین محور تحلیلی، ضروری بودن تفکیک دغدغهها در سطح کلان سازمانی است. این سخنرانی به لحاظ منطقی اثبات میکند که مهندسی پلتفرم یا زیرساخت و معماری نرمافزار، دو دیسیپلین کاملاً مجزا با اهداف متفاوت هستند. هدف مهندسی زیرساخت، فراهم کردن محیطی امن، مقیاسپذیر و خودکار برای اجرای کد است؛ در حالی که هدف معماری نرمافزار، سازماندهی کدها و دادهها به گونهای است که سیستم در برابر تغییرات تجاری منعطف بماند. ترکیب این دو مفهوم باعث ایجاد سیستمهایی میشود که از نظر زیرساختی مدرن به نظر میرسند، اما از نظر تغییرپذیری و نگهداری نرمافزاری کاملاً فلج هستند.
در نهایت، تأکید بر تفکر سیستمی به جای تمرکز بر ابزارها، یک تغییر الگو ضروری برای تیمهای توسعه مدرن است. معماری یک عمل Reductionist نیست که در آن با بهبود یک سرور یا یک کانتینر، کل سیستم بهبود یابد. کیفیت سیستم در گرو طراحی صحیح ارتباطات میان گرههاست.
به طور خلاصه، این سخنرانی یک نقد ساختارمند و کاملاً مهندسیشده بر استفاده بیرویه از ابزارهای ابری است. و پیام آن روشن است: قبل از آنکه نگران نحوه اجرای کد خود در یک کلاستر کوبرنتیز باشیم، باید نگران نحوه سازماندهی منطق تجاری در درون کدهای خود باشیم. معماری، طراحی بستر نیست؛ معماری طراحی ماهیت و ذات سیستم است.
منابع و مراجع:
· ویدیو و اسلایدهای ارائه Architecture Isn’t Kubernetes در همایش GOTO 2024
· مفاهیم پایه تفکر سیستمی در مهندسی نرمافزار
· اصول طراحی دامنه-محور و تأثیر آن بر معماری
· این مطلب، بخشی از تمرین درس معماری نرمافزار در دانشگاه شهیدبهشتی است.
