شبکه‌کننده (نه) مورد نیاز است

در زمان نوشتن این مقاله، جستجو در یک سایت شغلی محبوب برای عبارت "مهندس شبکه" حدود سیصد شغل خالی را در سراسر روسیه نشان داد. برای مقایسه، جستجوی عبارت "مدیر سیستم" تقریبا 2.5 هزار جای خالی و "مهندس DevOps" - تقریبا 800 را نشان می دهد.

آیا این بدان معناست که در زمان ابرهای پیروز، Docker، Kubernetes و وای فای عمومی همه جا دیگر نیازی به نتورکر نیست؟
بیایید آن را بفهمیم (ج)

بیایید با هم آشنا شویم. اسم من الکسی است و یک نتورکر هستم.

من بیش از 10 سال است که درگیر شبکه‌ها هستم و بیش از 15 سال است که با سیستم‌های مختلف *nix کار می‌کنم (من فرصتی داشتم که هم با لینوکس و هم با FreeBSD کار کنم). من در اپراتورهای مخابراتی کار می کردم، شرکت های بزرگی که به عنوان "تجاری" در نظر گرفته می شوند، و اخیراً در فین تک "جوان و جسور" کار می کنم، جایی که ابرها، devops، kubernetes و دیگر کلمات ترسناک که قطعا من و همکارانم را بی نیاز خواهند کرد. . یه روزی شاید.

سلب مسئولیت: "در زندگی ما، همه چیز همیشه و همه جا نیست، اما چیزی، گاهی اوقات در مکان ها" (ج) ماکسیم دوروفف.

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

به دنیای من خوش آمدید.

حتی در کجا می توانید با نتورکرها ملاقات کنید؟

1. اپراتورهای مخابراتی، شرکت های خدماتی و سایر ادغام کنندگان. همه چیز در اینجا ساده است: شبکه برای آنها یک تجارت است. آنها یا مستقیماً اتصالات (اپراتورها) را می فروشند یا خدماتی را برای راه اندازی/حفظ شبکه مشتریان خود ارائه می دهند.

در اینجا تجربه زیادی وجود دارد، اما پول زیادی نیست (مگر اینکه مدیر فروش یا مدیر فروش موفقی باشید). و با این حال، اگر شبکه‌ها را دوست دارید، و تازه در ابتدای راه هستید، حرفه‌ای در حمایت از برخی اپراتورهای نه چندان بزرگ، حتی در حال حاضر، یک نقطه شروع ایده‌آل خواهد بود (در شبکه‌های فدرال همه چیز بسیار برنامه‌نویسی شده است، فضای کمی برای خلاقیت است). خوب، داستان هایی در مورد اینکه چگونه می توانید در عرض چند سال از یک مهندس در حال وظیفه به یک مدیر سطح C تبدیل شوید نیز کاملا واقعی است، اگرچه نادر است، به دلایل واضح. همیشه نیاز به پرسنل وجود دارد، زیرا جابجایی اتفاق می افتد. این در همان زمان هم خوب است و هم بد - از طرف دیگر همیشه جاهای خالی وجود دارد - اغلب فعال ترین/هوشمندترین ها به سرعت یا برای ارتقاء یا به مکان های "گرمتر" دیگر می روند.

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

3. شرکت های تولید کنندهکه سود آن از توسعه (و اغلب، بهره برداری) برخی از نرم افزارها یا پلتفرم ها - همان محصول - به دست می آید. معمولاً آنها کوچک و زیرک هستند، هنوز از مقیاس شرکت ها و بوروکراتیزاسیون آنها فاصله دارند. اینجاست که همان devops، cubers، dockers و دیگر کلمات وحشتناک به طور انبوه یافت می شود، که مطمئناً مهندسان شبکه و شبکه را به یک مقدمه غیر ضروری تبدیل می کند.

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

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

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

