زمان «تکامل» برنامه‌های کاربردی ابری به SD-WAN فرارسیده است
وقتی با مشتری‌ها صحبت می‌کنیم، در مورد چالش‌هایی که کسب‌وکار آن‌ها با WAN موروثی تجربه می‌کنند زیاد می‌شنویم.
به‌خصوص مدیران و معماران شبکه در مورد مشکلات WAN-های فعلی به‌دلیل تغییر برنامه‌های کاربردی از مرکزداده‌ها به ابر صحبت می‌کنند.
چه وقتی SaaS جایگزین برنامه‌های کاربردی سنتی می‌شود و چه وقتی برنامه‌های کاربردی معینی به سرویس IaaS منتقل می‌شود، با این چالش‌ها روبه‌رو می‌شویم.
کاربران نهایی و بیشتر افرادی که با IT سروکار دارند، همه، از مزایای برنامه‌های کاربردی اَبرمحور مطلعند. اما بسیاری از کارکنان شبکه به ابر نگاه متفاوتی دارند. کارکنان شبکه وقتی سعی می‌کنند WAN-های قدیمی از برنامه‌های کاربردی ابریِ جدید پشتیبانی کنند گیر می‌افتند.
پس ناگریز بحث ما به موضوع مهم‌تر تغییری می‌کند: ازاین‌پس چه چیز در انتظار WAN است؟
می‌دانیم که یک WAN جدید چطور باید عمل کند و چگونه می‌توان آن را از محدودیت‌های موروثی آزاد کرد. واضح است که نوع جدیدی از WAN مورد نیاز است: یک SD-WAN که بتوان آن را برای کار در یک سازمانِ ابرمحور، خودکار و بهینه کرد؛ انتظار می‌رود که SD-WAN فقط «تعریف‌شده با نرم‌افزار [۱]» نباشد بلکه «خودران [۲]» نیز باشد.
چرا یک WAN موروثی برای این کار نامناسب است؟
کار یک WAN را می‌توان به‌سادگی توصیف کرد: اتصال کاربران به برنامه‌های کاربردی، از هرجا که ساکن هستند، چه در مرکز داده‌ها باشد و چه در محل دیگری یا در ابر.
همین است! با یک جمله می‌توان کار یک WAN را تعریف کرد. بنابراین چرا انجام همین یک جمله برای یک WAN موروثی آن‌قدر دشوار است؟
به دلیل اینکه WAN موروثی طوری طراحی شده بود که بیشتر ترافیکش و مهم‌ترین ترافیکی‌ای را که مصرف می‌کرد، داخلی باشد. ترافیک WAN به مرکز داده‌ها یا به انشعاب دیگری منشعب می‌شد. اما امروزه ترافیک انشعاب به ابر، سریع‌ترین ترافیک است، و البته برای بیشتر سازمان‌ها مهم‌ترین ترافیک.
WAN موروثی غالباً با ترافیک انشعاب‌به‌ابر همراه است تا مسیرهای ترومبون [۳] را از مرکز داده‌ها بگیرد و این هزینه‌های WAN را بالا میبرد و مانع عملکرد برنامه کاربردی است.
WAN موروثیِ امروز دهه‌هایی از پیچیدگی و مغلطه‌ای از پروتوکل‌های شبکه (و گواهی‌ها- که خودش موضوع دیگری است) به ارث برده است. حتی کارهای ساده، مثل تقویت هم‌زمان لینک‌های WAN چندگانه یا مسیردهی ترافیک بر مبنای اقدامات کیفی بسیار پیچیده هستند و در برخی از موارد تقریباً غیرممکن‌اند.
کارمندان IT ساعات زیادی را صرف پیکربندی، استقرار و اشکال‌یابی WAN موروثی می‌کنند؛ نتیجه، ازبین رفتن استعداد اصلی IT است، درعوض اینکه کسب‌وکار را به‌پیش ببرد، فقط درحد گذران «دخل‌وخرج» کارآیی دارد. WAN موروثی مانع عملکرد کارکنان IT می‌شود.
چگونه گرفتار این پیچیدگی شدیم؟
به شیوه‌های گوناگون. کلاً به ابتدای اینترنت باز می‌گردد که برای جان سالم به در بردن از حملات خطرناک کاملاً به‌شیوه‌ی توزیعی و بدون هیچ کنترل مرکزی معماری شد.
ظاهراً معماری اینترنت در خیلی موارد درست درآمد، در غیر این صورت اینترنت جایی نبود که امروز شاهد هستیم. اما جایی در میان راه سازمان‌ها نیز در همین فرضِ طراحی گیر افتادند؛ گمان کردند که هر WAN باید مثل یک اینترنت کوچک با تمام پیچیدگی‌های آن اجرا شود.
پیش به‌سوی SD-WAN ارکستری مرکزی (Centrally Orchestrated SD-WAN)
تغییر شبکه تعریف‌شده با نرم‌افزار [۱]، این الگوواره را که باید هر چیزی را توزیع کرد به چالش می‌کشد.
در واقع برای بسیاری از طراحی‌های شبکه، ازجمله ساخت WAN سازمانی، منافع بسیاری برای کنترل مرکزی یا ارکستراسیون وجود دارد. با SD-WAN ارکستری مرکزی می‌توان به دردسرهای نگهداری صدها سایتی که پیکربندی مرتبط دارند پایان داد. مشتریان می‌توانند امنیت و عملکرد را بهبود و پیچیدگی و هزینه‌ها را کاهش بدهند.
با یک SD-WAN ارکستری مرکزی می‌توان اساساً سازمان‌ها را از بار سنگین پیچیدگی و به‌هم‌ریختگی راهکارهای فوری فنی و CLI-های محرمانه‌ای که WAN-های موروثی در طی ۳۰ یا ۴۰ گذشته جمع کرده‌اند رهانید.
مشتریانی که WAN-های موروثی دارند می‌گویند «دیگر بس است». ما دیگر به چسب‌زخم‌های فوری برای مشکلات عمیق نیاز نداریم. ما به یک WAN نیاز داریم که برای ابر بهینه‌سازی شود و بتواند اهداف تجاری سطحِ‌بالا را به‌طور خودکار به رویکرد ثابت و گسترده‌ای در شبکه تبدیل کند.
[۱] software defined
[۲] self driving
[۳] اصطلاح ترافیک ترومبون (Terombone) را اولین بار گرِگ فِرو برای توصیف جریان ترافیک VLAN داخلی، در شبکه‌هایی که با دامنه‌های L2 تداخل دارند ساخت.
