خواندن ۱۸ دقیقه·۲ سال پیش

معرفی برخی از فناوری‌های تأثیر گذار بر دنیای معماری نرم‌افزار

طراحی مبتنی بر دامنه(Domain Driven Design)

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

نکات مثبت

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

از طرفی از آنجایی که دیدگاه این روش بر مبنای شئ‌گرایی توسعه داده شده است بنابراین با استفاده از مفاهیمی از آن جنس مانند پیمانه‌بندی و محصورسازی می‌توانیم انعطاف پذیری المان‌هایی که برای آن‌ها در حال برنامه ریزی هستیم را افزایش دهیم.

Hexagonal Architecture

این معماری در اصل با هدف ارائه یک رویکردی برای بیان نحوه برقراری ارتباط لایه‌ها در روش DDD ارائه شده است به صورتی که اگر فرض کنیم امکان دارد ارتباط میان لایه‌های چهارگانه(لایه دامنه، لایه رابط کاربری، لایه برنامه کاربردی، لایه زیرساخت) به درستی فهمیده نشود و محصورسازی آن‌ها تا حدودی نقض شود، حال برای اصلاح نگرشی که موجب این چنین اشتباهات می‌شود می‌توانیم از معماری شش‌ضلعی استفاده کنیم.

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

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

Command and Query Responsibility Segregation

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

حال برای پیاده‌سازی این روش نیاز به ایجاد انزوا در دو سطح یعنی نرم‌افزار و سطح فیزیکی پایگاه‌داده داریم:

سطح نرم‌افزار:

در این سطح به عنوان مثال این تغییرات نیاز است: دستورات از حالت داده محور به فرآیند محور تغییر کنند.

از طرفی سعی شود تا حد امکان دستورات به صورت همزمان اجرا شوند و درخواست‌هایی که به طرف پایگاه‌داده می‌روند صرفاً با یک شئ حاوی داده بازگردانده شوند(پایگاه‌داده تغییر نکند)

سطح فیزیکی:

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

الگوی MVVM

این الگو را از لحاظ ساختار و نحوه عملکرد می‌توانیم به عنوان یکی از زیرمجموعه‌های MVC در نظر بگیریم اما زمانی که بیشتر به روش کارکردی آن توجه می‌کنیم، می‌توانیم تفاوت‌های بزرگی را دریابیم. ساختار MVVM شامل سه بخش اصلی است: مدل، دید، ویومدل

نحوه جریان فرآیندها و داده در این الگو به صورت تعاملی بین این 3 بخش تقسیم شده است. در view که صرفاً وجه نمایشی نرم‌افزار است اطلاعاتی که به وسیله View Model از model ارائه می‌شود را به کاربران نشان می‌دهد. این جداسازی view از model باعث می‌شود تا گروه‌های توسعه نرم‌افزار بتوانند راحت‌تر به صورت همزمان در هر دو بخش بدون نیاز به ایجاد تغییر در بخش دیگر به توسعه نرم‌افزار بپردازند و از طرفی viewو view model می‌تواند نقش یک رابط کاربری و واصل را برای model ایفا کند تا تغییراتی که در سطح کسب و کار به وجود می‌آید تأثیر حداقلی را روی model بگذارد.

دو نوع ارتباط میان view و model برای انتقال داده برقرار است. که در یک نوع تغییرات model تنها به صورت یک طرفه در view نمایش داده می‌شود و در نوع دیگر این ارتباط به صورت دو طرفه و با اعمال تغییر متقابل اتفاق می‌افتد. حال نقش view model در این الگو در اصل بیشتر به صورت واسط میان دو بخش نمایش دهنده و حاوی داده‌ها است یعنی اگر حجم زیادی داده از model دریافت می‌کند، آن را طوری پردازش می‌کند تا قابل استفاده برای view هم باشد و عکس این فرآیند هم برقرار است. اما در بعضی نرم‌افزارها که سرعت پاسخگویی و راحتی کاربر در مشاهده تغییرات اهمیت دارد می‌توان این ارتباط را به صورت مستقیم بین view و model با استفاده از روش Data Binding برقرار کرد که البته در همه شرایطی توصیه نمی‌شود چون می‌تواند باعث استفاده بخش زیادی از منابع و اختلال در سرویس‌های بزرگ سازمان شود.