در واقع تفاوت اصلی در رویکرد کار است. شاید در میان نتورکرها باشد که بیشتر حامیان رویکرد «اگر کار کرد، به آن دست نزنید!» وجود داشته باشد. به عنوان یک قاعده، کاری را می توان (در یک فروشنده) تنها به یک روش انجام داد؛ کل پیکربندی جعبه دقیقاً در کف دست شما قرار دارد. هزینه خطا زیاد است و گاهی اوقات بسیار زیاد است (به عنوان مثال، برای راه اندازی مجدد روتر باید چندین صد کیلومتر را طی کنید و در این زمان چندین هزار نفر بدون ارتباط خواهند بود - یک وضعیت کاملاً رایج برای یک اپراتور مخابراتی) .

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

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

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

مشکل اصلی این است که مرکز داده بخش فناوری اطلاعات شما نیست، یک شرکت جداگانه است که هدف آن کسب سود است. از جمله به هزینه شما به عنوان مشتری. مرکز داده قفسه‌ها را فراهم می‌کند، برق و سرما را در اختیار آنها قرار می‌دهد و همچنین برخی از اتصالات «پیش‌فرض» به اینترنت را فراهم می‌کند. بر اساس این زیرساخت، مرکز داده می تواند تجهیزات شما را میزبانی کند (هم مکان)، سروری را به شما اجاره دهد (سرور اختصاصی) یا یک سرویس مدیریت شده (به عنوان مثال OpenStack یا K8s) ارائه دهد. اما کسب و کار یک مرکز داده (معمولا) مدیریت زیرساخت مشتری نیست، زیرا این فرآیند کاملاً کار بر است، خودکارسازی ضعیفی دارد (و در یک مرکز داده معمولی هر چیزی که ممکن است خودکار است)، حتی بدتر یکپارچه (هر مشتری) فردی است) و به طور کلی مملو از شکایت است ("شما به من بگویید سرور راه اندازی شده است، اما اکنون از کار افتاده است، همه اینها تقصیر شماست!!!111"). بنابراین، اگر میزبان در کاری به شما کمک کند، سعی می کند آن را تا حد امکان ساده و راحت کند. از آنجا که انجام آن دشوار است، حداقل از نقطه نظر هزینه های نیروی کار مهندسان همین میزبان، بی سود است (اما شرایط متفاوت است، به سلب مسئولیت مراجعه کنید). این بدان معنا نیست که میزبان لزوماً همه چیز را بد انجام می دهد. اما این به هیچ وجه واقعیت ندارد که او دقیقاً همان کاری را که شما واقعاً نیاز داشتید انجام خواهد داد.

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

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

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

در ادامه به طور خاص در مورد شرکت های مواد غذایی مدرن صحبت خواهیم کرد. در مورد اپراتورها و سازمانی، همه چیز روشن است، مثبت یا منفی - در سال های اخیر تغییرات کمی در آنجا ایجاد شده است، و قبلاً به نتورکرها در آنجا نیاز بود و اکنون به آنها نیاز است. اما با همان «جوان و جسور» همه چیز چندان روشن نیست. اغلب آنها کل زیرساخت خود را در ابرها قرار می دهند، بنابراین آنها حتی واقعاً به ادمین نیاز ندارند - البته به جز ادمین های همان ابرها. زیرساخت، از یک طرف، در طراحی آن کاملاً ساده است، از طرف دیگر، به خوبی خودکار است (ansible/Puppet، Terraform، ci/cd... خب، می دانید). اما حتی در اینجا شرایطی وجود دارد که نمی توانید بدون مهندس شبکه انجام دهید.

مثال 1، کلاسیک

فرض کنید یک شرکت با یک سرور با یک آدرس IP عمومی شروع به کار می کند که در یک مرکز داده قرار دارد. سپس دو سرور وجود دارد. سپس بیشتر... دیر یا زود، نیاز به یک شبکه خصوصی بین سرورها وجود خواهد داشت. از آنجا که ترافیک "خارجی" هم از نظر پهنای باند (مثلاً بیش از 100 مگابیت بر ثانیه) و هم به دلیل حجم بارگیری/آپلود در ماه محدود است (هاست‌های مختلف تعرفه‌های متفاوتی دارند، اما پهنای باند به دنیای خارج معمولاً بسیار گران‌تر از شبکه خصوصی).

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

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

