پنج کنفرانس جدید معماری نرم‌افزار

Building Distributed Applications with Event Driven Architecture • Eric Johnson • GOTO 2023

سخنران: Eric Johnson، توسعه‌دهنده ارشد در AWS
لینک: https://youtu.be/9StQpMLC-5Q?si=4RVsEkYcFtsd1SET

در این ویدیو، اریک جانسون، چالش‌ها و بهترین شیوه‌های ساخت برنامه‌های توزیع‌شده با معماری Event Driven (EDA) را بررسی می‌کند. او ابتدا EDA را تعریف می‌کند و مزایای آن را، مانند وابستگی ضعیف، مقیاس‌پذیری و پایداری، توضیح می‌دهد.

سپس انواع وابستگی را، از جمله وابستگی فناوری (technology dependency)، وابستگی داده (data dependency) و وابستگی مکان (location dependency)، مورد بحث قرار می‌دهد. او اهمیت کاهش وابستگی در سیستم‌های توزیع‌شده را برای بهبود انعطاف‌پذیری و قابلیت نگهداری تأکید می‌کند.

در ادامه، مفهوم Asynchronous communication را معرفی می‌کند که یکی از جنبه‌های کلیدی EDA است. او توضیح می‌دهد که چگونه Asynchronous communication می‌تواند به جداسازی سیستم‌ها کمک کند و عملکرد را بهبود بخشد. او همچنین از استفاده از (DLQ) Dead letter queue برای رسیدگی به پیام‌هایی که نمی‌توانند بلافاصله پردازش شوند، بحث می‌کند.

سپس چالش‌های مسیریابی پیام‌ها در سیستم‌های توزیع‌شده را مورد بحث قرار می‌دهد. او استدلال می‌کند که اغلب بهتر است از یک Message router، مانند صف SQS، برای انتقال پیام‌ها استفاده کرد به جای اینکه این کار مستقیما داخل خود اپلیکیشن انجام شود. این کار می‌تواند به ساده‌سازی برنامه و بهبود قابلیت نگهداری آن کمک کند.

در نهایت، مفهوم item potency را معرفی می‌کند که یک تکنیک برای اطمینان از پردازش هر پیام فقط یک بار است. او توضیح می‌دهد که چگونه می‌توان از یک شناسه یونیک، مانند یک توکن، برای ردیابی وضعیت هر پیام و جلوگیری از تکرار استفاده کرد.

خلاصه کلی:

• معماری EDA یک رویکرد قدرتمند برای ساخت برنامه‌های توزیع‌شده است که مقیاس‌پذیر، پایدار و قابل نگهداری هستند.
• برای بهبود انعطاف‌پذیری و قابلیت نگهداری، وابستگی بین سیستم‌ها را کاهش دهید.
• از Asynchronous communication برای جدا کردن سیستم‌ها و بهبود عملکرد استفاده کنید.
• از dead-letter queue برای رسیدگی به پیام‌هایی که نمی‌توانند بلافاصله پردازش شوند، استفاده کنید.
• از یک Message router برای مسیریابی به جای ارسال پیام مستقیما از خود برنامه فرستنده استفاده کنید.
• مفهوم item potency کمک میکند تا هر پیام فقط یک بار پردازش شود.

Data - The Land DevOps Forgot • Michael Nygard • YOW! 2023

سخنران: Michael Nygard، توسعه‌دهنده، معمار و نویسنده
لینک: https://youtu.be/459-H33is6o?si=2vKMHiTlqaf8wqxV

در این ویدیو، به چالش‌های مدیریت داده در زمینه DevOps پرداخته می‌شود. استدلال میشود که رویکرد سنتی مدیریت داده که متمرکز (monolithic) و یکپارچه (centralized) است، برای مقابله با پیچیدگی‌های داده‌های جدید مناسب نیست.