Event Sourcing

در حالت کلی می‌دانیم که نرم‌افزارها سعی در ذخیره حالت لحظه‌ای(جاری) برنامه‌ را دارند که با همان تکنولوژی همیشگی CRUD انجام می‌شود اما استفاده متداوم از این روش برای ذخیره همه حالت‌های المان‌های برنامه می‌تواند موجب بروز تعارض در دستورهایی که همزمان اعمال می‌شوند و رفته رفته کاهش سرعت عملکرد برنامه شود. حال با در نظر گرفتن مشکلات ذکر شده می‌توانیم با استفاده از Event Sourcing در ابتدا نه تنها با دانستن حالت کنونی عملیات بلکه با ذخیره ترتیبی حالات گذشته یک سری از رویدادهایی که برای شئ مورد نظر اتفاق افتاده را هم در نظر بگیریم و بتوانیم در مواقع بحران و یا خرابی از آن‌ها استفاده کنیم.

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

برخی از موارد کاربری روش به این صورت است:

· برای بروز نگه‌داشتن خواندن و نوشتن در CQRS

· زمانی که اعمالی مانند بروزرسانی و ثبت برخی ورودی‌ها را می‌توانیم از بقیه عملیات جدا کنیم تا به عنوان مثال عملکرد یک بخش بهتر شود.

· زمانی که باید ریسک بروز تعارض در به‌روز رسانی‌ها را به حداقل برسانیم.

Micro Frontends

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

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

برخی مزایا:

· قابلیت توسعه مستقل هر بخش

· آزادی در انتخاب تکنولوژی‌های مختلف برای توسعه

· تشکیل تیم‌های خود مختار

Low code platforms

عموماً نرم‌افزارها یا بسترهایی که برای استفاده از آن‌ها نیازی به زمینه فنی و مهندسی وجود نداشته باشد و کاربر سطح اول به صورت پیش‌فرض لازم نباشد که دانش بالایی از روش‌های ساخت نرم‌افزار و برنامه‌نویسی آن‌ها داشته باشد. در حالت کلی این گونه از محصولات باید دارای رابط کاربری گرافیکی و ساده برای عموم کاربران باشد تا هر فردی در سطوح و بخش‌های مختلف سازمان بتواند با کمترین دانشی در مورد آن تکنولوژی محصول خود را با استفاده از این بستر گسترش دهد و به هدف سازمانی خود برسد.

از مزایای این نوع نرم‌افزارها می‌توان به نکات زیر اشاره کرد:

· افزایش سرعت توسعه و انتشار نرم‌افزار

· راحت‌تر کردن فضای حل مسئله برای افرادی که آشنایی زیادی با محیط فناوری اطلاعات ندارند

· راحت کردن کار تیم‌های برنامه نویسی با ایجاد بستری برای رفع بعضی نیازها که موجب می‌شود تا برنامه‌نویسان برای موضوعات چالشی‌تر وقت صرف کنند.

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

Enterprise Service Bus

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

زمانی که از این فناوری استفاده می‌کنیم در اصل تغییرات در کامپوننت‌ها و یا افزودن آن‌ها را بسیار آسان کرده‌ایم و از طرفی به بخش امنیتی سیستم هم می‌توانیم کمک کنیم زیرا ESB فرآیند مانیتورینگ و گرفتن لاگ را آسان می‌کند. همچنین با استفاده از load balancing عملکرد نرم‌افزار را بهبود می‌بخشد.

برخی اصول ESB:

· تنظیم و هماهنگ کننده ارتباطی

