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

میکروسرویس چیست؟

میکروسرویس‌ راهکاری برای تقسیم یک برنامه کاربردی به بخش‌ها یا سرویس‌های کوچک، سبک، مستقل از یک‌دیگر و قابل ‌مدیریت است. به بیان دقیق‌تر، میکروسرویس یک معماری توسعه‌ نرم‌افزار توزیع‌شده (Distributed) است. 

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

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

شکل 1

معماری سرویس‌گرا (Service Oriented Architecture) چیست؟

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

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

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

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

تفاوت‌های معماری میکروسرویس، سرویس‌گرا و مونولیتیک 

در معماری مونولیتیک یا یکپارچه، ماژول‌های مختلف یک برنامه کاربردی ارتباط نزدیکی با یک‌دیگر دارند. به این ارتباط متقابل و نزدیک Tightly Coupled گفته می‌شود. در معماری فوق، اگر در نظر داشته باشیم تغییری در یکی از بخش‌ها اعمال کنیم، با مشکل روبه‌رو می‌شویم. این مسئله باعث می‌شود تا «استقرار پیوسته» (Continuous Deployment) دچار مشکل شود. معماری سرویس‌گرا رویکرد منعطف‌تری نسبت به معماری مونولیتیک دارد، به طوری‌که می‌توانیم برنامه را به بخش‌های مجزا از یک‌دیگر تقسیم‌بندی کنیم، اما بازهم هر بخش زیر چتر پلتفرم اصلی قرار دارد. معماری میکروسرویس بر خلاف دو معماری دیگر است و هر ماژول مستقل از دیگری است. این مجزا بودن ماژول‌ها از یک‌دیگر Loosely Coupled نام دارد. 

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

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

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

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

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

شکل 2

نحوه عملکرد معماری میکروسرویس به چه صورتی است؟

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

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

مطلب پیشنهادی

میکروسرویس‌ها چشم‌انداز دنیای نرم‌افزار را محتول می‌کنند

مزایای معماری میکروسرویس‌

امروزه، ماژولار بودن یک مزیت رقابتی بزرگ در دنیای توسعه نرم‌افزار به‌شمار می‌رود. به‌طوری که تجهیزات گران‌قیمت دنیای فناوری اطلاعات مثل سرورها نیز به‌سمت ماژولار بودن متمایل شده‌اند. میکروسرویس‌ها با این هدف به دنیای نرم‌افزار وارد شدند تا به توسعه‌دهندگان اجازه دهند برنامه‌های کاربردی خود را بر مبنای مولفه‌ها یا سرویس‌هایی که مستقل از یک‌دیگر هستند و به‌سادگی قابل ‌تغییر، حذف و به‌روزرسانی هستند توسعه دهند؛ بدون این‌که ساختار کلی برنامه با مشکل روبه‌رو شود. طراحی‌ها و استقرار میکروسرویس‌ها به‌لطف ابر و کانتینری‌سازی رشد قابل توجهی کرده‌اند. در مجموع باید بگوییم، میکروسرویس‌ها مزایای قابل توجهی در اختیار توسعه‌دهندگان نرم‌افزار قرار داده‌اند که از آن جمله به موارد زیر باید اشاره کرد:

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

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

میکروسرویس‌ها توسعه‌پذیر هستند. ماهیت مستقل ماژول‌های مختلف یک میکروسرویس اجازه می‌دهد با استفاده از زبانی خاص، بانک اطلاعاتی خاص و سروری خاص به توسعه برنامه کاربردی بپردازیم و در صورت نیاز تنها منابع همان پلتفرم را ارتقاء دهیم.

چالش‌های معماری میکروسرویس‌ها

در شرایطی که میکروسرویس‌ها مزایای درخشانی در اختیار ما قرار می‌دهند، اما معایبی نیز دارند. از معایب این پارادایم به موارد زیر باید اشاره کرد: 

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

مطلب پیشنهادی

Aggregate چیست و چرا الگوی مفیدی است

چرا معماری میکروسرویس (MicroService) شما به تجمیع نیاز دارد؟

معماری و طراحی میکروسرویس‌‌ها چه ویژگی‌های شاخصی دارد؟

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

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

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

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

میکروسرویس‌ها و کانتینرها

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

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

امنیت میکروسرویس‌ها

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

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

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