در گذشته دولوپرها به منظور پیاده‌سازی و اجرای اپلیکیشن‌های خود تنها به یک سرور فیزیکی اِتکا می‌کردند و همچنین کانفیگ و مدیریت این‌گونه سرورها به صورت دستی انجام می‌شد اما اساساً کانفیگ چنین سروری بسیار زمان‌بر بود و نیازمند تنظیم جزئیات زیاد بود و وقتی که دولوپرها برای اجرای اپلیکیشن‌های خود از چندین سرور فیزیکی مختلف استفاده می‌کنند، پیچیدگی شرایط دوچندان می‌شد. سپس ماشین‌های مجازی ورود پیدا کردند که در این روش نیز با وجود تسریع روند انجام کارها، هنوز هم بایستی تمام کارها توسط خود دولوپر و به صورت دستی انجام می‌شد و از همین روی دولوپرها به تکنولوژی Infrastructure as a Service یا به تعبیر دیگر IaaS روی آوردند که امروزه آن را تحت عنوان Cloud می‌شناسیم (برای آشنایی بیشتر با کلود، به مقالهٔ کلود چیست؟ مراجعه نمایید.)
از جمله ویژگی‌های تکنولوژی #کلود می‌توان به قابلیت ارائۀ سرور به مشتریان در بازه‌های زمانی کوتاه‌مدت (مثلاً یک ماهه) اشاره کرد. به عبارت دیگر، دولوپرها می‌توانند این سرورها را با پرداخت یک هزینۀ ماهیانه اجاره کرده و همچنین افزایش یا کاهش مقیاس آن‌ها متناسب با نیاز اپلیکیشن به ریسورس‌های مختلف همچون رَم، سی‌پی‌یو، فضای ذخیره‌سازی و غیره ساده‌تر و کار با آن بسیار سریع‌تر شده است.
تکنولوژی Platform as a Service یا به اختصار PaaS پیش از این نیز تحت تکنولوژی کلود و به عنوان یک متد دیپلوی اپلیکیشن وجود داشت و اکنون نیز قابلیت‌هایی همچون امنیت و مقیاس‌پذیری پیشرفته‌تری به آن افزوده شده است که یک از نمودهای عینی آن، فناوری کانتینر است.
در واقع، با ظهور تکنولوژی Container علاوه بر اینکه تکنولوژی PaaS به نوع دیگری پیاده‌سازی گردید و کار با آن ساده‌تر شد، مزیت‌های بیشتری نیز برای این تکنولوژی فراهم آورده شد که در نهایت Function as a Service یا به اختصار FaaS نام‌گذاری شد که نام تجاری‌تر آن Serverless است که برای کسب اطلاعات بیشتر در مورد کانتینر و سرورلِس، می‌توانید به ترتیب به مقالات زیر مراجعه نمایید:
- Container چیست و چه تفاوت‌هایی با Virtual Machine دارد؟
- آشنایی با معماری Serverless
برخی دولوپرها معتقدند که تکنولوژی کانتینر قدیمی شده و برای ساخت اپلیکیشن‌های مدرنِ امروزی بایستی معماری سرورلِس را جایگزین کرد؛ اما حقیقت امر آن است که معماری هر دو سرویس متناسب با تغییرات آیندۀ تکنولوژی و به منظور به‌کارگیری حداکثری از آخرین تکنولوژی‌ها طراحی شده‌اند که بسته به موقعیت، هر کدام از آن‌ها مزیت‌هایی نسبت به دیگری دارا است.
آشنایی با معماری Container
کانتینرها در واقع پکیج‌های سبک و جامعی هستند که شامل یکسری دیپندسی از پیش نصب‌شده و همچنین سورس‌کدهای اپلیکیشن مد نظر بوده و قابلیت اجرای سریع، مداوم و به صورت قابل‌اعتماد را روی سرورهای مختلف، صرف‌نظر از پلتفرمی که اپلیکیشن مد نظر روی آن دیپلوی می‌شود، دارا هستند. در ابتدا، این تکنولوژی بسیار نوآورانه به نظر می‌رسید اما واقعیت امر آن است که برای پیاده‌سازی معماری کانتینر، دولوپرها بایستی با سیستم‌عامل #لینوکس آشنا بوده و با نحوۀ اسکریپت‌نویسی به منظور قرارگیری اپلیکیشن در یک کانتینر آشنایی داشته باشند.
در همین راستا، کمپانی Dotcloud که ارائه‌دهندۀ تکنولوژی PaaS بود، یک ابزار CLI تحت عنوان Docker را ارائه کرد که مدیریت کانتینرها را آسان‌تر می‌کند و پس از آن نیز گوگل به منظور مدیریت کانتینرها، پلتفرمی #اپن‌سورس تحت عنوان Kubernetes را طراحی کرد (برای کسب اطلاعات بیشتر در مورد این فناوری، می‌توانید به مقالهٔ Kubernetes (کوبرنتیس) چیست؟ مراجعه نمایید.)
آشنایی با معماری Serverless
دلیل نام‌گذاری این معماری با نام Serverless، این است که دولوپرها برای اجرای کدهای بک‌اند اپلیکیشن خود نیاز به خریداری یا اجارۀ سرور ندارند و کدهای اپلیکیشن می‌توانند بدون هرگونه کانتینری نیز اجرا شود. به عبارت دیگر، همانند سایر سرویس‌های مبتنی بر کلود، هنوز هم سرورهای فیزیکی برای اجرای اپلیکیشن نیاز است با این تفاوت که لازم نیست تا دولوپرها دغدغه‌ای در مورد مسائل مربوط به سرور داشته باشند و مسئولیت این امر بر عهدۀ ارائه‌دهندۀ سرویس است (سرویسی در سال 2014 توسط کمپانی آمازون تحت عنوان AWS Lambda راه‌اندازی شد که فناوری سرورلِس را به یک ترِند در میان دولوپرها تبدیل کرد و زمانی که این کمپانی سرویس API Gateway خود را معرفی کرد، کارایی آن بهتر و گسترده‌تر هم شد.)
درآمدی بر تفاوت‌های مابین Container و Serverless
در حقیقت با اینکه سرورلِس تکنولوژی جدیدتری نسبت به کانتینر است، اما هر دوی آن‌ها مزایا و معایب خاص خود را دارا هستند و این امر موجب می‌شود تا هر دو تکنولوژی برای برخی موقعیت‌های خاص مفید و مناسب باشند به طوری که نمی‌توان به طور قطع در مورد برتری یکی از آن‌ها اظهار نظر کرد، بلکه نیازمندی‌های خود دولوپر تعیین‌کنندۀ سولوشن مناسب برای پیاده‌سازی و دیپلویمنت بهتر اپلیکیشن خواهند بود.
مزایا و معایب Container
تکنولوژی کانتینر این امکان را برای دولوپرها فراهم می‌کند تا بدون هیچ محدودیتی در رابطه با اندازۀ اپلیکیشن خود، آن را توسعه دهند اما در تکنولوژی سرورلِس، در برخی مواقع، محدودیت‌هایی همچون ابعاد پروژه و یا کمبود حافظه برای دیپلوی وجود خواهد داشت و این در حالی است که به طور کلی انتقال بین اپلیکیشن‌های موجود در کانتینرها ساده‌تر از معماری سرورلِس است.
در کانتینر مسائلی همچون مدیریت منابع، تعریف قوانین و کنترل امنیت در آن‌ها بسیار انعطاف‌پذیر بوده و دولوپر کنترل کاملی بر این امر خواهد داشت به طوری که اپلیکیشن‌ها می‌توانند با اِستک‌های نرم‌افزاری مختلفی در داخل کانتینرها نیز اجرا شوند و این در حالی است که تست، دیباگ و مانیتورینگ نرم‌افزار در معماری سرورلِس به این اندازه آسان نیست.
به طور کلی، یک کانتینر به دلیل ماهیتی که دارد، پرتابل بوده و این امکان را برای دولوپرها فراهم می‌کند تا بتوانند آن‌ها را روی هر پلتفرمی، از جمله سرورهای کلود و یا حتی یک سرور ساده، اجرا کنند چرا که کانتینرها به محصولات یک ارائه‌دهندۀ سرویس خاص وابسته نیستند و این در حالی است که سرورلِس به دلیل نوع ماهیتش، به یک ارائه‌دهندۀ سرویس به اصطلاح Third Party وابسته است. همچنن نیاز به توضیح نیست که پیاده‌سازی یک اپلیکیشن بزرگ و پیچیده با کانتینرها نتیجهٔ بهتری در بر خواهد داشت و همچنین انتقال چنین اپلیکیشنی به یک سرور کلود نیز کار آسان‌تری است.
یکی از بزرگ‌ترین معایب کانتینر، سَربار است به طوری که خود دولوپر بایستی کانتینر را مدیریت کند، از رفع اشکالات امنیتی آن اطمینان حاصل کند و در صورت نیاز، بر تمامی مسائلی از این دست نظارت داشته باشد. همچنین یادآوری این نکته خالی از لطف نیست که یادگیری کار با کانتینرها، راه‌اندازی و نگاه‌داری نیاز به تجربهٔ خوبی دارد.
مزایا و معایب Serverless
یکی از مهم‌ترین مزایای معماری سرورلِس، عدم نیاز به مدیریت زیرساخت‌ها توسط دولوپر است؛ بنابراین تنها کاری که یک دولوپر بایستی انجام دهد این است که فانکشن‌های خود را در سرور آپلود کند و سایر مسئولیت‌ها برعهدۀ ارائه‌دهندۀ سرویس (مثلاً کمپانی آمازون) خواهد بود. همچنین دولوپرها هیچ‌گونه نگرانی در مورد سخت‌افزار مورد نیاز برای پیاده‌سازی اپلیکیشن نخواهند داشت و تیم‌های توسعۀ نرم‌افزار نیز می‌توانند به جای نگرانی دربارۀ مسائل مربوط به نگاه‌داری یک اپلیکیشن، بر روی توسعۀ آن تمرکز کنند.
در حین استفاده از معماری سرورلِس، دولوپرها در مورد مقیاس‌پذیری سرور نگرانی نخواهند داشت چرا که خود ارائه‌دهندۀ سرویس کلود این کار را با ابزارهایی که در دست دارد، به صورت خودکار انجام می‌دهد. همچنین نیاز به توضیح نیست که استفاده از معماری سرورلِس برای پیاده‌سازی یک اپلیکیشن در مقایسه با کانتینرها هزینۀ کمتری را برای دولوپرها خواهد داشت چرا که هزینۀ آن به ازای اجرای هر فانکشن محاسبه شده و برای زمان‌هایی که فانکشنی در حال اجرا نیست، پولی پرداخت نمی‌شود (در واقع، زمانی که اپلیکیشن استفاده نمی‌شود، سرور خاموش بوده و هزینه‌ای را برای دولوپر در بر نخواهد داشت و از همین روی استفاده از این تکنولوژی برای استارتاپ‌هایی که بودجهٔ زیادی ندارند، بسیار عالی بوده و موجب صرفه‌جویی در هزینه‌هایشان خواهد شد.)
به‌روزرسانی یا تغییر یک فانکشن در تکنولوژی سرورلِس معمولاً آسان‌تر است چرا که مدل معماری‌اش موجب کاهش هرگونه وابستگی مابین فانکشن‌های یک اپلیکیشن می‌شود؛ به علاوه اینکه تقریباً می‌توان گفت که تمامی سولوشن‌های معماری سرورلِس از چیزی تحت عنوان Event Trigger پشتیبانی می‌کنند (Event Trigger اصطلاحی در کدنویسی است که مشخص می‌سازد چه فانکشن‌هایی پس از فعال شدن یک ایونت یا رویداد فراخوانی شوند.)
از جمله نقاط ضعف این معماری می‌توان به این نکته اشاره کرد که سرورلِس برای اپلیکیشن‌هایی که نیاز به زمان اجرای طولانی دارند، مناسب نیست و این در حالی است که کانتینرها برای چنین اپلیکیشن‌هایی مناسب‌ترند. همچنین باید گفت که سرورلِس به تکنولوژی جعبۀ سیاه نیز معروف است بدین معنا که کاربران آن دقیقاً نمی‌دانند که پشت‌پرده چه می‌گذرد!
سرورلِس عموماً به یک ارائۀ دهندۀ Third Party وابسته است و تغییر ارائه‌دهندۀ سرویس دردسر بزرگی را برای دولوپرها به همراه خواهد داشت (مثلاً فرض کنید که از سرویس‌های آمازون بخواهید به سرویس‌های مایکروسافت مهاجرت کنید.) همچنین راه‌اندازی این معماری مستلزم دقت بسیار زیاد است و عموماً نیازمند هزینه‌های قابل‌توجهی در ارتباط به استخدام درآوردن نیروی متخصص برای پیاده‌سازی معماری سرورلِس است.
نتیجه‌گیری
در یک کلام می‌توان گفت که اگر دولوپری با درآمد کافی، انعطاف‌پذیری و دانش لازم برای نصب و نگاه‌داری کانتینرها هستید و قصد دارید تا خودتان کنترل همه‌چیز را عهده‌دار باشید و همچنین نیازمندی‌های پیاده‌سازی و دیپلویمنت اپلیکیشن‌تان بسیار زیاد است، کانتینرها انتخاب خوبی برای شما هستند. به علاوه اینکه دولوپرها می‌توانند از سرویسی تحت عنوان Docker نیز استفاده کنند که هم قابلیت اجرا روی سیستم‌عامل ویندوز و هم روی لینوکس را دارا است (البته همان‌طور که پیش‌تر بیان کردیم، پلتفرم اپن‌سورس گوگل تحت عنوان Kubernetes نیز امکان مدیریت تنظیمات کانتینرها در مقیاس‌های بزرگ را برای دولوپرها فراهم می‌آورد به طوری که این پلتفرم طیف گسترده‌ای از ابزارها را ارائه می‌دهد که از آن جمله می‌توان Kubectl را نام برد که برای دیپلویمنت و دیباگ یک کانتینر به کار گرفته می‌شود.)
معماری سرورلِس معمولاً به طور کامل و از سمت ارائه‌دهندۀ سرویس مدیریت می‌شود و تنها کاری که بایستی دولوپرها انجام دهند، آپلود کردن کدها در سرور است که این امر باعث صرفه‌جویی در زمان ایشان می‌شود. همچنین این تکنولوژی نیازمند کنترل مستقیم نبوده و لازم نیست تا دولوپرها خود را درگیر زیرساخت‌های پایه‌ای آن کنند و برای استارتاپ‌هایی مناسب است که به دنبال صرفه‌جویی در هزینه‌های خود هستند یا استارتاپ‌هایی که درآمد اندکی دارند زیرا زمانی که باری روی سرور نباشد، هیچ هزینه‌ای در بر نخواهد داشت و از همین روی اگر مشکلی با محدودیت‌های پشتیبانی ارائه‌دهندۀ یک کمپانی خاص یا محصول خاص ندارید، تکنولوژی سرورلِس می‌تواند انتخاب خوبی برای شما و نیازهای‌تان باشد.
اگرچه سرورلِس در مقایسه با کانتینرها تکنولوژی جدیدتری است، اما کانتینرها همچنان در پیاده‌سازی و دیپلویمنت اپلیکیشن‌ها نقش پررنگی را ایفا می‌کنند. در حقیقت، هنوز هم دولوپرهایی هستند که احساس می‌کنند تکنولوژی سرورلِس توانایی رفع نیازمندی‌های اپلیکیشن ایشان را نداشته و از کانتینرها برای این امر استفاده می‌کنند؛ به علاوه اینکه کمتر دولوپری باتجربه‌ای را می‌توان یافت که تکنولوژی سرورلِس را تهدیدی برای کانتینرها به شمار آورد (اما استدلال کسانی که در زمینهٔ کلود صاحب‌نظر بوده و مخالف چنین موضوعی می‌باشند این است که همه چیز با سرعت در حال تغییر می‌باشد و چیزی که زمانی فوق‌العاده بوده، منسوخ خواهد شد و فناوری دیگر جایگزین آن می‌گردد که بسیار کارآمدتر و احتمالاً ارزان‌تر باشد. بنابراین، همچنان که معماری سرورلِس در حال پیشرفت است، ممکن است زمانی برسد که کانتینرها به تاریخ بپیوندند!)
روی هم رفته، کارکرد این دو تکنولوژی در برخی موارد با یکدیگر اصطلاحاً Overlapping داشته و ممکن است که دولوپری به منظور رفع حداکثر نیازمندی‌های اپلیکیشن خود، دست به استفاده از هردوی این تکنولوژی‌ها بزند!