دوشنبه , ۲۷ خرداد ۱۳۹۸
خرید فالوور اینستاگرام خرید لایک اینستاگرام

چه شد که DevOps متولد شد

برای نوشتن اولین متن برای ElastUp تصمیم داشتم از DevOps شروع کنم اما بهتر دیدم که ابتدا در مورد سیر تحولاتی بنویسم که در طول بازه ای کمتر از ۲۵ ساله به DevOps که این روزها هم بسیار محبوب شده برسم.

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

در سال‌های ابتدایی همه‌گیر شدن کامپیوترها، پیشرفت در سخت‌افزارها به‌خصوص از نظر سرعت، مهم‌ترین عامل پیشرفت سیستم‌های کامپیوتری به حساب می‌آمدند. در چنین فضایی، این بهبودها به اندازه‌ای چشم‌گیر بودند که اهمیت بهبودهای‌ نرم‌افزاری حس نشود. در این سال‌ها سه عضو عمده سیستم‌های کامپیوتری یعنی بخش‌های پردازش، ذخیره‌سازی و شبکه هر کدام دارای سخت‌افزارهایی مجزا بودند. اولین نرم‌افزارهای Back-end با پیچیدگی‌های امروزی بسیار فاصله داشتند و به طور معمول در قالب یک نرم‌افزار یکپارچه طراحی و اجرا می‌شدند. در این سال‌ها لینوکس و اکوسیستم آن در حال طی کردن مراحل نوزادی بودند و نرم‌افزارهای منبع‌باز و آزاد با ارزان‌تر شدن سخت‌افزارها در حال تربیت توسعه‌دهندگان آزاد بیشتری بودند. اما به تدریج در سال‌های ابتدایی قرن جدید سخت‌افزارهای محاسباتی به مرحله‌ای رسیدند که عملا امکان افزایش سرعت آن‌ها وجود نداشت، اما با این حال روند کمتر و کمتر شدن ابعاد ترانزیستورها با روند ثابتی ادامه داشت (این پیش‌بینی تکنولوژیک به قانون مور معروف است). بنابراین پیشرفت‌های سخت‌افزاری در قالب افزایش تعداد پردازنده‌ها روی یک چیپ پردازنده ادامه پیدا کرد.

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

اهمیت مجازی‌سازی به حدی بود که در مجموعه دستورات X86 جزو معدود افزونه‌های کاملا جدید در قرن ۲۱ (در واقع بعد از تثبیت این معماری در اواخر دهه ۹۰ میلادی) به حساب می‌آید. حالا مجازی‌سازی یک شهروند درجه یک برای پردازنده‌های چندهسته‌ای به حساب می‌آمد. مجازی‌سازی تا حد خوبی باعث نرم‌افزاری‌تر شدن بارهای کاری نرم‌افزارهای سطح تولید شده بود. به همین دلیل تغییراتی در معماری نرم‌افزارهای Back-end باعث شد که یکی از مهمترین محصولات آن، معماری سرویس محور، بوجود بیاید.

در سال‌های آغازین دهه ۲۰۱۰ میلادی تب “به عنوان یک سرویس” (as a Service) شروع به بالا گرفتن کرد و به این ترتیب نرم‌افزارهای بزرگ که تا آن روز معماری یکپارچه (monolith) داشتند، شروع به تکه‌تکه شدن کردند. این روند علاوه بر معماری نرم‌افزاری، به‌شدت بر زیرساخت‌ها نیز تاثیر گذاشت و به کمک مجازی‌سازی، زیرساخت به عنوان سرویس یا همان IaaS به روش اصلی پیاده‌سازی زیرساخت‌ها تبدیل شد. با استفاده از این سرویس امکان استفاده از سخت‌افزارهای معمولی در محیط‌های تحت بارهای تولیدی کاملا ممکن شد. همچنین روند هزینه‌بر و طولانی تامین زیرساخت محاسباتی مناسب با استفاده از این سرویس‌ها کم‌هزینه‌تر و حتی تا حد قابل توجهی کوتاه‌تر شد. حالا شرکت‌های کوچکتر توانایی دسترسی آسان‌تر به منابع محاسباتی را به‌دست‌آوردند. ظهور IaaS سبب پیدایش کلیدواژه‌های بسیار شنیده شده …Software Defined شد. بنابراین ناگفته پیداست که این روند منجر به نرم‌افزاری شدن منابع سخت‌افزاری (محاسبات، شبکه و ذخیره‌سازی) شد. به کمک این تغییرات عمده بود که صاحبان ایده به‌تدریج توانستند به پیاده‌سازی نرم‌افزاری ایده‌هایشان بپردازند و اکوسیستم‌های استارتاپی و نرم‌افزارهای موبایل به سرعت رشد کردند. این تغییر تکنولوژی در واقع یک بازی برد برد برای ارائه‌دهنده سرویس‌های کامپیوتری و توسعه‌دهندگان نرم‌افزار و کسب و کارها بود چرا که حالا روند بازنشسته‌شدن سخت‌افزارها کند شده و امکان اشتراک یک سخت‌افزار بین چند سرویس‌گیرنده فراهم شده بود که باعث کاهش هزینه سرویس‌ها از یک سو و افزایش درآمد سرویس‌دهنده‌ها از سوی دیگر شد. صاحبان کسب و کارها نیز توسعه‌دهندگانی داشتند که می‌توانستند تا حدودی، تمرکز کامل خود را بر روی اجرای ایده‌ها بگذارند. اما هم‌اکنون، طبق جمله معروفی که در ابتدای نوشته به آن اشاره کردم، نرم‌افزار در حال قورت دادن دنیا بود نیاز به اطمینان‌پذیر بودن نرم‌افزارها و زیرساخت‌ها کاملا احساس می‌شد.

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

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

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

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