· برقرار کننده این ارتباط برای هر بخش بااستفاده از تکنولوژی انتقال داده همان برنامه(Json,SOAP)

· همچنین استفاده از پروتکل‌های انتقال متفاوت برای بخش‌های مختلف

· ایجاد رابط‌های کاربری متفاوت برای استفاده در مواقع عقبگرد و یا مسیرهای جایگزین

در چند سال اخیر فضای کسب و کارهای مختلف به سمت ایجاد چابکی حداکثری رفته است در نتیجه برای لایه زیرساخت نیز این نیاز به شدت حس می‌شود که جهت کاهش هزینه و راحتی در تغییرات می‌توان از برخی فناوری‌ها مانند ESB بهره برد.

API Getaway

API Getaway در اصل نقش واسط میان API های مختلف یک سیستم و بخش مدیریت کننده درخواست‌ها را دارد به صورتی که اگر سرویسی در حال صدا زدن API خاصی باشد API Gataway درخواست یا درخواست‌های دریافت شده را میان سرویس‌های مرتبط پخش می‌کند تا تمامی بخش‌های متأثر در جریان این درخواست باشند و از طرفی در صورت نیاز بعضی سرویس‌های عملکردی در قسمت بک‌اند هم فراخوانی می‌کند. در واقع وظیفه اصلی در اینجا این است که با وجود تمامی پیچیدگی‌های نرم‌افزار و نحوه ارتباطی در میان سرویس‌های مختلف API Gataway سعی می‌کند تا با آسان‌ترین مسیر ممکن با مدیریت درخواست‌های روابط کاربری مختلف تمامی نیازمندی‌های کاربر را آماده کند.

حال می‌توانیم نتیجه بگیریم که سازمان‌ها از این فناوری استفاده می‌کنند چون:

· باید طی مکانیزمی جلوی استفاده بیش از حد از API ها را گرفت.

· بعضی کسب و کارها نیاز به تحلیل نحوه استفاده کاربران از API ها را دارند.

· اگر API های سازمان تجاری سازی شده باشند، برای مدیریت پرداخت‌ها به API Gataway نیاز داریم.

· در صورت استفاده از معماری میکروسرویس که یک درخواست ممکن نیازمند صدا زدن صدها برنامه دیگر شود.

· یک مدل یکپارچه از تمامی API ها ارائه شده در محصول شما و قابل مشاهده برای کاربران

در حالت کلی با افزایش استفاده از فناوری‌هایی مانندDevOps, Microservice و serverless Cloudموارد کاربری API Gataway نیز افزایش می‌یابد زیرا همه‌ی این فناوری‌ها از API ها برای انجام فرآیندهای خود استفاده می‌کنند در نتیجه بهره بردن از یک معماری که باعث یکپارچه‌سازی و مدیریت درخواست‌ها از رابط کاربری به سمت سرویس‌ها می‌شود می‌تواند موجب بدست آوردن ارزش‌های زیادی برای سازمان‌ها بشود.

نرم‌افزار مدیریت فرآیندهای کسب و کار

BPMSبه سازمان‌ها کمک می‌کند تا بتوانند بسیاری از عملیات و فعالیت‌ها را که عموماً وقتی انجام می‌شوند منجر به رسیدن سازمان به هدف تعیین شده خود می‌شود را دسته‌بندی کرده و به صورت خودکار پردازش کند. اکثر این فعالیت‌ها در مجموع ساختاری پیچیده دارند و بعضاً تکرار شونده و می‌توانند تابع الگو خاصی باشند که با بررسی و بهینه کردن مسیر انجام آن‌ها می‌توان از هدر رفت مقدار زیادی از منابع سازمانی جلوگیری کرد.

مراحلی که طی آن‌ها فرآیندهای سازمان بررسی و بهینه می‌شوند به این صورت است:

1. طراحی: فرآیند را بشکن و در هر قطعه مسیرهای جدیدی را طراحی کن(یا باز طراحی)

