معماری Serverless در مقابل کانتینر

مزایا و معایب هر معماری مبتنی بر serverless و کانتینری باید بر اساس نیازهای کسب و کار شما مورد توجه قرار گیرد.

 

 

تصمیم گیری بین تکنولوژی ها، چارچوب ها یا معماری ها بخش مهمی از زندگی معماران توسعه دهندگان و سازمانی است. با این حال، قوانین توسعه نرم افزار در حال تغییر هستند، و تیم باید همیشه قبل از برنامه نویسی ویژگی های کسب و کار خود را در مورد معماری خود و یا محیط محاسبات فکر می کنم.

 

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

 

آمازون لامبدا را در سال ۲۰۱۵ معرفی کرد، همان سال که Kubernetes آزاد شد. هر دو تکنولوژی جاذبه زیادی به دست آوردند. پس از چند سال تثبیت، توسط بسیاری از سازمان های مختلف و شرکت هایی که می خواهند حجم کاری خود را به ابر انتقال دهند، استفاده می شوند.

 

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

 

مدل محاسباتی serverless

یک مدل محاسباتی serverless به تیم کمک می کند که زیرساخت ها یا هزینه های مدیریت پلت فرم را تقریبا به صفر برساند. در اصل، شما کد تابع خود را به یک ارائه دهنده محاسبات سرور ابری و سرور مجازی (AWS، Google Cloud، Microsoft Azure) می دهید و می گوید: “لطفا این تابع را برای من اجرا کنید هر زمان که وجود داشته باشد یک درخواست من قبول می کنم راه را اجرا می کنم و من نگران نگهداری زیرساخت ها، سیستم عامل یا مقیاس پذیر بودن یا دسترسی برنامه نیستم”.

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

 

علاوه بر این، حجم کار سرور ابری و سرور اختصاصی بدون محدودیت به اجرای تابع محدود می شود، اما امکان ذخیره سازی داده ها serverless و هاست ، بدون نیاز مکانیزم احراز هویت و بسیاری موارد دیگر امکان پذیر است. بنابراین اگر اعتقاد داشته باشید که نیازهای کامپیوتری شما می تواند در محدودیت های سرویس های serverless با توجه به سرعت اجرای، امنیت و منابع برای عملیات و هزینه های فردی متناسب باشد، احتمال زیادی وجود دارد که می تواند توسعه و چابکی کسب و کار شما را سریع تر کند.

معماری Serverless در مقابل کانتینر

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

 

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

 

لینک کوتاه : http://yon.ir/b0PPq