امروزه ما در دنیایی زندگی می‌کنیم که اختلالی بی‌سابقه بازار را فراگرفته. به‌گونه‌ای که تمامی استراتژی‌ها دستخوش تغییرات شده و به کاربران این فرصت را می‌دهد تا یک شبه راه صدساله را برای رسیدن به یک نام تجاری معتبر طی نمایند. اما باید بدانید که این اتفاق درست زمانی شکل می‌گیرد که مدیران به دنبال ایجاد یک مکالمه کاملا متفاوت با فناوری IT باشند. در واقع CIO و CTO تلاش می‌کنند تا از طریق فناوری‌های IT یک شریک تجاری برای خود دست و پا نمایند. تفاوت یک تامین کننده تجاری با یک شریک تجاری را در قالب یک مثال توضیح می‌دهم، یک تامین کننده تجاری معمولا می گوید: "چه زمانی زیرساخت‌ها آماده خواهند بود؟ چه زمانی قابلیت مورد نظر را ارائه می‌دهند؟ چگونه می‌توان بودجه مربوطه را با قابلیت‌های موجود کاهش داد؟ و.... " در‌حالی که یک شریک تجاری کاملا متفاوت می گوید: "هر چیزی که نیاز دارید را هر هر‌زمانی که لازم است بسازید؛ یک API جدید امنیتی که میتوانید از آن استفاده کنید؛ این نتیجه یک پایلوت جدید است که به تازگی اجرا شده است؛ و در نهایت ما در این ماه X برابر هزینه ها را کاهش دادیم"
این اتفاق توسط بخش فناوری اطلاعات (IT) شروع می شود و تنها یک هدف دارد. محصولات را عرضه کرده و به بازار بیاورد، به فرایند توسعه محصول و نوآوری سرعت دهد و بر سرعت سازندگان تاکید کند. این مسئله تنها زمانی رخ می‌دهد که IT بر روی تسک هایی تمرکز کند که business پروژه ها از یکدیگر مجزا کرده و به توسعه دهندگان کمک کند سریعتر کار کنند. آن دسته از تسک هایی که business آنها تفکیک نشده اند باید به صورت اتوماتیک خارج از سیستم قبلی با بیشترین عملکرد بارگذاری شوند. این تغییر پارادایم نیاز به یک تحول دارد و همان‌طور که یکی از دوستانم (استیون) به درستی خاطرنشان می‌کند، سیستم مربوطه با افراد و سازمانی که در آن مشغول به فعالیت هستید ارتباط بیشتری نسبت به فناوری‌های زیربنایی دارد.
دوران قبل از مجازی‌سازی
همه ما می‌دانیم که در دوران قبل از مجازی‌سازی، استقرار زیرساخت‌ها به صورت دستی انجام می‌گرفت. در این دوران برای تامین زیرساخت‌ها باید ماه‌ها منتظر می‌ماندیم، سپس به سراغ قفسه‌بندی، انباشته‌سازی، سیم‌کشی، نصب و پیکربندی می‌رفتیم. این برنامه‌ها به صورت یکپارچه صورت می‌گرفت و وابستگی شدیدی به استقرار دستی داشت. راهنمای نصب آن نیز ده‌ها صفحه بود که اکثرا فرصت خواندن را به کاربران نمی‌داد. این مسئله منجر شده تا کارآیی مرکز داده برای تامین چرخه و استفاده از ظرفیت‌های موجود تنها در 25 الی 40 درصد خلاصه شود. در این مدل، تیم‌های توسعه تلاش می‌کنند تا زیرساخت‌ها و عملیات‌های موجود را در یک راستا به فعالیت درآورند و برای ایجاد هرگونه تغییر، حتی تغییری جزئی هفته‌ها و ماه‌ها برنامه‌ریزی نمایند. این فرآیند با توجه به دستی بودن به یک چالش اساسی برای کاربران تبدیل شده بود.
مجازی‌سازی/فضای ابری خصوصی
با پیشرفت علم و تکنولوژی به این درک رسیده‌ایم که مجازی‌سازی و فضای ابری خصوصی می‌تواند نوید‌دهنده یک راه بهتر در این راستا باشد. در واقع این سیستم به دنبال آن است تا کارایی سرور را با کوچک کردن ردپای زیرساخت‌ها بهبود بخشد و اتوماسیون را با ارائه مدل‌های جدید برای افزایش سرعت در کسب و کار به شرایط مطلوب برساند.
واقعیت این است که با توجه به اینکه مجازی‌سازی همواره بر روی تاثیرات مثبت سرورها تاکید دارد و حتی این امکان را برای سازمان‌ها به وجود می‌آورد که به تلفیق منطقی برخی مراکز داده بپردازند، اما با این‌حال بسیاری از وعده‌ها به واقعیت تبدیل نمی‌شوند. در واقع تهیه و برنامه‌ریزی ظرفیت‌ها بهبود نیافته و سازندگان همچنان بر اساس الگوهای پیش‌بینی شده از محصول خود موظف به تهیه ظرفیت مورد نیاز برای اوج هستند. در بعضی موارد، سازندگان باید ظرفیت خود را به دو برابر برسانند تا سناریوهای بازیابی خرابی‌ها (DR ، یا n-1) را در خود جای دهند. در کسب و کار نیز برای پخش این بخش در چندین واحد تجاری چیزی حدود 3 الی 5 سال زمان در نظر گرفته شده است. هر چند که برحسب تجربه می‌توان گفت که هرگز به پایان نمی‌رسد.
تیم‌های زیرساختی برای شروع کار مجازی‌سازی به سراغ اتوماتیک سازی می‌روند هر چند که این توانایی در تیم‌های توسعه‌دهنده گسترش پیدا نکرده است. جالب اینجاست که مدل‌های تحویل داده شده همچنان دستی بوده و در طی روز و یا به صورت هفتگی نیاز به بهره‌گیری از سیستم اتوماسیون محدود دارند. اگر نگاهی به سیستم داخلی شرکت‌ها و سازندگان بیاندازید متوجه خواهید شد که اکثر آنها همچنان به سختی در حال ایجاد تغییر هستند و به ندرت توانسته‌اند در این راه به موفقیت برسند.
خبر خوب این است که سازمان‌هایی که برای مجازی‌سازی محیط خود اقدام کرده‌اند، از یک استراتژی فضای ابری خصوصی پیروی می‌کنند که سرعت ارائه خدمات را افزایش داده است. به‌گونه‌ای که در مرحله بعدی این خدمات به تکامل خواهند رسید. در واقع مجازی‌سازی نه تنها حرکت واقعی VM را ساده‌تر می‌کند، بلکه بازتاب توانایی سازمان برای تحول و سازگاری با نیازهای کسب‌وکار با استفاده از نیروی کار IT را نیز فراهم می‌آورند.
سیری در فضای ابری
تکمیل تغییراتی که در سیستم‌ها برای انتقال به فضای ابری صورت می‌گیرد، این امکان را به مشتریان می‌دهد تا تمامی وعده‌های عملی نشده مجازی‌سازی را به واقعیت تبدیل نمایند. تهیه تقاضای شبکه، محاسبه، ذخیره‌سازی، بانک اطلاعاتی و سایر منابعی که در یک مدل pay-as-you-go وجود دارد باعث می‌شوند تا سرعت تیم توسعه برای محقق کردن خواسته مشتریان افزایش پیدا کند. اما باید بدانید که این تحول به هیچ عنوان لحظه‌ای نخواهد بود. در عوض، سرعت حرکت تیم‌های توسعه در هنگام حرکت مشتری در مراحل مختلف افزایش پیدا کرده است.
مراحل انجام فضای ابری- مراحل حرکت پروژه
در طی انجام مراحل فضای ابری، سازمان‌ها باید بیاموزند که 1-چند پروژه با مزایای مد نظر آغاز می‌شود؟ 2- پایه و اساس تحول سازمانی که از طریق تیم ابری در مرکز (CCoE) بارگذاری شده چیست؟ 3-آیا حرکت‌های جمعی صورت می‌گیرد؟ در این قسمت شما را با عوامل تاثیرگذار بر افزایش سرعت سازندگان آشنا می‌کنیم.
⦁ زیرساخت به عنوان کد:
در اولین مرحله از پروژه، این امکان وجود دارد که مشتریان کارهای خاصی را به صورت دستی انجام دهند. با این وجود، وقتی در مسیر حرکت قرار می‌گیرند، زیرساخت‌ها را به عنوان کد، پذیرش می‌کنند. این بدان معنی‌ست که تمام زیرساخت‌ها به سادگی با اسکریپت‌ها اتوماسیون نشده و به صورت کد مورد توسعه قرار می‌گیرند. همچنین می‌توان گفت که این قالب در استقرار محیط در طی مدت چند دقیقه نقشی موثر ایفا می‌نماید.
⦁ Cloud COE:
این تیم با توجه به الگوهای موجود، به توسعه و حفظ زیرساخت‌های اصلی، بازسازی و طراحی مجدد آنها می‌پردازند. Cloud COE حتی توانایی آموزش به تیم‌های مربوطه را برای حرکت در مسیر درست برنامه‌های فضای ابری نیز دارد. همچنین تیم‌های توسعه از زیرساخت‌ها به عنوان خط لوله استفاده کرده و با ادغام آن با برنامه‌های خود، شرایط لازم برای رسیدن به خواسته‌ها را محقق می‌سازند.
⦁ پذیرش خدمات AWS:
از جمله شرکت‌هایی که به سراغ بهره‌گیری از این خدمات رفته‌اند می‌توان به آمازون (EC2)، فروشگاه بلوک الاستیک آمازون (EBS)، توازن بار الاستیک آمازون (ELB)، ذخیره سازی ساده آمازون سرویس (S3)، هویت و مدیریت دسترسی AWS (IAM)، سرویس مدیریت کلید AWS (KMS) ، AWS Cloud Formation و Amazon CloudWatch اشاره کرد. نکته جالب اینجاست که امروزه مشتریان برای از بین بردن برنامه‌های یکپارچه خود و همچنین مدیریت خدمات موجود به سراغ استفاده از AWS می‌روند.
⦁ امنیت:
اگر چه امنیت به‌طور سنتی می‌تواند مانع بزرگی در سرعت محقق کردن اهداف باشد. اما اگر بتوانید آن را به صورت صحیح در AWS به اجرا درآورید مطمئنا سطح شفافی از آن چیزی که مد نظر دارید حاصل خواهد شد.
اختیارات فضای ابری- مرحله فازی
هیچ شکی در این نیست که سرعت حرکت تیم‌های توسعه‌دهنده به محض حرکت مشتریان در مراحل اولیه پذیرش، بهبود پیدا می‌کند. اما در بسیاری از موارد، فرصت بهینه‌سازی با مرحله حرکت به پایان نمی‌رسد. در واقع مشتریان به ندرت با این فرصت روبرو می‌شوند که کلیه برنامه‌های خود را به عنوان بخشی از مسیر حرکت خود بازسازی نمایند. از همین رو فرصتی برای بازسازی مداوم به منظور تسریع سرعت سازندگان ایجاد شده است. بازسازی مجدد برنامه‌ها اغلب مستلزم جدا شدن و تجزیه سرویس‌های کوچک‌تر با APIها و در عین حال حداکثر استفاده مجدد است. از همین‌رو مشتریان به دنبال بارگذاری قسمت‌های متمایز شده از برنامه به بستر AWS و تمرکز بر روی کسب‌وکار خود هستند.
در طی مرحله Reinvention، سازمان‌ها معمولا از خدمات کاملا مدیریتی مانند Amazon Kinesis برای شمارش داده‌ها، AWS Lambda برای پردازش زمان واقعی، Amazon Aurora و Amazon DynamoDB برای رابطه دیتابیس‌ها و NoSQL و آمازون Redshift برای ذخیره داده‌ها استفاده می‌کنند. از همین رو می‌توان گفت که حداکثر زمان موجود برای ایجاد تمایز، توسط سازندگان مشاغل صرف خواهد شد. بعید است که بتوان توسعه را به عنوان یکی از بهترین راه حل‌ها برای ارسال پیام و یا مدیریت APIها در نظر گرفت. در عوض، این الگوریتم ها، گردش کار تجاری و آنالیزهای زمان واقعی شما هستند که باعث خوشحالی مشتریان شما می‌شوند و به رشد شغلی شما کمک می‌کنند. در این مرحله، همچنین تلاش متمرکز‌تری برای تبدیل عملیات به یک مدل واقعی DevOps انجام خواهد شد. فضای ابری COE همچنین بیشتر روی توسعه و بازسازی مرجع، چارچوب‌های حاکمیتی و انطباق تمرکز دارد و به تیم توسعه اجازه می‌دهد استقلال بیشتری برای استقرار زیرساخت‌ها و برنامه‌های کاربردی از طریق خط لوله CI / CD یکپارچه داشته باشد. علاوه‌براین تیم‌های امنیتی با پذیرش متدولوژی های DevSecOps و افشای قابلیت‌های امنیتی از طریق API، سرعت خود را تسریع می‌بخشند.
تکمیل محاسبات داده‌های بزرگ
برای چشم‌انداز این موضوع، باید ببینیم که داده‌های بزرگ فضای ابری با توجه به تحولات صورت گرفته چگونه محاسبه می‌شود.
اولین تحول محاسباتی عمده در زمان‌های اخیر از سرورهای فیزیکی گرفته تا سرورهای مجازی در مراکز داده بوده است. در این مرحله به منظور استفاده بالاتر از محیط های یکنواخت و استقلال سخت افزار به سراغ قابلیت‌های جید DR رفته‌اند. مرحله بعدی سرورهای مجازی در فضای ابری می‌باشد. این امر باعث ایجاد منابع تقاضا، مقیاس پذیری بیشتر و چابکی و بهبود در دسترس بودن و تحمل خطا شده است. اما از دیدگاه سرعت سازنده، هنوز به پیشرفت لازم دست پیدا نکرده‌اند. هر چند همواره نگرانی‌هایی در رابطه با دسترسی زیاد DR وجود دارد که باید توسط مدیریت تصاویر طلایی و پچ کردن سرورها انجام شود به‌گونه‌ای که حجم کاری آنها با شما یکسان شود. از دیدگاه سازنده، تنها کاری که می‌خواهید انجام دهید این است که روی منطق کسب‌وکار تمرکز کنید و آن را براساس برنامه یا در پاسخ به یک رویداد به اجرا درآورید.
درست همین‌جاست که AWS Lambda و انتقال به رایانه بدون سرور وارد می‌شود. با AWS Lambda هیچ سروری برای مدیریت و اتصال وجود ندارد. سازندگان به سادگی شروع به نوشتن عملکرد خود می‌کنند در‌حالی که سرویس Lambda به صورت خودکار در حال اجرا بوده و به مدیریت مقیاس‌پذیری می‌پردازد. به عنوان مثال، VidRoll، از AWS Lambda برای تهیه منطق مشاغل خود برای مناقصه آگهی در زمان واقعی و برای رونویسی فیلم‌ها در زمان واقعی استفاده می‌کند. اما باید بدانید که با استفاده از لامبدا، VidRoll میتوانید به کمک 2 الی 3 مهندس کارها را به سرانجام برسانید.
نمونه مشابه دیگر در تکامل سرویس‌های داده بزرگ در AWS دیده شده است. به عبارت بهتر این امکان وجود دارد که مشتریان به مدیریت Hodoop خود در EC2 و EBS بپردازند. در واقع این امر چالش‌های بسیار بزرگی را در بازسازی فرض‌های از پیش تعیین شده برای افراد به وجود می‌آورد که در فضای ابری نیز ادامه دارد. به عنوان مثال: به دلیل همراه بودن محاسبه و ذخیره سازی، سیستم شما در ساعات اوج بیش از حد مورد استفاده قرار گرفته است که این مسئله در دیگر ساعات صدق نمی‌کند. حال نکته اینجاست که شما نمی‌توانید سیستم را به راحتی در ساعات اوج خاموش کنید بلکه باید داده‌ها را در HDFS تداوم بخشید، و پیش از آن که حتی بتوانید یک داده را به اجرا درآورید، دائماً باید مقدار زیادی از آنها را به HDFS محلی انتقال دهید.
آمازون EMR با جدا کردن محاسبات و ذخیره سازی و اعمال فشار S3 به عنوان مرکز داده مداوم، به این مسائل می‌پردازد. به عنوان مثال FINRA قادر است یک سیستم HBase جدید را روی EMR راه‌اندازی کند و پرس‌وجوها را در کمتر از 30 دقیقه انجام دهد. زیرا داده‌ها در S3 باقی می‌مانند. از نظر هزینه‌ها نیز می‌توان گفت که مدیریت FINRA در EC2 با اعمال S3 برای ذخیره‌سازی داده‌ها، هزینه‌ها را به طور قابل توجهی کاهش می‌دهد و حتی شرایطی را فراهم می‌کند تا حجم کافی برای استفاده از سیستم نیز وجود داشته باشد. همچنین می‌توان گفت که امروزه سازندگان و مهندسین داده نیز دیگر در تصمیمات بلند مدت فن‌آوری قفل نشده‌اند، هرچند که در محقق شدن بستر تحلیلی نقشی موثر ایفا می‌کند. اما تاکنون به این مسئله فکر کرده‌اید که اگر مدیران تمایل به مدیریت هیچ سیستمی نداشته باشند چه اتفاقی رخ می‌دهد؟ باید بدانید که آمازون آتنا گزینه‌ای کاملاً بدون سرور را ارائه می‌دهد که با در اختیار داشتن زمان چرخش صفر و به روزرسانی‌های شفاف، مراکز داده می توانند به سادگی یک سؤال SQL بنویسند و موتور Presto را سریعاً به اجرا درآورند.
با هر تحولی می‌توان دانست که موفقیت‌ها چگونه اندازه‌گیری می‌شوند و هدف نهایی چیست. باید بدانید تمرکز بر روی سرعت تیم‌های توسعه‌دهنده معیار بزرگی برای موفقیت در فضای ابری محسوب می‌شود و می‌تواند در زمان تبدیل شدن به یک شریک تجاری در تصمیم‌گیری‌های شما نقشی موثر داشته باشد و در تکمیل AWS نیز عملکرد خوبی از خود نشان دهد.