معماری مایکروسرویس تشویق می‌کند که هر مایکروسرویس (که در واقع پروسسی نرم‌افزاری است) کار مستقلی را به درستی انجام دهد و درخواست‌های کابران از طریق ارتباط بین این مایکروسرویس‌ها انجام شود. بنابراین به‌نظر می‌آید که حالا کانتینرها بهترین محیط بسته‌بندی و اجرای مایکروسرویس‌ها به حساب می‌آیند. ارتباطات زیاد بین این مایکروسرویس‌ها نیز می‌توانند از مجازی‌سازی شبکه‌ها روی یک یا چند ماشین مدیریت شوند. از سوی دیگر استفاده از قابلیت جابجایی مناسب کانتینرها نیازمند وابستگی کم آن‌ها به محل قرارگیری داده‌ها است. بنابراین Software Defined Storage ها باید وارد محیط شوند. این‌بار بر خلاف نقش اساسی سیستم‌عامل‌ها در اوج‌گیری مجازی‌سازی، مدیریت فرآیندهای مربوط به اجرا و انتقال کانتینرها به ابزارهایی موسوم به ابزارهای ارکستریشن سپرده شد. معروف‌ترین ابزار ارکستریشن در حال حاضر کوبرنیتز بسیار معروف است. این ابزار به نوعی فرزند منبع باز پروژه Borg شرکت گوگل است، که در زمان معرفیش توسط گوگل از دید بسیاری یکی از اصلی‌ترین عوامل تمایز گوگل با سایر شرکت‌ها شناخته می‌شد. اما حالا Kubernetes در دسترس عموم قرار گرفته تا خودکار کردن فرآیندهای نرم‌افزاری را با مدیریت کانتینرها همه‌گیر کند. مدیریت انسانی چنین فرآیندهایی نیازمند فرهنگ و ساختار تیمی متفاوتی است که این روزها تحت عنوان کلی DevOps شناخته می‌شود که هدف اساسی آن چابک کردن ارائه نرم‌افزارها و پاسخگو نگاه‌داشتن آن‌ها در بیشترین زمان ممکن است. دغدغه اصلی ما در ElastUp یادگیری، پیاده‌سازی و آموزش این فرآیندها و پیگیری تازه‌ترین پیشرفت‌های مهندسی نرم‌افزار است.

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

در پست‌های بعدی بیشتر و عملی‌تر در مورد DevOps و رایانش ابری که عمدا در این مطلب به آن اشاره نکردم خواهم نوشت.  

تصویر سربرگ مقاله از hackernoon

 

درباره ی امیراحمد ضیایی‌پور

Avatar
دانشجوی دکترای الکترونیک، دانشگاه امیرکبیر علاقه‌مند به خودکارسازی فرآیندهای نرم‌افزاری، پردازش‌ موازی و توزیع‌شده و طراحی سخت‌افزار و اکوسیستم Cloud-Native کارشناس DevOps شرکت تحلیلگر امید

دیدگاه بگذارید

avatar
  مشترک شدن  
اطلاع‌رسانی