2. مدل: فرآیندها را به صورت بصری ارائه کن تا برخی جزئیات را بتوانیم مدیریت و تغییر بدهیم.

3. اجرا: فرآیند بدست آمده را آزمون کن.

4. بررسی لحظه‌ای: به صورت لحظه‌ای مسیر انجام کارها را زیر نظر بگیر تا از درستی انجام کار و اثر گذاری آن مطمعن شوی.

5. بهینه کردن: در مجموع در طول همه مراحل بالا اگر احساس کردی که تغییری نیاز است انجام شود تا سیستم بهتر عمل کند الان وقتش هست.

مزایا و معایب BPMS:

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

سیستم مدیریت قوانین کسب و کار

برای درک کارایی سیستم‌های مدیریت قوانین ابتدا باید بدانیم تعریف قوانین کسب و کارها چه چیزی را شامل می‌شود؟

در اصل بعد از تعیین مسیرها و روندهایی که طی آن‌ها فرآیندهای کسب و کار شکل می‌گیرند، قوانین کسب و کار مانند تابلوهای کنار جاده هستند که به این مسیرها شکل می‌دهند و مراقب هستند که کسی از مسیر اصلی خارج نشود(در واقع ضوابطی که طی آن کسب و کارها به هدف تعیین شده می‌رسند).

این قوانین دو قسمت دارند:

1. شرط‌ها: که با استفاده از آن‌ها موقعیتی را ایجاد می‌کنیم تا عملیات مورد نظر انجام شود.

2. اعمال: که ترسیم کننده فعالیت‌هایی است که باید در واکنش به شروط ارائه شده، انجام شوند.

حال با شناخت کلی که از قوانین داریم می‌توانیم این نوع سیستم‌ها را تعریف کنیم: برعکس BPMS که تعریف کننده فرآیندها، شرایط و قوانین حاکم بر آن‌ها بودند، در BRMS سازمان‌ها از دل این قوانین توانایی خلق فرآیندها را ارائه می‌کنند.

بنابراین یک BRMS تشکیل شده است از ۳ قسمت:

· یک محیط توسعه جهت گسترش و خلق قوانین جدی متشکل از یک فضای low-cod,No-code تا هر فرد غیر فنی هم بتواند در آن فعالیت کند.

· یک منبع کلی برای تمامی قوانین‌

· یک موتور پردازش قوانین کسب و کار که به درخواست‌های همه سرویس‌ها پاسخ می‌دهد.

مثال: یک شرکتی که سه نوع اشتراک برای کاربرانش ارائه می‌دهد را در نظر بگیرید: ابتدا قوانین دسته بندی هر کاربر بر اساس معیارها ثبت می‌شود. مثلاً: کاربران دارای سن بالای ۵۰ در گروه سوم قرار می‌گیرند.

پس از ثبت قوانین و قرار گرفتن آن‌ها در مخزن قانون‌ها حال تمامی قسمت‌های سازمان می‌توانند از آن استفاده کرده و برای دسته بندی داده‌های ورودی خود آن را به کار گیرند.

Message Queue

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

حال به طور کلی این معماری به سه قسمت تقسیم می‌شود:

１- نقطه به نقطه: به صورتی که برنامه ارسال کننده به صورت پیش فرض اطلاعاتی از مقصد دارد و پیام‌ها را به مقصد ارسال می‌کند.

２- Publish/subscribe: صادر کننده پیام به شکل کلی پیام‌ها را منتشر می‌کند و ممکن است یک یا چندین دریافت کننده در حال گوش دادن به پیام‌های ارسالی باشند و آن‌ها را دریافت کنند.

３- درخواست/پاسخ: فرستنده به درخواست گیرنده داده ارسال می‌کند.(می‌تواند چندین بار داده‌ها منتقل شود.)

