درباره DevOps و اسنوفلیکها
امروزه در IT تقریباً غیرممکن است که حرفی درباره DevOps نشنوید. DevOps موضوع جدید و داغ صنعت است که از جایی که صحبت از ابر تمام شد ادامه میدهد و اگر به صحبتهای مردم درباره آن گوش دهید، ممکن است تصور کنید که مدیریت سیستمهای سنتی قبلاً مرده و دفن شده است.
ابتدا باید درباره منظورمان از DevOps صحبت کنیم. این میتواند گیجکننده باشد چون مانند ابر، یک اصطلاح قدیمیتر اغلب دزدیده میشود تا چیز متفاوتی یا در بهترین حالت مرتبطی با چیزی که قبلاً وجود داشت به کار رود. DevOps سنتی ادغام نقشهای توسعهدهنده و عملیاتی بود. در دهههای ۱۹۶۰ تا ۱۹۹۰، این روش استاندارد اجرای سیستمها بود. در این دنیا، افرادی که نرمافزار مینوشتند معمولاً همان کسانی بودند که آن را استقرار و نگهداری میکردند. از این رو ادغام «توسعهدهنده» و «عملیات»، که عملیات یک اصطلاح نیمهاستاندارد برای نقش مدیر سیستم است. این نقشها تا ظهور «بخش IT» در دهههای ۱۹۹۰ و ۲۰۰۰ به طور رایج جدا نشده بودند.
جایی که امروزه اغلب از DevOps صحبت میشود به عنوان ادغام دقیق توسعهدهندگان و کارکنان عملیاتی نیست بلکه به عنوان تغییر در کارکنان عملیاتی با تمرکز بسیار بیشتر بر کدنویسی نه خود برنامه بلکه در تعریف زیرساختهای برنامه به عنوان کد به عنوان امتداد طبیعی معماریهای ابری است. DevOps سنتی آن چیزی نیست که امروزه به طور رایج اتفاق میافتد بلکه یک DevOps «جعلی» جدید است که در آن توسعهدهندگان توسعهدهنده میمانند و عملیات عملیات میماند اما عملیات به یک نقش «کد-محور» جدید تبدیل شده است.
آنچه امروز قابل توجه است این است که نقش مدیر سیستم شروع به تفکیک به دو نقش مرتبط اما به طور قابل توجهی متفاوت کرده است، که یکی از آنها به اشتباه توسط اکثر صنعت DevOps نامیده میشود. من از اصطلاح اسنوفلیک برای اشاره به معماریهای سنتی سیستمها استفاده میکنم زیرا هر سرور مجزا میتواند به عنوان یک «اسنوفلیک منحصر به فرد» دیده شود.
من از اصطلاح اسنوفلیک برای اشاره به معماریهای سنتی سیستمها استفاده میکنم زیرا هر سرور مجزا میتواند به عنوان یک «اسنوفلیک منحصر به فرد» دیده شود. همه آنها متفاوت هستند، حداقل تا آنجا که به شکلی مدیریت نشوند که یکسان بمانند. در محیطهای سنتی یک مدیر سیستم برای کار روی هر سرور به صورت جداگانه وارد میشود.
تسهیل مدیریت معماریهای اسنوفلیک اغلب شامل تلاش برای به حداقل رساندن تفاوتها بین سیستمها به روشهای معقول است. این به طور کلی با انتخاب یک سیستمعامل و نسخه استاندارد واحد (Windows 2012 R2 یا Red Hat Enterprise Linux 7) به جای اجازه دادن به هر نصب سرور که یک سیستمعامل یا نسخه متفاوت باشد شروع میشود.
قدم بعدی معمولاً ایجاد یک روش استقرار استاندارد یا یک تصویر استاندارد طلایی است که برای ساختن همه سیستمها استفاده میشود تا سیستمعامل پایه و همه بستههای پایه، اغلب شامل سفارشیسازی سیستم، بستههای نظارت، بستههای امنیتی، پیکربندی احراز هویت و تغییرات مشابه استاندارد باشند.
فراتر از این مراحل، محیطهای اسنوفلیک معمولاً از اسکریپتهای مدیریت سفارشی یا ابزارهای مدیریتی برای حفظ استانداردسازی بین سیستمها در طول زمان استفاده میکنند. هر چه اشتراکات بیشتری بین سیستمها وجود داشته باشد، نگهداری و عیبیابی آنها آسانتر است.
رویکرد DevOps به طور ارگانیک از مدل معماری ابر رشد میکند. معماری ابر حول سیستمهای به طور خودکار ایجاد شده و به طور خودکار تخریب شده، که به طور گسترده یکسان هستند و از طریق یک رابط برنامهریزی یا API کنترل میشوند، طراحی شده است. این مدل به وضوح خود را برای کنترل مرکزی از طریق یک سیستم مدیریت به جای تلاشهای دستی یک مدیر سیستم ارائه میدهد.
ایدهای که از دنیای معماری ابر ظهور کرده این است که معماری سیستمها باید به صورت مرکزی «در کد» تعریف شود نه در خود سرورها. این در ابتدا گیجکننده به نظر میرسد اما وقتی عمیقتر نگاه میکنیم خیلی منطقی است. مجموعههای ابزاری رایج در این حوزه شامل Puppet، Chef، CFEngine و SaltStack هستند.
ایده پشت این مجموعههای اتوماسیون این است که یک سرویس مرکزی برای مدیریت و کنترل همه سیستمها استفاده میشود. این مرجع مرکزی سرورهای مجزا را از طریق توصیفات مبتنی بر کد از اینکه سیستم چگونه باید به نظر برسد و رفتار کند مدیریت میکند. در دنیای Chef، اینها «دستورها» نامیده میشوند که اشاره ظریفی است اما قیاس به خوبی کار میکند. کد هر سیستم ممکن است شامل اطلاعاتی مانند فهرستی از بستهها و نسخههای بستههایی باشد که باید نصب شوند، تغییراتی که باید در پیکربندی سیستم ایجاد شود و فایلهایی که باید به دستگاه کپی شوند.
این تعاریف استاندارد به این معنی است که سیستمها، پس از اختصاص به یک نقش، میتوانند به طور خودکار «خودشان را بسازند». یک سیستم جدید ممکن است توسط یک مدیر درخواست شود یا یک سیستم نظارت بر ظرفیت ممکن است تصمیم بگیرد که برای یک نقش به ظرفیت بیشتری نیاز است و نمونههای جدید سرور را به طور خودکار بدون هیچ مداخله انسانی ایجاد کند.
تعریف سیستمها در کد برخی عواقب غیر واضح دارد. یکی این است که پشتیبانگیری از سیستمهای کامل دیگر لازم نیست. چرا از سیستمی که میتوانید آن را با حداقل تلاش، تقریباً فوری بازسازی کنید پشتیبان بگیرید? دادههای محلی از سیستمهای پایگاه داده باید پشتیبانگیری شوند اما فقط دادههای پایگاه داده، نه کل سیستم.
مقدار مستنداتی که برای سیستمهای تعریف شده در کد نیاز است بسیار حداقل است. در محیطهای اسنوفلیک مدیر سیستم باید مستندات خاص هر هاست را نگهداری کند که بسیار وقتگیر و مستعد خطا است. سیستمهایی که از طریق کد مرکزی تعریف شدهاند به مستندات کمی نیاز دارند و مستندات میتواند در سطح گروه، نه سطح گره مجزا مدیریت شود.
آزمایش سیستمهایی که در کد تعریف شدهاند نیز آسان است. میتوانید یک سیستم را از طریق کد ایجاد کنید، آن را آزمایش کنید و بدانید که وقتی آن تعریف را به محیط تولید منتقل میکنید، سیستم تولید به طور قابل تکرار دقیقاً همانطور که در آزمایش ایجاد شد، ایجاد خواهد شد.
رویکرد DevOps، با این حال، با هشدارهای بزرگی نیز همراه است. مجموعه مهارتهای لازم برای مدیریت یک سیستم به این روش بسیار بیشتر از آنچه برای مدیریت سیستمهای سنتی لازم است، است زیرا حداقل تمام دانش مدیریت سیستم سنتی هنوز مورد نیاز است به اضافه دانش برنامهنویسی محکم، معمولاً از زبانهای مدرن مانند Python و Ruby و دانش فریمورکهای خاص مورد نظر.
مدیران سیستم کار کردن در هر یک از این دو اردوگاه تمایل دارند که همه سیستمها را به عنوان نیازمند تناسب با قالب خود ببینند. متخصصان جدید DevOps اغلب فکر میکنند سیستمهای اسنوفلیک قدیمی هستند و نیاز به بهروزرسانی دارند. مدیران اسنوفلیک (سنتی) تمایل دارند که جنبش «زیرساخت به عنوان کد» را احمقانه، پر از سربار غیرضروری، بیش از حد پیچیده و بسیار تخصصی ببینند.
واقعیت این است که هر دو رویکرد به شدت ارزشمند هستند و هر دو بسیار قابل اجرا خواهند ماند. هر دو برای بارکارهای بسیار متفاوت منطقی هستند و من گمان میکنم سازمانهای بزرگ به طور رایج هر دو را از طریق نوعی ترکیب خواهند داشت. در بازار SMB که معمولاً تعداد بسیار کمی از سرورها، هیچ اهرم مقیاسپذیری برای توجیه معماریهای ابری و اختلاف بالا بین سیستمها وجود دارد، گمان میکنم DevOps تقریباً به طور نامحدود خارج از هنجار باقی بماند.
این تفاوت در رویکرد به این معنی است که، برای مثال در ایالات متحده، اکثر کشور متشکل از شرکتهایی است که بر مدل مدیریت اسنوفلیک متمرکز خواهند ماند در حالی که برخی از شرکتهای ساحل شرقی میتوانند مدل DevOps را به طور مؤثر ارزیابی کنند. اما در ساحل غربی جایی که معماریهای مدرنتر و تمرکز بسیار بیشتر بر برنامههای میزبانی شده عوامل اقتصادی اصلی هستند، DevOps از تازهوارد به عادی شدن بالغ در حال حرکت است.
هیچکدام از رویکردها بهتر یا بدتر نیستند، آنها دو رویکرد مختلف هستند که دو روش بسیار متفاوت تأمین سیستمها و دو نیاز اساسی متفاوت آن سیستمها را خدمت میکنند. با ظهور معماریهای ابری و مدل DevOps، با این حال، بسیار مهم است که مدیران سیستم موجود بدانند که مدل DevOps به چه معناست و چه زمانی اعمال میشود تا بتوانند بارکارها و نیازهای منحصر به فرد خود را به درستی ارزیابی کنند.
منتشر شده در وبلاگ StorageCraft.
آگهی
