خلاصه پنج تا از بهترین و جدید ترین سخنرانیای معماری نرم افزار

ویدیو اول :

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

چوپرا انگیزه‌هایی که منجر به ایجاد Netflix Drive شدند را توضیح می‌دهد که از جمله آن‌ها می‌توان به نیاز به زیرساختی توزیع شده، قابل مقیاس و کارآمد اشاره کرد. او بیان می‌کند که دارایی‌ها در Netflix عمدتاً مجموعه‌ای از فایل‌ها و پوشه‌ها هستند که دارای داده و متاداده‌ای هستند که توسط سیستم‌ها و خدمات مختلف مدیریت می‌شوند. از لحظه تولید داده‌ها مستقیماً از دوربین تا زمانی که این داده‌ها در نهایت به فیلم‌ها و نمایش‌ها تبدیل می‌شوند، این دارایی‌ها با انواع مختلف متاداده توسط سیستم‌های مختلف برچسب‌گذاری می‌شوند.

چوپرا بیان می‌کند که Netflix Drive در واقع یک نرم‌افزار لبه‌ای است که بر روی ایستگاه‌های کاری هنرمندان استودیو اجرا می‌شود. این سیستم، که به عنوان یک سیستم فایل ابری چند رابطه‌ای و چند سیستم‌عاملی طراحی شده است، قصد دارد تا حس و عملکرد یک سیستم فایل معمولی POSIX را ارائه دهد. علاوه بر این، این سیستم مانند یک میکروسرویس عمل می‌کند که دارای نقاط پایانی REST است و عملیات پس‌زمینه‌ای دارد که توسط بسیاری از جریان‌های کاری و موارد استفاده خودکار استفاده می‌شود، جایی که کاربران و برنامه‌ها به طور مستقیم با فایل‌ها و پوشه‌ها سر و کار ندارند.

او همچنین به طراحی و معماری Netflix Drive می‌پردازد، به زندگی‌نامه یک نمونه معمولی از Netflix Drive اشاره می‌کند و برخی از درس‌هایی که از این فرایند آموخته شده‌اند را با مخاطبان به اشتراک می‌گذارد. بخش مهمی از سخنرانی به بررسی چگونگی پشتیبانی Netflix Drive از نیازهای متنوع استودیوها و پلتفرم‌های Netflix و نقش آن به عنوان یک قطعه اساسی زیرساخت ذخیره‌سازی اختصاص دارد. او تاکید می‌کند که Netflix Drive به گونه‌ای طراحی شده است که می‌تواند انواع مختلفی از ذخیره‌سازی‌های داده و متاداده را در بر بگیرد و به یک چارچوب عمومی تبدیل شود که انواع مختلفی از مخازن داده را پشتیبانی کند.

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

و متاداده‌ها و امنیت است. او بیان می‌کند که Netflix Drive توانسته است عملکردی نزدیک به یک سیستم فایل محلی ارائه دهد و به طور چشمگیری از سایر سیستم‌های ذخیره‌سازی ابری مانند Google Drive عملکرد بهتری داشته باشد.

ویدیو دوم :

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

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

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

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

ویدیو سوم :

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

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

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

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

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

ویدیو چهارم :

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

آن‌ها در مورد اینکه چطور میکروسرویس‌ها می‌توانند به افزایش سرعت تحویل کمک کنند صحبت می‌کنند و در عین حال به این نکته اشاره می‌کنند که می‌توانند باعث پیچیدگی شوند. یکی از پنلیست‌ها تاکید می‌کند که مهم است پیش از رفتن به سمت میکروسرویس‌ها، مشکلات اصلی را شناسایی کرده و راه حل مناسب را پیدا کنیم، چه این راه حل میکروسرویس باشد یا نه.

یکی دیگر از موضوعات مورد بحث، اهمیت ابزارها و تیم‌ها در مدیریت میکروسرویس‌ها بود. بحث شد که چطور ساختار تیم‌ها و فرایند توسعه نرم‌افزار باید با یکدیگر هماهنگ باشند و اینکه تغییرات سازمانی چگونه باید با معماری میکروسرویس‌ها همراه شوند.

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

ویدیو پنجم :

در این ویدیو، جنیفر و استیون، مهندسین در تیم API سیستم‌های نتفلیکس، به بررسی تاریخچه، چالش‌ها و فلسفه پشت معماری میکروسرویس‌ها و API های فدرالیزه شده می‌پردازند. آنها داستان شروع نتفلیکس را با یک مونولیت ساده که به مرور به میکروسرویس‌های متعدد تقسیم شد، تعریف می‌کنند و اشاره می‌کنند که چگونه مواجهه با چالش‌های مقیاس‌بندی و انعطاف‌پذیری آن‌ها را به سمت معماری فدرالیزه GraphQL سوق داده است.

تکامل معماری:

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

معماری فدرالیزه و چالش‌های آن:

آن‌ها به مشکلات رشد یک API Gateway تکی اشاره می‌کنند که به تدریج به مونولیت جدیدی تبدیل شد. برای مقابله با این چالش، معماری فدرالیزه GraphQL را به کار گرفتند که به تیم‌های مختلف اجازه می‌دهد قسمت‌های مختلفی از گراف کلی API را مدیریت کنند. این رویکرد، تقسیم وظایف و مالکیت را بهبود می‌بخشد و به هر تیم اجازه می‌دهد با سرعت خودش پیش برود.

کاربرد و مزایا:

آنها نمونه‌هایی از چگونگی کاربرد و مزایای این معماری را ارائه می‌دهند، از جمله افزایش بهره‌وری، توانایی مدیریت بهتر ترافیک و داده‌ها، و انعطاف‌پذیری بیشتر در توسعه و نگهداری سرویس‌ها.

فلسفه و اجرای فدرالیزه:

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

چالش‌ها و درس‌های آموخته:

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

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

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