حرکت به سوی دنیای Docker می بایست از جایی شروع شود ، همیشه از مدیران سیستم انتظار می رود تا برنامه های قدیمی موجود را حفظ کرده و در عین حال برنامه های جدیدی پیاده سازی و اجرا کنند .
آن ها مدام به ابزار های خود نگاه کرده و از خود می پرسند که این برنامه ها در کجا می بایست اجرا شوند؟؟ در VM یا در Container!!

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

سناریو اول : "می خواهید برنامه کاربردی جدید یا برنامه های کاربردی نوشته شده قبلی خود را از صفر تا صد با استفاده از معماری Micro-service مبتنی بر Container بنویسید."

در بسیاری از موارد شرکت ها مدل یکپارچه برنامه خود را رها کرده و نسخه جدید آن را بر پایه مدل Micro-service مبتنی بر Container می نویسند. با استفاده از Docker، شرکت ها نیز می توانند
توسعه و تحویل برنامه ها را سرعت بخشیده و همان کد را بدون هیچ تغییری روی هر زیرساختی اجرا کنند.

سناریو دوم : "می خواهید نرم افزار موجود خود را طبق معماری Micro-service توسعه داده و قبل از اتمام کدنویسی از مزایای داکر بهره مند شوید."

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

سناریو سوم : "می خواهید بدون نوشتن کد جدید برنامه خود را از مدل مبتنی بر ماشین مجازی یکپارچه (Monolithic VM) به مدل مبتنی بر Container بدون هیچ دردسری منتقل کنید."

معمولا این دسته از مشتریان به مزیت قابلیت حمل برنامه کاربردی ارائه شده توسط داکر علاقه دارند. تصور کنید اگر CIO شرکت به شما بگوید: "میخوام هزار ماشین مجازی ای که در مرکز داده
داریم تا آخر هفته در Cloud به کار خودشون ادامه بدهند" انجام این کار حتی برای دزد ماشین های مجازی بسیار سخت است! درسته که قابلیت حمل برای ماشین مجازی وجود دارد اما عالی
و بدون نقص نیست زیرا تغییر Vendor وجود دارد. به عنوان مثال تصور کنید که مجازی سازی vSphere در مرکز داده دارید و اجاره دهنده زیرساخت ابری Azure است - بنابراین از چه مبدلی برای
انتقال در زمان خواسته شده استفاده خواهید کرد! انجام این کار از طریق کانتینر به تلاش بسیار کمی نیاز دارد زیرا کانتینر ها به شکل ذاتی ویژگی قابلیت حمل دارند و می توانند در یک ماشین مجازی
یا حتی Cloud بدون هیچ تغییری اجرا شوند. با استفاده از قابلیت حمل ذاتی ، کانتینر ها به راحتی می توانند از ماشین مجازی به هر مقصدی مثل ماشین مجازی، سرور فیزیکی یا Cloud انتقال یابند.

اگر هر کدام از این سناریوها با کسب و کار شما مطابقت داشت، احتمالا موردی مناسب برای شروع کار با Docker خواهد بود.
کاربر:از سرور فیزیکی برای پیاده سازی Docker استفاده کنم یا سرور مجازی؟
متخصص داکر:جذابیت استفاده از Docker رو میشه این مورد دونست: "تصمیم برای استفاده داکر در هر زیرساختی مثل نصب شبکه سرور فیزیکی، مجازی ،ابری یا حتی ترکیبی از همه موارد تنها به هدف و نیاز کسب و کار شما بستگی داره(البته مرتب هم میتونه تغییر کنه)
کاربر: اما مطمئنا شما توصیه ای دارید!!!
متخصص داکر: من به شما پاسخ دو کلمه ای میدم که کسی این پاسخو دوست نداره : "بستگی داره"
کاربر: شما درست می فرمایید بله اصلا پاسخ جالبی نیست.
متخصص داکر:بله متوجه شدم که این پاسخ جالبی نبود اما برای Docker واقعا پاسخی دقیق و درست بود.

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

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

