خلاصه ۵ ویدیوی مرتبط با معماری نرم‌افزار

عنوان ویدیو:Cracking the Case: How to Migrate from Monoliths to Microservicesسخنران:Stephanie Baum – مهندس نرم‌افزار در Lightstepلینک ویدیو:https://www.youtube.com/watch?v=KGYYTDVKqKwخلاصه:در یک اجلاس معماری برنامه کاربردی، جلسه‌ای با تمرکز بر گذار از سیستم‌های یک‌پارچه (مونولیت) به میکروسرویس‌ها ارائه شد که توسط استفانی بام، مهندس نرم‌افزار در لایت‌استپ، ارائه می‌شد. استفانی با پیشینه‌ای غنی در زمینه مهندسی فول‌استک و تجربه کمک به شرکت‌های بزرگ فورچون در مهاجرت به میکروسرویس‌ها، تجربیات ارزشمندی را به این موضوع اضافه می‌کند. جلسه با عنوان “شکافندگی پرونده: چگونه از مونولیت‌ها به میکروسرویس‌ها مهاجرت کنیم”، به چالش‌های فنی و تصمیم‌گیری مرتبط با این تحول اشاره داشت، از جمله انتخاب صحیح پشته فناوری و ارزیابی مزایا و معایب تقسیم یک مونولیت به معماری مبتنی بر خدمات.استفانی مفهوم اهداف سطح خدمات (SLO) و اهمیت تعریف آن‌ها از پیش را برای هدایت فرآیند مهاجرت بدون ایجاد اختلال در تجربه کاربران توضیح داد. او دیدگاه‌هایی در مورد مدیریت عملیات نظیر مدیریت پیکربندی، محفظه‌سازی، و ادغام و توزیع مستمر(CI/CD) ارائه داد تا اطمینان حاصل کند که این راه‌اندازی‌ها قابل تکرار و مقیاس‌پذیر می‌باشند. جلسه هم‌چنین شامل ملاحظات استراتژیک در مورد انتخاب زبان‌های برنامه‌نویسی و تصمیم‌گیری برای استفاده از معماری‌های بدون سرور در مقابل میکروسرویس‌های سنتی بود، بر اساس آشنایی تیم و پیچیدگی منطق کسب‌وکار.“اثر میکروسرویس” قسمت عمده‌ای از ارائه استفانی بود، جایی که او در مورد پیچیدگی‌های ناشی از افزایش تعداد خدمات و هماهنگی آن‌ها صحبت کرد. این افزایش، نقاط شکست جدیدی ایجاد کرده و پیگیری منطق معاملاتی در سراسر سیستم را پیچیده می‌کند. او پیشنهاد داد که ابزارهای مشاهده‌پذیری مانند آنچه توسط لایت‌استپ ارائه می‌شود که قابلیت ردیابی را ادغام می‌کنند، برای مدیریت این پیچیدگی ضروری است و اطمینان حاصل می‌کند که تیم‌ها می‌توانند مالکیت و مسئولیت واضحی برای خدمات خود حفظ کنند.در پایان، استفانی بر استفاده از ابزارهای نظارت بر کارایی برنامه(APM) برای کاهش پیچیدگی کد اضافی طی مهاجرت و شناسایی احتمالی گلوگاه‌ها در مونولیت و میکروسرویس جدید تأکید کرد. استفاده از APM به توسعه‌دهندگان اجازه می‌دهد تا کارایی کد و تعاملات با سرویس‌های خارجی را در زمان واقعی پایش کنند، زیرساختی برای یک مهاجرت روان فراهم می‌آورد. او بر اهمیت SLOها برای فراهم کردن شفافیت در مورد سلامت سرویس‌ها در طی و پس از مهاجرت تأکید کرد. استفانی جلسه را با تشویق حاضرین برای کشف منابع مانند ماسکوت تعاملی LightStep و وبلاگ برای تجربه عملی و یادگیری بیشتر در مورد مشاهده‌پذیری مدرن به پایان رساند.عنوان ویدیو:What Software Architecture Should Look Like • Dave Farley • GOTO 2022سخنران:Dave Farley – نویسنده کتاب “Continuous Delivery”لینک ویدیو:https://www.youtube.com/watch?v=Eg_dapdKCHUخلاصه:معماری نرم‌افزار، طبق تعریف ویکی‌پدیا، به عنوان ساختارهای کاربردی یک سیستم نرم‌افزاری توصیف شده است، اما این تعریف بسیاری پرسش‌ها را بی‌جواب می‌گذارد و نشان از پیچیدگی مفهوم معماری دارد که به سختی می‌توان به طور مستقیم تعریف کرد. دیو فارلی، مدافع رویکرد مهندسی به توسعه نرم‌افزار، این مفهوم را در کتاب خود به نام “مهندسی نرم‌افزار مدرن” توصیف می‌کند. طی دوران حرفه‌ای خود، که گاهی به عنوان توسعه‌دهنده نرم‌افزار و گاهی به عنوان معمار نرم‌افزار شناخته می‌شد، فارلی دریافته است که نقش شامل طراحی است - صرف نظر از عنوان یا مقیاس - که نشان می‌دهد جزئیات در هر سطحی در طراحی سیستم‌های اطلاعاتی حیاتی است.فارلی تعریف محبوب گریدی بوچ از معماری نرم‌افزار را، که تصمیمات مهم طراحی را که هزینه تغییر را مشخص می‌کند، نقد می‌کند. او بر این باور است که دیدگاه بوچ بیش از حد پیش‌بینی‌کننده برای رشته‌ای است که به انعطاف‌پذیری و نوآوری نیاز دارد و به همین دلیل به یک فرآیند تکاملی علاقه‌مند است. او از تمثیل “نقشه گردشگری” به عنوان یک راهنما برای تکامل طراحی سیستم‌ها از طریق اشتباهات تکراری و عمیق‌تر شدن درک استفاده می‌کند.بر اساس تعاریف رالف جانسون، فارلی پیشنهاد می‌کند که معماری برگه ویش‌لیست توسعه‌دهندگان است - تصمیمات حیاتی که آنها امیدوار بوده‌اند از ابتدا درست انجام شده باشد، و درک مشترک کارشناسان توسعه‌دهندگان از طراحی سیستم در هر نقطه زمانی. او تاکید می‌کند که معماری باید امکان تنظیم و تکامل را فراهم کند چون ناممکن است که همه چیزها از ابتدا درست باشد. برای فارلی، معماری موفقیت‌آمیز در مدیریت پیچیدگی‌ها و ایجاد فضایی برای یادگیری از خطاها نهفته است بلکه ترس از اشتباه را کاهش می‌دهد.در نهایت، فارلی معماری نرم‌افزار را به عنوان مجموعه‌ای از محدودیت‌ها می‌بیند که هدایت و محافظت از فرآیند توسعه را در بر دارد و با ایجاد پتانسیل برای تغییر تطبیق می‌دهد. او تشویق به مشارکت همه توسعه‌دهندگان در بحث‌های معماری را می‌کند، بازتاب طبیعت تکراری طراحی نرم‌افزار و به رسمیت شناختن اینکه حتی تغییرات کوچک می‌توانند تأثیر قابل توجهی بر سیستم داشته باشند. در نهایت، معماری خوب فقط حوزه انتزاعی یا نقشه اولیه نیست؛ بلکه یک گفتگوی مستمر است که از طریق تصمیمات روزانه توسعه‌دهندگان نرم‌افزار جریان دارد و اطمینان حاصل می‌کند که حتی با پیچیدگی و ناپایداری نرم‌افزار، پیشرفت ممکن است، اشتباهات قابل اصلاح است و معماری می‌تواند برای برآوردن نیازهای هر سیستم تکامل یابد.عنوان ویدیو:Software Architecture Principles From 5 Leading Expertsسخنران:Dave Farley – نویسنده کتاب “Continuous Delivery”لینک ویدیو:https://www.youtube.com/watch?v=SYtkbv8LNv0خلاصه:ویدیو به جنبه‌ای که اغلب در حوزه توسعه نرم‌افزار نادیده گرفته می‌شود، یعنی طراحی نرم‌افزار، می‌پردازد. سخنران، دیو فارلی، تأکید می‌کند که توسعه نرم‌افزار خیلی بیشتر از صرف ترجمه دستورالعمل‌های زبان انسانی به کد است. او توجه می‌دهد که طراحی نرم‌افزار بخش حیاتی این فرایند است، با این حال، کمبود گفتگوهای عمیق در مورد آن در جامعه حرفه‌ای به طور قابل توجهی مشاهده می‌شود. فارلی نشان می‌دهد که دوران حرفه‌ای او بیشتر بر روی طراحی سیستم‌های نرم‌افزاری متمرکز بوده است، و به جنبه‌های متنوعی مانند مدولاریتی، انسجام، و جدایی دغدغه‌ها اشاره می‌کند.فارلی نسبت به گرایش صنعت به بحث بر سر انواع پارادایم‌های برنامه‌نویسی و ابزارها، به جای تمرکز بر اصول اساسی طراحی نرم‌افزار، ابراز نگرانی می‌کند. او اشاره می‌کند که این کمبود توجه به طراحی ممکن است از دشواری در بیان و آموزش اصول مؤثر طراحی نرم‌افزار ناشی شود. او موازنه‌ای بین طراحی نرم‌افزار و نویسندگی ایجاد می‌کند و نشان می‌دهد که هر دو نیاز به ساختار صحیح و همچنین انتقال فکر منظم و معنی‌دار دارند.در تحلیل خود، فارلی بر اهمیت خوانایی و توانایی تغییر کد به عنوان دو اصل بنیادین طراحی خوب نرم‌افزار تأکید دارد. او ادعا می‌کند که این اصول باید در تمام سطوح طراحی سیستم، از خطوط کد فردی گرفته تا معماری سیستم‌های بزرگ، اعمال شوند. هدف، بر طبق فارلی، خلق نرم‌افزاری است که قابل فهم و ساده برای تغییر باشد، تضمین می‌کند که کیفیت فنی سیستم براساس قابلیت سازگاری با تغییر تعریف شود.به سمت پایان ویدیو، فارلی به جوانب عملی طراحی نرم‌افزار می‌پردازد. او درباره استفاده از مدل‌های وایت‌برد برای تصویرسازی و انتقال به تصویر کشیدن مؤثر معماری سیستم بحث می‌کند، که درک و تغییر سیستم توسط اعضای تیم را ساده‌تر می‌کند. او بر اهمیت داشتن درک مشترک از طراحی سیستم در درون یک تیم تأکید دارد که به باور او برای حفظ یک سیستم خوب طراحی شده که با گذشت زمان قابل ناوبری و آداپته است، حیاتی است.عنوان ویدیو:The Evolution of Reddit.com's Architectureسخنران:Neil Williamsمحل برگزاری:QCon San Francisco 2017لینک ویدیو:https://www.youtube.com/watch?v=nUcO7n4hek4خلاصه:ارائه ویدیویی، دیدگاه جامعی از معماری ردیت و چالش‌های عملیاتی آن ارائه می‌دهد. در ابتدا، سخنران ردیت را به عنوان یک پلتفرم آنلاین بزرگ معرفی می‌کند و به پایگاه کاربری وسیع و حجم بالای ترافیک آن اشاره می‌نماید. سپس معماری اصلی ردیت توضیح داده شده، با تمرکز بر روی برنامه پایتون مونولیتیک اصلی آن (R2) و انتقال تدریجی به برنامه‌های کاربردی جدید مدرن با استفاده از Node.js. این برنامه‌های کاربردی به عنوان مشتریان API عمل می‌کنند و با دروازه API ردیت و سرویس‌های پشتیبانی ارتباط برقرار می‌کنند که بسیاری از آن‌ها برای بهبود مدولاریته از R2 مونولیتیک جدا شده‌اند.در ادامه سخنرانی، سخنران به پیچیدگی‌های معماری مونولیتیک ردیت می‌پردازد. او توضیح می‌دهد که چگونه زیرساخت‌های ردیت برای کنترل انواع درخواست‌ها و فعالیت‌های کاربران طراحی شده‌اند، به عنوان مثال رأی دادن یا پست کردن که به صورت ناهمزمان پردازش می‌شوند. این قسمت همچنین پوشش می‌دهد فناوری‌های پشتیبانی مانند Memcache، Postgres و Cassandra و نقش‌های آن‌ها در کنترل داده‌ها و ذخیره‌سازی در ردیت.بخش قابل توجهی از ارائه به بحث در مورد چالش‌ها و راه‌حل‌های مرتبط با سیستم‌های لیست‌بندی و صف ردیت اختصاص داده شده است. سخنران پیچیدگی‌های مدیریت محتوای پویا مانند رأی‌ها و نظرات را توضیح می‌دهد، به ویژه در شرایط ترافیک بالا. مسائلی مانند تجمع در صف و تداخل قفل بحث شده‌اند و استراتژی‌هایی مانند تقسیم‌بندی صف و استفاده از کش و داده‌های دنرمالایز شده برای بهبود کارایی مد‌نظر قرار گرفته‌اند.در نهایت، سخنرانی با بینش‌هایی پیرامون توانمندسازی سرورها و رویه‌های خودکارسازی مقیاس‌پذیری ردیت به پایان می‌رسد و بر اهمیت نظارت‌پذیری، انتقال‌پذیری و مدیریت هوشمندانه سرویس‌های دارای حالت در مقابل بی‌حالت تاکید می‌کند. سخنران از درس‌های آموخته شده از چالش‌های مختلف، از جمله مشکلات مربوط به خودکارسازی مقیاس‌بندی و تکثیر پایگاه داده، بحث می‌کند و بر نیاز به چندین لایه حفاظتی و سادگی در طراحی سیستم برای اطمینان از قابلیت اطمینان و نگه‌داری بهتر، تأکید ویژه‌ای می‌کند. ارائه با اشاره به توسعه و رشد مداوم ردیت به پایان می‌رسد.عنوان ویدیو:Software Architecture: A Mature Discipline?سخنران:Philippe Kruchten – استاد مهندسی نرم‌افزار در دانشگاه British Columbia کانادالینک ویدیو:https://www.youtube.com/watch?v=70kyGrjs8rUخلاصه:ویدیو با عنوان “معماری مرورگر وب SDI در یک رشته بالغ”، ویژگی‌های برنده جایزه معماری نرم‌افزار لیندا ال. نورثاپ، فیلیپ کروشتون را نمایش می‌دهد. میزبان، جیمز ایورس، رهبر گروه معماری نرم‌افزار در مؤسسه مهندسی نرم‌افزار دانشگاه کارنگی ملون است. از دهه ۱۹۸۰مؤسسه SEI به طور قابل توجهی در توسعه و بلوغ حوزه معماری نرم‌افزار کمک کرده است و به سازمان‌ها با راه‌حل‌های معماری کمک نموده و به بهبود کلی دانش در این زمینه انجام شده است. روش‌های SEI به طور گسترده شناخته شده و بر بسیاری از حرفه‌ای‌ها و دانشجویان معماری نرم‌افزار در سراسر دنیا تأثیر گذاشته‌اند.فیلیپ کروشتون، استاد افتخاری مهندسی نرم‌افزار در دانشگاه بریتیش کلمبیا، دارای یک حرفه درخشان در هر دو زمینه علمی و صنعتی است. کار او در معماری نرم‌افزار بر طراحی سیستم‌های بزرگ در حوزه‌های مختلف از جمله مخابرات، دفاع، هوا‌فضا و حمل و نقل تأثیر گذاشته است. دخالت او در توسعه نرم‌افزار به وضوح در روند تحلیل متحد رشنال(RUP) که از بدو تأسیس آن رهبری کرده است، خلاصه شده است. روش “چهار به علاوه یک” دیدگاهRUP یک کمک بنیادین به حوزه معماری نرم‌افزار است.در ارائه خود، کروشتون بر روی تکامل معماری نرم‌افزار تأمل می‌کند. او به معنا‌شناسی اصطلاح می‌پردازد و توجه می‌دهد که چگونه تعاریف آن متفاوت بوده است، غالباً بر ساختار، اجزا و اتصال‌دهنده‌ها تأکید می‌کند. کروشتون تأکید می‌کند که نقش معماری نرم‌افزار با گذشت زمان از یک تعریف باریک به عنوان فهم مشترکی از مسیر یک پروژه و حفظ یکپارچگی مفهومی تغییر کرده است. او همچنین در مورد فرآیند معماری بحث می‌کند که از روش‌های بیشتر سنتی به رویکردهای چابک و تکراری تکامل یافته است.در نهایت، کروشتون به آینده معماری نرم‌افزار می‌پردازد و بر اهمیت تحقیق در بهبود این زمینه تأکید می‌کند. او بر نیاز به اکتشاف جنبه‌های اقتصادی، نقش بدهی فنی و جنبه‌های اجتماعی معماری نرم‌افزار اشاره می‌کند. بینش‌های او نشان می‌دهد که در حالی که معماری نرم‌افزار بالغ شده است، هنوز بسیاری برای کشف و درک وجود دارد، به‌خصوص در زمینه شیوه‌های توسعه نرم‌افزار مدرن.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است