صنایع پایداری که سالها تحت سلطه رهبران خود جا افتاده بوده اند، درحال مختل شدن توسط صنعت نرم افزار هستند. شرکت هایی مانند Square ، Uber ، Netflix ، Airbnb و Tesla همچنان دارای ارزش بازار خصوصی هستند که به سرعت در حال رشد است. اشتراک این شرکت های نوآور در چیست؟
حرکت به سمت ابر، تحولی طبیعی در تمرکز برروی نرم افزار بوده و معماری برنامه های کاربردی ابر بومی، در مرکز رسیدن به ویژگی های حیاتی این شرکت هاست. منظور از ابر، هر محیط محاسباتی است که در آن می توان منابع محاسباتی ، شبکه ای و ذخیره سازی را بصورت سلف سرویس بر اساس تقاضا تهیه و آزاد نمود. این تعریف شامل زیرساخت‌های ابری عمومی همچون سرویس‌های وب آمازون ، Google Cloud یا Microsoft Azure و زیرساخت‌های ابری خصوصی مانند VMware vSphere یا OpenStack است.
در این مقاله توضیح خواهیم داد که چگونه معماری برنامه های بومی ابر، این ویژگی ها را قادر می‌سازد. سپس چند جنبه اصلی از معماری برنامه های بومی ابر را بررسی خواهیم کرد.
ابتدا انگیزه های رایج در انتقال به معماری کاربردی بومی ابر را بررسی می نماییم.
مشخص گردید که سرعت در بازار برنده می‌شود. مشاغلی که قادر به نوآوری، آزمایش و ارائه سریع راه حل‌های مبتنی بر نرم افزار هستند، از سایر مدل‌های سنتی تحویل رقابت پذیرترند.
در یک شرکت، مدت زمان لازم برای ایجاد محیطهای برنامه جدید و استقرار نسخه های جدید نرم افزار، به طور معمول برحسب روزها ، هفته‌ها یا ماه‌ها اندازه‌گیری می‌شود. این کمبود سرعت، خطری را که می تواند با هر نسخه منتشر شود محدود می‌کند چراکه هزینه ساخت و رفع اشتباه نیز در همان مقیاس زمانی اندازه‌گیری می‌شود.
شرکتهای اینترنتی اغلب به دلیل عملکرد خود صدها بار در روز مستقرسازی را انجام می دهند. چرا استقرار دائمی (Continuous Deployment) مهم است؟ اگر بتوان صدها بار در روز نرم افزار را مستقر کرد، تقریبا می توان بلافاصله از خطاها خلاص شد. اگر بتوانید تقریباً بلافاصله از اشتباهات خلاص شوید، می توانید ریسک بیشتری کنید. اگر می توانید بیشتر ریسک کنید، می توانید آزمایشات بیشتر و حساستری را امتحان کنید که نتایج این کار می تواند به مزیت رقابتی بعدی شما تبدیل شود!
خاصیت کشسانی و سلف سرویس زیرساخت های ابری به طور طبیعی خود را به سمت این روش سوق می دهد. تهیه یک محیط برنامه جدید با برقراری ارتباط با API سرویس ابری، سریعتر از یک فرایند دستی مبتنی بر فرم است. افزودن سلف سرویس و هوک‌ها به محیط ساخت دائمی تیم‌ها، سرعت را بیشتر افزایش می‌دهد.
خیلی سریع رفتن کافی نیست. اگر سوار اتومبیل خود شوید و پدال را فشار دهید، در نهایت تصادفی هزینه بر یا مرگبار را خواهید داشت. صنایع حمل و نقل همچون هواپیما و قطار سریع السیر برای سرعت و ایمنی ساخته شده‌اند. معماری برنامه های بومی ابر، نیاز به حرکت سریع را با نیازهای پایداری، دسترس‌پذیری و دوام برقرار می‌سازد. معماری برنامه های کاربردی بومی ابر، ما را قادر می سازد تا به سرعت از اشتباهات خلاص شویم.
معماری های ما باید ابزار لازم برای دیدن شکست هنگام وقوع را در اختیار قرار دهند. ما به توانایی اندازه گیری پیشرفت، ایجاد نمایه برای "آنچه طبیعی است" ، تشخیص انحراف از هنجار (از جمله مقادیر مطلق و میزان تغییر) و شناسایی اجزای سازنده در این انحرافات نیاز داریم. معیارهای غنی از ویژگی ها، چارچوب‌ها، ابزارهای نظارت، هشدار و تجسم داده ها در قلب تمام معماری های برنامه های بومی ابر قرار دارند.
برای محدود کردن خطر همراه با خرابی، باید دامنه اجزا (components) یا ویژگی هایی را که می توانند تحت تأثیر خرابی قرار گیرند، محدود کنیم. اگر هربار که موتور توصیه‌ها از کار می‌افتد، کسی نتواند از سایت Amazon.com محصولی را خریداری کند، این فاجعه بار خواهد بود. معماری‌های برنامه یکپارچه، اغلب دارای این نوع حالت خرابی هستند. معماری برنامه بومی ابر معمولا از میکرو سرویس‌ها استفاده می‌کنند.
تجزیه یک سیستم به اجزای مستقر قابل استفاده مجدد کافی نیست. ما همچنین باید از بروز نقص در آنها در بسیاری از وابستگی‌های تحویل آنها جلوگیری کنیم. مایک نیگارد در کتاب Release It چندین الگوی تحمل خطا را توصیف کرد. معروفترین آنها قطع کننده مدار است. قطع کننده مدار، نرم افزاری کاملاً مشابه قطع کننده مدار الکتریکی است: با باز کردن مدار بین قطعه ای که از آن محافظت می کند و باقیمانده سیستم خراب، از خرابی آبشاری جلوگیری می‌شود. همچنین در حالتیکه مدار باز است، می تواند یک رفتار برگشت پذیر مانند یک مجموعه توصیه های پیش فرض محصول را ارائه دهد.
به کمک قابلیت‌های مشاهده، جداسازی خطا و تحمل خطا، ما ابزار لازم را برای شناسایی خرابی، بهبود خرابی و ارائه سطح معقولی از خدمات به مشتریان خود داریم درحالیکه درگیر فرآیند شناسایی و بازیابی هستیم. شناسایی برخی از خرابی ها آسان است: آنها هر بار که رخ می دهند همان الگوی قابل تشخیص را دارند. از یک وارسی سرویس استفاده می کنیم، که معمولاً یک جواب دودویی دارد: سالم یا ناسالم، بالا یا پایین. هر بار که با چنین شکست‌هایی روبرو شویم، بارها و بارها اقدام مشابهی انجام خواهیم داد. در صورت عدم موفقیت در بررسی سلامت، ما به راحتی سرویس موردنظر را مجدداً راه اندازی کرده و یا مجدداً مستقر می‌کنیم. معماری های کاربردی بومی ابر در این شرایط منتظر مداخله دستی نیستند. در عوض، آنها از شناسایی و بازیابی خودکار استفاده می‌کنند.
با افزایش تقاضا، ما باید ظرفیت خود را برای ارائه خدمات به این تقاضا مقیاس‌پذیر کنیم. در گذشته با مقیاس‌گذاری عمودی تقاضای بیشتری را برطرف می‌کردیم: سرورهای بزرگتری خریداری می‌کردیم. سرانجام اهداف خود را به دست آوردیم، اما به آرامی و با هزینه زیاد. این امر منجر به برنامه‌ریزی ظرفیت براساس پیش بینی اوجِ استفاده شد. ما پرسیدیم "بیشترین قدرت محاسباتی این سرویس چقدر است؟" و سپس سخت افزار کافی را برای پاسخگویی به آن خریداری کردیم. بسیاری از اوقات ما این اشتباه را پیدا کرده ایم و هنوز هم در طی رویدادهایی مانند جمعه سیاه ظرفیت موجود را از بین می بریم. اما غالباً با ده ها یا صدها سرور با CPU هایی که عملاً بیکار هستند روبرو می شویم که منجر به معیارهای ضعف استفاده می‌گردد. شرکت های نوآور با دو حرکت پیشگامانه با این مشکل کنار آمده اند:
با دردسترس قرار گرفتن زیرساخت های ابری عمومی مانند سرویس‌های وب آمازون، این دو حرکت باهم همگرا شدند. تلاش مجازی‌سازی به ارائه دهنده ابر واگذار شد و مصرف‌کننده در مقیاس افقی برنامه‌های خود در تعداد زیادی از موارد، برروی سرور ابری تمرکز کرد. اخیراً تغییر دیگری با انتقال از سرورهای مجازی به کانتینرها به عنوان واحد استقرار برنامه اتفاق افتاده است.
این تغییر به سمت ابر، در را برای نوآوری بیشتر باز کرد چراکه شرکت‌ها برای استقرار نرم افزارهای خود دیگر به سرمایه های اولیه نیاز ندارند. تعمیر و نگهداری نیز به سرمایه گذاری کمتری نیاز داشته و تهیه از طریق API نه تنها سرعت استقرار اولیه را بهبود بخشید ، بلکه سرعت تحقق تقاضا را نیز به حداکثر رساند.متأسفانه همه این مزایا با هزینه همراه است. برنامه ها برای مقیاس افقی و نه عمودی باید متفاوت طراحی شوند. خاصیت ارتجاعی ابر، زودگذر بودن را می‌طلبد. نه تنها باید بتوانیم نمونه‌های برنامه جدید را به سرعت ایجاد کنیم بلکه باید بتوانیم آنها را به سرعت و با خیال راحت دفع کنیم. روشهای سنتی مانند جلسات خوشه ای و سیستم فایلهای اشتراکی که در معماری‌های عمودی عمدتا به کار رفته اند، مقیاس چندانی ندارند.
در ژانویه 2014، دستگاه های تلفن همراه 55 درصد میزان استفاده از اینترنت را در ایالات متحده تشکیل دادند. دیگر، روزهای اجرای برنامه‌ها برای کاربرانی که روی پایانه‌های رایانه‌ای متصل به میز کار می‌کنند، گذشته است. درعوض باید تصور کنیم که کاربران ما با اَبَررایانه‌های چندهسته ای در جیب خود، در حال قدم زدن هستند. این امر، پیامدهای جدی برای معماری برنامه های ما دارد چراکه به طور تصاعدی کاربران بیشتری می‌توانند در هر زمان و هر مکان با سیستم های ما ارتباط برقرار کنند.
از مشاهده موجودی حساب چک به عنوان مثال استفاده می کنیم. این کار قبلاً با برقراری تماس با مرکز تماس بانک، رفتن به محل خودپرداز یا پرسش از فروشنده در یکی از شعب بانک انجام می‌شد. این مدل‌های تعامل مشتری، محدودیت های قابل توجهی در تقاضا ایجاد می‌کنند که می‌تواند هر زمان برای سیستم های نرم افزاری اساسی بانک اعمال شود.
حرکت به سمت خدمات بانکی آنلاین باعث افزایش تقاضا شد اما هنوز مدل تعاملی را اساساً تغییر نداد. برای تعامل با سیستم هنوز مجبور بودید از نظر فیزیکی در یک ترمینال رایانه ای باشید که هنوز تقاضا را به میزان قابل توجهی محدود می‌کند. اکنون هزاران مشتری می توانند در هر زمان و هر مکان با سیستم های بانک تعامل داشته باشند. یک مدیر بانکی گفته است که در روز پرداخت ، مشتریان هر چند دقیقه چند بار مانده های خود را بررسی می کنند. سیستم های بانکی قدیمی به سادگی برای پاسخگویی به این نوع تقاضا طراحی نشده اند، درحالیکه معماری برنامه های بومی ابر چنین است.
برنامه‌های تلفن همراه اغلب مجبورند با چندین سیستم قدیمی و همچنین چندین میکروسرویس در یک معماری برنامه ابری تعامل داشته باشند. این سرویس ها را نمی‌توان برای تأمین نیازهای منحصر به فرد هر یک از سیستم عامل‌های مختلف تلفن همراهِ مورد استفاده مشتریان طراحی کرد. مجبور کردن بار ادغام این سرویس های متنوع برروی توسعه دهنده تلفن همراه، تأخیر و ترافیک شبکه را افزایش می‌دهد که این امر منجر به کندی زمان پاسخ‌دهی و مصرف زیاد باتری شده و در نهایت کاربران منجر به حذف برنامه شما می‌شوند! معماری‌های برنامه‌های بومی ابری از مفهوم توسعه همراه اول از طریق الگوهای طراحی مانند API Gateway پشتیبانی می‌کنند که بار تجمیع خدمات را به سمت سرور منتقل می‌کند.
اکنون چند ویژگی اصلی معماری برنامه های بومی ابر را بررسی خواهیم کرد. همچنین خواهیم دید که چگونه این ویژگی‌ها مواردی را که قبلاً بحث کردیم، برطرف می‌سازد.
برنامه دوازده عاملی مجموعه‌ای از الگوهای معماری کاربردهای بومی ابر است که در ابتدا توسط مهندسین Heroku توسعه یافته است. این الگوها، توصیف می‌کنند که "چرا" معماری برنامه های بومی ابر آنها را بهینه می‌کند. آنها بر سرعت، ایمنی و مقیاس‌پذیری با تکیه بر پیکربندی اعلانی و فرایندهای بدون‌حالت که به صورت افقی مقیاس می‌شوند و یک اتصال کلی shell به محیط استقرار، تمرکز دارند. سیستم عامل‌های برنامه‌های ابری همچونCloud Foundry ، Heroku و Amazon Elastic Beanstalk برای استقرار برنامه های دوازده عاملی بهینه شده‌اند.
در زمینه دوازده عاملی، برنامه به یک واحد استقرارپذیر اشاره دارد. یک برنامه دوازده عاملی را می توان به روشهای زیر توصیف نمود:
میکروسرویس‌ها تجزیه سیستم‌های تجاری یکپارچه به خدمات مستقر مستقلی را نشان می دهند که "یک کار را به خوبی انجام می دهند". این یک کار، معمولاً نشان دهنده یک توانایی تجاری یا کوچکترین واحد خدمات "اتمی" است که ارزش تجاری را ارائه می‌دهد. معماری‌های میکروسرویس به چندین روش؛ سرعت، ایمنی و مقیاس‌پذیری را فعال سازد:
تیم‌هایی که در حال توسعه معماری برنامه‌های بومی ابری هستند، معمولاً مسئول استقرار و فعالیت‌های مستمر آنها هستند. پذیرندگان موفق برنامه‌های بومی ابری، تیم‌ها را با پلتفرم‌های سِلف سرویس توانمند کرده‌اند.
همانطوریکه تیمهای توانایی تجاری متعددی را برای ساخت میکروسرویس‌ها در زمینههای مختلف ایجاد می‌کنیم، یک تیم توانایی جداگانه‌ای نیز ایجاد می‌کنیم که مسئول ایجاد بستری برای استقرار و بهره‌برداری از این میکروسرویس‌ها باشد.
بهترین این سیستم عامل‌ها لایه انتزاعی اولیه را برای مصرف کنندگان خود افزایش می‌دهند. با استفاده از زیرساخت به عنوان سرویس (IAAS) از API خواستیم تا موارد سرور مجازی، شبکه‌ها و فضای ذخیره سازی ایجاد نماید تا اَشکال مختلف مدیریت پیکربندی و اتوماسیون را برای فعال کردن برنامه ها و سرویس های پشتیبانی خود اعمال کنیم. اکنون سیستم عامل‌هایی در حال ظهور هستند که به ما امکان می‌دهند درباره برنامه‌ها و خدمات پشتیبانی فکر کنیم.
کد برنامه به صورت آرتیفکتِ از پیش ساخته شده (ممکن است آنهایی که به عنوان بخشی از خط لوله تحویل دائمی تولید می‌شوند) یا کد منبع خام، در یک ریپازیتوری ریموت قرار می‌گیرد. سپس این پلتفرم آرتیفکت برنامه را ایجاد می‌کند. سپس یک محیط برنامه را ایجاد نموده، برنامه را مستقر ساخته و فرایندهای لازم را شروع می‌کند. تیم‌ها مجبور نیستند درمورد اینکه کدشان در حال اجرا است یا چگونه به آنجا رسیده است، فکر کنند چراکه این پلتفرم ما را از این نگرانی‌ها رها می‌سازد. این پلتفرم‌ها اغلب مجموعه وسیعی از قابلیت‌های عملیاتی اضافی را ارائه می‌دهند:
تنها حالت تعامل بین سرویس‌ها در معماری برنامه بومی ابر از طریق API های منتشر شده و نسخه‌سازی شده است. این API ها معمولاً به سبک HTTP REST با سریال سازی JSON هستند اما می‌توانند از پروتکل‌های دیگر و قالب‌های سریال‌سازی نیز استفاده کنند.
تیم‌ها می‌توانند بدون نیاز به همگام‌سازی با تیمهای دیگر، هر زمان که نیاز باشد، قابلیت‌های جدیدی را به کار گیرند، مشروط بر اینکه هیچ قرارداد API موجود را بر هم نزنند. مدل اصلی تعامل برای بستر زیرساختِ سلف سرویس نیز همانند سرویس‌های تجاری، از طریق API است. به جای ارسال تیکت برای تهیه، مقیاس‌گذاری و حفظ زیرساخت‌های برنامه، همان درخواست‌ها به API ارسال می‌شود که به طور خودکار درخواست ها را سرویس‌دهی می‌کند.