مفهوم «Data mesh» را معرفی می‌کند، یک رویکرد غیرمتمرکز برای مدیریت داده که از اصول میکروسرویس‌ها و service mesh الهام گرفته است. Data mesh مالکیت و مدیریت داده را به تیم‌هایی که آن را ایجاد و استفاده می‌کنند، واگذار می‌کند و از این طریق، تمرکز داده را از بین می‌برد و شبکه‌ای از داده را ایجاد می‌کند.

سخنران چندین مزیت کلیدی Data mesh را برجسته می‌کند:

• افزایش چابکی: تیم‌های داده (Data teams) می‌توانند بدون اتکا به یک مرجع مرکزی، داده‌های خود را به سرعت سازگار کنند.
• بهبود کیفیت داده: مالکان داده(Data owners)، داده‌های خود را با جزئیات بهتری می‌بینند، بنابراین کیفیت داده های تولید شده توسط خودشان را در اولویت قرار دهند.
• کاهش هزینه‌ها: تیم‌های داده(Data teams) می‌توانند هزینه‌های مرتبط با نگهداری یک پلتفرم داده متمرکز(centralized data platform) را به حداقل برسانند.

پیاده‌سازی Data mesh چالش‌های خاصی را به همراه دارد:

• مسائل فرهنگی: تیم‌های داده باید مالکیت و مسئولیت داده‌های خود را بپذیرند.
• موانع فنی: ابزارها برای Data mesh هنوز نوپا هستند و نیاز به بررسی دقیق‌تر برای استفاده های فنی دارند.

در نتیجه، Data mesh به عنوان یک رویکرد امیدوارکننده به مدیریت داده ظهور می‌کند که به سازمان‌ها چابکی، کیفیت داده و کارایی هزینه را بهبود می‌بخشد. با این حال، پذیرش موفقیت‌آمیز آن مستلزم تغییر فرهنگی در تیم‌های داده، ارزیابی دقیق آمادگی فنی و رویکرد استراتژیک به انتخاب فروشنده است.

Tales of Kafka @Cloudflare: Lessons Learnt on the Way to 1 Trillion Messages

سخنران: Matt Bou, Andre Meta، اعضای تیم Cloudflare Application Services
لینک: https://youtu.be/_booBjCB7rU?si=qb0OlUw3ZR8Weall

این سخنرانی به بررسی چگونگی مقیاس‌پذیری استفاده از Kafka در Cloudflare برای پردازش بیش از یک تریلیون پیام می‌پردازد.

اوایل Kafka در Cloudflare
سرویس Cloudflare در سال ۲۰۱۵ شروع به استفاده از Kafka کرد تا سرویس‌ها را از هم جدا کند و ارتباط بین تیم‌ها را بهبود بخشد. تیم در ابتدا از kafka به صورت یک cluster یکپارجه استفاده می‌کرد، اما با رشد شرکت، این کلاستر به یک گلوگاه تبدیل شد.

ایجاد انتزاع روی Kafka
برای رفع محدودیت‌های مقیاس‌پذیری در کلاستِر یکپارچه، Cloudflare یک کلاستر برای انتقال پیام‌ها (message bus cluster)ایجاد کرد. این کلاستر برای همه تیم‌های Cloudflare در دسترس است و روشی ساده برای ایجاد و مدیریت topic های Kafka فراهم می‌کند.

بهبود مقیاس‌پذیری و قابلیت اطمینان
سرویس Cloudflare چندین استراتژی را برای بهبود مقیاس‌پذیری و قابلیت اطمینان زیرساخت Kafka خود پیاده‌سازی کرده است. این موارد عبارتند از:

• افزایش تعداد پارتیشن‌ها و consumerها: این امر به Cloudflare اجازه می‌دهد پیام‌های بیشتری را بدون نیاز به افزایش تعداد واسط‌ها پردازش کند.
• استفاده از یک contract واحد برای هر topic: این امر اطمینان حاصل می‌کند که همه consumerها به یک روش یکسان پیام‌ها را می‌خوانند و می‌نویسند.
• مستندسازی best practiveها: این امر به تیم‌ها کمک می‌کند تا از اشتباهات رایج اجتناب کنند و اطمینان حاصل کنند که از Kafka به روشی یکنواخت و قابل اعتماد استفاده می‌کنند.

