ابر بومی چیست و چگونه دنیای توسعه نرم‌افزار را متحول خواهد کرد؟

ابر بومی (Native Cloud) چیست؟

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

شرکت نرم‌افزاری Pivotal که چارچوب Spring را توسعه داده و خدمات ابری ارائه می‌کند در این ارتباط می‌گوید: «ابر بومی رویکردی برای ساخت و اجرای برنامه‌هایی است که به‌طور کامل از مزایای رایانش ابری استفاده می‌کنند».

بنیاد محاسبات ابر بومی (Cloud Native Computing Foundation)، سازمانی که سعی دارد الگوی برنامه‌نویسی ابر بومی را به‌عنوان یک پارادایم استاندارد به دنیای نرم‌افزار معرفی کند، ابر بومی را یک پشته نرم‌افزاری منبع‌باز توصیف می‌کند که سه ویژگی زیر را دارد: 

• Containerized: هر بخش که شامل برنامه‌ها، فرآیندها و غیره می‌شود در کانتینرهای مخصوص خود بسته‌بندی می‌شود. این موضوع تکرارپذیری، شفافیت و جداسازی منابع را تسهیل می‌کند.
• Dynamically Orchestrated: پیکربندی‌ها به‌شکل پویا تنظیم می‌شوند تا کانتینرها به‌گونه‌ای برنامه‌ریزی و مدیریت شوند که از منابع به بهترین شکل استفاده کنند. 
• Microservices-oriented: برنامه‌ها به ریزسرویس‌هایی تقسیم می‌شوند تا چابکی بیشتری پیدا کنند و قابلیت نگه‌داری از برنامه‌ها بیشتر شود. 

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

کانتینرها (Containers)

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

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

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

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

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

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

تنظیم و هماهنگی (Orchestration)

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

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

انجام همه این کارها به‌صورت دستی به تلاش زیادی نیاز دارد. علاوه بر این، واکنش سریع به تغییرات غیرمنتظره در میزان مصرف منابع سرور امکان‌پذیر نیست، از این‌رو باید ابزارهای مناسبی در اختیار داشته باشید که به‌طور خودکار همه این کارها را انجام دهند. برای حل این مشکل راه‌حل‌های مبتنی بر هماهنگی (Orchestration) پدید آمدند. راه‌حل‌هایی که برای خودکارسازی واکنش‌ها به تغییرات غیرمنتظره مورد استفاده قرار می‌گیرند. از گزینه‌های محبوب در این زمینه باید به Docker Swarm، Kubernetes، Apache Mesos و ECS آمازون اشاره کرد. 

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

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

ریزسرویس‌ها (Microservices)

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

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

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

مقیاس‌بندی (Scaling)

ریزسرویس‌ها دستیابی به اصل مقیاس‌بندی را تسهیل می‌کنند، به‌طوری که هر زمان با افزایش درخواست‌های کاربران روبه‌رو شدید به‌سادگی قادر به راه‌اندازی یک کانتینر دیگر هستید. به این تکنیک مقیاس افقی (Horizontal Scaling) گفته می‌شود. شما می‌توانید از این تکنیک در ارتباط با برنامه‌های کاربردی بدون حالت (Stateless) استفاده کنید و درخواست‌های کاربر را برای نمونه‌ای از یک برنامه کاربردی موجود ارسال کنید. در معماری ریزسرویس تمامی سرویس‌هایی که روی ماشین‌های مختلف قرار دارند قادر به برقراری ارتباط با یک‌دیگر هستند. مکانیزم فوق اجازه می‌دهد عملکردهای جدیدی به سرویس‌ها اضافه کنیم و از فرایند توزیع و تحویل پیوسته خودکار استفاده کنیم. در این حالت، برنامه‌های کاربردی پایدارتر می‌شوند، زیرا هر ویژگی می‌تواند به‌شکل مستقل آزمایش و توزیع شود. با توجه به این‌که هر سرویس روی پردازه ایزوله‌شده‌ای میزبانی می‌شود، اگر سرویسی با مشکل گلوگاه روبه‌رو شود و به منابع زیادی احتیاج داشته باشد امکان انتقال به ماشین‌ها و سرورهای دیگر بدون هیچ‌گونه تاثیری روی عملکرد سرویس یا سرویس‌های دیگر وجود دارد. هنگامی که کاربران بیشتری از یک ویژگی برنامه کاربردی استفاده کنند، آن سرویس می‌تواند با توزیع روی سرورهایی که توان پردازشی بیشتری دارند یا با استفاده از کش بدون این‌که روی سرویس‌های دیگر تأثیری بگذارد، مقیاس‌بندی شود. مزیت دیگری که مقیاس‌بندی در سطح ابر بومی و کانتینرها ارائه می‌کند، سهولت نگه‌داری از کدهای برنامه کاربردی است. در نتیجه زمان مورد نیاز برای تحویل نسخه‌های جدید کمتر می‌شود و هزینه‌ها کاهش پیدا می‌کند. علاوه بر این، قابلیت استفاده مجدد از کدها افزایش می‌یابد، زیرا یک ویژگی به‌صورت سرویس میزبانی شده و امکان استفاده چند سرویس از یک ویژگی به‌جای پیاده‌سازی مجدد کد در هر مورد وجود دارد. معماری مبتنی بر سرویس امکان استفاده از مجموعه گسترده‌ای از فناوری‌ها برای رفع نیازها را ارائه می‌کند. به‌عنوان نمونه بسته‌های تحلیل داده زبان برنامه‌نویسی آر یا پایتون می‌توانند به‌صورت مجزا توزیع و میزبانی شوند و همزمان می‌توان از سی‌شارپ برای پیاده‌سازی سرویس‌ها استفاده کرد، در حالی‌که می‌توان از NodeJS در سمت سرور استفاده کرد و AngularJs و ReactJs را برای پیاده‌سازی رابط کاربری استفاده کرد. 

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

چالش‌های مرتبط با ریزسرویس‌ها 

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

چگونه مشکلات مرتبط با ریزسرویس‌ها را حل کنیم؟ 

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

ساختار ریزسرویس‌ها

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

Spring Boot چارچوب معروف Spring را با چند چارچوب و کتابخانه دیگر ادغام می‌کند تا چالش‌های اضافی معماری ریزسرویس را مدیریت کند.

Eclipse Microprofile عملکردی مشابه دارد، اما از Java EE استفاده می‌کند. به‌طور کلی، شرکت‌های فعال در زمینه ارائه برنامه‌های سرور مبتنی بر Java EE  مجموعه‌ای از مشخصات و پیاده‌سازی‌های مختلف و قابل تعویض را ارائه می‌کنند تا توسعه‌دهندگان بتوانند به بهترین شکل از مزایای توسعه مبتنی بر ابر بومی استفاده کنند. 

کلام آخر

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

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