در این اپیزود که در دسامبر ۲۰۱۴ منتشر شده است، استفان تیکف با ادریان کاکرافت در ارتباط با پلتفرم‌های پیشرفته ابری مصاحبه می‌کند. آدریان بیشتر به خاطر رهبری Netflix برای انتقال به یک معماری کاملاً ابری، و به شدت پویا شناخته شده است. همچنین به عنوان یک مهندس برجسته در Sun Microsystems کار می‌کرد و یکی از بنیان­گذاران آزمایشگاه‌های تحقیقاتی eBay است. در حال حاضر آدریان به عنوان یک مشاور فناوری در Battery Ventures مشغول به کار است.
آدریان به برنامه خوش آمدی. طبق معمول از شما می‌خواهم که با معرفی خودتان شروع کنید. که هستید و چه می‌کنید؟
سلام، متشکرم که من را به این برنامه دعوت کردید. من یک فن‌شناس (Technologist) و توسعه‌دهنده‌ی نرم‌افزار هستم و مدت زیادی است که این کار را انجام می‌دهم. اجازه بدهید از ابتدا شروع کنم. من کارم را با گرفتن مدرک فیزیک از انگلیس شروع کردم و حدود ۵ سال به عنوان مهندس نرم‌افزار کار کردم. در این مدت، در شرکتی به نام Cambridge Consultants در انگلیس سیستم‌های تعبیه شده‌ی بلادرنگ و انواع نرم‌افزار را تولید می‌کردم. ما در دهه‌ی ۸۰ یکی از اولین کاربران ایستگاه‌های کاریِ (WorkStation) Sun بودیم که به عنوان بستر توسعه از آن استفاده می‌کردیم. به تدریج Sun دفتری در نزدیکی ما افتتاح کرد و من به آن‌ها پیوستم. پس از آن حدود ۵ سال به عنوان مهندس سیستم در شرکت Sun در انگلیس کار کردم. بعد از آن حدود ۲۰ سال پیش به آمریکا نقل مکان کردم و در بخش‌های مختلف مهندسی Sun کار کردم. اساساً تمرکز من روی طرح‌ریزی ظرفیت کارایی (Performance Capacity Planning) بوده است. در راستای این هدفِ Sun من یک مهندس برجسته در موضوع برنامه‌ریزی ظرفیت کارایی بودم و کتابی با عنوان Sun Performance and Tuning نوشتم که خیلی‌ها آن را دارند و بیشتر مردم به جای اسم کتاب طرح روی جلد آن را به خاطر می‌آورند. آخرین شغلی که در Sun داشتم، معمار ارشد در ارتباط با پردازش‌های با کارایی بالا (High Performance) بود.
در سال 2004 شرکت Sun یک کوچک‌سازی انجام داد و تعدادی از افراد را در فازهایی کنار گذاشت و آن گروه به طور کلی کنار گذاشته شد. بعد از آن به eBay پیوستم. کمی با eBay کار کردم و کمک کردم در طول سالیان در مقیاس رشد کنند. در آن‌جا به عنوان یک معمار دسترس‌پذیری متمایز روی مسائل مقیاس‌پذیری و دسترسی‌پذیری کار کردم. چیزهایی زیادی در مورد سیستم‌های مقیاس بزرگ که با مشتریان سروکار دارند -بر خلاف سیستم‌های سازمانی که با سازمان‌های دیگر سروکار دارند- یاد گرفتم. من به تشکیل آزمایشگاه‌های تحقیقاتی eBay کمک کردم و در سال ۲۰۰۷ به Netflix پیوستم. فکر می‌کنم Netflix به زودی در آلمان و پس از آن در فرانسه راه‌اندازی می‌شود. این‌که [سامانه] چطور پاسخ می‌دهد جالب خواهد بود.
من به Netflix پیوستم و حدود ۳ یا ۴ سال گروهی از توسعه‌دهندگان نرم‌افزار را مدیریت کردم. در اواخر این دوره تصمیم گرفتیم به فضای ابری (Cloud) منتقل شویم و من هدایت یکی از تیم‌ها را بر عهده داشتم تا بخشی از بستر را به فضای ابری منتقل کنیم. سپس تیمی تشکیل دادیم و من معمار آن شدم در عوض اینکه بخواهم بیرون بروم و در مورد این‌که ما چه کار می‌کنیم و چطور به ابر منتقل می‌شویم صحبت کنم و به دیگران توضیح دهم و مراحل گذشتن از سوء تفاهم‌ها و انکارها و پذیرفتن‌ها را طی کنم.
در نهایت در انتهای سال گذشته، علاقه‌ی زیادی خارج از Netflix به این موضوع نشان داده شد. سپس من به یک شرکت سرمایه‌گذاری به نام Battery Ventures رفتم. هفت ماه گذشته در آن‌جا بوده‌ام و کارهای مشابهی انجام داده‌ام. زمان زیادی را در کنفرانس‌ها هستم و فناوری‌های جدید را توضیح می‌دهم. و زمان زیادی را با شرکت‌های تابعه‌ای که Battery در آن‌ها سرمایه‌گذاری کرده است می‌گذرانم و به مقیاس‌پذیری، دسترس‌پذیری، انتقال به فضای ابری و به طور کلی ارزشمندتر کردن آن‌ها کمک می‌کنم.
خیلی دشوار است که مقاله‌ای پیدا کنیم که به نحوی فضای ابری یا پردازش ابری را ذکر نکند. با این حال، شما آن‌ها را چطور تعریف می‌کنید؟ فضای ابری چیست و پردازش ابری برای شما به چه معناست؟
فکر می‌کنم بزرگ‌ترین تغییر [در ارتباط به این مسأله است] که اگر در شرکتی کار می‌کنید و برای انجام کارهای خود به تعدادی کامپیوتر احتیاج دارید، باید یک درخواست بدهید و صبر کنید تا یک نفر دیگر به آن رسیدگی کند. در برخی شرکت‌ها این کار یک یا دو ماه طول می‌کشد تا فقط یک کامپیوتر آماده شود. مسئله‌ی مهم درباره‌ی ابر این است که خدمت ارائه می‌کند. شما فراخوانی‌هایی از واسط برنامه نویسی انجام می‌دهید و تعدادی کامپیوتر طی چند دقیقه پاسخ می‌دهند. این اساسی‌ترین تفاوت است؛ چرخه‌ی خرید را تسریع می‌کند. [همچنین] به این معنی است که کامپیوتر‌ها مجدداً در اختیار قرار می‌گیرند چون پاسخ در عرض چند دقیق آماده می‌شود. همه چیز پویاتر می‌شود. شما می‌توانید از ابر به عنوان یک راه سریع‌تر برای کارهایی که قبلاً در مراکز داده (Data Center) انجام می‌شد استفاده کنید، اما چیزهای جالب زمانی اتفاق می‌افتد که از آن به نحوی پویاتر استفاده کنید، آنگاه متوجه آن خواهد شد. [زمانی که] کامپیوتر‌ها بی‌دوام می‌شوند، می‌توانید آن‌ها را خاموش و روشن کنید؛ از آن برای چند ساعت استفاده کرده و آن را پس دهید. در واقع این ماهیت فضای ابری است. فکر می‌کنم این برابر است با این که بوفه‌ای (Self Service) از ابراز را در اختیار توسعه‌دهندگان قرار دهیم تا کارها را خودشان انجام دهند. اهمیتی ندارد که فضای ابری عمومی یا خصوصی است؛ [خدمت­رسانی] باید بر اساس تقاضا باشد و باید ظرفیت کافی برای کاری که می‌خواهید انجام دهید وجود داشته باشد، فقط همین.
پس این مسئله کاربرد [فضای ابری] خصوصی را به شرکت­هایی محدود می­کند که توانایی خرید تعداد زیادی کامپیوتر فیزیکی را دارند؟ آن قدر زیاد که هر آن­چه به فکر توسعه­دهنده برسد را ممکن کند؟
اگر به هزار کامپیوتر احتیاج داشته باشید و هزار کامپیوتر در اختیار نداشته باشید، هنوز هم به مشکل برمی­خورید، و این امکان وجود دارد که در AWS این اتفاق بیفتد. البته یکی از مزیت‌های فضای ابری عمومی این است که شما از ظرفیت‌های بسیار بیشتری استفاده می‌کنید. می‌توانید آن را به شکل یک ماهی کوچک در یک حوض بزرگ در نظر بگیرید. اگر شما یک ماهی کوچک در یک حوض بزرگ باشید، به خوبی جواب می­دهد. اگر شما کاربری بزرگ در ابری کوچک باشید -چه عمومی باشد چه خصوصی- جواب نخواهید گرفت. آن را به عنوان یک میانگین آماری از تعداد زیادی موارد کاربرد در حوضی از منابع (Pool of Resources) در نظر بگیرید؛ این‌طور به نظر خواهد رسید که نامحدود است اما در واقع محدود است و تنها تا حدی مقیاس‌پذیر است.
چطور شد که Netflix به فضای ابری مهاجرت کرد؟ تاریخچه‌ی آن چیست؟
Netflix کار خود را به عنوان یک شرکت تحویل DVD شروع کرد و در آن زمان به عنوان یک شرکت بزرگ فناوری در نظر گرفته نمی‌شد. زمانی که من به آن‌ها ملحق شدم، آن‌ها برای الگوریتم‌های شخصی‌سازی‌شان شناخته شده بودند، که فناوری جالبی بود و ارتباطی با مقیاس‌پذیری و ... نداشت. وقتی که من در سال ۲۰۰۷ به آن‌ها پیوستم حدود شش میلیون مشتری داشتند، و معمولاً آن مشتری‌ها هر آخر هفته مراجعه کرده و DVD مورد نظر خود را انتخاب می‌کردند. هر بار که دیسکی را برمی‌گرداندند، دیسک دیگری به آن‌ها ارسال می‌شد. بنابراین تعامل با Netflix ارسال دیسک‌ها از طریق پست بود. این به تعداد کمی وب سرور و تعداد کمی کامپیوتر‌های پشتیبان و یک پایگاه داده بزرگ احتیاج داشت؛ یک برنامه‌ی یکپارچه (Monolothic) متمرکز.
این وضعیت در سال ۲۰۰۷ بود. در سال ۲۰۰۷ ما پخش بلادرنگ (Streaming) را برای فهرستی کوچک راه‌اندازی کردیم؛ که خیلی سریع رشد کرد. زمانی که با یک خدمت پخش بلادرنگ تعامل می‌کنید هر کلیک باید از طریق وب‌سایت عبور کند. هر گاه که تصمیم بگیرید چیزی را تماشا کنید آن را از طریق وب‌سایت باز می‌کنید و می‌توانید آن را پخش کنید. بنابراین ترافیک زیادی مبادله می‌شود تا مشخص شود چه کاری باید انجام شود؛ کامپیوتر [حاوی فیلم] و فیلم باید جستجو شوند و کلید امنیتی به شما داده شود تا بتوانید فیلم مورد نظر را رمزگشایی کنید و همچنین فعالیت‌های شما ثبت (Log) شود تا بتوانیم کیفیت خدمات را تضمین کنیم. اندازه‌ی بافرها، سرعت شما، شبکه‌ی تحویل محتوایی (CDN) که از آن استفاده می‌کنید و ... [مسأله می‌شود] و تعداد تراکنش‌ها نسبت به حالت DVD هزاران بار بیشتر است و ترافیک آن نیز به مراتب بیشتر است. که البته زمانی که با تعداد کمی کامپیوتر و تعداد کمی فیلم و تعداد کمی از مشتریان کار را شروع کنید، اشکالی ندارد. اما نرخ استفاده به سرعت افزایش پیدا کرد. چون چیزی جلوی تماشای فیلم شما را نمی‌گیرد و نیازی به برگرداندن DVD و انتظار برای DVD بعدی نیست. تعداد زیادی از افراد به سرعت شروع به زیاده‌روی در تماشای محتوا کردند. بنابراین تعداد تعاملاتی که افراد با Netflix داشتند و تعداد چیزهایی که تماشا می‌کردند بالا رفت و تعداد تعاملات با وب‌سایت به شدت بالا رفت. وقتی به مرکز داده‌ها و کامپیوترهایی که کار پخش را انجام می‌دادند نگاه کردیم دیدیم که ظرفیت به سرعت در حال پر شدن است. در سال ۲۰۰۸ یک قطعی در Netflix رخ داد. برنامه‌ی یکپارچه‌ی مرکزی در هم شکست؛ در واقع مشکل ذخیره‌سازی بود، خرابی در SAN داده‌هایمان را تخریب کرد؛ وضعیت بدی بود. در نتیجه متوجه شدیم که ما در اجرای کارها در مرکز داده خوب عمل نمی‌کنیم و به دنبال راهی برای مقیاس‌پذیری گشتیم. افزایش مقیاس برای بار کاری فزاینده‌ای که نمی‌دانستیم با چه سرعتی رشد خواهد کرد. اینجا آن نقطه‌ی جالب است که ما نمی‌دانستیم و نمی‌توانستیم پیش‌بینی کنیم به چه ظرفیتی احتیاج داریم. در سال ۲۰۰۹ کامپیوترهای پشتیبان به فضای ابری انتقال یافتند، در ۲۰۱۰ وب‌سایت به فضای ابری منتقل شد و در ۲۰۱۱ پایگاه‌داده‌ها [منتقل شد] و در ۲۰۱۲ شروع به متن‌باز کردن ابزارهایی که ساخته بودیم کردیم. فکر می‌کنم این بخش اصلی تاریخچه باشد.
بنابراین شما احتمالاً موافقید که این تصمیم درستی بود که Netflix آن را با ادراک پس از فاجعه انجام داد؟
بله.
آیا آن را به دیگران هم توصیه می‌کنید؟ چقدر وابسته به این است که در کسب و کاری که باشید که ضرورتاً غیر قابل پیش‌بینی رشد می‌کند؟ چقدر باید پویا باشید تا این کار معنا داشته باشد؟
قطعاً جالب‌تر است که در شرکتی کار کنید که به سرعت رشد می‌کند. اگر بخواهید ارزش سهامتان افزایش پیدا کند. اگر بارکاریِ ایستا یا تدریجاً کاهنده‌ای دارید، بهتر است که به همان حال رهایش کنید. کسب و کار DVD هنوز تحت یک بستر یکپارچه روی کامپیوترهای بزرگ قدیمی IBM در حال اجراست و فکر نمی‌کنم که کد آن را در سال‌های اخیر عوض کرده باشند و هنوز هم شش میلیون کاربر دارد. فکر می‌کنم به حدود دوازده میلیون هم رسید و دوباره به شش میلیون برگشت. Netflix هم اکنون پنجاه میلیون کاربر دارد که پخش بلادرنگ می‌کنند. این رشد آن چیزی است که هدایت کننده بود. در صورتی که بار کاریتان قابل پیش‌بینی باشد می‌توانید بهینه‌سازی کنید. اما بارهای کاری قابل پیش‌بینی در جاهایی هستند که کارکردن در آن خسته‌کننده است‌ :) دو راه وجود دارد که می‌توانید به کسب و کار فکر کنید: اگر به یک کالا یا در واقع خدمت سودمند تبدیل شده‌اید، باید هزینه را بهینه و قابل پیش‌بینی کنید و فناوری‌های بسیاری برای این کار وجود دارد. اما اکنون در بسیاری از کسب و کارها، دنیا با چنان سرعتی در حال توسعه است که آن‌چه که واقعاً مهم است این است که با چه سرعتی می‌توانید یک چیز جدید را توسعه دهید. به محض این‌که به این نقطه برسید، سرعت توسعه‌ی نرم‌افزار یک مسئله‌ی کلیدی می‌شود که برای تمامی کسب و کارها مفید است. یعنی زمانی‌که همه چیز بر مدار نرم‌افزار هدایت می‌شود و اینترنت اشیاء گریبان‌گیر همه شده است. اگر همه‌چیز بر اساس نرم‌افزار باشد و نرم‌افزار طولانی‌ترین بخش توسعه‌ی هر چیزی باشد، [آنگاه سرعت توسعه نرم‌افزار اهمیت می‌یابد]. آن‌چه که من می‌بینم این است که فضای ابری بخشی از این افزایش سرعت است. تمام آن نیست، اما بخشی از افزایش سرعت توسعه‌ی نرم‌افزار است. این یک مسئله‌ی عمومی است که همه سعی دارند نحوه‌ی استفاده از آن را یاد بگیرند.
من سعی می‌کنم که این مصاحبه را به سمت کسب و کار نبرم هر چند جالب خواهد بود. اما هنوز می‌خواهم در مورد سه چیز بپرسم: رشد، کاهش هزینه و افزایش سرعت. به نظر می‌رسد که نظر شما این است که بهینگی باید بیشتر در رشد و سرعت باشد و کم‌تر در هزینه. درست است؟
تعداد زیادی شرکت هستند که هزینه‌های سنگین و متورمی در زیرساخت دارند. آن‌ها سیستم‌های بسیار پیچیده‌ی ذخیره‌سازی SAN دارند که از فروشندگان پرهزینه تهیه می‌کنند. اگر این شرایط شماست، مهاجرت به فضای ابر عمومی، معمولاً هزینه‌ی کم‌تری دارد، جایگزینی با یک چهارچوب [سخت‌افزاری] معمولی است. می‌توانید آن را به ساعت در زمان نیاز بخرید. مجبور نیستید پیش از نیاز آن را بخرید. ساختارهای نرم‌افزاری و متن‌باز بیشتری در آن‌جا دارید. اگر این گذار را به عنوان بخشی از گذار به فضای ابری انجام می‌دهید، معمولاً با کاهش هزینه همراه است. اگر از سخت‌افزارهای معمول با نرم‌افزارهای متن‌باز و از مراکز داده استفاده می‌کنید، هزینه‌ها وابسته به کاری که می‌کنید، نحوه‌ی انجام آن، و میزان ظرفیت مورد نیاز شماست. قطعاً ممکن است بتوانید چیزی ارزان‌تر از فضای ابری بسازید اما باید آن را به همان نحوی که فضای ابری ساخته شده است، بسازید که بسیاری از سازمان‌های بزرگ این‌طور نیستند. اگر تعداد کامپیوترهایشان را بر کل بودجه‌ی IT تقسیم کنید، متوجه می شوید که آن‌ها چند دلار بابت هرکامپیوتر در ساعت پرداخت می‌کنند که در فضای ابری حدود چند سنت در ساعت است.
یکی از چیزهایی که به آن اشاره کردید این است که اگر به فضای ابری منتقل شوید از دید معماری تغییراتی رخ می‌دهد. شاید مجبور شوید نرم‌افزار را به شکل دیگری بسازید. به نظر شما هنگام تصمیم‌گیری به انتقال به فضای ابری چه چیزهایی تغییر می‌کند؟
می‌توانید از فضای ابری به عنوان راه سریع‌تری برای انجام کارهایی که در مرکز داده انجام می‌دادید استفاده کنید. به نظر من این بخش زیادی از مزایا را از دست می‌دهد. مزیت واقعی زمانی به دست می‌آید که کارهایی بکنید که در مراکز داده نمی‌توانستید انجام دهید. به راحتی می‌توانید آزمایش‌های سخت‌افزاری در مقیاس بسیار بزرگ (با کامپیوترهای پراکنده در سراسر دنیا) انجام دهید که تنها چند روز طول می‌کشد. دیگر نیازی نیست که به واحد عملیات بروید و از آنان پایگاه‌داده‌ای توزیع شده در سراسر دنیا با ۱۰۰ گره و چندصد ترابایت SSD و ... بخواهید که تا بعد از ظهر آماده شود! ما این کار را در Netflix انجام دادیم. بدون گرفتن اجازه حدوداً بیست دقیقه طول کشید. می‌خواستیم آزمایشی در رابطه با نوشتن شدید در پایگاه‌داده‌ای توزیع شده در سراسر دنیا انجام دهیم و ببینیم چه می‌شود. این تصمیم را در یک جلسه گرفتیم. بعد از ظهر ساخته شده بود و ۱۸ ترابایت داده از نسخ پشتیبان ما بر روی آن ریخته شده بود در همه دنیا گسترده شده بود. هرجور مشکلی که می‌توانستیم با شدت برایش ایجاد کردیم تا اطمینان یابیم که خوب کار می‌کند. دو سه روز بعد آن را پاک کردیم. ۹۶ ماشین بود که هرکدام ۶ گیگابایت RAM داشت و دوترابایت فضای ذخیره‌سازی SSD داشت. با زیرساخت ثابت، نمی‌توانید این کار را انجام دهید. چون حتی گرفتن تأیید خرید یک ماشین چند میلیون دلاری زمان زیادی می‌برد. من حتی نمی‌دانم واقعاً چقدر هزینه می‌برد اما [در فضای ابری] ساعتی چند صد دلار هزینه داشت. هفته‌ی بعد به جلسه رفتیم و اثبات کردیم که کار می‌کند. وقتی که با کدی که کار می‌کند یا نمونه نتایج خود وارد جلسه‌ای شوید، در مباحثات برنده‌ می‌شوید. این بحث وجود داشت که چطور می‌توانیم این را توزیع‌شده انجام دهیم؟ آیا می‌توانیم به آن اطمینان کنیم؟ در یک ابر جهانی، چه پهنای باندی می‌توانیم از آن بگیریم؟ در بخشی از آن ما ۹ گیگابایت پهنای باند گرفتیم. در واقع این تمام بحث‌ها را خاتمه می‌دهد به این شکل که می‌گوییم: این کار می‌کند، اثباتش کردیم! [طرف مقابل:] باشه، فکر کنم می‌توانیم ازش استفاده کنیم. به جای صرف مدت زیادی برای توجیه و بحث و ... یک اتصال کوتاه برقرار کردیم.
درواقع یعنی امکان آزمایش کردن و قابلیت آزمودن چیزهاست.
اساساً کاهش ریسک. چیزهایی که ممکن است کار نکند را می‌آزمایید تا ببینید کار می‌کنند یا نه. موارد بسیاری هستند که این روش، قدرت‌مند بوده است.
آیا این نرم‌افزار واقعی اجرایی را هم تحت تأثیر قرار می‌دهد؟ آیا به خاطر اجرا شدن در فضای ابری آن را به شکل دیگری ساختید؟ اگر روی مرکز داده بود آن را به شکل دیگری می‌ساختید؟
بله. به شکلی ساخته شده است که پویا باشد. فکر کنم می‌خواهید در مورد ارتش میمون ها صحبت کنید. این در مورد قواعد معماری بازار ( Marchitecture ) است؛ افراد در مورد میمون آشوب‌گر ( Chaos Monkey ) شنیده‌اند که در‌واقع برای اجبار کردن یک قاعده معماری است.
می‌شود بگویید میمون آشوب‌گر چیست؟ مطمئن نیستم همه بدانند که چیست.
قاعده را توضیح می‌دهم و بعد مشخص می‌شود که چرا منطقی است. در حال حاضر یک قیاس میان حیوانات خانگی با گاوهای دام ( Cattles vs. Pets ) وجود دارد. تعدادی سخنرانی در این مورد دیده‌اید. اگر کامپیوتری در محیط عملیاتی دارید که نام آن را می‌دانید و اگر دچار مشکل شود همه ناراحت می‌شوند، این یک حیوان خانگی است. مثل گربه‌ی خانگی شماست، اگر مریض شود باید آن را پیش دام‌پزشک ببرید. نوع دیگر کامپیوترها، گاوهای دام هستند. در مورد دام‌های یک مرتع شنیده‌اید. مقداری زیادی شیر می‌گیرید، اگر تعدادی از آن‌ها بمیرند، آن‌روز کمی کم‌تر شیر می‌گیرید تا گاوهای بیشتری بخرید :) قاعده‌ای که Netflix اتخاذ کرد این بود که هرچیزی در محیط عملیاتی گله‌ای از گاوهای دام‌ است. همه چیز خودمقیاس‌پذیر (Autoscale) است. هیچ حیوان خانگی‌ای وجود ندارد، هیچ کامپیوتری نیست که اگر به مشکل بر بخورد برای کسی مهم باشد. وقتی که این قاعده را برقرار کنید، باید آن را بیازمایید؛ بچرخید و تعدادی از کامپیوترها را به تصادف خراب کنید. این کاری است که میمون آشوب‌گر انجام می‌دهد. زمانی که بیدار باشد، بین ۵ تا ۹ ماشین را انتخاب کرده و آن‌ها را خراب می‌کند: ببخشید، این گاو مرد! در این شرایط سامانه به صورت خودکار تناسب را با جایگزینی برقرار می‌کند. اگر کسی به صورت مخفیانه یک کامپیوتر خاص را وارد محیط عملیاتی کرد و میمون آشوب‌گر آن را خراب کرد و این باعث ناراحتی شد، اشتباه از اوست [نه میمون]؛ نباید این کار را می‌کرد. بنابراین این قاعده‌ی معماری، فرآیندی است که توسعه‌دهندگان را مجبور می‌کند که به شکل جدیدی فکر کنند.
بنابراین هر چیزی که ترتیب می‌دهید خودمقیاس‌پذیر (Autoscale) است وی هر کامپیوتری در گروه باید فاقد حالت و قابل ازدست‌رفتن باشد که بتواند مجدداً راه‌اندازی شود. آن‌ها این را یک مرحله پیش‌تر بردند: ماشین‌های لایه‌ی داده را هم خراب کردند که در‌واقع یک مخزن داده ۳ بار رونوشت‌شده Cassandra بود، حتی دیسک‌های درون آن‌ها را هم خراب کردند. وقتی یک نمونه را پاک می‌کنید، ممکن است چند گیگابایت داده را از دست بدهید چون یک مدل ذخیره‌سازی الحاقی نیست بلکه دیسک داخل نمونه‌ها قرار دارد اما این اطلاعات جایگزین و با دونسخه‌ی دیگر همگام‌سازی می شود. این ثابت می‌کند که می‌توان یک لایه‌ی داده‌ی بی‌دوام (Ephemeral) هم ساخت. این نوع دیگری از فکر کردن است؛ در مقایسه با طرز فکر مرکز داده که می‌گویید این کامپیوترها باید همواره کار کنند و بی‌نقص‌اند. به جای این‌کار از ناوگان یا گله‌ای از کامپیوترهای استفاده می‌کنید که خیلی مقاوم است چون می‌توانید تعداد زیادی از آن‌ها را از دست بدهید و همه چیز همچنان کار کند.
برای اتصال مجدد در زمان اجرا از چه چیزی استفاده کردید؟ تصور من این است که باید نوعی ترازگر بار ثبت شده (Load Balancer) وجود داشته باشد -حال چه مجازی باشد یا نه- که بداند با چه کسی صحبت کند و یا چه کسی عضو گروهی است که می‌خواهد با آن صحبت کند و چطور این کار را رسیدگی کند. آیا مجبور شدید خودتان آن را بسازید یا توانستید از چیزهای فراهم در پلتفرم استفاده کنید؟
دو جواب برای این سؤال وجود دارد. در لبه‌هایش، چیزهایی وجود دارد که از منظر خارجی قابل رؤیت هستند. مثلاً یک DNS وجود دارد که باید به واسط برنامه‌نویسی شناخته شده‌اش مراجعه کنید و ساده است. DNS یک نام را می‌گیرد و آن را معمولاً در سه ناحیه (Zone) در AWS پخش می‌کند. ما از ترازگر بار کشسان آمازون (Elastic Load Balancer: ELB) استفاده کردیم. سطح اول ELB یک جداکننده DNS است که اساساً درخواست‌ها را به روش چرخشی (Round Robin) میان سه ناحیه تقسیم می‌کند. لایه‌ی بعدی مجموعه‌ای از کامپیوترها هستند که به لحاظ منطقی چیزی مانند HAProxy را اجرا می‌کنند. شما کامپیوترهای پشت کار (Back-end) را در آن ثبت می‌کنید و [این لایه] سلامت آن‌ها را بررسی می‌کند و حوضچه‌ای از خدمات و کامپیوترهای خدمت‌رسان را پشت ترازگر بار -لایه‌ای از تعداد زیاد سرور‌های پروکسی- نگه‌داری می‌کند. این لبه کار است. اساساً یک گروه خودمقیاس‌پذیر دارید و آن را در ترازگر بار ثبت می‌کنید و AWS به کامپیوترهایی که داخل و خارج می‌شوند رسیدگی می‌کند.
این لبه‌اش است اما وقتی داخل سامانه می‌شوید، می‌خواهید که بتوانید بین کامپیوترها صحبت کنید. این کار را می‌توانید از طریق یک گذرگاه پیام یا چیز شبیه به آن انجام دهید اما آنچه Netflix استفاده می‌کند یک ثبت‌گر سرویس (Service Registry) است که مقدار زیادی فراداده داخلش قرار می‌گیرد و Eureka نام دارد که یکی از پروژه‌های متن‌باز است. اساساً یک سرور Tomcat جاوا است که برای این استفاده، تخصیص یافته است. همه هر سی ثانیه یک بار آن را فراخوانی می‌کنند و می‌گویند که من اینجا هستم و این اطلاعات من است. فراخوانی دیگری هم هست که تقریباً هر سی ثانیه انجام می‌شود و می‌گوید به من بگو بقیه کجایند. در نتیجه نقشه‌ای از جهان از او می‌گیرد که تمام نمونه‌ها و نام‌ها و فراداده‌های مربوط به آن‌ها را دریافت می‌کند. بنابراین زمانی که می‌خواهید یک سرویس را با نام آن فراخوانی کنید آن را در این نقشه پیدا می‌کنید. معمولاً می‌گویید فلان سرویس را می‌خواهید و نسخه‌ی آن برای‌تان مهم نیست و پاسخ می‌گیرید که فلان نسخه، آخرین نسخه است که ترافیک به سمتش می‌رود و نمونه‌ای در فلان جا هست و آن را فراخوانی می‌کنید. مثلاً معمولاً نمونه‌ای که در ناحیه (Zone) یکسانی باشد را فراخوانی می‌کنید.
در این زمینه پروژه‌ متن بازی به نام Ribbon نوشته شده است که حول کتابخانه‌ی Jersey است و نوعی کلاینت Http جاوا است که در کد سمت کلاینت مربوط به بستر تعبیه شده است. مؤلفه‌ای هم در سمت سرور وجود دارد که در واقع، یک سرور پایه است و نام آن Karyon است. این دو با Eureka کار می‌کنند تا یکدیگر را پیدا کنند و فراخوانی‌های مستقیم را به روشی بسیار دسترس‌پذیر، انعطاف‌پذیر و با گزینه‌های بسیار برای مسیریابی ترافیک، انجام دهند.
خیلی دوست دارم که ساعت‌ها فقط در مورد این کتابخانه‌ها صحبت کنم. اما کمی به سطح بالاتر برویم. چطور مشکلات خودراه‌اندازی (Bootstrap) را حل کردید؟ خود Eureka چطور در دسترس می‌ماند و رونوشت (Replicate) می‌شود؟ چون نمی‌تواند از خودش استفاده کند، درست است؟
خوب، سرویس‌های مستقل دیگری وجود دارند. بنابراین نحوه‌ی آرایش به این شکل است که یک منطقه AWS را می‌گیرید و سه ناحیه را در آن منطقه اختیار می‌کنید؛ چون می‌خواهید همه چیز سه بار رونوشت شود. بعد یک نسخه از Eureka را هر ناحیه اجرا می‌کنید و آن‌ها به سرویس نام route53 هدایت می‌شوند و یک DNS می‌سازند و خود را در DNS ثبت می‌کنند. بنابراین یک DNS وجود ندارد که اگر برود [مشکلی ایجاد شود]. می‌توانید به هریک از این سه مراجعه کنید البته معمولاً نسخه‌ی محلی را ترجیح می‌دهید. یک پروتکل جانبی وجود دارد که اطلاعات یک سمت را در دیگری تکرار می‌کند تا سه نسخه وجود داشته باشد.
در واقع سیستم خیلی قوی است. اگر با تئوری CAP آشنایی داشته باشید، اکثر سرویس‌های هماهنگ‌سازی ( ‌‌‌Coordination) از نظر من زیادی سعی می‌کنند که سازگار (Consistent) باشند؛ یعنی زمانی که سامانه را تفکیک (Partition) می‌کنید،‌ به شکل بدی شکست می‌خورند: نمی‌توانند به سازگاری برسند و بنابراین دست از کار می‌کشند. Eureka یک سامانه‌ی AP است: به هنگام انفکاک، در دسترس است. سامانه حتی زمانی که تمامی گره‌ها را خراب کنید، کار می‌کند. این چیزی است که برای مدتی توسعه داده می‌شد، چون به تدریج شکست رخ می‌دهد. بنابراین، اساساً می‌توانید تمامی سرویس‌های نام را از دور خارج کنید و همه چیز همچنان کارخواهد کرد، فقط نمی‌توانید کامپیوتر جدیدی برای آن سرویس اضافه کنید. وقتی که Eureka مجدداً راه‌اندازی شود وضعیتش را بارگذاری می‌کند و مجدداً همه چیز را کشف می‌کند. اساساً طوری ساخته شده است که بسیار دسترس‌پذیر و قدرتمند باشد به جای این‌که سعی کند -مثلاً به مانند روشی که ZooKeeper انجام می‌دهد- سازگار باشد. ما به این فکر هم افتادیم آن را بر اساس ZooKeeper بسازیم اما ZooKeeper این حالت‌های شکست را دارد که آن را نامطلوب‌تر می‌کند.
می‌توانید حدود ۶۰ ثانیه در مورد تئوری CAP صحبت کنید؟ این‌که کدام بخش‌هایش را به کار می‌برید و یا با کدام بخش آن پیوند دارید یا در Netflix داشتید؟ آیا AP روش مرسومی است که شما چیزها را می‌سازید؟
منظورم این است که سرانجام باید تصمیم گرفت که سازگاری یا دسترس‌پذیری است که برای شما اهمیت بیشتری دارد. از نظر فیزیک‌دانان همه‌چیز در واقع ناسازگار است، به خاطر نظریه‌ی نسبیت انیشتین. اما قاعده‌ی اصلی در Netflix این است که هیچ انفکاک یا شکستی نباید یک سرویس را از دسترسی خارج کند. ما قطعاً در زمان انفکاک به شدت به سمت دسترس‌پذیری تکیه داریم. این به این معنی است که اگر Netflix را تفکیک کنید و تمام شبکه‌های میان آن را قطع کنید همچنان به کار ادامه می‌دهد؛ سامانه‌های منفرد به کار خود ادامه می‌دهند و به مرور از سازگاری با سایر سامانه فاصله می‌گیرند. زمانی که آن را مجدداً متصل می‌کنید معمولاً آخرین نوشتن ثبت می‌شود؛ Cassandra وارد کار می‌شود و هر کسی که آخرین نوشتن را انجام داده باشد، اطلاعات بقیه را بازنویسی می‌کند. بنابراین در نهایت به حالت سازگار بازمی‌گردد و ممکن است برخی تغییرات از دست بروند یعنی اگر چیز را تغییر بدهید که جای دیگری هم تغییر کرده باشد. عموماً بهتر است که با مشکلات ناسازگاری سروکار داشته باشیم تا از دسترس خارج شویم. برای خدمتی مثل Netflix که پنجاه میلیون نفر در سراسر دنیا می‌خواهند فیلم ببینند، انتظار دارند که وقتی تلویزیون را روشن می‌کنند، باید کار کند و نباید پیغام بدهد که ببخشید، ما فعلاً در دسترس نیستیم! سخت است که به یک بچه‌ی سه ساله بگوییم نمی‌توانی کارتون دایناسورها را ببینی چون Netflix در دسترس نیست! درست است؟
فکر می‌کنم واضح است که در این کاربرد خاص، خیلی متقاعد کننده است. برای حساب‌داری یا پرداخت قبوض چطور؟ یا موارد کاربردی دیگری که افراد معمولاً انتظار سازگاری ۱۰۰٪ دارند چون خیلی به آن عادت کرده‌اند؟ یا این‌که این قاعده را به طور کلی به کار می‌برید؟
این قاعده در مورد مشتریانی که با قطعی خدمات مواجه‌اند، به کار می‌رود. اگر دکمه‌ی پخش را می‌زنید باید فیلم پخش شود. هر چیزی که در حلقه‌ی انجام این کار قرار دارد باید خیلی دسترس‌پذیر باشد. چیزهایی در پشت صحنه هست که لازم نیست خیلی دسترس‌پذیر باشد، مثلاً سامانه‌های پرداخت قبوض بیشتر باید سازگار باشند اما این‌ها در این حلقه قرار نمی‌گیرند. به طور خاص در Netflix این‌طور است.
یا مثلاً در فرایند ثبت نام، شما نمی‌خواهید که کاربری در حین ثبت نام از قلم بیفتد چون به علتی نمی‌توانید در این لحظه کارت اعتباری آنان را تأیید کنید. می‌توانید بگویید فعلاً از خدمات استفاده کن و تأیید را بعداً بصورت ناهمگام انجام دهید. اما اکثر برخی چیزها هست که می‌خواهید سازگار باشند. این‌ها معمولاً چیزهای کم ترافیک هستند که به خدمت‌رسانی مربوط نمی‌شوند. بنابراین این چیزها را در فضای دیگری تقسیم می‌کنید. چیزهایی مثل ZooKeeper به شما این قابلیت را می‌دهند که مسدودشدن‌های (Blocking) بصورت سراسری سازگار داشته باشید، چیزهایی داشته باشید که بیشتر مشابه تراکنش‌ها هستند، چیزهایی که را تحمیل می‌کنند، انتخاب پیشوا (Leader Election) و … . اما عموماً در بخش‌هایی که مشتری با آن مواجه می‌شود، از آن دوری می‌کنید. این تمایز در Netflix کاملاً رعایت می‌شود.
درست به نظر می‌رسد. یکی از چیزهایی که در ابتدای برنامه به آن اشاره کردید، برنامه‌ای بود که به ارسال DVD ها رسیدگی می‌کرد و یکپارچه (Monolithic) بود. موضوعی که می‌دانم به آن علاقمند هستید این است که یک برنامه‌ی یکپارچه را به واحدهای کوچک‌تر که امروزه به آن‌ها ریزسرویس (Microservice) می‌گویند تقسیم کنید. آیا این قاعده را در Netflix به کار بردید؟ نتیجه‌ی آن چه شد؟
در آن زمان به آن ریزسرویس نمی‌گفتیم. اما آنچه متوجه شدیم این بود که در آن زمان Netflix حدود صد توسعه‌دهنده داشت که یک [نرم‌افزار] یک‌پارچه را می‌ساختند و همواره روی کدهای یکدیگر متوقف می‌شدیم. این یک مشکل خیلی معمول است. دو مشکل با [نرم‌افزار] یک‌پارچه وجود دارد که با بزرگ‌شدن مقیاس مشکلات بزرگی می‌شوند. زمانی که دو یا سه نفر کد می‌نویسند مهم نیست. عموماً افراد با نوشتن یک برنامه‌ی یک‌پارچه شروع می‌کنند چون سریع‌ترین راهی است که می‌شود کاری را انجام داد. سرانجام سازمان بزرگ می‌شود و ویژگی‌های مختلفی دخیل می‌شود. این بد نیست اما مقیاس‌پذیری آن در سازمان‌های بزرگ سخت است.
ما دو مشکل داشتیم: یکی این که همه می‌خواستند شئ فیلم را تغییر دهند و همه می‌خواستند شئ مشتری را تغییر دهند، تقریباً در هر تغییری که در کد داشتند. بنابراین وقتی که کدتان را توسعه می‌دادید، تعدادی فایل jar را می‌خواندید و تضمین کیفیت، این فایل‌ها را برمی‌داشت و سعی می‌کرد آنان را در تمام شاخه‌ها (‌Branch) ادغام کند و آخرین نسخه‌ی کد را بیرون بدهد. این باعث انواع بدی از تصادم‌ها و مشکلات می‌شد و مدام باعث تحویل دیرتر کدها می‌شد. چون مرحله‌ی ادغام سخت‌تر و سخت‌تر می‌شد و تضمین کیفیت تبدیل به گلوگاه شده بود چون همه کدهای یکدیگر را تخریب می‌کردند. این یک مشکل بود. راه‌حل آن جداسازی کد و تفکیک تیم‌ها است؛ به نحوی که هر مهندس- به جای توسعه‌ی یک فایل jar که به jar فایل‌های همه افراد دیگر وابستگی شدیدی دارد- یک سرویس را توسعه می‌دهد که اتصالات واضحی -در فراخوانی‌های REST یا هر واسط دیگری- به کدهای دیگران داشت. این به این معنی است که درهم پیچیدن اشیاء دیگر نمی‌تواند اتفاق بیافتد چون در فضاهای آدرس متفاوتی هستند.
چه تعداد از این‌ها را در Netflix ساختید؟ دنبال عدد دقیق نیستم، چند دوجین؟ صدها؟
اجازه بدهید که به دلیل دیگر مشکل‌ساز در [نرم‌افزار] یک‌پارچه بپردازیم. مشکل این است که اگر تلاش کنید که بروزرسانی‌های هفتگی را تحویل دهید -مثلاً Netflix هر دو هفته این کار را انجام می‌داد- اگر یک چیز خراب می‌شد باید به عقب برمی‌گشتید. ۹۹ چیز دیگری هم که تحویل شده بودند باید برمی‌گشتند چون بخشی از انتشار بودند. درست است؟ بنابراین یک چیز خراب همه‌چیز دیگر را مسدود می‌کند. این مشکل دیگر است. در بخش عملیات تحویل، این مشکل وجود دارد. به نحوی این مشکل مشابه تیم تضمین کیفیت در بخش عملیات است، درست است؟
بله.
بنابراین تقسیم چیزها به بخش‌های جداگانه که می‌توانند به طور مستقل استقرار پیدا کنند این مشکل را برطرف می‌کند. در این صورت شما توسط کد فرد دیگری مسدود نمی‌شوید. همه چیز روان‌تر می‌شود. اتفاقی که می‌افتد این است که چند صد مهندس دارید که هر کدام سرویس خودشان را می‌سازند و به سرعت چند صد سرویس دارید. الان Netflix شاید بین ۵۰۰ تا هزار سرویس داشته باشد. نسخه‌های مختلفی از سرویس‌ها هم وجود دارند. چون زمانی که نسخه‌ی جدیدی را راه‌اندازی می‌کنید، نسخه‌ی قبلی را تعطیل نمی‌کنید. چون الان این لایه اطلاعات را در Eureka دارید که مسیریابی ترافیک را بین چیزها رسیدگی می‌کند و از نسخه‌ها آگاه است. بنابراین اگر سرویسی دارید که به نسخه‌ی سه از سرویس دیگری احتیاج دارد، نسخه‌ی سه همواره آنجاست، حتی اگر نسخه‌ی چهار و پنج راه‌اندازی شده باشند. اگر کس دیگری به ویژگی جدیدی از آن سرویس نیاز داشته باشد از نسخه‌ی پنج استفاده می‌کند، اما این کار شما را که از نسخه‌ی سه استفاده می‌کنید، مختل نمی‌کند. سرانجام [شما هم] به نسخه‌ی جدیدتری از کتابخانه ارتقاء می‌دهید و دیگر نسخه‌ی سه استفاده نمی‌کنید و در عوض از نسخه‌ی پنج استفاده می‌کنید. اما این کار استقرار نسخه‌ی جدید را از ترخیص نسخه‌ی قدیمی تفکیک می‌کند. همیشه نسخه‌ی جدید را به صورت همگام انجام می‌دهید، اما ترخیص نسخه‌ی قدیمی را به صورت ناهمگام انجام می‌دهید. گاهی به این کار الگوی کد تغییرناپذیر یا سرور تغییرناپذیر ( Immutable Server ) می‌گویند چون کد عملیاتی را تغییر نمی‌دهید بلکه نمونه‌ی دیگری از کد جدید در کنار کد قدیمی راه‌اندازی می‌کنید. البته مشکل این کار این است که شکل معماری شما شبیه چیزی به نام ستاره‌ی مرگ ( Death Start ) می‌شود: تعداد زیادی از نقاط با خطوط میان آن‌ها که در یک دایره قرار دارند و معماری ساده‌تری وجود ندارد که بتوان آن را نشان داد. اما این جریان واقعی کسب و کار را منعکس می‌کند. می‌توانید یک سرویس را در نظر بگیرید [و تنها ارتباطات آن را در نظر آورید] چون این، آن‌چیزی است که واقعاً مهم است. اگر با اریک ایوانز درباره‌ی طراحی برآمده از حوزه (Domain Driven Desing) صحبت کنید -فکر می‌کنم با او مصاحبه کرده باشید- مفهومی به نام زمینه‌ی کران‌دار ( Bounded Context ) وجود دارد. کاری که شما با ریزسرویس‌ها می‌کنید این است که یک زمینه‌ی کران‌دار ایجاد می‌کنید که می‌گوید: این‌ها مصرف‌کنندگان سرویس من هستند، این‌ها وابستگی‌های سرویس من هستند و لازم نیست چیزی بیش از این بدانم. سپس من می‌توانم سرویس‌ام را توسعه دهم و [توسعه‌ را] تکرار کنم و آن را به بسیاری چیزهای دیگر که در واقع هیچ ربطی به من ندارند، وصل نکنم. بنابراین تمرکز روی این زمینه‌ی کران‌دار برای توسعه‌دهندگان خیلی پربارتر است.
تعداد سرویس‌‌ها، نسخه‌های متفاوتی که از آن‌ها وجود دارد، و ارتباطات و همکاری آن‌ها با هم برای ارائه‌ی یک قابلیت دارای نمود برای مشتری، … همه این موارد چطور در تحلیل مشکلات تأثیر می‌گذارد؟ اگر اشتباهی رخ دهد چه کار می‌کنید؟ آیا به شدت سخت نیست که علت خطا را تشخیص دهید؟ چون تعداد قطعات در حال حرکت خیلی زیاد هستند.
به ظاهر پیچیده‌تر از آن‌چیزی است که هست. از بیرون بی‌نظم به نظر می‌رسد اما در واقع پیدا کردن علت خطا [نسبت به پیدا کردن خطاها در برنامه‌های یکپارچه] آسان‌تر است. چون اگر یک jar فایل در خلال اجرای یک برنامه‌ی یک‌پارچه خراب شود، فهمیدن این‌که واقعاً چه چیزی شکست خورده، خیلی دشوار است، چون همه چیز در هم پیچیده شده است. ما معمولاً ایمیل‌هایی داشتیم که همه در [بخش] مهندسی می‌گفتند: «این نسخه خراب است نمی‌تونیم بفهمیم چرا. می‌شه همه یه نگاهی بندازید و ببینید که چیزهای خودتون درسته؟» این یکی از دلایلی است که ما به سراغ ریزسرویس‌ها رفتیم. حالا یک کران دارید: کران شکست. این سرویس خراب است: آن را فراخوانی می‌کنید و خطا می‌دهد. واضح است که خراب است. یا این‌که حافظه کم می‌آورد و خود را نابود می‌کند چون نوعی نشتی حافظه یا زباله‌روب (Garbage Collector) دارد یا این‌که مشکلی مربوط به پردازنده دارد و همه‌ی انواع دیگری از مشکلات که می‌توانند پیش بیایند؛ اکنون [همه‌ی این مشکلات] در سطح یک نسخه‌ی خاص از یک سرویس مهار شده‌اند.
به سامانه‌ی خود نگاه می‌کنید و [می‌بینید] که یک خدمت خاص تعداد زیادی خطا در وقایع خود ثبت کرده است؛ پس اشکالی دارد، درست است؟ خوب، چه کسی این را نوشته است؟ بله او را می‌شناسم، می‌روم و صدایش می‌کنم. [فرض کنید] برای [خرابی]‌ هر ریزسرویسی در PagerDuty یک درخت فراخوانی قرار می‌دهید. مشکل این کار این است که شکست‌ها معمولاً یک لایه بالاتر از علت اصلی‌شان رخ می‌دهند. بنابراین وقتی که یک سرویس خراب داشته باشید سرویس‌های وابسته به آن هم به شکست می‌گرایند. یک تأثیر جالب آن که رخ می‌داد این است که در نهایت API جلوکار در همه فراخوانی‌ها وجود داشت. چون هرچیزی که شکست می‌خورد در API نمایان می‌شد و باید در وابستگی‌هایش کنکاش می‌کردیم تا بفهمیم واقعاً چه اتفاقی افتاده است. بنابراین تیم API تصمیم گرفت، سامانه‌ای توسعه دهد که انگشت [اتهام] را به سمت افراد بگیرد و بگوید که [سرویس] آن‌ها خراب است. در واقع این ابزار خیلی محبوب شده و نامش Hystrix است و یک الگوی مدارشکن ( Circuit Breaker ) است.
در واقع اتفاقی که افتاد این بود که نسخه‌ای از کتاب Michael Nygard گرفتم و آن را منتشر کردم :). آن‌ها کتاب را خوانده و دسته‌ای از الگوها را پیاده‌سازی کردند. کاری که ما باید می‌کردیم این بود که مدارشکن‌ها را بسازیم. وقتی مدارشکن‌ها را داشته باشید، سرور API می‌تواند تمام وابستگی‌هایش را در این مدارشکن‌ها بپیچد و اگر مشکلی ببیند مدارشکن را فعال کرده و می‌گویند من خراب نیستم بلکه فلانی خراب شده است. انگشت اتهام را نشانه می‌گیرد و این به PagerDuty می‌رود. تیم API می‌تواند شب را بخوابد و تماس به هر کسی که وابستگی مشکل‌ساز را داشت منتقل می‌شود.
این به این معنی است که نمی‌توانید مشکلات خود را به گردن تیم عملیات بیندازید؛ چون توسعه‌دهندگان گوش به زنگ (On Call) هستند، یاد می‌گیرند کدهای قدرتمند بنویسند و سامانه‌هایی بسازند که نقاط مشکل‌ساز واقعی را نشان می‌دهند و خیلی قابل خطایابی هستند.
اگر چیزی را مشکل دیگری جلوه دهم، مجبور نیستم آن را حل کنم اما در واقع بهتر است که مشکلات مستقیماً به خود شما بیاید تا اینکه مشکلات بیشتری ایجاد کند و این نوع دیگری از فکر کردن نسبت به توسعه‌دهنده‌ی عادی یک سامانه معظم است. در نهایت شب‌ها بهتر می‌خوابید چون کدتان کار می‌کند و در واقع زمان کم‌تری صرف می‌شود که خودتان خطا را برطرف کنید و آن را اجرا کنید تا این‌که به تیم عملیات توضیح دهید که چه کار کرده‌اید. خصوصاً در یک مدل تحویل مستمر که کدتان را چندین بار در هفته یا در روز به‌روزرسانی می‌کنید.
خیلی هم جالب‌تر است، درست است؟
خوب خیلی جالب نیست که ساعت ۴ صبح بیدار شوید! اما در حقیقت اگر در کار خود شایسته باشید، [این اتفاق] خیلی نامحتمل است. و افرادی که نمی‌توانند راه ساختن سامانه‌های قابل اتکا را پیدا کنند، احتمالاً نباید برای شما کار کنند؛ این هم یک راه دیگر فکر کردن به آن است.
به تعدادی چیز اشاره کردید، برخی‌ها را با نام، برخی‌ها را با مفهوم مثل تحویل مستمر و توسعه و عملیات و البته فضای ابری و ریزسرویس‌ها. چقدر فکر می‌کنید که این‌ها مرتبط‌اند؟ آیا کاملاً مستقل‌اند و صرفاً در کنار هم خوب کار می‌کنند؟ یا این‌که یکی پیش‌نیاز دیگری است؟ نظر شما در مورد این اتصال‌ها چیست؟
فکر می‌کنم در دنیای مدرن که همه چیز مبتنی بر نرم‌افزار است و زمان تحویل نرم‌افزار مهم است، تحویل مستمر واقعاً در حال تبدیل شدن به یک مزیت رقابتی و متمایزکننده است. اگر یک شرکت، ده استقرار در روز انجام دهد نسبت به دیگری که هر شش ماه، یک نسخه می‌دهد در یادگیری، توسعه و پیدا کردن محصول بهتر، خیلی سریع‌تر خواهد بود. این انتقالی است که خیلی از سازمان‌ها در آن دست و پا می‌زنند یعنی انتقال به مدل مبتنی بر خدمت (SaaS) و تحویل مستمر. وقتی سعی کنید این کارها را انجام دهید، شاید برای یک نرم‌افزار یکپارچه بتوانید به هر دو هفته یکبار دست پیدا کنید، اگر Etsy باشید می‌توانید روزی چند بار این کار را انجام دهید اما خیلی سخت است. اگر واقعاً بخواید که نرم‌افزار یک‌پارچه را سریع کنید باید عمیقاً مطالعه کنید که Etsy چطور این کار را کرده است. کاری که آن‌ها کرده‌اند واقعاً حیرت‌آور است اما کاری که اکثر افرادی بخواند انجام دهند، این است که موارد را از هم جدا کنند و زمینه‌های جداگانه‌ی کران‌دار تعیین کنند تا همه چیز بتواند مستقل حرکت کند.
وقتی که استقلال را کسب کنید، تیم‌های مستقل می‌توانند مدیر محصول داشته باشند، می‌توانند تمام توسعه‌ای که روی آن محصول جواب می‌دهد را داشته باشند و می‌توانند عضو دلخواه توسعه و عملیات یا تحویل دلخواه خود را داشته باشند و آن تیم می‌تواند مستقل [محصول] تحویل دهد. این یک تیم سازمانی توسعه و عملیات (DevOps) است، آمازون به آن تیم دو پیتزا می‌گوید. هر چیزی که نامش باشد، آن‌ها مالک همه چیز هستند، از تصمیم‌گیری در مورد کاری که باید انجام دهند گرفته تا تحویل آن و هر چیزی دیگری که حول API آمازون باشد. میزان اعتماد در آن تیم بالا می‌رود و هر چیز خارج از تیم، یک فراخوانی API است و بنابراین یک چیز خارجی نسبتاً غیرقابل اعتماد است و فرض بر آن نیست که فراخوانی‌هایی که خارج از تیم انجام می‌دهید موفق خواهند بود. بنابراین میزانی از اعتماد در این زمینه‌ی کران‌دار وجود دارد و این در واقع مدل توسعه و عملیات است و این همان چیزی است که افراد باید از آن بگذرند تا به توسعه و عملیات دست یابند. چون دیگر چیزی وجود ندارد که مجبور باشید با مسئول ذخیره‌سازی، مسئول شبکه، مدیر سیستم و انواع دیگر تیم‌ها در عملیات در میان بگذارید تا کاری را انجام دهید. این یک تیم کلیدی چندنقشه است که API لازم برای آن را دارد.
این از نظر من دلیل واقعی برای سازگاری فضای ابری و توسعه و عملیات است. منظورم این است که توسعه و عملیات برای این است که واسط میان توسعه و عملیات بهینه شود. در واقع برای رسیدن به توسعه و عملیات (DevOps) دو رهیافت وجود دارد. شما می‌توانید یک فرد عملیات باشید یعنی در کار خودکارسازی کد زیرساخت بهتر باشید و بعد شروع به توسعه کنید یعنی یک فرد عملیاتی که بعداً شروع به توسعه و ساختن واسط‌های بهتر برای فرایندهای توسعه می‌کند. از طرف دیگر، این روش هم هست که افراد تیم توسعه یاد بگیرند کار عملیات را انجام دهند و از فضای ابری به عنوان لایه‌ی خودکارسازی برای فراهم‌سازی زیرساخت خودکارسازی استفاده کنند که Netflix هم از همین‌جا شروع کرد. این دو روش به نوعی در میانه به هم می‌رسند: ابزارهای مشابهی دارند اما گاهاً با مفاهیم متفاوت.
برای برخی از کتابخانه‌هایی که به آن‌ها اشاره کردید مثلاً Eureka ، Ribbon و Karyon کاملاً واضح است که Netflix زمان زیادی را در آن‌ها سرمایه‌گذاری کرده است تا برای اهدافش در بستر قابل استفاده باشند اما بخش زیادی از آن را متن‌باز کردید. دلیل این کار چیست؟ آیا یک دلیل کسب و کاری محض بود؟ آیا می‌خواستید همکاران جدیدی داشته باشید؟ هدف این کار چه بود؟
یک مجموعه از دلایل بود، برخی چیزها هم اتفاق افتاد که ما انتظار نداشتیم. درباره‌ی این یک ارائه داشتم و چهار یا پنج مورد متفاوت است. مورد اول این بود که ما داشتیم از وابستگی به کد تجاری فاصله می‌گرفتیم و الان نمی‌خواهیم با نرم‌افزار سازمانی‌ای سروکار داشته باشیم که برای آن پول زیادی داده باشیم در حالی که متوجه شده بودیم در دنیای متن‌باز دسترس‌پذیری و پشتیبانی بهتری داریم. بنابراین می‌خواستیم مسیرمان را به یک مدل کسب و کار متن‌باز تغییر دهیم که در آن تمام کدی که برای ساختن Netflix از آن استفاده می‌کنیم متن‌باز باشد. تصمیم گرفتیم که گواهی‌نامه‌ی Apache را تغییر دهیم. بنابراین رابطه‌ای با بنیاد Apache برقرار کردیم. وکلای ما با وکلای آن‌ها صحبت کردند و چیزی که از آن حاصل شد توافقی بود که هر مهندس در Netflix می‌توانست از هر محصول دارای گواهی‌نامه Apache بدون نیاز به صحبت با کس دیگری استفاده کند. فقط دانلودش می‌کردید و می‌دانستید که معنی آن گواهی‌نامه چیست. همچنین می‌توانست در رفع مشکلات در هر پروژه‌ی Apache شرکت کند بدون این‌که از کسی تأیید بخواهد؛ یا بخواهید توانایی تعامل با چیزهایی که در ذیل این گواهی‌نامه‌ها قرار دارند را رسمی کنید.
زمانی که ما پروژه‌های خودمان را متن‌باز کردیم، برخی مالکیت‌های معنوی یا امتیازاتی که Netflix در پروژه‌های متن‌باز دارد هنگام متن‌باز شدن آن، در خود پروژه نوشته می‌شوند. اساساً [با این‌کار] یک حالت دفاع از ثبت اختراع می‌سازید که از متن‌باز کردن پروژه‌تان حفاظت می‌کند. این زمینه‌ی انجام کارهاست. این فقط به این خاطر بود که ما می‌خواستیم عضوی از انجمن [تولید کنندگان محصولات متن‌باز] باشیم و می‌خواستیم بقیه بدانند که ما نه تنها دینمان را به آن‌چه فکر می‌کردیم مفید است ادا کردیم بلکه آن‌ها را در مسیر اصلی [توسعه] قرار داده‌ایم. چون نمی‌خواستیم به طور مداوم شاخه‌ها (‌Branch) را Rebase کنیم تا با نرم‌افزاری که در حال توسعه است همراه باشیم؛ می‌خواستیم تغییراتمان در مسیر اصلی قرار داشته باشد. این دلیل اول بود.
دلیل دوم این بود که می‌خواستیم توسعه‌دهندگان بهتری استخدام کنیم و توسعه‌دهندگان واقعاً خوب، پروژه‌های متن‌باز به نام خودشان دارند. برخی از بهترین توسعه‌دهندگان در دنیا چیزهای حیرت‌آوری ساخته‌اند، من می‌خواهم آن‌ها را استخدام کنم. آن‌ها می‌خواهند ببینند که Netflix محل خوبی برای ساختن نرم‌افزار متن‌باز است؛ بنابراین در انتقال به Netflix احساس راحتی می‌کنند. چون Netflix از کار آن‌ها هر آن‌چه که باشد، به عنوان یک پروژه‌ی جانبی حمایت می‌کند.
سومین دلیل -که به نحوی انتظارش را داشتیم اما تأثیر کوتاه مدت به شدت قدرتمند‌تری داشت- این بود که اگر نزد توسعه‌دهنده‌ای بروید و بگویید می‌شود کدت را تمیز کنی؟ تقریباً همیشه در انتهای لیست قرار می‌گیرد. درست است؟ [اما] اگر نزد توسعه‌دهنده‌ای بروید و بگویید می‌خواهی کدت را متن‌باز کنی؟ تمیزکاری کد تبدیل به بالاترین اولویت شب‌ها و آخر هفته‌ها‌یش می‌شود. چون قرار است که نام آن‌ها در کد قرار بگیرد و بخشی از رزومه‌ی دائمی آنان خواهد شد و می‌خواهند که خوب به نظر برسد. بنابراین برخی از بزرگ‌ترین پاک‌سازی‌های کد، مستندات، جداسازی، استخراج کدهایی که در Netflix در هم پیچیده شده بود به صورتی که قابل جداسازی باشد، اینکه بیشتر فکر شده باشد و تمیزتر باشد [به این شکل اتفاق افتاد]. در حقیقت این یک راه خارق‌العاده برای بهبود کیفیت کدی است که استفاده می‌کنید. چون بسیاری از چیزهایی که سایرین در محصولات خود دارند بسیار آشفته‌تر از آن است که دوست دارند به آن اعتراف کنند. چون صرفاً قرار است که کار را انجام دهد. درست است؟ و این منجر به منفعت کوتاه مدت کسب و کار شد. منفعت بلند مدت‌تر این بود که می‌توانید از میان کسانی که کد و معماری شما را می‌شناسند استخدام کنید. می‌توانید ببینید که چه کسانی از پروژه‌ی متن‌باز Fork کرده‌اند و ببینید چه کسی فعال‌تر است. [و به آن‌ها بگویید:] آیا می‌خواهی در Netflix کار کنی و از این کد نگه‌داری کنی؟ به هرحال داری این کار را انجام می‌دهی درست است؟ :) این تبدیل به راهی برای یافتن افراد جالب برای استخدام است و تا اینجا چند باری اتفاق افتاده است.
همه‌ی چیزهایی که متن‌باز کرده‌اید را می‌شود به عنوان چیزی شبیه به یک بستر روی زیرساخت سطح پایین آمازون ارائه کرد. نمی‌دانم آیا موافقید؟
بخشی از آن بله.
به سایر شرکت‌ها در این مورد چه توصیه‌ای می‌کنید؟ آیا همه باید از محصولات Netflix استفاده کنند؟ یا شرکتی که تعداد زیادی توسعه‌دهنده ندارد هم باید محصولات خودش را توسعه دهد؟ افراد چطور باید در این مورد تصمیم‌گیری کنند؟
فکر می‌کنم احتمالاً سه رده‌ی متفاوت از محصولات در Netflix متن‌باز شد. تقریباً چهل و چهار یا پنچ پروژه در آن هست و کمی سخت است که آن‌ها را پیدا کنیم و در حال کار کردن روی آن هستیم. محصولاتی هستند که به طور خاص برای بستر AWS هستند. می‌توانید به آن‌ها مانند نوعی CloudFoundry توسعه‌پذیر نگاه کنید. بستری توسعه‌پذیر و مؤلفه‌بندی‌شده برای انجام همان کارهایی است که CloudFoundry انجام می‌دهد. توسعه‌دهنده‌گان شما به این بستر متصل می‌شوند و می‌توانید کد را به سادگی در سراسر دنیا استقرار دهید. این یک رده [از محصولات] است.
تعدادی ابزار مستقل هم وجود دارد که کاری به بستر خاص ندارد. مثلاً یک ابزار پایش هزینه به نام Ice هست که خیلی خوب است. ابزارهای امنیتی مستقل هم وجود دارند که برنامه‌های Ruby on Rails هستند که به نام Scumblr منتشر شدند و افرادی که تلاش می‌کنند کارهای بدی بر علیه شرکت شما انجام دهند را در اینترنت پیدا می‌کند :) و به تیم امنیت اطلاع می‌دهد تا از حملات DoS یا ویدیوهای یوتیوبی که چیزهای بدی مثل دزدیدن حساب‌کاربری و ... [جلوگیری کنند]. این یک ابزار مستقل است و ربطی به بستر ندارد ولی چیز مفیدی بوده است و چیزهایی زیادی آن‌جا هست.
سومین دسته هیچ ربطی به فضای ابری ندارند. الگوریتم‌ها، کتابخانه‌هایی برای بهتر کردن ZooKeeper و تعداد زیادی تکه‌های مفید دیگر در زمینه‌ی کلان داده‌ها (Big Data). یک کتابخانه‌ی Clojure هم برای صحبت کردن با Pig وجود دارد که PigPen نام دارد.
اجازه دهید کمی موضوع را عوض کنیم و در مورد این‌که این روزها چه می‌کنید صحبت کنیم. چون همان‌طور که اشاره کردید دیگر در Netflix نیستید و عضوی از یک شرکت سرمایه‌گذاری هستید. چه کارهایی انجام می‌دهید که روزتان را سپری کنید؟
تا حدی به نظر می‌رسد کاری که من در Netflix انجام می‌دادم طراحی کلی بود. زمانی زیادی را صرف صحبت کردن در مورد Netflix به عموم می‌کردم. بخشی از آن به این خاطر بود که Netflix توسط مهندسین خوب، بهتر شناخته شود. بخشی به این خاطر بود که الگوهایی که Netflix توسعه می‌داد به بن‌بست‌هایی تبدیل نشود که سایرین کارهایشان را به روش دیگری انجام دهند. به نوعی محافظت از معماری در آینده با توضیح دادن آن به تعداد افراد بیشتری که همین کارها را انجام می‌دادند. این دلیل‌ها بود. زمانی زیادی هم صرف صحبت با سرمایه‌داران می‌کردم و ایده‌هایم را مطرح می‌کردم. به نوعی این دو کار را که فعالیت‌های نیمه‌وقت بودند را به صورت کار روزانه‌ام در آورده‌ام. کاری که الان می‌کنم این است که تمام وقتم را صرف صحبت کردم در مورد ایده‌های نو و حتی زمان بیشتری را صرف سخنرانی در کنفرانس‌ها می‌کنم. بهار آینده به برلین و کوپنهاگن می‌روم. یک جلسه‌ی وب (Web Summit) هم در اروپا هست و تعداد دیگری هم کنفرانس که [عنوان‌شان را] فراموش کرده‌ام.
چه چیزهایی یاد گرفتید یا [طور دیگر بگویم] شرکت‌های دیگر با Netflix چه تفاوتی دارند؟
فکر می‌کنم اتفاقی که افتاده است این است که سازمان‌ها سعی می‌کنند یاد بگیرند چطور خدمات وب را بسازند. این چیزی است که قبلاً ضرورت نداشت. یکی از محرک‌های بزرگ آن این است که به نوعی اینترنت اشیاء در حال رخ دادن برای شرکت‌هاست. یکی از شرکت‌هایی که اخیراً زیاد با Netflix صحبت می‌کند Nike است که امور پشت‌کار (Backend) مربوط به چندین مارک را دراختیار دارد و مشتری‌های خیلی زیادی در جاهای مختلف و انبوهی ترافیک از آن‌ها دارد. آن‌ها می‌خواهند از محصولات متن‌باز Netflix برای ساختن امور پشت‌کارشان استفاده کنند. جای تعجب دارد ولی IBM هم یکی از بزرگ‌ترین کاربران محصولات متن‌باز Netflix است. آن‌ها می‌خواهند یک مجموعه کامل از سرویس‌ها بسازند تا یک لایه‌ی نرم‌افزاری بشود. بعد از ساختن لایه‌ی نرم‌افزاری، آن را مقاوم کرده و سپس امکاناتی به آن اضافه کنند و برای این کار از کد Netflix استفاده کردند. تعداد کمی از شرکت‌ها هم علاوه بر استفاده از کد، از ایده‌های و اختراعات حول آن استفاده کردند.
در حال حاضر سر و صدای زیادی در مورد Docker وجود دارد. من به صحبت‌های سالومن هایکس در مورد این‌که چرا Docker را ساختند، گوش کردم. نحوه‌ی فکر آن‌ها همان قواعد معماری است که من در مورد آن‌ها صحبت می‌کنم. این‌که شما کد را در تصاویر تغییر ناپذیر (Immutable Image) قرار می‌دهید و سپس آن را استقرار می‌دهید، این ایده‌ی Docker است و شما به سرعت زیرساخت پویای خود را مستقر می‌کند. بنابراین یک هم‌پوشانی جالب در اینجا وجود دارد که در حال حاضر با آن دست و پنجه نرم می‌کنم و سعی می‌کنم آن را بفهمم و با دیگران در مورد آن صحبت می‌کنم. تا حدی تبدیل شدن مفهوم ریزسرویس‌ها به مسیر اصلی با کارهایی که من در Netflix می‌کردم در یک راستاست و این بخش زیادی از کارهایی است که الان انجام می‌دهم.
در سوی دیگر شرکت‌های زیرمجموعه هستند که Battery Ventures در آن‌ها سرمایه‌گذاری کرده است. به نظر می‌رسد اگر به روش توزیع‌شده کار کنید از ویدیو کنفرانس خیلی استفاده کنید. یکی از شرکت‌های فعال در این زمینه BlueJeans Network است. آن‌ها یک ویدیوکنفرانس چند پروتکله دارند که می‌تواند انواع مختلف سخت‌افزار را به هم متصل کند. به جای این‌که همه را مجبور کنید از Skype یا Hangout یا ... استفاده کنند می‌شود همه‌ی این‌ها را در یک جلسه کنفرانس گرد آورد. آن‌ها پشتیباین از Hangout را اعلام کرده‌اند ولی فکر نکنم هنوز راه‌اندازی شده باشد. من با آن‌ها کار می‌کنم و خیلی سریع در حال رشد کردن هستند. به آن‌ها در مقیاس‌پذیرشدن، دسترس‌پذیر شدن و سرعت دادن به فرآیند توسعه کمک می‌کنم تا بتوانند سریع‌تر انتشار دهند. با حرکت به یک معماری ریزسرویس‌گون‌تر و حرکت از نرم‌افزار یک‌پارچه‌ی مبتنی بر Mysql به [مدل] Nosql توزیع‌شده‌تر مثل Cassandra یا چیزهای مثل آن. هنوز در حال بررسی فناوری مناسب هستیم اما این پروژه‌ی جالبی برای من است چون انگار که من به Netflix برگشته‌ام معمار فضای ابری هستم اما این یکی تبادل ویدیو دوطرفه است!
حالا که صحبت از گیر افتادن شد، توصیه شما در مورد گیر افتادن در [محصولات] یکی از شرکت‌های ارائه‌دهنده‌ی فضای ابری چیست؟ آیا مانند گیرافتادن در یک پایگاه‌داده خاص این هم نوعی از گیرافتادن است که همه باید از آن دوری کنند؟ چه راهبردهایی برای پاسخ به آن وجود دارد؟
در واقع پایگاه‌های داده مثال خوبی هستند. مطمئن نیستم که کسی هرگز گفته باشد که من این نیاز شما را هم در MySQL می‌نویسم و هم در PostgreSQL یا هم در DB2 و هم در Oracle تا اینکه در هیچ‌کدام گیر نیفتم. فکر نکنم این اتفاق هرگز رخ دهد.
شرکت‌های تولید‌کننده‌ی محصول ممکن است این کار را بکنند. سازمان‌های این‌کار را نمی‌کنند ولی شرکت‌های تولید کننده‌ی محصول ممکن است این کار را بکنند چون ممکن است در ابتدا روی پایگاه داده‌ی دیگری کار کنند.
محصولات زیادی هستند که روی تمام پایگاه داده‌ها قابل انتقال هستند و در نهایت به ساختن کوچکترین مخرج مشترک مجبور می‌شوید. بنابراین سعی کنید بهترین محصولی که می‌توانید را پیدا کنید که نیازهای شمار را برآورده می‌کند و از تمامی امکانات آن استفاده می‌کنید؛ این طرز فکر به توسعه‌دهنده نزدیک‌تر است. طرز فکر عملیات این است که من چند تأمین‌کننده می‌خواهم چون اگر در یکی گیر بیفتم قیمت‌ها را افزایش می‌دهند. این دو با بحث زیاد به هم می‌رسند. آن‌چه که من می‌بینم این است که فضای ابری نمونه‌ای دیگر از آن است. افراد عملیاتی بیش از یک تأمین‌کننده می‌خواهند تا قدرت نفوذ داشته باشند. فکر می‌کنم اگر یک سازمان باشید، عموماً از قبل، مشتریِ [مثلاً] مایکروسافت هستید و Azure گزینه‌ی طبیعی شماست چون ویندوز های زیادی در محیط شما هست که می‌خواهید در فضای ابری قرار دهید و Azure بهترین پشتیبانی از ویندوز را دارد. و احتمالاً AWS بهترین پشتیبانی را از لینوکس دارد. می‌توانید ویندوز را روی AWS و لینوکس را روی Azure داشته باشید تا به نوعی راهبرد پشتیبان داشته باشید. چیزی که من می‌بینم این است که اکثر سازمان‌های معظم در حال فراهم کردن دو تأمین‌کننده (Dual Source) با AWS و Azure هستند اما در استارآپ‌ها عموماً میل به گوگل و AWS است. استارآپ‌ها نمی‌خواهند پول خرج کنند و بسته‌هایی که در شروع ماشین‌های رایگان یا تخفیف یا ... دارند قدرت نفوذ زیادی در آن‌جا دارند. آمازون و گوگل خیلی مایلند که استارت‌آپ‌ها را در محیط خود داشته باشند.
به نظر می‌رسد که می‌توان آن‌ها را ترغیب کرد تا معامله‌ی بهتری کرد. این همیشه وجود داشته است. در گذشته با تهیه‌ی نمونه‌ی اولیه از هر دو شرکت Sybase و Oracle قیمت آن‌ها را می‌شکستید. چیزی تغییر نکرده است. زمانی که به آن دست پیدا کردید، استفاده از یک شرکت پربارتر است. چون از تمامی امکانات آن‌ها استفاده می‌کنید و می‌توانید کار بیشتری را در زمان کم‌تری انجام دهید. و برای اکثر افراد سرعت توسعه از بهینه‌سازی هزینه مهم‌تر است. مسئله‌ی دیگر این است که در واقع، شما گیر شرکتی که قیمت‌هایش را بالا ببرد نمی‌افتید. به نظر من این چیزی است که خیلی افراد واقعاً به آن فکر نکرده‌اند. اگر من گیر AWS بیفتم آن‌ها قیمت‌ها را بالا نمی‌برند، [در واقع] آن‌ها مدام قیمت‌ها را کاهش می‌دهند. همین مسئله که گوگل وجود دارد باعث شده که آمازون قیمت‌هایش را کاهش دهد و همین‌طور بقیه. چیزی که شما با آن مواجه‌اید این است که تقریباً هر هیجده ماه قیمت‌ها نصف می‌شود. بنابراین اگر به هزینه‌ی سه سال یک سیستم فکر می‌کنید، باید در نظر بگیرید که طی سه سال آینده قیمت فضای ابری به یک چهارم کاهش می‌یابد. بنابراین جریمه‌ی گیر افتادن در یک شرکت در حقیقت خیلی کم‌تر است. فکر می‌کنم مسئله‌ی کلیدی واقعاً این است که اگر شما سعی می‌کنید محصولی بزرگ و پیچیده را منتشر کنید، باید در یک فضای ابری بزرگ باشید (ماهی کوچک در حوض بزرگ). اگر چیز کوچکی را اجرا می‌کنید از میان شرکت‌های بیشتری می‌توانید انتخاب کنید. اگر فقط دو یا سه کامپیوتر می‌خواهید می‌توانید از DigitalOcean تعدادی کامپیوتر کوچک انتخاب کنید. اگر می‌خواهید ده‌ها هزار کامپیوتر داشته باشید، تعداد [سرویس‌دهنده‌های] کمی هستند که می‌توانید از آن‌ها استفاده کنید.
در ارتباط با بحث‌هایی که می‌گویند اگر در کسب و کاری هستید که آمازون یا گوگل هم در آن هستند، به نوعی درحال همکاری با رقیب‌تان هستید، چه می‌گویید؟ فرض کنید که شما یک کتابفروش یا خرده‌فروش هستید و نسبت به انتقال به آمازون بدبین هستید. پاسخ شما به این نگرانی‌ها چیست؟
تعداد زیادی شرکت‌های خرده‌فروشی در آمریکا وجود دارند که از استفاده از آمازون امتناع می‌کنند. آن‌ها با تلاش با ایجاد فضای ابری خودشان دارند دست و پای خود را می‌بندند. آن‌ها تیم‌های داخلی دارند که سعی می‌کنند چیزی را بسازند که مقیاس‌پذیر نیست یا امکانات کم‌تری دارد یا پایدار نیست و محصول آن‌ها روی آن اجرا می‌شود و از آن رنج می‌برند. بنابراین به نوعی خود را محدود می‌کنید. Netflix مثال شاخص آن است. AmazonPrime رقیب مستقیم Netflix است (یک خدمت پخش فیلم است). اگر سؤال را برگردانید، شاید بهتر معنی پیدا کند. اگر AmazonPrime روی AWS اجرا می‌شد و Netflix این‌طور نبود، آن وقت AmazonPrime روی بهترین فضای ابری موجود اجرا می‌شد (بزرگ‌ترین مقیاس، کم‌ترین هزینه، گسترده‌ترین فضای جغرافیایی و ...) در حالی که برای Netflix این‌طور نبود. بنابراین استفاده‌ی Netflix از AWS این مزیت محتمل را خنثی می‌کند.
مسئله‌ی دیگر این است که Netflix با تبدیل شدن به یک مشتری قدرت‌مند و شناخته‌شده، پیشنهادات ممتازی از AWS دریافت می‌کند. Netflix با چابک و پیشرفته بودن در نحوه‌ی استفاده از فضای ابری می‌تواند ادعا کند که برخی مواقع از فضای ابری بهتر از خرده‌فروشی‌های آمازون استفاده می‌کند. بنابراین این امکان را دارید که از امکانات رقیب‌تان برعلیه آنان استفاده کنید. به آن فن در جودوی جوجیتسو فکر کنید که در آن از وزن حریف بر علیه خودشان استفاده می‌کنید. اکثر افراد این‌طور به آن فکر نمی‌کنند، اما فکر می‌کنم این طرز نگاه Netflix به آن باشد. قطعاً این آگاهی وجود دارد که آن‌ها وابسته به یک رقیب هستند، اما تا کنون AmazonPrime تنها یک و نیم درصد از ترافیک شبکه در آمریکا را داشته و Netflix حدود ۳۴ درصد که تقریباً بیست برابر آن است. بنابراین از این منظر رقیب بزرگی نیست. بزرگ‌ترین رقیب در واقع یوتیوب است که تقریباً چیزی بین یک سوم تا نصف ترافیک Netflix را دارد. گوگل یک رقیب است اما Netflix روابط کاری نزدیکی با گوگل هم دارد. بنابراین در این فضای رقابتی مدرن شما مجبورید سرانجام با رقبای خودتان کار کنید و از هر قدرت نفوذی که دارید بر علیه آنان استفاده کنید تا مزیت پیدا کنید.
نهایتاً چون من آلمانی هستم باید این سؤال را بپرسم: شما در مورد نگرانی‌های امنیتی که افراد در مورد انتقال به یک فضای ابری دارند چه می‌گویید؟
شما می‌خواهید در مورد راه‌اندازی Netflix در آلمان از من بپرسید :)
امنیت یکی دیگر از مسائلی است که اگر به نحوه‌ی انجام آن در گذشته بنگرید، در فضای ابری جواب نخواهد داد. برخی افراد از این موضوع ناراحت می‌شوند. اما افرادی که مشتاقند به چیزهایی نگاه می‌کنند که هرگز در مراکز داده قابل انجام نبود. و چیزی که در مورد زیرساخت قابل برنامه‌نویسی وجود دارد این است که می‌توانید تمامی وضعیت آن را بازتاب دهید. این باعث می‌شود که بتوانید در مورد سامانه‌تان با قدرت اظهار نظر کنید. اگر یک مرکز داده‌ی عادی را در نظر بگیرید و بخواهید تمامی راه‌های خارجی [ارتباط با] آن را بدانید، برخی از آن‌ها را از قلم خواهید انداخت. [شاید] یک آرایه‌ی ذخیره‌سازی باشد که تحت یک حالت خاص فراخوانی‌ای به شرکت سازنده انجام می‌دهد. انواع چیزهایی اضافی در حال رخ دادن هستند که شما از آن‌ها خبر ندارید یا نمی‌توانید آن را بیابید و به نوعی از زیر دست شما می‌گذرند و یا کسی آن‌ها را در کامپیوترها قرار می‌دهد. خیلی دشوار است که به درستی تمامی راه‌های ورودی را مدیریت کرد. اما اگر به یک حساب‌کاربری در AWS نگاه کنید و بگویید لیستی از تمامی کامپیوترها به من بده و در این لیست پیش بروید، آدرس IP، ELB و IPهای Elastic هر یک را می‌بینید و بس. اقلام اطلاعاتی مشخصی وجود دارد که می‌توانید به آن‌ها دسترسی پیدا کنید و می‌توانید با قدرت در مورد آن اظهار نظر کنید.
Netflix یک میمون امنیتی دارد که متن‌باز است که در واقع تمامی این موارد را زیر نظر می‌گیرد. به گروه‌های امنیتی‌ای که نصب کرده‌اید نگاه می‌کند و به شما می‌گوید که چه چیزهایی به وضعیت غیرایمن رفته‌اند و به صورت پویا این اطلاعات را پایش می‌کند. خیلی سخت است که این کارها را در فضای ابری انجام دهید، مگر این‌که در محیطی مبتنی بر فضای ابری حضور داشته باشید. نمی‌توانید ابزاری را در پورت SPAN یک سوئیچ قرار دهید و تمام ترافیک را جمع‌آوری کنید و روی آن تشخیص انجام دهید. باید چیزها را به نحو دیگری بسازید. بنابراین دنیای دیگری از تولیدکنندگان و ابزار وجود دارد. در واقع Battery Ventures در برخی از این‌ها سرمایه‌گذاری می‌کند. در حقیقت این یکی از مناطق مورد توجه توسعه‌ی ابری است.
در پایان،‌ به شنوندگان ما در مورد نحوه آشنایی [با فضای ابری] چه توصیه‌ای می‌کنید؟ چون به نظر خیلی شلوغ می‌رسد و چیزهای جالب زیادی وجود دارد. نقطه‌ی شروع مناسب کجاست؟
اگر چهار سال به عقب برگردیم زمانی که Netflix شروع به کار کرد، ما مجبور بودیم همه چیز را بسازیم. استانداردها را می‌خواندیم و همه چیز را اختراع می‌کردیم و به بحث می‌نشستیم و آزمایش می‌کردیم. وضعیت فعلی این است که همه چیز خیلی بالغ‌تر است. الگوها خیلی بهتر هستند و ابزار خیلی پیشرفته‌تر است. فکر می‌کنم در حال حاضر احتمالاً بهترین نقطه برای شروع (اگر از صفر شروع می‌کنید) این است که به Docker نگاهی بیندازید. Docker چهار تا از مشکلات جالبی را که Netflix سعی در حل آن داشت، برطرف می‌کند. Netflix هم شروع به استفاده از آن کرده است. اگر چهار سال پیش وجود داشت، قطعاً از آن استفاده می‌کردیم. یکی از کارهایی که انجام می‌دهد این است به سرعت مستقر می‌شود. در عرض چند ثانیه می‌توانید یک محفظه‌ی Docker را مستقر کنید. دومین چیز قابلیت انتقال (Portability) است. محفظه‌ها را روی لپ‌تاپ‌تان بسازید و آن را در چند فضای ابری مستقر کنید. کد جداسازی شده و قطعات تغییر ناپذیر کد را Build می‌کنید که در واقع همان ریزسرویس‌ها هستند. سومین مسئله فروشگاه برنامه‌هاست. می‌توانید از DockerHub سی‌هزار محفظه‌ی Docker از پیش‌ساخته را دانلود کنید و به آن‌ها دسترسی پیدا کنید و به عنوان نقطه‌ی شروع از آن استفاده کنید. این چیزی است که ما هرگز آن را نداشته‌ایم. یک فروشگاه ریزسرویس‌ها است که می‌توانید به راحتی دانلود کنید و با آن کار کنید. آخرین چیز این است که نیاز به چیزهایی مثل Chef یا Puppet را برطرف می‌کند. پیکربندی در خود محفظه قرار دارد و این چیزی است که مستقر می‌شود. شما پیکربندی را در زمان اجرا تغییر نمی‌دهید، شما آن را در زمان Build تولید می‌کنید و سپس فقط آن را مستقر می‌کنید. بنابراین فکر می‌کنم که بسیاری از قواعد معماری که Netflix در نظر داشت را دربرمی‌‌گیرد. البته همه مستقلاً این چیزها را کشف کردند اما محصولات Netflix برای آن هست. فکر می‌کنم نگاهی به آن بیاندازید.
جای دیگری که می‌توانید به آن سر بزنید بلاگ فنی و مخزن کد متن‌باز Netflix در GitHub است و سعی کنید مطالب آن را بفهمید. به Twitter نگاه کنید. به Facebook نگاه کنید. بهترین نرم‌افزارهایی که اکنون می‌توانید بگیرید، متن‌بازها هستند که محصول تولیدکنندگان بزرگ‌مقیاس وب هستند. این‌ها بهترین و پیش‌رفته‌ترین نرم‌افزارها هستند. محصولات فروشی که پول زیادی برای آن‌ها می‌دهید، چیزهایی هستند که مقیاس‌پذیر نیستند و یا به کندی تکامل پیدا می‌کنند و این مشکلات توزیع‌شدگی را برطرف نمی‌کنند. بنابراین فکر می‌کنم دوره‌ی واقعاً جالبی است. می‌توانید محصولتان را خیلی سریع و ارزان بسازید به طوری که بسیار مقیاس‌پذیر و دسترس‌پذیر باشد. فکر می‌کنم این چیزی باشد که پنج یا ده سال پیش امکان نداشت. دوره‌ی جالبی برای تولید است.
آدریان، برای این گفتگو خیلی متشکرم. حضور شما در این برنامه لذت‌بخش بود. باز هم ممنونم که با ما بودید.
ممنونم که مرا دعوت کردید.