برنامه‌های آینده
سرویس Cloudflare در حال کار بر روی چندین پروژه برای بهبود بیشتر زیرساخت Kafka خود است. این موارد عبارتند از:

• توسعه ابزاری به نام Guia: این ابزار کار را برای تیم‌ها آسان‌تر می‌کند تا با Kafka شروع کنند و از آن به روشی آماده برای تولید استفاده کنند.
• تولید کد مشتری برای زبان‌های متعدد: این امر کار را برای تیم‌ها آسان‌تر می‌کند تا از Kafka در زبان برنامه‌نویسی مورد نظر خود استفاده کنند.

Practical (a.k.a. Actually Useful) Architecture • Stefan Tilkov • GOTO 2023

سخنران: Stefan Tilkov - معمار نرم‌افزار، سخنران و نویسنده‌ی متخصص در زمینه‌ی رایانش ابری، میکروسرویس‌ها و DevOps است. او با شرکت‌های متعددی، از جمله IBM، گوگل و نتفلیکس، همکاری داشته است و چندین کتاب و مقاله در مورد معماری ابری منتشر کرده است.
لینک: https://youtu.be/BNTt2aLB1tg?si=RVJxnIpYEB4A_oUH

این ویدیو ۱۰ توصیه برای معماری عملی را ارائه می‌دهد. این توصیه‌ها بر اساس تجربه سخنران و سایر معماران است که در طیف گسترده‌ای از پروژه‌ها کار کرده‌اند.

توصیه ۱: انتخاب آگاهانه
هنگام صحبت از معماری، باید از دیدگاه‌های مختلف، مانند معماری دامنه، معماری ماکرو و معماری میکرو، آگاه باشید. معماری دامنه با ساختار کلی سیستم سروکار دارد، در حالی که معماری ماکرو با اجزای سطح بالا سیستم سروکار دارد. معماری میکرو با جزئیات پایین سیستم، مانند اجزای سخت‌افزاری و نرم‌افزاری، سروکار دارد.

توصیه ۲: فقط مستند نکنید، تصمیم بگیرید
مستندسازی معماری موجود مهم است، اما هدف نهایی نیست. شما همچنین باید در مورد معماری تصمیم بگیرید و از آن دفاع کنید. این کار را می‌توان از طریق فرایندی به نام تصمیم‌گیری معماری (architectural decision making - ADM) انجام داد. ADM شامل مستندسازی تصمیمات گرفته شده، منطق پشت تصمیمات و جایگزین‌هایی است که در نظر گرفته شده‌اند.

توصیه ۳: تشویق به تصمیم‌گیری و استفاده از ADRها
رکورد تصمیم معماری (Architectural Decision Records - ADRs) راهی برای مستندسازی تصمیمات معماری است. ADRها باید شامل اطلاعات زیر باشند:

• تصمیم گرفته شده
• منطق پشت تصمیم
• گزینه‌هایی که در نظر گرفته شده‌اند
• افرادی که تصمیم را گرفته‌اند
• تاریخ تصمیم‌گیری

رکوردهای ADR می‌توانند برای برقراری ارتباط تصمیمات معماری با سایر ذینفعان و ردیابی تکامل معماری در طول زمان استفاده شوند.

توصیه ۴: معماری ایستا نیست
معماری یک فرایند تکراری است که با تغییرات سازگار می‌شود. با تغییر نیازمندی‌های سیستم، معماری ممکن است نیاز به به‌روزرسانی داشته باشد. به همین دلیل مهم است که معماری را مستند کنید و تصمیماتی بگیرید که انعطاف‌پذیری کافی برای سازگاری با تغییرات را داشته باشند.

توصیه ۵: سادگی را بر پیچیدگی اولویت دهید
از فناوری‌های شناخته‌شده و اثبات شده استفاده کنید، مگر اینکه دلیل خوبی برای انجام کاری غیر از این داشته باشید. معماری‌های پیچیده برای نگهداری دشوارتر هستند و بیشتر احتمال دارد دچار مشکل شوند.

