در این اپیزود که در ژوئن ۲۰۱۶ منتشر شده است جف میرسون با جان پریر در مورد OpenStack صحبت می‌کند. OpenStack یک سیستم‌عامل ابری متن‌باز است. جان پریر بنیانگذار OpenStack و مدیر ارشد فنی Automic Software است. به عنوان مدیرارشد فنی، او مسئولیت راهبری استراتژی خودکارسازی (Automation) را بر عهده دارد. او که بیش از ۲۰ سال تجربه رهبری در صنعت IT را دارد، اخیراً مدیرارشد فنی آزمایشگاه ابداعات CenturyLink شده است و بر روی فناوری‌های جدید و درحال ظهور ابری، شامل قابلیت همکاری بین ابری و DevOps تمرکز دارد. جان قبلاً رهبر راهبردی و فناوری AppFog بوده است و رهبری توسعه و تحویل اولین نسخه Microsoft Exchange Server را هم بعهده داشته است. او همچنین، رهبری R&D را در RackSpace انجام می‌دهد.
جان، به SE Radio خوش آمدی.
از اینکه دعوتم کردید متشکرم.
OpenStack چیست؟
همانطور که شما گفتید یک پروژه متن‌باز است. یک سیستم‌عامل ابری است. اساساً ایده پشت OpenStack ساختن یک زیرساخت متن‌باز به منزله یک پلتفرم به عنوان خدمت (Platform as a Service) است. بنیانگذاران اولیه، RackSpace و NASA بودند. دو پروژه اول، یکی پروژه محاسبات و دیگری یک پروژه ذخیره‌سازی اشیاء بود. از آن زمان طی ۶ سال اخیر، تعداد پروژه‌ها و محدوده آن‌ها خیلی فراتر از آن دید اولیه شده است.
برای آن دسته از مخاطبان که ممکن است این اصطلاح را ندانند بگویید زیرساخت به عنوان خدمت (Infrastructure as a Service) چیست؟
می‌توان اینطور دید که به جای اینکه بروید و کامپیوترهای خود را بخرید، یک ساختمان بیابید، آن را اجاره کنید، برق و سیستم تهویه‌اش را برپا کنید و یک مرکز داده برپا کنید، در عوض، آن را از کس دیگری اجاره می‌کنید. در حالی که می‌توانید پروژه‌های زیرساخت به عنوان خدمت خصوصی هم داشته باشید، وقتی از زیرساخت به عنوان خدمت صحبت می‌کنیم، اغلب افراد زیرساخت‌های ابری عمومی مانند Amazon و Azure و Google Cloud را در نظر می‌آورند. بنابراین نگاه ساده‌اش این است که سرورها را از کس دیگری اجاره می‌کنم.
ما این ابرهای عمومی مانند Amazon و Azure و Google Cloud را داریم. چرا به یک سیستم‌عامل ابری متن‌باز نیاز داریم؟
سئوال خوبی است. فکر می‌کنم سئوال می‌تواند به این شکل باشد که چرا به ازای هرکدام از پیاده‌سازی‌های اختصاصی به یک نسخه متن‌باز هم نیاز داریم. من اینطور استدلال می‌کنم که اول از همه، برای صنعت و اکوسیستم خوب است. اما بطور خاص زیرساخت‌های ابری، خیلی مبتنی بر همکاری هستند. شرکت‌ها و سازمان‌های زیاد مختلفی با هم جمع می‌شوند. این توانایی که بتوانیم یک پروژه بزرگ مانند این را با همکاری هم بسازیم خیلی قدرت‌بخش است. شرکت‌های خیلی کمی در دنیا هستند که بتوانند پروژه‌ای که به بزرگی OpenStack امروز باشد را راه‌اندازی و نگهداری کنند. آخرین باری که دیدم، بیش از ۳۰۰۰۰ عضو بنیاد OpenStack بودند که در بهبود نرم‌افزار مشارکت می‌کنند که چیز خیلی خوبی است.
بنابراین، این، همان سیستم‌عامل متن‌بازِ زیرساخت به عنوان سرویس است. آیا می‌توانید مثالی از شرکت‌هایی بزنید که امروزه از OpenStack استفاده می‌کنند تا یک نمونه کاربرد اولیه داشته باشیم که شاید در ادامه بحث به آن ارجاع داشته باشیم.
صدها شرکت هستند که امروزه به شکل‌های مختلف از OpenStack استفاده می‌کنند. برخی از آن‌ها حالت تصویر تبلیغاتی‌مان را دارند. از تجاری‌های‌شان، Wal-Mart است. Wal-Mart برای توسعه سیستم تجارت الکترونیک خود، در مراکز داده‌شان، از OpenStack استفاده می‌کنند. مورد دیگر آزمایشگاه تحقیقاتی CERN است که در سوییس یک برخورددهنده بزرگ مقیاس می‌سازد. هرکسی که در نشست‌های اخیر طراحی OpenStack بوده‌، [مشاهده کرده است که] هر دو این سازمان‌ها پیش‌قدم شده‌اند و نحوه استقرار بزرگ‌مقیاس خود را ارائه کرده‌اند.
آیا این سازمان‌ها، سرورهای خود را دارند و OpenStack را بر روی آن اجرا می‌کنند یا اینکه یک میزبان ابری را اجاره کرده‌اند که OpenStack را بر روی آن قرار داده‌اند؟
سئوال خوبی است. بسته به سازمان، ممکن است هرکدام از این‌ها یا هردو را انجام دهند. نحوه مرسوم نصب OpenStack این است که در یک ابر درمحل (On-premises) یعنی خصوصی باشد. بنابراین [احتمالاً شرایط در هنگام نصب به این شکل است که] مرکز داده خودم را دارم و احتمالاً مجازی‌سازی کرده‌ام و طی ۱۰ سال اخیر، با استفاده از VMware یا دیگر فناوری‌های مجازی‌سازی، این کار را انجام داده‌ام و حال واقعاً می‌خواهم که خدمات بیشتر، خودکارسازی‌های بیشتر و پاسخگویی‌های بیشتری برای مشتری‌های داخلی خود داشته باشم.
بنابراین ابر، دراقع یک لایه خودکارسازی بر روی مجازی‌سازی است. به من اجازه می‌دهد که منابع را چه ماشین‌های مجازی باشد و چه سیستم‌های ذخیره‌سازی باشد و یا شبکه و … را به جریان آورم. اغلب افراد در ارتباط با OpenStack به دنبال مورد کاربردی هستند که داخل یک مرکز داده استفاده شود. اما بدون اینکه تغییری در مدل آن ایجاد شود می‌تواند توسط فرد دیگری هم مدیریت شود. اگر یک سازمان معظم (Enterprise) باشم و نخواهم مرکز داده خودم را راه بیاندازم و با یکی از شرکت‌های میزبانی، قراردادی ببندم که «لطفا زیرساخت من را بر روی سخت‌افزار، شبکه‌ام و ... اجرا کنید» در این حالت هم OpenStack مناسب است.
البته برخی ارائه‌کننده‌های سرویس ابری هم هستند که OpenStack را اجرا می‌کنند و در فضای زیرساخت‌های ابری عمومی با آمازون و گوگل و دیگران دارند رقابت می‌کنند.
حال باید به این بپردازیم که OpenStack چطور کار می‌کند. ما یک چشم‌انداز سطح بالا از برخی موارد کاربرد آن و نحوه استقرار آن داشتیم. شما به اصطلاح مجازی‌سازی اشاره کردید. مجازی‌سازی چیست؟
در گذشته، مرسوم بوده که کامپیوتری می‌خریدید و یک سیستم‌عامل رویش می‌گذاشتید و یک یا تعدادی برنامه کاربردی بر روی آن اجرا می‌کردید. اما حدود ۱۵ سال قبل ایده مجازی‌سازی سرور‌ها، به سرورهای در سطح PC آورده شد. این واقعاً براساس تکنیک‌هایی رشد کرد که برای مدت طولانی در Mainframe ها و دنیای Minicomputer ها وجود داشت. ایده پشت مجازی‌‌سازی این است که می‌توانم یک کامپیوتر منفرد را برداشته و یک Hypervisor بر روی آن قرار دهم. کاری که Hypervisor انجام می‌دهد این است که سخت‌افزار زیرین را انتزاع می‌کند و این قابلیت را ارائه می‌دهد که چندین پشته مختلف نرم‌افزار - از سیستم‌عامل به بالا- را مستقلاً اجرا کنم. بنابراین می‌توانم یک کامپیوتر فیزیکی را برداشته و کاری کنم که شبیه ۲ یا ۴ یا ۸ کامپیوتر مجازی شود و اگر کاربر آن‌ها باشم، هیچ تفاوتی در صحبت کردن با آن‌ها نسبت به یک جعبه قابل لمس فیزیکی نباشد.
با یک کم جزییات بیشتر، رابطه Hypervisor و سخت‌افزاری که رویش قرار دارد چیست؟
Hypervisor لایه‌ای از نرم‌افزار است که می‌داند سخت‌افزار فیزیکی به چه شکل است، حال چه CPU باشد، چه سیستم ذخیره‌سازی باشد، چه شبکه باشد. اساساً، در سطح درایور یک نقطه تماس می‌سازد که می‌تواند در دسترس انواع مختلف ماشین‌های مجازی قرار گیرد.
ما در مورد ارتباط Hypervisor و سخت‌افزار زیر آن صحبت کردیم. برای اینکه سئوال Hypervisor چیست را کامل‌تر پاسخ دهیم، در مورد رابطه بین Hypervisor و ماشین‌های مجازی‌ای که مدیریت می‌کند، کمی بیشتر صحبت کنید.
Hypervisor به شما اجازه می‌دهد که ماشین‌های مجازی را به جریان بیاندازید و این ماشین‌های مجازی جوری به نظر می‌رسند و عمل می‌کنند که انگار ماشین‌های فیزیکی هستند. شما درایورهای مجازی‌شده دارید که از لحاظ دسترسی به CPUها، منابع ذخیره‌سازی داده، شبکه و ... همان سرویس‌هایی را می‌دهند که در ماشین‌های فیزیکی می‌دهند. بنابراین درواقع، یک لایه مترجم بین این محیط مجازی‌شده و سخت‌افزار فیزیکی وجود دارد. و درخواست‌هایی از انواع مختلفی از ماشین‌های مجازی را به سمت سخت‌افزار فیزیکی هدایت می‌کند.
عالی است. حال که از Hypervisor، ماشین‌های مجازی و سخت‌افزاری که همه آن‌ها بر رویش قرار گرفته‌اند، تصویری داریم، [می‌توان گفت] OpenStack مجموعه‌ای از Hypervisor‌ها که در یک مرکز داده یا در چندین مرکز داده گسترده شده‌اند را گرفته و این مجموعه از Hypervisor‌ها را به یک حوض (Pool) مشترک از منابع تبدیل می‌کند. چرا این مفید است؟
به شکل خیلی خوبی آن را توضیح دادید. ابر، اساساً یک لایه خودکارسازی بر روی ماشین‌های مجازی است. بنابراین اگر به تاریخچه مراکز داده در سازمان‌های معظم نگاه کنید، ما ۲۰ سال پیش با معماری‌های کلاینت/سروری آغاز کردیم. و حدود ۱۵ سال پیش، مجازی‌سازی طلوع کرد. تقریباً در حدود ۱۰ سال پیش، بیشتر فروشگاه‌های محاسباتی جدی، مجازی‌سازی شده‌اند. این، مشکل تحویل به سازمان را برطرف نکرد. همچنان این رویه در سازمان‌های معظم وجود داشت که فرضاً اگر توسعه‌دهنده، یک ماشین مجازی یا گروهی از ماشین‌ها را درخواست می‌کرد، همچنان باید یک درخواست ثبت می‌کرد، باید کسی می‌بود که در محیط کنسول یا خط فرمان، منابع را می‌ساخت و درخواست را بروز می‌کرد و ایمیلی در پاسخ می‌فرستاد. این می‌توانست چندین روز طول بکشد.
حدود ۱۰ سال پیش، آمازون، سرویس‌های وبیِ آمازون را آغاز کرد. سرویس اصلی در آن زمان EC2 بود. EC2 اساساً یک روش خودکار برای گرفتن ماشین‌های مجازی بصورت آنی بود. این خیلی انقلابی بود. من می‌توانستم، کارت اعتباری‌ام را بکشم تا حسابم را شارژ کنند و بلافاصله، می‌گفتم که ۱۰ ماشین مجازی می‌خواهم که این مقدار حافظه و اینقدر فضای دیسک داشته باشند. و حدود ۳ دقیقه بعد، آن ماشین‌ها بالا و درحال کار بودند و می‌توانستم از آن‌ها استفاده کنم. داخل سازمان‌های معظم، این کار بیشتر طول می‌کشید. آنچه OpenStack و نرم‌افزار ابر، انجام داد این بود که این سطح از خودکارسازی را بر روی مجازی‌سازی فراهم کرد. بنابراین درواقع، مدیر و همنواکننده (Orchestrator) ماشین‌های مجازی و منابع است.
بسیار خوب. این توضیح خیلی خوبی بود. برای اینکه آنچه الان گفتید را مرور کنم: روی این حوض مشترک منابع، یک واسط هست که به توسعه‌دهنده اجازه می‌دهد درباره‌ی آن‌چه رخ می‌دهد، نگران نباشد. توسعه‌دهنده می‌گوید می‌خواهم این مقدار محاسبات را به جریان بیاندازم و نمی‌خواهم مجبور باشم به عنوان یک توسعه‌دهنده بیش از حد ضرورت نگران مقادیر پیکربندی باشم. می‌توانم مشخص کنم چه می‌خواهم و در پشت پرده، این حوض وسیع از منابع، متوجه می‌شود که واقعاً چه به من بدهد. من یک بشقاب مجازی‌سازی‌شده کامل از منابعی که می‌خواهم را دریافت می‌کنم.
بله، این نگرش خیلی خوبی به آن است. اگر دو نسل به عقب برگردید، به عنوان یک توسعه‌دهنده، مرسوم بوده که بروم و یک سرور فیزیکی بخرم، جعبه‌اش را باز کنم، به برق بزنم، سیستم‌عامل بر رویش نصب کنم، ابزارهایم را رویش نصب کنم، مکانی بر روی میزم برایش بیابم. اما وقتی به دنیای مجازی رفتیم، همه این کارها را برایم می‌کردند اما همچنان یک رابطه یک به یکی با ماشین‌های مجازی داشتم. در ابر، فقط درخواست منابعی را می‌کنم که می‌خواهم و برایم مهم نیست که آیا بر روی ماشین ۱ است یا ماشین ۱۰۰۰ داخل مرکز داده. من به عنوان یک توسعه‌دهنده تنها می‌خواهم که به منابع دسترسی داشته باشم. بنابراین واقعاً آنچه که توسعه‌دهنده در مورد خیلی از امور تدارکات، نگرانی داشته را انتزاع کرده‌ایم.
و به عنوان آخرین نکته در مورد این حوض مشترک Hypervisorها که با OpenStack مدیریت می‌شود: این Hypervisorها می‌توانند از انواع مختلفی باشند. می‌توانند Xen یا KVM یا VMware یا Windows Server و … باشند اما کاربر با این Hypervisor‌ها از طریق یک واسط سازگار OpenStack تعامل دارد. چرا این مزیت محسوب می‌شود؟
چون در دنیای واقعی، لزوماً از هرچیزی، یک مجموعه هم‌‌ریخت ندارید. ممکن است انواع مختلفی از کامپیوترهای فیزیکی داشته باشید. نحوه تدارک دیدن هرکدام ممکن است متفاوت باشد. ممکن است انواع مختلفی از شبکه‌ را داشته باشید. بنابراین دنیای واقعی، آشفته است. و آنچه OpenStack انجام می‌دهد این است که یک واسط انتزاعی بر روی آشفتگی‌ فراهم می‌کند و پیچیدگی زیر آن را مدیریت می‌کند تا به عنوان توسعه‌دهنده یا به عنوان یک اپراتور یا مدیرسیستم، دیگر نگرانش نباشم و سیستم، به جای من از آن مراقبت می‌کند.
آیا در عمل، این ناهم‌ریختی سرورهای مختلف در یک خوشه فرضاً KVM و VMware و Windows Server چیز معمولی بین کاربران OpenStack است؟
وقتی یک Hypervisor همراه با دیگر Hypervisorها زیر یک لایه سازگار OpenStack نشسته است، آیا هیچ مشخصه‌ی خاصی هست که باید Hypervisor از آن تبعیت کند؟ از نظر CPU یا ذخیره‌سازی یا دیگر خصیصه‌ها؟
سئوال خوبی است. من نمی‌دانم که واقعاً مربوط به موضوع باشد یا نه. بله، باید یک حداقل چیزهایی داشته باشید :-) اما هرکدام از Hypervisorهای سیستم‌های مجازی‌سازی پیشرفته را که در نظر بگیرید، چه VMware یا Hyper-V یا هرچیز دیگر که باشد، همه‌شان به مقدار کافی خوب هستند که با OpenStack رانده شوند. البته OpenStack سیستم‌های لخت (Bare Metal) را هم می‌راند. یک سیستم لخت، درواقع سیستمی است که Hypervisor نداشته باشد.
یک سئوال مضحک بپرسم. چه چیزی مانع می‌شود که OpenStack را بر روی یک خوشه عظیم از دستگاه‌های Raspberry Pi اجرا کنم؟
قطعاً می‌توانید. اگر من بخواهم چنین سیستمی برپا کنم، Hypervisor را بر روی دستگاه‌های Pi نصب نمی‌کنم چون آن‌ها خیلی کوچک هستند بلکه باید آن‌ها را به عنوان سیستم‌های لخت اجرا کنید. اما هرکدام از آن‌ها، برای برنامه‌ریز OpenStack نقاط محاسباتی آدرس‌پذیر مستقلی هستند.
خیلی جالب است. خیلی از بحث دور نشویم اما آیا فکر می‌کنید می‌توانیم آینده‌ای داشته باشیم که در آن، بتوانم در کمد لباسم، مرکز داده‌ای از چیزهایی در اندازه Raspberry Pi داشته باشم و بتوانم Jobهای بزرگ Map/Reduce بر رویش اجرا کنم؟
قطعاً. اگر به محبوبیت Docker و محفظه‌ها نگاه کنید، آن هم کمک می‌کند که به این آینده برسیم. چون محفظه‌ها، خیلی سبک‌تر از ماشین‌های مجازی هستند و می‌توانید در هر پیکربندی که باشد، ظرفیت خیلی بیشتری بگیرید. مثلاً اگر دستگاه‌های Raspberry Pi را برداریم و آن‌ها را به عنوان سیستم‌های لخت در نظر بگیریم، و یک پشته کامل از محفظه‌های Docker داخل آن بسازیم، به این فکر کنید که چه مقدار قدرت پردازشی می‌توانید داشته باشید. و بعد با یک ابزار همنواسازی (Orchestrator) مانند OpenStack آن‌ها را در زیر، خوشه‌ کنیم.
این خیلی خارج از طبیعت یک بحث در مورد OpenStack می‌شود اما من مصاحبه‌هایی با افراد داشتم که در نهایت به این سئوال‌ رسیده‌ام: وقتی زیرساخت خود را محفظه‌سازی می‌کنید و از Docker استفاده می‌کنید تأثیر اقتصاد افزایش مقیاس (Economies of Scale) چیست؟ وقتی می‌توانیم معماری‌مان را با فناوری‌های جدید‌تر به جای مجازی‌سازی، محفظه‌سازی کنیم، آیا آماری یا یک تصویر عددی از میزان اقتصادی بودن آن دارید؟
می‌توانم در یک حکایت پاسخ دهم. من یک تیم مهندسی را در Rackspace اداره کردم. همانجا بود که با NASA کار تأسیس OpenStack را انجام دادیم. بعد از آن، به HP رفتم و یک ابر عمومی مبتنی بر OpenStack بنا کردم. ماجرای بعدی من یک شرکت به نام AppFog بود که یک شرکت پلتفرم به عنوان سرویس است که مبتنی بر CloudFoundry است. این یک لایه انتزاع دیگر است. برای یک توسعه‌دهنده یک محیط شگفت‌آور است چون تنها نگران منطق و مؤلفه‌هایی هستید که در نرم‌افزارتان دارید و آن‌ها را به سیستم می‌فرستید و رسیدگی به همه بخش‌های عملیاتی‌اش برای‌تان انجام می‌شود.
در پشت صحنه هر سیستم PaaS‌ای، همه چیز محفظه‌سازی شده است. اگر به OpenShift یا CloudFoundry یا … نگاهی بیاندازید، همه این سیستم‌ها، یک سیستم محفظه‌سازی اجرا می‌کنند. در AppFog ما ماشین‌های مجازی که در زیرساخت‌های ابری عمومی متنوعی از قبیل آمازون، RackSpace و HP و … داشتیم را بکار گرفتیم و برای اجرای محفظه‌ها، بر روی آن ماشین‌های مجازی، برش‌هایی (Slice) دادیم. فرضاً می‌توانید یک ماشین مجازی ۸ گیگی را برداشته و ۸ تا ۱۰ محفظه مختلف در داخل آن اجرا کنید. بنابراین می‌توانید اقتصادی‌تر باشید و چگالی خیلی بهتری بگیرید. بنابراین اگر برنامه‌ای دارید که ۱۱۲ مگا است، برای اجرای آن به یک ماشین کامل ۸ گیگی نیاز ندارید. می‌توانید در فضای یکسانی برنامه‌های بیشتری را پر کنید. بنابراین آنچه می‌بینیم این است که با Docker و سیستم‌های محفظه‌شده، در‌واقع یک زیرساخت به عنوان سرویس داخل به بیرون داریم. شرکت Docker سیستم محفظه‌شده داخل PaaS خود را برداشت و آن‌ را جدا کرد و یک API مستقل سطح پایین بر روی آن ساخت. آن‌ها کارهای زیاد واقعاً خوبی از نظر توسعه همکارانه برای توسعه‌‌دهنده‌ها و محفظه‌ها انجام دادند.
اکنون با در دست داشتن این سیستم‌های محفظه‌شده باید تمام چیزهایی که PaaS را عملیاتی می‌کند را از نو بسازیم مثل سیستم مانیتورینگ، بررسی سلامتی (Health Check) و چیزهایی از این قبیل. واقعاً دنیای جالبی است. پاسخ کوتاه به سئوال شما این است که فکر می‌کنم بهره‌وریِ ۵ تا ۱۰ برابر بهتری بگیرید و البته این به آن معنی است و هم نیازمند آن است که برنامه‌ریز (Scheduler) ما هم هوشمندتر باشد.
بسیار خوب. ما یک کم بعدتر به بحث برنامه‌ریز می‌پردازیم اما بگذار کمی به دید سطح بالا برگردیم. OpenStack یک مجموعه‌ اصول طراحی دارد. و دو هدف اصلی OpenStack مقیاس‌پذیری (Scalability) و قابلیت ارتجاع (Elasticity) است. برای کسی که تجربه خیلی زیادی در ساختن نرم‌افزار برای زیرساخت‌های به عنوان خدمت ندارد، شاید مقیاس‌پذیری و قابلیت ارتجاع هر دو یک چیز به نظر برسد. تفاوت بین مقیاس‌پذیری و قابلیت ارتجاع چیست؟
سئوال خوبی است. مقیاس‌پذیری، قابلیت اخذ منابع به وقت نیاز است. فرضاً اگر سایتی بسازم تا چیزی را بفروشم، آن را اجرا می‌کنم و مقدار مشخصی ترافیک دارم. ناگهان، زمان کریسمس می‌رسد و ترافیک به سایتم ۱۰ برابر افزایش می‌یابد. یا باید از قبل، زیادی تدارک می‌دیدم تا حساب این را بکنم که الان ۱۰ برابر ترافیک بیشتر دارم و یا وقتی این ترافیک، ظاهر می‌شود، بخواهم افزایش مقیاس بدهم و بخواهم به وقت نیاز، منابع را اضافه کنم. مقیاس‌پذیری در‌واقع به این معنا است. هدف و اصل OpenStack این است که به شدت مقیاس‌پذیر باشد. بنابراین یک سیستم OpenStack می‌تواند صدها هزار ماشین مجازی را در یک خوشه اجرا کند.
قابلیت ارتجاع درواقع، خیلی مشابه [با مقیاس‌پذیری] است به این معنا که می‌خواهید حوض (Pool) منابع‌تان را رشد دهید اما به علاوه می‌خواهید بتوانید آن‌ را منقبض‌ هم بکنید. این در‌واقع یک بخش اساسی در ابر است. این که منابع را فقط اضافه و اضافه کنم، یک مطلب است، اما این که به محض نیاز آن را افزایش داده و به محض نیاز آن را منقبض کنید و بتوانید هم افزایش مقیاس و هم کاهش مقیاس داشته باشید، چیزی است که به آن قابلیت ارتجاع می‌گوییم.
دیگر اصل طراحی OpenStack این است که هر ویژگی که اهداف اصلی سرویس ( قابلیت ارتجاع و مقیاس‌پذیری) را محدود کند، باید اختیاری (Optional) باشد. فکر می‌کنم خیلی مهم است که این اصول مشخص شود چون این یک پروژه متن‌باز عظیم است که در آن نیاز دارید، نوعی همراستایی بین اعضاء تیم توزیع‌شده برقرار شود. مثالی از یک ویژگی در OpenStack که به‌طور بالقوه مقیاس‌پذیری یا قابلیت ارتجاع را محدود می‌کرد و بنابراین بایدبه یک ویژگی اختیاری تبدیل می‌شد چیست؟
اگر به گزینه‌های اصلی شبکه که داشتیم بنگرید، یک نوع شبکه هموار (Flat) و انواعی از حالت‌های مختلف شبکه داشتیم که می‌توانستید انتخاب کنید. این جالب است اما شبکه وقتی واقعاً جالب شد که شبکه تعریف‌شده با نرم‌افزار (Software Defined Networking) بوجود آمد که در OpenStack درواقع، با Nicira رهبری می‌شد که بعداً به مالکیت VMware درآمد. به ناگاه ما دو نوع سیستم شبکه داشتیم. شما به عنوان یک اپراتور یا کسی که می‌خواست استقرار OpenStack را انجام دهد، باید بین آن دو انتخاب می‌کردید. اگر ما به عنوان یک گروه این سیاست را داشتیم که بگوییم: «بسیار خوب، الان باید به جای ماژول‌های شبکه توکار، از روش شبکه تعریف‌شده با نرم‌افزار استفاده کنید» در اینصورت فکر می‌کنم این یک روش تطبیق خیلی عقب‌مانده‌ای می‌شد. اما این که می‌توانستید انتخاب کنید و مؤلفه‌ها اختیاری بودند، پذیرش آن را خیلی ساده‌تر کرد چون می‌توانستید معماری و حالت و سبک استقراری که با آن راحت بودید را انتخاب کنید.
براساس اصول طراحی آن، در OpenStack همه‌چیز، باید ناهمگام (Asynchronous) باشد. چرا ناهمگامی اینقدر مهم است؟
اگر چیزها را همگام کنید، جدل (Contention) خواهید داشت و مسدود می‌شوید و کارایی‌‌تان کاهش می‌یابد. بنابراین کاملاً با توان عملیاتی (Throughput) مرتبط است و با این که بتوان سیستم‌های کامپیوتری و مراکز داد‌ه‌ای ساخت که قادر باشید برای آن توافق سطح سرویس (Service Level Agreement) داشته باشید. این خصوصاً در کاربردهای معظم مهم است چون در آنجا، بخش فناوری اطلاعات سازمان معظم به کسب‌وکار، یک تعهد SLA می‌کنند. مثلاً زمان پایین بودن [حداکثر] مقدار مشخصی دارد و سطوح کارایی مشخصی وجود دارد که حفظ خواهد شد و … . بنابراین اگر در معماری‌تان یا جریان کاری یا سیستم‌تان، مکان‌های همگامی داشته باشید، این‌ها جاهایی است که می‌تواند باتلاق کار شود و جاهایی است که می‌توانید کنترل‌ را از دست بدهید. بنابراین، این کاملاً مرتبط با حفظ کردن کارایی و زمان بالا بودن سیستم و مقیاس‌پذیری آن است.
OpenStack همچنین بر روی معماری اشتراک هیچ چیز (Share Nothing) تأکید دارد. برای کسی که این اصطلاح را واقعاً متوجه نشده است، ممکن است چیز عجیبی به نظر برسد. چون اگر معماری داشته باشید که هیچ چیزی نتواند به اشتراک گذاشته شود، چطور می‌خواهید اطلاعات را از یک بخش معماری به بخش دیگر، منتقل کنید؟! شاید بتوانید این اصطلاح اشتراک هیچ چیز را تعریف کنید.
اگر یک معماری دارای اشتراک داشته باشم، احتمالاً از تکه‌ای از حافظه یا تکه‌ای از دیسک برای نگهداری حالت استفاده می‌کنم. اما وقتی ماشین‌های مجازی داشته باشید که ما آن‌ها را بی‌دوام (Ephemeral) می‌خوانیم، این می‌تواند مشکل‌زا باشد. چون یک ماشین مجازی می‌تواند از دید شما خارج شود و هرزمانی برود. بنابراین باید یک سیستم معماری داشته باشید که اگر یک ماشین مجازی رفت برایش مشکلی ایجاد نشود. درواقع اگر از حالت مشترک استفاده کنید، به آن ماشین مجازی که دیدی از جهان را در خود نگه می‌دارد، وابسته می‌شوید و اگر آن ماشین از بین برود، مشکل‌ ایجاد می‌شود. راهی که می‌توانید با این مشکل برخورد کنید این است که از چیزهایی مانند گذرگاه پیام (Message Bus) استفاده کنید. یعنی همه بر روی یک گذرگاه پیام با هم تعامل می‌کنند. می‌توانید برای یکسری از رخدادها، ثبت‌نام کنید تا بتوانید تغییرات در حالت و اینجور چیزها را ببینید. [به این ترتیب] هر ماشین مجازی دید خودش از دنیا را دارد و مستقل از دید دیگران و بر طبق دید خود، عمل می‌کند.
فرض کنید OpenStack به این شکل نابخردانه طراحی می‌شد که داشتن حالت مشترک، کار ساده‌ای است، در آنصورت می‌توانید مثال بزنید که چه چیز خطرناکی پیش می‌آمد؟ فرضاً یک باگ در سطح برنامه که می‌توانست از این شرایط حالت مشترک، منتشر شود را مثال بزنید.
اگر حالت را به اشتراک می‌گذاشتیم، به اموری که حالت را معتبر نگه می‌دارند، وابسته می‌شدیم. یک مثال خوب برای‌تان می‌آورم. اولین باری که به Rackspace رفتم تا کار مهندسی ابر را بکنم، آن‌ها یک زیرساخت محاسباتی داشتند که مبتنی بر یک شرکت با نام Slicehost بود که مالکیتش را گرفته بودند. و آن‌ها، خودشان یک سیستم ذخیره اشیاء ساخته بودند. قبل از من، هفته اول، وقتی می‌خواستند سیستم اشیاء را راه‌اندازی کنند، ترافیک زیادی سمتش آمد و پایین آمد و چندین روز طول کشید تا آن را برگردانند. مشکلی که در طراحی آن سیستم اشیاء بود این بود که آن را در یک پایگاه داده متمرکز قرار داده بودند. به عنوان یک سیستم ذخیره‌سازی تعداد خیلی خیلی زیادی دیسک دارید و اگر همه ترافیک‌تان را مسیریابی کنید و این نیازمندی را داشته باشید که برای هر تراکنشی یک درخواست همگام (Synchronous) به پایگاه داده داشته باشید، می‌ببینید که چطور مقیاس‌پذیری‌تان می‌تواند تحت تأثیر قرار گیرد. هرچه افراد بیشتری بخواهند با سیستم صحبت کنند، جدل بیشتری بر روی منبع مشترک خواهید داشت و مع‌الاسف، خاموشی بدتری خواهید داشت. خبر خوب این است که ما درس‌هایمان را از آن آموختیم و یک سیستم ذخیره‌سازی اشیاء را از نو ساختیم. یعنی سیستم Swift که اکنون در OpenStack قرار دارد.
بسیار خوب. بگذار در مورد سازگاری تدریجی (Eventual Consistency) صحبت کنیم. OpenStack با ذهنیت سازگاری تدریجی طراحی شده است. آیا می‌توانید این اصطلاح را تعریف کنید و توضیح دهید که چرا این اصطلاح به OpenStack مرتبط است؟
بله، قطعاً این یکی از مفاهیم اساسی در سیستم‌های توزیع‌شده بزرگ‌مقیاس است. دوباره سیستم ذخیره‌سازی‌ اشیاء را به عنوان مثال استفاده می‌کنم. فرض کنید که سیستم ذخیره‌سازی‌ام را ساخته‌ام و ده هزار دیسک دارم. سیستم‌های ذخیره‌سازی اشیاء با روش تهیه کپی‌های تکراری بر روی برخی نمونه‌ها (Instance) کار می‌کنند. بنابراین وقتی تکه داده‌ای را می‌نویسم، بین ده‌هزار درایو، منتشر می‌شود و حداقل ۳ کپی وجود خواهد داشت. بنابراین هرگاه، یک کپی از دسترس خارج شود، می‌دانم که دو کپی خوب دیگر دارم تا از آن‌ها بازیابی کنم. ایده‌اش این است که ما در سیستم، تأخیر (Latency) داریم. بنابراین ممکن است که برنامه‌ای داشته باشم که به دنبال تکه خاصی از محتوای ذخیره‌شده باشد و برنامه دیگری هم داشته باشم که از لحاظ جغرافیایی در سمت دیگر توپولوژی رونوشت‌برداری (Replication) باشد و در یک لحظه زمانی، هر دو فکر می‌کنند که دارند فلان فایل را نگاه می‌کنند اما آن فایل برای مدت زمان مشخصی -قبل از آنکه رونوشت‌برداری رخ دهد- در هر دو سمت یکسان نیست. و این اشکالی ندارد. این همان ایده سازگاری تدریجی است. در نهایت، وقتی رونوشت‌برداری انجام شد، همه چیز سازگار می‌شود اما باید این حقیقت را بپذیریم که در یک پنجره زمانی، برنامه A و برنامه B ، با پرس‌وجو از چیزی که فکر می‌کنند که ذخیره‌‌گاه اشیاء یکسانی است، نتایج متفاوتی حاصل می‌کنند.
و OpenStack درجه‌ای از سازگاری قابل تنظیم (Tunable Consistency) را دارد. آیا می‌توانید این اصطلاح را هم توضیح دهید و بگویید که چطور سطح سازگاری در OpenStack قابل تنظیم است؟
بله، این چیزی است که بعد از من اضافه شد. اگر همگامی محکم‌تری بخواهید آن را با میزان انعطاف‌پذیری (Resiliency) مصالحه می‌کنید. می‌توانید سیستمی بسازید که کاملاً سازگار باشد. یعنی اگر سازگاری تدریجی را یک سر طیف و همواره سازگار بودن را سر دیگر طیف در نظر بگیرید، می‌توانید سیستمی بسازید که طبق هر کدام از این حالت‌ها کار کند. در OpenStack، برای عده‌ای، پارامتر‌های اولیه طراحی کفایت نمی‌کرد. این یک چیز خوب درباره متن‌باز است. در بخشی از کار این پروژه، برخی گفتند که: «ما این همه کپی نمی‌خواهیم ولی می‌خواهیم که همه همگامی محکم‌تری داشته باشند. ما می‌خواهیم که دو برنامه که به یک ذخیره‌گاه اشیاء نگاه می‌کنند همواره وقتی سئوال یکسانی می‌پرسند، جواب یکسانی بگیرند.» و این قابلیت، به عنوان یک فرآیند عادی متن‌باز، اضافه شد.
حال که در مورد متن‌باز صحبت کردیم، آیا می‌توانید روشن کنید که انجمن متن‌بار OpenStack چطور کار می‌کند و افراد چطور با هم تعامل می‌کنند؟ متن‌باز چطور پیش می‌رود؟
من این موضوع را خیلی دوست دارم. فکر می‌کنم که متن‌باز یک جنبش عظیم بوده است. فکر می‌کنم خیلی از ابداعاتی که در مورد نحوه ساختن نرم‌افزار با تعاملات داشته‌ایم از پروژه‌هایی مانند OpenStack می‌آید. در‌واقع نیازمندی‌هایی که در این زمینه وجود دارد -یعنی این که چطور انجمن بزرگی از افراد که بین کشورها و فرهنگ‌های زیادی گسترش دارند و در مناطق زمانی مختلفی گسترش دارند، همگی در یک پروژه تعامل داشته باشند- باعث شده است خیلی از ابداعات رخ دهد. من می‌بینم که نتیجه این ابداعات، به سازمان‌های معظم هم می‌رسد، اینکه چطور نرم‌افزار بسازند، چطور خط لوله تحویل مستمر (Continuous Delivery) خودشان را بسازند، اینکه چطور در آن خط لوله‌های تحویل مستمر و یکپارچه‌سازی مستمر، خودکارسازی داشته باشند.
در OpenStack ما با یکسری ابزارهای پایه برای کنترل نسخ (Version Control) و بازبینی کد (Code Review) و خودکارسازی تست شروع کردیم. و در طی سال‌ها، این‌ها خیلی خیلی پیچیده شد طوریکه بخش یکپارچه‌سازی مستمر، بخش تست مستمر، بخش استقرار مستمر اضافه شده است و ابزارهای آن هم از دیگر پروژه‌های متن‌باز مانند Jenkins رشد کرده است. تیم اولیه‌ای بود که ابزارهایی برای ما در ارتباط با نحوه مدیریت کردن کد منبع، نحوه Build کردن آن و نحوه استقرار مستمر می‌ساخت. این تیم در Rackspace برای من کار می‌کرد و همینطور برایم در HP کار کرد، این افراد کار عظیمی برای انجمن متن‌باز انجام دادند. از طریق این تلاش‌های همکارانه است که OpenStack می‌تواند به این شکل، تأثیرگذار باشد: از طریق مجموعه ابزارهای خوب، مجموعه فرآيندهای خوب که هرکسی بداند قوانین چه هستند. و اگر از قانون پیروی نکنید، نمی‌توانید بر انجمن اثر بگذارید. انجمن خواهد گفت: «ما افرادی که از قوانین پیروی نمی‌کنند را نمی‌خواهیم.»
بنابراین سطح بالایی از ارتباطات وجود دارد و این امکان فراهم است که صدای‌تان را برسانید. این‌ها، چیزهای ایستایی نیستند که بر روی الواح نوشته شده باشند و با فرسایش کوه‌ها پایین آمده باشند بلکه یک فرآیند زنده، دارای نفس و طبیعی است که همواره در حال بازبینی است و همه می‌توانند پیشنهاد بدهند، همه می‌توانند در مکالمه وارد شوند. و فکر می‌کنم [این روش] نرم‌افزار بهتری می‌سازد.
وقتی در مورد فرآیندهایی که نرم‌افزار بهتری می‌سازد صحبت می‌کنیم، تست، در توسعه OpenStack، اهمیت خیلی زیادی دارد. به من بگویید، تست چگونه انجام می‌شود؟ برای کسی که می‌خواهد چیزی را کامیت کند و از او خواسته می‌شود که تست همراه آن را هم کامیت کند، چه سرمشق‌هایی (Best Practice) هست؟ در مورد چالش‌هایی که در مورد تست یک سیستم توزیع‌شده بزرگ مانند OpenStack وجود دارد [صحبت کنید].
موضوع خیلی خوبی است. همانطور که اشاره کردید باید با این سیاست، فرآیند و یا مجموعه قوانین آغاز کنید که هرگاه، کدی را داخل می‌فرستید باید همراه با آن تست را هم داخل بفرستید. اگر تست نداشته باشید نمی‌توانید مرحله بازبینی کد را رد کنید. اینکه چطور می‌توانید اعتبارش را تأیید کنید، سئوال خیلی جالب‌تری است.
از جنبه‌هایی، فرآیند یکپارچه‌سازی مستمر، می‌تواند واقعاً کمک‌تان کند. درواقع می‌توانید یک مأموریت تعریف کنید. با همین روش، Jenkins برای OpenStack برپا شده است. در آن می‌توانید یک ارشد (Master) داشته باشید و سیستم‌های CI کارگزار (Slave) خواهید داشت که می‌تواند برای یک سناریوی خاص، تنظیم شده باشد. مثلاً در HP، وقتی OpenStack را برپا می‌کردیم، توپولوژی مخصوصی برای مرکز داده داشتیم. روشن است که از ادوات HP، شبکه‌های HP و رَک‌های HP استفاده می‌کردیم. بنابراین توپولوژی ما شبیه هیچ توپولوژی دیگری در دنیا نبود. بنابراین ما می‌خواستیم که یک کارگزار CI برپا کنیم که هربار که کدی از OpenStack به داخل trunk می‌رفت، علاوه بر آنکه فرآیند یکپارچه‌سازی مستمر را به جریان می‌انداخت و وارد تست‌های یونیت پایه می‌شد، کار را با سرور‌های کارگزار CI از جمله ما هم بفرستد تا ما با تست در پیکربندی خودمان پیش برویم. آنگاه می‌توانستیم رأی خودمان را به‌ سرور CI برگرداندیم و بگوییم که نمره‌ A را گرفته است. و می‌توان در مورد این سیاست تصمیم‌گیری کرد که اگر [تست‌ها در] برخی کارگزارهای خاص، شکست خوردند آیا باعث مسدود شدن ادغام کد جدید به trunk بشود یا خیر.
این روش خیلی مؤثر است و در سازمان‌های معظمی که ممکن است چندین واحد کسب و کار یا دپارتمان مختلف داشته باشند، هم کار می‌کند. ما از آن در HP استفاده کردیم تا گروه شبکه، گروه نرم‌افزار و گروه ذخیره‌سازی را به هم ملحق کنیم. هرکدام از این‌ها، درباره مؤلفه‌های OpenStack و اینکه چه تست‌هایی باید قبول شود، دید خود را داشتند. بنابراین، سرورهای CI مختلفی را برپا کردیم که رأی خود را برمی‌گرداندند و اطلاعات را به بالادست می‌فرستادند.
ما در مورد توسعه خود OpenStack صحبت کرده‌ایم. از آنجایی که داریم به انتهای بحث نزدیک می‌شویم، می‌خواهم کمی از دید بالاتری نگاه کنم و در مورد کاربرد OpenStack صحبت کنیم. از طریق انتزاعی که OpenStack از حوض مشترک منابع دارد، توسعه‌دهنده با این مجموعه API های درمعرض قرار گرفته، به منابع محاسباتی، شبکه و ذخیره‌سازی دسترسی می‌یابد. خیلی دوست دارم با جزییات بیشتری توضیح داده شود که وقتی این مجموعه API در معرض قرار می‌گیرد، توسعه‌دهنده چه تجربه‌ای خواهد داشت و چگونه می‌توانیم بیشترین بهره را از اینAPI برای تولید سیستم‌مان ببریم.
تمام هدفش همین بوده است. هدف OpenStack این نیست که سیستمی بسازیم که فقط ساخته باشیم. اگرچه گاهی وقتی داخل پروژه هستیم، این نگاه را از دست می‌دهیم. هدف این سیستم درواقع ساخت محیطی است که افراد بتوانند برنامه‌های‌شان را بنویسند. بنابراین API ای که در معرض قرار داده می‌شود و حتی سرویس‌های پلتفرمی که در معرض قرار می‌گیرد همه جزیی از آن پرده‌ای است که توسعه‌دهنده به آن می‌نگرد. در نهایت، هدف از ابر، استقرار در ابر و «پلتفرم به عنوان سرویس» همگی این است که تجربه توسعه‌دهنده، روان‌تر شود و باعث شود که توسعه‌دهنده فقط نگران منطق سیستم‌اش باشد تا اینکه بخواهد فکر کند که: «آیا وب‌سرورها را بدرستی تنظیم کرده؟ گواهی‌های اعتبار پایگاه داده چه هستند؟ و ...»
بسیار خوب، و شاید یک موضوع فنی دیگر باشد که قبلاً اشاره کردم اما در آن عمیق نشده‌ایم و آن برنامه‌ریز (Scheduler) است. برنامه‌ریز چیست و چرا با موضوع OpenStack مرتبط می‌شود؟
برنامه‌ریز، واقعاً قلب OpenStack است. قلب هر نوع سیستم توزیع‌شده‌ای است، چه در مورد توری‌ها (Grid) و سیستم‌های محاسباتی با کارایی بالا صحبت کنیم و چه در مورد سیستم‌های محفظه‌شده‌ (Containerized) دارای برنامه‌ریز مانند Kubernetes یا Mesos صحبت کنیم.
برنامه‌ریز، یک همنواساز (Orchestrator) است که فرضاً می‌گوید: «از من خواسته شده که بار کاری مشخصی را مستقر کنم. آن را باید کجا بگذارم؟ آیا می‌خواهم که یک نمونه را مستقر کنم یا چند نمونه؟ اگر بخواهم چند نمونه را مستقر کنم، چه قوانینی در مورد همجواری (Affinity) یا ناهمجواری وجود دارد؟ و ... » واقعاً قلب یک زیرساخت محاسباتی است. برنامه‌ریز است که می‌گوید: «این درخواست برای اجرای فلان برنامه خاص وجود دارد. آن را در کجای بستر قرار دهم؟» عموماً یک حلقه بازخورد و یک حلقه مانیتورینگ وجود دارد که ممکن است بررسی سلامتی (Health Check) یا هر چیز دیگری خوانده شود تا اگر به عنوان برنامه‌ریز، بار کاری خاصی را مستقر کردم، بفهمم که به مشکل خورده یا مرده است. و در سیستم‌های ابری، معمولاً همه زیرساخت‌ها اصطلاحاً تغییرناپذیر (Immutable) هستند یعنی بجای اینکه تلاش کنیم چیزی که خراب شده، را درست کنیم، تنها یک گلوله در مغزش خالی می‌کنیم و یکی دیگر را مستقر می‌کنیم.
بخاطر آورید که پیشتر در این مورد صحبت کردیم که نمی‌توانیم بر روی ماشین‌های مجازی حساب کنیم. آن‌ها بی‌دوام (Ephemeral) هستند. نمی‌توانید حساب کنید که همیشه آنجا هستند. یک دلیلش همین است. چون اگر مجبور باشیم یکی را بیرون بیاندازیم و یکی دیگر را جایش بگذاریم و سر قلابش را به ترازگر بار (Load Balancer) بدهیم، این کار را می‌کنیم. سناریوی دیگر که در اینجا نقش بازی می‌کند، حرکت بار کاری (Workload Motion) است. برای نمونه، اگر سرور خاصی داشته باشم و نیاز داشته باشم که آن را پایین بیاورم، اولین کاری که باید بکنم این است که همه ماشین‌های مجازی و همه برنامه‌هایی که بر روی آن اجرا شده را به بخش‌های دیگر سیستم، تخلیه کنم. اتفاقی که در این حال می‌افتد این است که یک اخطار به برنامه‌ریز برگشت داده می‌شود که: «من ۲۷ نمونه از فلان برنامه‌ها را داشتم که اینجا اجرا بودند. تو باید برای آن‌ها یک جای دیگر پیدا کنی.» و برنامه‌ریز آن‌ها را دوباره برنامه‌ریزی می‌کند. به این ترتیب قادر خواهیم بود که برای سروری که برای تعمیرات یا مقصود دیگری قرار است پایین بیاید، ماشین‌های مجازی و برنامه‌هایی که بر روی آن بوده را خاموش کنیم.
خیلی علاقه‌مندم که بحث را به این ترتیب ببندم که از دید بالاتری نگاه کنیم و از منظر آینده‌، تصویرش کنیم. ما برای اینکه پردازش ابری انجام دهیم همه این روش‌های مختلف را داشته‌ایم: AWS و Azure و DigitalOcean و Rackspace و هر چیزی که از OpenStack استفاده می‌کند. این پلتفرم‌های مختلف در طی زمان چطور دارند تکامل می‌یابند؟ و توسعه‌دهنده چطور باید این شرایط را تشخیص دهد؟
این سئوال واقعاً خوبی است. آنچه طی چند سال اخیر دیده‌ایم، یک گسترش بزرگ در رهبران بازار از قبیل Amazon و Azure است. دیده‌ایم که در گوگل، کارهای واقعاً خوبی انجام شده‌است. آن‌ها توجه خود را معطوف به سازمان‌های معظم کرده‌اند که تازگی دارد. فکر می‌کنم آنچه در طی زمان خواهیم دید چند چیز است. یک رقابت ادامه‌دار بین بازیگران بزرگ خواهیم دید. بازیگرانی که صاحب پول هستند، می‌خواهند کنترل کار را به دست بگیرند و می‌خواهند که مراکز داده بسازند و می‌خواهند در این تجارت مشاور املاک‌گونه، شریک باشند و بنابراین یک گسترش ادامه‌دار از مایکروسافت و آمازون و اپل و برخی دیگر از آن‌ها خواهیم دید.
مورد دومی که خواهیم دید رقابت در فضای عمودی ابر است. برای من به عنوان یک فراهم‌کننده سرویس ابری، خیلی دشوار است که در تجارت کالایی اینچنین رقابتی و حساس به قیمت، رقابت داشته باشم اما اگر ارزش بیافرینم و ابری بسازم که برش عمودی خاصی را هدف قرار داده باشد، چه مربوط به حکومت باشد، یا مربوط به بهداشت باشد یا هر چیز دیگری که باشد، من را قادر می‌سازد که ارزش منحصربفردی برای بخش خاصی از بازار، فراهم کنم. فکر می‌کنم این برش‌های عمودی را هم خواهیم داد.
در نهایت، فکر می‌کنم API روی آن‌ها (API مربوط به آمازون، API مربوط به OpenStack در ابر Rackspace و ...) با هم متشکل می‌شوند. یعنی درست مثل امروز که وقتی بار کاری‌ام را داخل ابر می‌گذارم، نمی‌دانم کجا اجرا می‌شود، فکر می‌کنم در آینده قادر خواهیم بود که یک بار کاری را در یک بافت ابری (Cloud Fabric) بگذاریم و آن بافت می‌تواند با ارزیابی داده‌های زیاد، الگوریتم‌های ابتکاری (Heuristic) را اجرا کند تا بسته به سیاست‌های تعریف‌شده کسب و کار آن بار کاری را در مرکز داده آمازون یا مایکروسافت یا یک مرکز داده خصوصی قرار دهد. از نظر من، این چیزی است که در Automic Software روی آن کار می‌کنیم تا چنین دنیایی بسازیم.
خیلی جالب به نظر می‌رسد. دارد وقت می‌گذرد و نمی‌خواهم سئوال بزرگی بپرسم اما خوب الان سئوال بزرگی پرسیدم :-)
آیا فکر می‌کنید یک دنیای ابری چندزبانی خواهیم داشت که در آن مثلاً یک شرکت بزرگ هستم و ابر برای رسانه‌ی خودم را دارم که فرضاً بر روی داده‌های Netflix اجرا می‌شود و مثلاً سیستم‌های یادگیری ماشینی دارم که بر روی مراکز داده گوگل هستند چون گوگل در زمینه پلتفرم‌های یادگیری ماشین به عنوان سرویس، خوب است و شاید ذخیره‌سازی‌ام بر روی آمازون باشد چون آمازون در این زمینه بهترین است. آیا به سمت یک دنیای ابری چندزبانی پیش می‌رویم؟
معتقدم به سمت آن دنیا پیش می‌رویم و این ناشی از سیاست‌های کسب و کار و ویژگی‌ها و پیکربندی‌های ابرهای مختلف است. بنابراین وقتی بارکاری خاصی داشته باشم که فلان خصیصه‌ها را داشته باشد مثلاً می‌تواند این خصیصه را داشته باشد که یادگیری ماشین باشد، سیستم خواهد گفت که: «من می‌دانم که این باید بجای آمازون، به گوگل برود.» یا مثلاً می‌تواند به این شکل باشد که بگویم: «این محیط توسعه و تست من است. ارزان‌ترین جا را برایش پیدا کن.» آن موقع ممکن است که آن، جایی در سرورهای DigitalOcean باشد. من اعتقاد کامل دارم، دنیا به این سمت می‌رود. من خیلی در مورد خودکارسازی‌های ابتکاری و الگوریتمی هیجان‌‌ دارم. فکر می‌کنم این سومین پایه از یک سه‌پایه است.
اولین پایه، خودکارسازی‌های سنتی است که امروزه داریم: خودکارسازی‌ انتشار برنامه کاربردی و خودکارسازی مراکز داده که برای چندین سال در جریان بوده است که با خودکارسازی دفترچه‌دستور (Runbook) و خودکارسازی بارکاری (Workload) آغاز شد و اکنون خیلی از کارهای DevOps را در جاهای خودکار این فضا انجام می‌دهیم.
پایه دوم، خودکارسازی بومی ابر (Cloud Native) است که درواقع از دنیای PaaS آمده است. اگر به CloudFoundry و OpenShift و Herokou بنگرید، آن‌ها واقعاً یک اکوسیستم غنی برای توسعه‌دهنده هستند اما برای اپراتورها، یک خودکارسازی خودسر دارند. می‌بینم که این دو دنیا هر چه سریع‌تر دارند با هم ترکیب می‌شوند.
و البته پایه سوم، خودکارسازی ابتکاری یا الگوریتمی است که غیرقطعی است، برآمده از سیاست است یعنی به سیستم می‌گویید که چه می‌خواهید و به سیستم حجم زیادی داده از سنسورها - آن را اینترنت اشیاء (Internet of Things) بخوانید- و داده‌های تله‌متری از سرورها و شبکه‌‌ها و … می‌آید. و قادر است که بگوید برای فلان نوع خاص بارکاری، بگذار آن را بسته به خصوصیات بارکاری و در دسترس بودن منابع، فرضاً در گوگل یا در فلان مرکز داده خصوصی که در اوهایو یا کلیولند داریم، بگذاریم.
جای خوبی است که بحث را پایان دهیم. افراد کجا می‌توانند بیشتر در مورد تو بدانند؟
وب‌سایت ما، www.automic.com است. همچنین در توییتر، شناسه‌ام @johnpour است.