Latency(تاخیر): برنامه هایی که به تاخیر حساس هستند بهتر روی سرور فیزیکی ایفای نقش می کنند. حساس بودن نصب شبکه به تاخیر در سرویس های مالی بسیار مشاهده می شود( مثل برنامه هایی مربوط به معاملات تجاری و ...).

Capacity(ظرفیت):ماشین های مجازی جهت استفاده مناسب از ظرفیت بهینه شده اند.اگر برنامه مبتنی بر کانتینر شما ، تمام ظرفیت زیرساخت فیزیکی رو اشغال نکنه ، مجازی سازی هنوز میتونه مفید باشه.

Mixed Workloads: روی سرور فیزیکی تنها می توانید یک سیستم عامل اجرا کنید، بنابراین، اگر بخواهید از ترکیب کانتینر های ویندوزی و لینوکسی استفاده کنید، می بایست از مجازی سازی استفاده کنید.

Disaster Recovery (بازیابی فاجعه): همانند بهینه سازی ظرفیت، یکی از مزایای عالی VM ها قابلیت های پیشرفته در حوزه بازیابی اطلاعات(site recovery) و در دسترس بودن بالای سیستم ها(High Availablity)است.
در حالی که این قابلیت ها ممکن است در میزبان های فیزیکی وجود داشته باشند اما انتخاب های بیشتری از طریق مجازی سازی خواهید داشت.

Existing Investments and Automation Frameworks (سرمایه گذاری های موجود و چارچوب اتوماسیون): بسیاری از سازمان های خدمات شبکه در حال حاضر مجموعه وسیعی از ابزارها را در زمینه هایی مانند پیاده سازی زیرساخت
ایجاد کرده اند بنابریان باید بتوان از زیرساخت و سرمایه گذاری موجود در حوزه های جدید استفاده نمود.

Multitenancy:برخی از مشتریان دارای حجم کاری خاصی هستند و نمی توانند هسته های لینوکسی و ویندوزی(Kernels) را به اشتراک بگذارند. در این مورد VM ها لایه ای اضافی برای ایزوله سازی علاوه بر Container ها ایجاد می کنند.

Resource Pools / Quotas: بسیاری از راه حل های مجازی سازی مجموعه ای از ویژگی های گسترده ای برای کنترل اینکه چگونه ماشین های مجازی از منابع استفاده کنند را ارائه می دهند.Docker
نیز مفهوم محدودیت منابع را فراهم می کند، اما برای سرور فیزیکی مدیریت منابع به شما بستگی دارد.

Automation / API (اتوماسیون و واسط های برنامه نویسی): تعداد بسیار کمی از افراد در یک سازمان به طور معمول توانایی پیاده سازی با API روی سرور فیزیکی را دارند. اگر هدف اتوماسیون است،
شما به API نیاز خواهید داشت، که این معیار را سرور های فیزیکی ندارند.

Licensing Costs (هزینه های صدور مجوز): اجرا بدون واسط روی سرور فیزیکی به خودی خود هزینه ها را کاهش می دهد، زیرا مجبور نیستید License های Hypervisor را خریداری کنید و حتی نیازی به
پرداخت هزینه برای سیستم عامل های مختلف جهت میزبانی داکر نخواهید داشت و تنها از یک سیستم عامل استفاده خواهید کرد(آن هم می تواند متن باز باشد)

نکته آخر ، سهولت در تصمیم گیری درباره ی مکان اجرای برنامه مبتنی بر کانتینر ، کاملا وابسته به مزایاییست که نصب شبکه آن زیرساخت برای کسب و کارتان در زمان حال و آینده خواهد داشت پس نمی بایست این سوال
«سرور فیزیکی یا مجازی؟» مد نظر باشد - سوال مناسب این است که کدام زیرساخت بیشترین مزایا را برای برنامه و اهداف و نیاز های کسب و کار من خواهد داشت. بنابراین شما می توانید تمامی راه حل های
مبتنی بر داکر را با هم ترکیب نموده تا به آسانی و با سرعت بالا تغییرات احتمالی حال و آینده را مدیریت کنید.