توصیه ۶: دامنه را درک کنید
فقط روی فناوری تمرکز نکنید؛ مشکل کسب‌وکار را که در حال حل آن هستید، درک کنید. بهترین معماری آن است که مشکل را به ساده‌ترین و کارآمدترین روش ممکن حل می‌کند.

توصیه ۷: از نوآوری در دامنه نترسید
مهم‌ترین نوآوری‌ها اغلب در حوزه کسب‌وکار هستند، نه فناوری. پذیرای ایده‌های جدید باشید و از آزمایش کردن ایده‌های جدید نترسید.

توصیه ۸: context را در نظر بگیرید
یک معماری خاص که برای همه مناسب باشد، وجود ندارد. رویکرد خود را با نیازهای خاص پروژه سازگار کنید. عواملی مانند اندازه و پیچیدگی سیستم، بودجه و زمان را در نظر بگیرید.

توصیه ۹: به دنبال تکامل پذیری باشید، نه کمال
معماری باید انعطاف‌پذیری کافی برای سازگاری با تغییرات را داشته باشد. سعی نکنید معماری کاملی ایجاد کنید که هرگز نیازی به تغییر نداشته باشد.

توصیه ۱۰: از کثیف شدن دست‌های خود نترسید
دامنه کسب‌وکار و فناوری را که از آن استفاده می‌کنید درک کنید. از اینکه آستین‌های خود را بالا بزنید و در اجرای معماری مشارکت کنید نترسید.

Building Resilient Frontend Architecture • Monica Lent • GOTO 2019

سخنران: Monica Lent. مهندس نرم‌افزار با بیش از ۱۰ سال تجربه. او در حال حاضر یک مهندس نرم‌افزار ارشد در شرکت SumUp، یک شرکت پردازش پرداخت اروپایی است. او همچنین یک سخنران و نویسنده در زمینه معماری نرم‌افزار است.
لینک: https://youtu.be/TqfbAXCCVwE?si=Z6ld16z9-ZnYu8KM

این سخنرانی صرفاً در مورد نکات فنی نیست؛ بلکه یک بررسی فلسفی از رویکرد ما برای ساخت و نگهداری نرم‌افزار است.

بازنویسی (Rewriting): ضرورت در برابر انعطاف
بازنویسی نرم‌افزار اجتناب‌ناپذیر است، زیرا نیازها، فناوری‌ها و پارادایم‌ها در حال تغییر هستند. با این حال،این کنفرانس تمرکز را از «جایگزین کردن کد بد» به «ساخت با در نظر گرفتن انعطاف» تغییر می‌دهد. این تغییر ظریف ما را تشویق می‌کند تا انعطاف‌پذیری و قابلیت نگهداری را در اولویت قرار دهیم و کد را نه به عنوان یک محصول استاتیک، بلکه به عنوان یک موجود زنده که می‌تواند به طور ظریف تکامل یابد، ببینیم.

بدهی فنی (Technical Debt): دشمن نامرئی
سخنران تصویری غم‌انگیز از بدهی فنی به عنوان یک دشمن آرام و زیرک ترسیم می‌کند. جذابیت رفع سریع مشکلات، بارِ کدِ به ارث رسیده و جذابیت فناوری‌های جدید همگی می‌توانند به این بار نامرئی کمک کنند، که سرعت و کیفیت توسعه را کاهش می‌دهد. او معماری آگاهانه و شیوه‌های کدنویسی منظم را به ما یادآوری کرد که یک بخیه به موقع (یا یک تصمیم طراحی خوب‌تأمل‌شده) می‌تواند ما را از ماه‌ها دردسر در آینده نجات دهد.