Kafka یکی از ابزارهای مبتنی بر این معماری است که در دسته pub/sub قرار می‌گیرد. یکی از ویژگی‌های اصلی این ابزار استفاده از یک موتور تحلیلگر در میان ارسال پیام‌ها برای استفاده کننده است که در اصل موجب به وجود آمدن امکانات گسترده‌ای مانند: جداسازی و کاهش وابستگی میان بخش‌ها، ارائه موقعیت مکانی برخط(اجرای الگوریتم روی آن‌ها) و جمع آوری و دسته بندی داده‌های مرتبط می‌شود.

از مزایای بسیار زیاد این فناوری می‌توان به جداسازی کامپوننت‌ها، افزایش قابلیت تغییر پذیری و استفاده مجدد اشاره کرد.

Docker and Containerization

برای تعریف مفهوم کانتینر باید به کاربرد و تفاوت آن با ماشین‌های مجازی در فرآیند انتشار و توسعه نرم‌افزار پرداخت به صورتی که می‌دانیم هر دوی آن‌ها انتزاعی هستند که در لایه برنامه کاربردی با جدا سازی و ایزوله کردن پکیج‌های کد باعث راحت‌تر شدن فرآیند توسعه و انتشار مداوم نرم‌افزار، استفاده راحت‌تر از DevOpsو در نتیجه افزایش چابکی در نرم می‌شوند. حال چرا در سال‌های اخیر استفاده از این مفهموم و فناوری‌های مختلف آن افزایش یافته است؟

برخی مزایای کانتینرها نسبت به ماشین‌های مجازی به این صورت هستند:

１- استفاده بهینه‌تر از حجم استفاده نشده منابع زیرساخت و تقسیم آن میان بخش‌هایی که نیاز به کمک دارند.

２- حذف تکرارهایی که در ماشین‌های مجازی ایجاد می‌شود و همچنین باعث هدر رفت منابع می‌شود.

３- آسان‌تر کردن ایجاد تغییرات و افزودن بخش‌های جدید به برنامه

４- در اصل کانتینرها به مجازی سازی نرم‌افزارها می‌پردازند در صورتی که ماشین‌های مجازی همین کار را برای سخت‌افزار انجام می‌دهند.(سطح انتزاع بالاتر در کانتینرها)

５- کاهش زمان غیر فعال بودن سرویس‌ها(down time) و همچنین کاهش زمان setup time که هر دو به بالا بردن میزان availability برنامه کمک می‌کنند.

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

Container orchestration

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

از طرفی چون استقلال سرویس‌ها را افزایش می‌دهد بنابراین سازگاری بسیار بالایی با معماری میکروسرویس دارد زیرا به به هر سرویس شبکه، فضای ذخیره سازی و مدیریت مخصوص به خود آن سرویس را می‌دهد همچنین می‌توانیم با استفاده از آن کنترل بیشتری روی قسمت‌های مختلف برنامه در هر اجرا داشته باشیم و چرخه حیات هر کدام را زیر نظر بگیریم. در کل همه موارد بالا موجب می‌شود تا هماهنگی به وجود آمده کمک زیادی به اجرای فرآیند‌های DevOps، CI/CD و دستورات مدیریت API ها می‌کند.

برخی موارد کاربری Container orchestration:

１- پیکربندی و برنامه‌ریزی مناسب

２- تخصیص منابع بهینه

３- افزایش قابلیت فعال بودن کانتینر

４- Load balancing and traffic routing

５- بررسی لحظه‌ای سلامت کانتینرها

حال یکی از ابزارهای شناخته شده و open source که این فناوری را پیاده سازی می‌کند Kubernetes نام دارد که در واقع ویژگی اصلیش مدیریت و توسعه کانتینرهای برنامه‌هایی است که برای اجرا به چندین کنتینر همزمان نیاز دارند. در نتیجه Kubernetes بسیاری از فرآیندهای دستی را خودکار می‌کند و به دسته بندی کانتینرهایی که برای اجرا نیاز به یک مجموعه زیرساخت یکسان دارند کمک می‌کند.