افزایش سرعت در عصری که نرم افزارها، سرمایه کسب و کارها هستند
کسب و کارها نیاز به سرعت بالاتر دارند. از جمله تأثیرات تحول دیجیتال (و فشار آن برای پیروزی در اکونومی نرم افزار) می توان به تمایل شدید به حرکت سریع اشاره کرد. بر اساس گزارش State of Application Services در سال ۲۰۱۹، انگیزه حدود نیمی از سازمان ها (۴۸ درصد) برای پیاده سازی سریع تر، تحول دیجیتال بوده است.
اما مسئله اصلی فقط در مورد پیاده سازی نیست و به توسعه و پاسخگویی به تهدیدات روز نیز مربوط می شود.
سازمان ها تمایل دارند اپلیکیشن ها را سریع تر توسعه دهند و عرضه کنند. آن ها دوست دارند با سرعت بیشتری با تغییرات شرایط کسب و کار منطبق شوند و با سرعت بیشتری پاسخگوی حملات باشند.
آن ها چگونه می توانند به این اهداف دست یابند؟
توسعه سریع تر
هر چه تعداد پیاده سازی بیشتر باشد، سرعت توسعه شما هم بیشتر است. این هدف اغلب با روش های سرعت-محور امکان پذیر است. گزارش سال ۲۰۱۹ گیت لب با نام Global Developer Report: DevSecOps دریافت که اکثراً (۵۴ درصد) از اسکرام (Scrum) و ۳۷ درصد از آن ها از کانابان (Kanban) استفاده می کنند.
استفاده از کامپوننت
اگر معماری اپلیکیشن ها با سبک های توسعه تناسب نداشته باشند، این روش ها کافی نخواهند بود. تیم های کوچکتر و متمرکزی که تعداد عرضه زیادی دارند برای توسعه قابلیت های جدید یا رفع مشکل اپلیکیشن های سنتی و یکپارچه مناسب نیستند. استفاده از کامپوننت به همراه میکرو سرویس ها و معماری های توزیع یافته تر، با اصول معماری و عملیاتی مدرن سازگاری بیشتری دارد. بنابراین جای تعجب نیست که به طور میانگین بیش از ۸۰ درصد از یک اپلیکیشن مدرن با کامپوننت های جانبی ساخته شده اند و حجم عظیمی از این کامپوننت ها هم متن باز هستند.
API ها
به کارگیری API ها نیز برای آنهایی که به دنبال توسعه سریع تر با معماری توسعه با کامپوننت هستند کاملاً عادی شده است. API ها فرایند پیاده سازی را از اینترفیس جدا می کنند و به تیم ها اجازه می دهند بدون تأثیرگذاری بر استفاده کامپوننت ها یا اپلیکیشن های دیگر از API، پردازش را تغییر دهند. این کار کاملاً رایج است و ۶۴ درصد از سازمان ها برای کاربردهای داخلی یا خارجی خود از API استفاده می کنند. بر اساس گزارش Jitterbit’s State of API Integration در سال ۲۰۱۸، حدود ۵۰ درصد از این سازمان ها برای ارائه سریع تر ایده های خود به بازار به API ها متکی اند.
اتوماسیون (CI/CD)
برای دستیابی به پیاده سازی مکرر، سیستم بیلد هم باید همگام با آن حرکت کند. منظور از سیستم بیلد ابزارهای CI/CD هستند که مراحل کدنویسی تا تست و انتشار را پوشش می دهند. مشهورترین ابزارهای بیلد و CI در نظر سنجی ما، گیت لب GitLab با ۶۱ درصد، Jenkins با ۳۶ درصد و Travis CI با ۱۲ درصد بودند. پژوهش ما به این نتیجه رسید که ۱۶ درصد از شرکت کنندگان نظرسنجی، برای اتوماسیون شبکه هم از Jenkins استفاده می کنند (اگر سازمان ها به دنبال توسعه دواپس به چیزی فراتر از توزیع تا پیاده سازی باشند نتیجه ای امیدوار کننده است).
توسعه سریع تر
توسعه سریع تر به معنای ورود سریع تر ایده ها به بازار نیست. این کار نیازمند پیاده سازی است. اگرچه شرکت های تکنولوژی مبتنی بر کلود، به تقسیم عرضه-پیاده سازی کاملاً مسلط شده اند اما این تحول برای بسیاری از شرکت های معتبر چالش برانگیز است. ساختار فعلی سازمان ها و نیاز مستمر به پشتیبانی از اپلیکیشن های سنتی و یکپارچه سبب ایجاد ناسازگاری هایی شده اند که یکپارچه سازی آن ها را با نیازهای عملیاتی مدرن دچار چالش کرده اند. اما بدون شک سازمان ها باید برای اپلیکیشن هایی که به پیاده سازی سریع تر و با تعداد بیشتر نیاز دارند بر این چالش ها غلبه کنند.
پیاده سازی مستمر
سازمان های معتبر، اتوماسیون را با آغوش باز پذیرفته اند و در حال به کارگیری آن در سیستم پیاده سازی خود هستند. مشکل اصلی این است که اغلب ساختارهای آی تی سنتی، خدمات اتوماسیون و سلف-سرویس ناهماهنگی را ارائه می دهند. ما در پژوهش خود شاهد این مشکل بودیم. هر یک از تیم ها که کاملاً از یکدیگر مجزا بودند به نحوی بر اقدامات اتوماسیون در آی تی تأثیر داشتند.
ساختار تیم ها از اهمیت بسیار زیادی برخوردارند و سازمان هایی که به دنبال سیستم های خودکار هستند، اگر می خواهند کار پیاده سازی را سریع تر انجام دهند باید ابعاد فرهنگی پیاده سازی مستمر را در نظر داشته باشند.
کلود عمومی
در گذشته عدم توانایی در دست یابی به پیاده سازی مستمر، توسعه دهندگان و صاحبان اپلیکیشن را وادار می کرد به سمت کلود عمومی بروند، چون موانع راه پیاده سازی را از میان برمی دارد. یکی از عوامل تأثیر گذار بر این مشکل، اختلاف عقیده در مورد تعداد پیاده سازی هاست. نظرسنجی NetOps / DevOps ما در سال ۲۰۱۸ به این نتیجه رسید که ۵۵ درصد Devops و ۵۲ درصد معماران کلود احساس می کردند تعداد پیاده سازی های سازمانشان به اندازه کافی نیست اما ۳۰ درصد از هر دو گروه موافق این تعداد بودند.
اما این تنها عامل نیست. تحول دیجیتال قطعاً عامل تعیین کننده ای است. ۳۳ درصد از شرکت کنندگان نظرسنجی State of Application Services اظهار داشتند که به دلیل پذیرش ابتکارها و نوآوری های تحول دیجیتال، اپلیکیشن ها را از کلود عمومی عرضه می کنند. قابلیت یکپارچه سازی آسان سرویس های اپلیکیشن و اتوماسیون اجرا، عاملی بسیار مهم برای سازمان هایی است که قصد دارند با سرعت بیشتری به تعداد پیاده سازی بالاتر برسند.
کانتینرها
پیاده سازی مداوم نه تنها در کلود، بلکه در زیرساخت موجود در محل نیز، اغلب به قابلیت استفاده از سیستم های اختصاصی اپلیکیشن و سرویس های اپلیکیشنی که از این مدل پشتیبانی کنند نیازمند است. سازمان ها به دلیل توانایی در به روزرسانی سریع و توانایی کار مستمر در محیط های کاملاً تغییر پذیر، به شکل روزافزونی در حال حرکت به سمت کانتینرها هستند. به عقیده ما کانتینرها نه تنها برای پشتیبانی از معماری های مدرن اپلیکیشن مثل کلود نیتیو (پرکاربردترین کانتینر در میان شرکت کنندگان نظرسنجی Container Adoption Benchmark سال ۲۰۱۹ دیامانتی (Diamanti))، بلکه به دلیل پشتیبانی از زیرساخت، تقاضای بالایی دارند. در پژوهش ما تقاضا برای سرویس های اپلیکیشن زیرساخت داخلی در کانتینرها سال به سال رشد کرده و از ۴ درصد در سال ۲۰۱۷ به ۱۵ درصد در سال ۲۰۱۹ رسیده است.
پاسخ های سریع تر
مسئله اصلی فقط توزیع و پیاده سازی نیست. سازمان ها در بحث امنیت و عملیات های خود نیز به سرعت بالا نیاز دارند. در دنیای امروزی که حجم عظیمی از تعامل ها توسط ربات ها انجام می شوند، پاسخگویی سریع برای جلوگیری از افتادن به دام سوء استفاده ها یا آلودگی ها برای سازمان ها از اهمیت بسیار بالایی برخوردار است.
آنالیز آنی تهدید
یکی از راه هایی که سازمان ها به دنبال آن هستند تا سرعت توانایی خود در پاسخگویی به حملات را افزایش دهند، بکارگیری آنالیز آنی تهدید است. با قرارگیری «امنیت» در اولویت کار و همچنین تبدیل شدن آن به چالشی دائمی جای تعجب نیست که ۴۱ درصد از شرکت کنندگان نظرسنجی آن را جزء پنج استراتژی و تکنولوژی روز در سال ۲۰۱۹ می دانستند.
با افزایش سرعت یادگیری ماشین و اتوماسیون در تشخیص سریع تر ترافیک مشکل ساز، قابلیت دسترسی سرویس های اپلیکیشن امنیتی «هوشمند» نیز سرعت خواهد گرفت.
لحاظ نمودن هماهنگی
یادگیری ماشین تنها راه هوشمندتر کردن زیرساخت و سرویس های اپلیکیشن نیست. همانند نیاز به پاسخ سریع تر به رشد ظرفیت و پردازش همراه با کاربران، زیرساخت و سرویس های اپلیکیشن نیز رو به تکامل می روند تا ارکستراسیون را به عنوان قابلیت اصلی در خود جای دهند. پلتفرم های سرویس اپلیکیشن با لایه های هماهنگی یکپارچه سرویس هایی خواهند بود که مقیاس آن ها بر حسب تقاضا (و به صورت آنی) تغییر می کند. اگرچه امروزه چنین قابلیت هایی وجود دارد (در واقع جزء لاینفک کلود و کانتینرها هستند)، قابلیت تغییر مقیاس خودکار بر حسب نیاز اپلیکیشن و کاربر در اغلب سیستم های امروزی به صورت ذاتی دیده نمی شود. اما در آینده شاهد چنین قابلیتی در آن ها خواهیم بود.
شناسایی سریع تر خرابکاران
در نهایت سازمان ها باید برای کسب و کار و امنیت خود به جنگ با ربات ها برخیزند. چه سازمان ها به توقف اسکرپینگ (که تهدیدی جدی برای کسب و کار محسوب می شود) نیاز داشته باشند و چه بخواهند مانع یافتن آسیب پذیری ها توسط ربات ها شوند، شناسایی سریع تر ربات های خرابکار از اهمیت بسیار بالایی برخوردار است. امروزه قرار دادن یک چک باکس (که کنار آن عبارت «من ربات نیستم» نوشته شده است) کافی نیست، چون ربات ها در حال هوشمندتر شدن هستند و قادرند چنین تکنیک های ابتدایی و ساده را دور بزنند.
سازمان ها به سرویس های «محافظت در برابر ربات» روی آورده اند که می توانند برای شناسایی و مسدود کردن ربات های خرابکار، از تکنیک های مدرن تر و موفق تر استفاده کنند. در پاسخ به این نیاز، ما هر ماه شاهد افزایش استفاده از سرویس های محافظت در برابر ربات هستیم و انتظار داریم این روند ادامه داشته باشد.
توسعه سریع تر، پیاده سازی سریع تر و در نتیجه پاسخگویی سریع تر
ما در مورد نیاز کسب و کارهای امروزی به سرعت به این نتیجه رسیدیم که باید به فرایندها نگاه کنیم. فرایندهای توسعه به صورت خودکار درمی آیند تا سرعت خود را با CI/CD افزایش دهند. فرایندهای پیاده سازی به صورت خودکار درمی آیند تا با پیاده سازی مستمر و کلود سرعت بگیرند. با استفاده از سیستم ها و اضافه شدن ارکستراسیون به پلتفرم های سرویس اپلیکیشن به صورت ذاتی، فرایندهای تغییر مقیاس و امنیت نیز به صورت خودکار درمی آیند.
ما به این نتیجه رسیدیم که سرعت به توانایی سازمان در خودکارسازی فرایندهای توسعه، پیاده سازی و امنیت وابسته است.