چه کاری باید انجام دهید؟

شبکه را به بخش هایی تقسیم کنید - vlans. آدرس دهی خود را در هر vlan پیکربندی کنید، دروازه ای را انتخاب کنید که ترافیک بین شبکه ها را انتقال دهد. acl را در گیت‌وی پیکربندی کنید تا دسترسی بین بخش‌ها را محدود کنید یا حتی یک فایروال جداگانه در نزدیکی آن نصب کنید.

مثال 1، ادامه دارد

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

چه کاری باید انجام دهید؟

سرورها را با استفاده از LAG (Link Aggregation Group) با دو سیم به سوئیچ های رک وصل کنید (همچنین باید اضافی باشند). اتصالات بین قفسه ها را رزرو کنید و آنها را به یک "ستاره" (یا CLOS امروزی مد روز) تبدیل کنید تا از بین رفتن یک رک روی بقیه تأثیر نگذارد. رک های "مرکزی" را انتخاب کنید که هسته شبکه در آن قرار دارد و سایر رک ها در آن وصل خواهند شد. در عین حال آدرس دهی عمومی را مرتب کنید، از میزبان (یا در صورت امکان از RIR) یک زیرشبکه بگیرید که خودتان (یا از طریق میزبان) به دنیا اعلام می کنید.

آیا همه اینها می تواند توسط یک مدیر سیستم "معمولی" که دانش عمیقی از شبکه ها ندارد انجام دهد؟ مطمئن نیستم. آیا میزبان این کار را انجام می دهد؟ شاید اینطور باشد، اما شما به یک مشخصات فنی نسبتاً دقیق نیاز دارید، که کسی نیز باید آن را ترسیم کند. و سپس بررسی کنید که همه چیز به درستی انجام شده است.

مثال 2: ابر

فرض کنید یک VPC در یک ابر عمومی دارید. برای دسترسی از دفتر یا بخشی از زیرساخت به شبکه محلی داخل VPC، باید یک اتصال را از طریق IPSec یا یک کانال اختصاصی پیکربندی کنید. از یک طرف، IPSec ارزان تر است، زیرا بدون نیاز به خرید سخت افزار اضافی، می توانید یک تونل بین سرور خود با آدرس عمومی و ابر راه اندازی کنید. اما - تأخیر، عملکرد محدود (از آنجایی که کانال باید رمزگذاری شود)، به علاوه اتصال تضمین نشده (از آنجایی که دسترسی از طریق اینترنت معمولی است).

چه کاری باید انجام دهید؟

اتصال را از طریق یک کانال اختصاصی بالا ببرید (به عنوان مثال، AWS آن را Direct Connect می نامد). برای انجام این کار، یک اپراتور شریک پیدا کنید که شما را متصل کند، در مورد نزدیکترین نقطه اتصال به شما (هم شما به اپراتور و هم اپراتور به ابر) تصمیم بگیرید و در نهایت، همه چیز را تنظیم کنید. آیا می توان همه این کارها را بدون مهندس شبکه انجام داد؟ حتما بله. اما نحوه عیب یابی بدون او در صورت بروز مشکل دیگر چندان واضح نیست.

همچنین ممکن است مشکلات در دسترس بودن بین ابرها (اگر چند ابری دارید) یا مشکلات تاخیر بین مناطق مختلف و غیره وجود داشته باشد. البته الان ابزارهای زیادی ظاهر شده اند که شفافیت اتفاقات را در فضای ابری افزایش می دهند (همان هزار چشم) اما اینها همه ابزار یک مهندس شبکه است و جایگزینی برای او نیست.

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

یک نتورکر چه چیزی باید بداند؟

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

