سازمان هایی که کارهای خود را به سرور ابری منتقل کردهاند ، باید پس از این جابجایی به دنبال ساخت نرمافزاری باشند که برای استفاده از منابع سرور ابری طراحی شده باشد.
چه چیزی در یک Buzzword وجود دارد؟
اغلب احساس دوگانهای ( علاقه/ تنفر) نسبت به کلمات ترکیبی (buzzword) وجود دارد . از سویی به قدری بی نظم و بیحساب از این کلمات استفاده میشود که تقریباْ کاربرد واقعی خود را از دست میدهند و از سویی دیگر به نظر می رسد تنها راه بیان اجمالی برخی مفاهیم، استفاده از buzzword است.
Cloud-native ( بومی سرور ابری) از این دسته کلمات است . اخیراْ به نظر میرسد که به همه چیز و هیچچیز عنوان بومی سرور ابری داده میشود. باور نمیکنید؟ عبارات «سختافزار بومی سرور ابری» ، « کارشناس فروش بومی سرور ابری» و « شرکت حسابداری بومی سرور ابری» را در گوگل جستجو کنید. میبینید که استفاده از این عبارت همهگیر شده است. با این حال ، اگر از این عبارت استفاده نکنیم، چگونه میتوانیم موج جدید نرمافزارهایی را که برای اجرا بر روی پلتفرم سرور ابری عمومی و سرور مجازی ساخته میشوند را توصیف کنیم؟ به نظر میرسد که نمی توان عنوانی بهتر از ( بومی سرور ابری ) و ( سرور مجازی ) برای این نرمافزارها یافت. با اینکه برخی تمایل دارند که از عبارت « اپلیکیشنهای نوین سرور ابری » که به تازگی رایج شدهاست استفاده کنند، اما به نظر نمیرسد که این عبارت نیز برتری چندانی نسبت به عنوان قبلی داشته باشد.
به عنوان یک استارتآپ امنیتی که رویکرد کاملاْ متفاوتی نسبت به حفاظت از این اپلیکیشنها دارد، اگر نتوانیم تغییرات ایجاد شده را به صورت مفهوم و قابل درک توضیح دهیم، چگونه میتوانیم نحوهٔ عملکرد خود را شرح دهیم؟
مفهوم اصلی «بومی سرور ابری»
پس بهتر است ابتدا به مفهوم واحد و مورد توافق برای عبارت « بومی سرور ابری » دست پیدا کنیم. تعاریف متعددی برای این عبارت وجود دارند و اغلب آنها بسیار جزءنگر و در عین حال نارسا و ناکارامد هستند. از نظر ما بهترین شیوهٔ شناخت بومی سرور ابری و سرور مجازی آن است که زمانی که از پلتفرم سرور ابری به عنوان سیستم عامل استفاده میکنیم، در حقیقت برنامه ها و ابزار ما بومی سرور ابری هستند.
از جنبهٔ تاریخی، ما از سرور ابری و سرور اختصاصی به عنوان راهی برای استفاده از سختافزارهای مجازی از جمله رایانش، ذخیرهسازی و ایجاد شبکه ، استفاده میکنیم. وقتی که از « بومی سرور ابری » صحبت میکنید، در حقیقت یک مرحله پیشرفت کردهاید و اقدام به طراحی، ساخت، نصب و اجرای نرمافزارهای متکی بر پلتفرم سرور ابری میکنید تا مجموعهای غنی از سرویسهای قابل انجام و مجموعهای خلاصه و کاربردی را برای استفادهٔ آسانتر از آن نرمافزارها را ارائه کنید .
انتظار بر این است که این پلتفرم مانند هر سیستم عامل دیگر، بتواند دغدغههای شما در مورد اموری همچون مدیریت منابع ذخیرهسازی، نیازهای مربوط به فرایند تطبیق با هستهٔ سختافزار و ادارهٔ وظایف پیچیدهای که به صورت عادی در برخی اپلیکیشنها وجود دارد ، را برطرف کند. درست مانند سایر سیستمهای عامل نیازی نیست که از جزئیات اتفاقاتی که رخ میدهد ، آگاه باشید.
اصول کلی ساخت نرمافزارهای «بومی سرور ابری»
حال با توجه به تعریف بالا از نرمافزار بومی سرور ابری به برخی از اصول اساسی در ساخت این نرمافزارها اشاره میکنیم:
حدالامکان از سرویسهای کنترلشده استفاده کنید. اگر AWS را معادل Windows بدانیم، پس میتوان Kinesis را معادل DirectX دانست. اگر قرار باشد که برای سیستم Windows یک بازی طراحی کنید، احتمالاْ نمیتوانید از موتور گرافیکی مندرآوردی خودتان استفاده کنید ، بلکه از آنچه که پلتفرم بومی در اختیار شما قرار میدهد، استفاده خواهید کرد. اگر بخواهید در لحظه اطلاعات در حال اجرا را جمعآوری و پردازش کنید، نباید به خطوط ارتباطی پیچیدهٔ ماشینهای EC2 اکتفا کنید، بلکه بهتر است از Kinesis استفاده کنید.
به عرضهکنندهٔ سرور ابری و سرور مجازی فرصت دهید که به سلامت نرمافزار و توسعهٔ آن رسیدگی کند
. از ساختارهایی که لازم است خودتان مسئولیت نظارت بر سلامت آنها ، بارگیری و انجام امور مربوط به توسعهٔ آنها را بر عهده داشته باشید، دوری کنید. اینگونه ساختارها مشکلات پیچیدهای هم از نظر عملکردی و هم از نظر صرف هزینه ایجاد میکنند و تا کنون سبب نابودی سازمانهای بسیاری شدهاند. پلتفرمهای جدید سرور ابری و سرور اختصاصی تا حد زیادی راه گریز از این مشکلات را برای شما فراهم میکنند. سرویسهایی همچون AWS Lambda و Google Cloud Run به شما امکان میدهند که بدون آنکه کاری به ادارهٔ سلامت و توسعهٔ سیستم داشته باشید، فرمانها و دستورات لازم را اجرا کنید. با وجود سرویسهای ذخیرهسازی نظیر Azure Blobs یا AWS دیگر لازم نیست به فکر میزان ظرفیت و خروجی سیستم باشید. این کار سبب میشود که اپلیکیشن شما انعطافپذیرتر باشد و انجام عملیات را نیز برای شما سادهتر میکند.
دستوراتی که مینویسید به خاطر اصول کسب و کار باشد.
بهتر است از نوشتن دستور به عنوان آخرین راهحل استفاده کنید و حدالامکان این راهحل را برای اجرای اصول و اهداف پر ارزش کسب و کار خود ذخیره کنید. تمام آنچه که غیر از این مورد به آن نیاز دارید ، آن است که یک API درخواست کنید. اگر کار اصلی شما در این مرحله ، ساخت API نیست ، حتما کس دیگری آن را ساخته است . از آن استفاده کنید. ممکن است این کار به نظر گرانتر بیاید، اما در نظر بگیرید که نه فقط برای نوشتن کدها ، بلکه برای ارزیابی، حفظ و اجرای این دستورات نیز باید هزینه کنید .
نگران وابستگی به یک عرضهکننده نباشید .
مهم است که وقتی نرمافزار را نوشتید ، دیگر نگران اتفاقاتی که ممکن است در صورت تغییر پلتفرم برای آن پیش بیاید، نباشید. اگر اپلیکیشن خود را به شکلی تغییر دهید تا از مشکلاتی که ممکن است در پلتفرمهای بعدی وجود نداشته باشد، بخشی از امکانات و تواناییهای خود را ازدست خواهید داد. این مسئله در استفاده از سرور ابری عمومی بیشتر به چشم میخورد . هرگز نباید به یک پلتفرم واحد متکی باشید. همیشه این امکان را دارید که تمام یا بخشی از اپلیکیشن خود را به یک سرور ابری یا سرور مجازی دیگر منتقل کنید. پس تمام توجه خود را صرف استفادهٔ بیشتر و بهتر از پلتفرمی که انتخاب کردهاید ، بکنید و نگران اتفاقاتی که ممکن است در صورت جابجایی اپلیکیشن پیش بیاید، نباشید.
آیا این اصول در مورد DevOps, CI/CD, Agile و Twelve-Factor نیز صدق میکنند؟
بسیاری از افراد این مسائل را به امور دیگر نیز تعمیم میدهند. آنها هر چیزی را که دوست دارند در کنار هم قرار میدهند. ترندهای جالب و ( گاه نه چندان جالب) در ساخت نرمافزار وجود دارند. اگر تا جایی که میتوانید کارهای خود ( از جمله امنیت) را به صورت خودکار به خطوط ارتباطی جدید CI/CD منتقل نکنید، در آینده با مشکل مواجه خواهید شد. عدم ارتباط مستقیم میان این اصول و این تکنولوژیها به معنای عدم رعایت آنها نیست. این امر بدین معنی است که حتی اگر نرمافزارهایی که بومی سرور ابری نیستند ، هم میسازید ، باید این اصول را رعایت کنید. خلاصه آنکه اگر قرار است نرمافزار بومی سرور ابری بسازید، بهتر است از پردازش بومی سرور ابری ، ساختارهای بومی سرور ابری استفاده کنید و امنیت بومی سرور ابری و هماهنگسازی بومی سرور ابری را نیز از خاطر نبرید.