اجبارها (Constraints): آزادی در چارچوب‌ها
ا‌جبارهای معماری، که اغلب به عنوان محدودیت‌ها(limitations) دیده می‌شوند، می‌توانند متحدان قدرتمندی باشند. با تعیین مرزهای مشخص در مورد نحوه تعامل کد، همانطور که در برنامه‌نویسی شیءگرا یا فانکشنال دیده می‌شود، توسعه‌دهندگان چارچوبی برای ساخت سیستم‌های قابل پیش‌بینی (predictable) و قابل نگهداری (maintable) به دست می‌آورند. این کار مانند گاردرِیل‌های کنار جاده است؛ محدودیت‌ها، سفر ایمن و کارآمد را قابل دسترس می‌کنند و در نهایت توسعه‌دهندگان را آزاد می‌گذارند تا بر روی راه‌حل های خلاقانه در چارچوب ساختار موجود تمرکز کنند.

تغییرات کوچک، تأثیر بزرگ: اثر پروانه‌ای
سخنران به زیبایی نشان می‌دهد که چگونه تصمیمات به ظاهر کوچک می‌توانند در طول زمان، تأثیرات قابل توجهی داشته باشند. تنظیم قوانین وابستگی، استفاده مجدد محتاطانه از کد و اجرای خودکار سازی ممکن است به نظر جزئی بیایند، اما اثر تجمعی آنها بزرگ است. درست همانطور که قطرات کوچک در نهایت دره‌ها را می‌تراشند، این انتخاب‌های آگاهانه بدهی‌های فنی را کاهش می‌دهند و یک codebas درست‌تر و قابل مدیریت‌تر را شکل می‌دهند.

مالکیت فردی: توانمندسازی معماران تغییر
هر ویژگی، بزرگ یا کوچک، تاثیرگذار بر تصمیمات معماری است. با باز گذاشتن دست توسعه‌دهندگان برای مشارکت و مالکیت بر این انتخاب‌ها، باعث ایجاد حس مسئولیت‌پذیری و حس سرمایه‌گذاری شخصی در برنامه نویسان می‌شویم. این مالکیتِ جمعی، هوشیاری نسبت به معماری را افزایش می‌دهد، تصمیم‌گیری‌ها را هدفمندتر و کد را از ابتدا مستحکم‌تر می‌کند.

آن سوی وب: یک اثر هنری الهام‌بخش
جامعه توسعه وب یک جزیره منزوی نیست. سخنران ما را تشویق می‌کند تا ایده‌ها را فراتر از این جای معمول جستجو کنیم و راه حل‌ها و استراتژی‌ها را در سایر پارادایم‌های برنامه‌نویسی و جوامع کاوش کنیم. این تلاقی ایده‌ها می‌تواند منجر به بروز رویکردهای نوآورانه و موثری در معماری شود و به ما یادآوری کند که می‌توانیم از دیدگاه‌های متنوع برای ساخت سیستم‌های بهتر استفاده کنیم.

انسانی کردن حرفه: ساختن سیستم‌ها، نه صرفاً چند خط کد
سخنرانی فراتر از جزئیات فنی می‌رود و جنبه‌های انسانی توسعه نرم‌افزار را هم بیان می‌کند. سخنران، علاقه به بازنویسی‌ها(Rewrites) و ارزشمند بودنِ یادگیری از دیگر جوامع را بیان می‌کند. این رویکرد، محیطی مشارکتی تر و پربارتر برای توسعه ایجاد می‌کند، جایی که دانش و ایده‌ها آزادانه جریان می‌یابند و توسعه‌دهندگان احساس آزادی برای آزمایش و یادگیری را دارند.

جمع بندی نظرات: طراحی معماری سفری بی‌پایان است، نه مقصدی مشخص
ساخت معماری‌های انعطاف پذیر برای front-end، مانند یک سفر است، نه یک دستاورد یکباره. این سخنرانی نقشه‌ی راهی را ارائه می‌دهد که پر از استراتژی‌های عملی و ایده‌های قابل توجهی است. با اولویت‌بندی قابلیت نگهداری، پذیرش محدودیت‌ها و پرورش فرهنگ یادگیری مداوم، می‌توانیم رابط‌های کاربری‌ای بسازیم که نه تنها امروز به خوبی کار می‌کنند، بلکه با تغییرات وب سازگار می‌شوند.

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.