علاوه بر، در واقع، شبکه ها - اگرچه به سادگی یک زمینه بی پایان برای مطالعه وجود دارد، حتی اگر فقط روی یک منطقه تمرکز کنید (شبکه های ارائه دهنده، شرکت ها، مراکز داده، Wi-Fi ...)

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

• قادر است نه تنها به عنوان یک کاربر در لینوکس کار کند، بلکه می تواند آن را حداقل در سطح sysadmin-jun مدیریت کند: نرم افزار لازم را نصب کنید، یک سرویس ناموفق را راه اندازی مجدد کنید، یک سیستم ساده بنویسید.
• درک کنید (حداقل به طور کلی) چگونه پشته شبکه در لینوکس کار می کند، چگونه شبکه در هایپروایزرها و کانتینرها (lxc / docker / kubernetes) کار می کند.
• البته بتوانید با ansible/chef/Puppet یا سیستم SCM دیگری کار کنید.
• یک خط جداگانه باید در مورد SDN و شبکه های ابرهای خصوصی (به عنوان مثال، TungstenFabric یا OpenvSwitch) نوشته شود. این یک لایه عظیم دیگر از دانش است.

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

از سوی دیگر، همان عادت "درک نحوه عملکرد سیستم" به نتورکرها برتری بسیار خوبی نسبت به "عمومی" های مختلف می دهد که در مورد فن آوری ها از مقالات در Habré/Medium و چت در تلگرام می دانند، اما مطلقاً هیچ ایده ای ندارند که چگونه باید انجام دهند. آیا این یا آن نرم افزار روی اصول کار می کند؟ و دانش الگوهای خاص، همانطور که شناخته شده است، با موفقیت جایگزین دانش بسیاری از حقایق می شود.

نتیجه گیری، یا فقط TL;DR

1. یک مدیر شبکه (مانند یک مهندس DBA یا VoIP) متخصصی است با مشخصات نسبتاً باریک (برخلاف مدیران سیستم/devs/SRE)، که نیاز به آن فوراً ایجاد نمی‌شود (و ممکن است در واقع برای مدت طولانی ایجاد نشود) . اما اگر به وجود بیاید، بعید است که با تخصص خارجی (برون سپاری یا مدیران معمولی همه منظوره، "که همچنین از شبکه مراقبت می کنند") جایگزین شود. چیزی که تا حدودی غم انگیزتر است این است که نیاز به چنین متخصصانی اندک است و مشروط به شرط، در شرکتی با 800 برنامه نویس و 30 مدیر/مدیر، ممکن است تنها دو نتورکر وجود داشته باشند که وظایف خود را عالی انجام دهند. آن ها بازار بسیار بسیار کوچک بود و هست و با حقوق خوب - حتی کمتر.
2. از طرف دیگر، یک نتورکر خوب در دنیای مدرن باید نه تنها خود شبکه ها (و نحوه خودکارسازی پیکربندی آنها) را بداند، بلکه باید بداند که سیستم عامل ها و نرم افزارهایی که در بالای این شبکه ها اجرا می شوند چگونه با آنها تعامل دارند. بدون این، درک آنچه همکارانتان از شما می‌خواهند و انتقال (معقولانه) خواسته‌ها/نیازهای خود به آنها بسیار دشوار خواهد بود.
3. هیچ ابری وجود ندارد، فقط کامپیوتر شخص دیگری است. باید بدانید که استفاده از ابرهای عمومی/خصوصی یا خدمات ارائه‌دهنده میزبانی «که همه کارها را برای شما به صورت کلید در دست انجام می‌دهد» این واقعیت را تغییر نمی‌دهد که برنامه شما همچنان از شبکه استفاده می‌کند و مشکلات مربوط به آن بر عملکرد آن تأثیر می‌گذارد. درخواست شما انتخاب شما جایی است که مرکز صلاحیت قرار خواهد گرفت که مسئولیت شبکه پروژه شما را بر عهده خواهد داشت.

منبع: www.habr.com