موضوعی که در چند سال گذشته در اکثر سمینارها و همایش‌ها در موردش صحبت میشه، مسئله‌ی تحول دیجیتاله!صحبت‌هایی مثل این‌که اگر شرکتی می‌خواد موفق بشه، باید کارهاشو با استفاده از نرم‌افزارها انجام بده و هوشمند بشه؛ یا اینکه نرم‌افزارها دارن دنیا رو می‌بلعن و سازمان‌ها باید از برنامه‌های Cloud-Native که بر اساس میکرو سرویس (Microservice)ها ساخته شده، استفاده کنن.

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

  Burr Sutter مدیر شرکت Red Hat در سخنرانی Red Hat Summit 2016، ویدئویی رو در رابطه با چالش‌های توسعه‌دهندگان و تیم‌های عملیاتی منتشر کرد که مورد توجه افراد زیادی در سان‌فرانسیسکو قرار گرفت؛ اگه بخواین می‌تونین از طریق این لینک بهش دسترسی داشته باشین.

ما هم بر اساس همین ویدئو، در ادامه‌ی این پست می‌خوایم سرویس‌های Cloud-Native رو به همراه میکرو سرویس‌ها و یه سری مفاهیم دیگه، به دو زبان ساده و فنی توضیح بدیم.

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

توضیحات اولیه

فرض کنین، می‌خواین اپلیکیشن جدیدی با ویژگی‌های زیر داشته باشین. موارد زیر هم به عنوان اطلاعات اولیه به تیم توسعه داده شده و قراره برنامه بر اساس اون‌ها ساخته بشه:

• برنامه باید از طریق مرورگر و یا برنامه‌ی موبایلی قابل استفاده باشه و کاربر‌ها بتونن با هر دستگاهی ازش استفاده کنن.
• برنامه باید با توجه به تعاملات به صورت لحظه‌ای به‌روزرسانی بشه و تجربه‌ی کاربری خوبی رو ایجاد کنه.
• رفتار و تعاملات مشتری‌ها باید ذخیره بشه و مورد بررسی قرار بگیره تا بشه برای هر کاربر با توجه به نوع تعامل و خواسته‌هاش تجربه‌ی منحصر‌به‌فردی به وجود آورد. علاوه بر این می‌خوایم بدونیم مشتری‌ها بیش‌تر چه کارهایی انجام دادن و به چه چیزایی علاقه‌مند بودن و چطوری با برنامه‌ی ما ارتباط برقرار کردن.
• تیم فنی و بیزینسی باید از اطلاعاتی که از سمت کاربران رسیده با‌خبر باشن، به این اطلاعات میگن تجربه‌ی دیجیتال، این موضوع نشون می‌ده این دو تیم از زمان ایده‌پردازی تا انتهای پیاده‌سازی پروژه باید در کنار همدیگه کار کنن. 
• برنامه باید برای اضافه کردن ویژگی‌های جدید در هر لحظه آماده باشه و فورا به‌روز‌رسانی بشه. دیگه دوره‌ی این گذشته که هر ۱۲ یا ۱۸ ماه برنامه بررسی و آپدیت بشه! لازمه که با توجه به خواسته‌ی مشتری، برنامه در سریع‌ترین زمان ممکن با خواسته‌هاش تطابق پیدا کنه.

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

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

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

مرحله‌ی اول:‌ چشم‌انداز توسعه‌دهنده

اول از همه باید به محصول از دید یک توسعه‌دهنده نگاه کرد.

توضیح به مدیرعامل:
Developerها یا توسعه‌دهنده‌ها افرادی هستند که چهره‌ی دیجیتالی کسب‌وکار شما رو می‌سازن و نیازمندی‌های کسب‌وکارتون رو تبدیل به ویژگی‌های فنی می‌کنن. اون‌ها می‌تونن بر اساس تقاضای بازار خیلی سریع نمونه‌هایی از برنامه رو بسازن و در صورت نیاز اون رو تغییر بدن. برای انجام این کار اون‌ها لازم دارن که از برنامه و هدف سازمان آگاه باشن تا بتونن بر اساس اون برنامه رو پیاده‌سازی کنن و توسعه بدن.

دمو:
خب در مرحله‌ی اول، باید به برنامه با نگاه یک توسعه‌دهنده نرم‌افزار نگاه کرد. توی این مثال، توسعه‌دهنده‌ها قراره برنامه رو با زبان جاوا روی لپ‌تاپ خودشون پیاده‌سازی کنن. برای این کار اونا روی لپ‌تاپشون یه سری ابزارهایی دارن که بهش میگن (IDE (Integrated Development Environment.

این ابزار‌ها بهشون کمک می‌کنه بتونن راحت‌تر کارهای پیاده‌سازی و توسعه‌ی برنامه رو انجام بدن. بعضی از این ابزارها روی لپتاپ‌شون نصبه و بعضی‌هاش هم به صورت ابری در اختیارشون قرار می‌گیره. 

وقتی توسعه‌دهنده اطمینان پیدا کرد، هر چیزی که برای تولید محصول به اون نیاز داره در اختیارش قرار داره، می‌تونه نوشتن یا به‌روزرسانی کردن برنامه رو شروع کنه. هر زمانی‌که ساختن قسمتی از برنامه تموم بشه و یا در قسمتی از برنامه تغییری به‌وجود بیاد، می‌تونه اون رو بده به سیستم CI .CI یا Continuous Integration قسمت‌های مختلف برنامه رو با هم ادغام و یکپارچه می‌کنه.

این‌جا لازمه چندتا اصطلاح رو معرفی کنیم:

برنامه‌ی ابری: 
به زبان خیلی ساده یعنی اون برنامه روی لپتاپ‌ نصب نیست؛ ولی توسعه‌دهنده‌ها از طریق اتصال به اینترنت می‌تونن از اون برنامه استفاده کنن.

IDE (محیط توسعه یکپارچه): 
ابزارهای محلی که رو لپتاپ توسعه‌دهنده و یا روی سرورهای ابری وجود داره و به توسعه‌دهنده برای ساختن برنامه کمک می‌کنه.

Stacks:
مجموعه‌ای از نرم‌افزارها، زبان‌های برنامه‌نویسی و فریم‌ورک‌ها که توسعه‌دهنده از اون‌ها برای نوشتن و توسعه‌ی برنامه استفاده میکنه.

میکرو سرویس: 
میکرو سرویس‌‌ها قسمت‌های کوچیکی از کل برنامه هستن که کاری خاصی رو در راستای هدف برنامه انجام میدن.

پوش کردن در گیت:
این‌که برنامه رو روی مخازن یا همون ریپازیتوری‌های گیت یا گیت‌هاب به روز کنیم. اینطوری آخرین تغییرات برنامه رو ذخیره کردیم و می‌تونیم اون رو تست کنیم و با بقیه بخش‌ها پکپارچه‌سازی کنیم. گیت تمام تغییراتی که در برنامه به وجود بیاد رو ردیابی (Track) می‌کنه.

یکپارچه‌سازی مستمر یا “Continuous Integration) ”CI):
مجموعه‌ای از تست‌های خودکار که وقتی قسمتی از برنامه به‌روز بشه و یا تغییری در اون به‌وجود بیاد، تست‌هایی رو انجام میده تا مطمئن بشه، برنامه داره به درستی و در راستای هدف اصلیش کار می‌کنه.

 مرحله‌ی دوم: عبور از پایپ‌لاین

خب در بخش قبل گفتیم یه وقتایی توسعه‌دهنده تغییری در برنامه ایجاد می‌کنه که نیاز هست مورد آزمایش قرار بگیره و با سایر قسمت‌های برنامه ادغام و یکپارچه بشه؛ در واقع این تغییر یا به‌روزرسانی از پایپ‌لاین (Pipeline) عبور می‌کنه تا در نهایت به تولید و انتشار ختم بشه.

حالا ببینیم پایپ‌لاین چیه؟ 

توضیح برای مدیرعامل: 
پایپ لاین همون زنجیره‌ی تامین مورد‌نیاز برای تحول دیجیتالی محصول شماست. وظیفش اینه که مطمئن بشه محصول با کیفیتی مناسب و از راهی درست به مشتری برسه؛ در حالی‌که هزینه‌ی صرف‌شده برای اون هم مقدار معقولی باشه.

دمو: 
در این مرحله، هدف اینه که تک‌تک بیت‌های برنامه رو مورد بررسی قرار بدیم. یعنی قبل از این‌که برنامه تولید بشه و به دست مشتری برسه، اون رو مورد آزمایش قرار بدیم و دوباره بررسی و پکپارچه‌اش کنیم. در واقع پایپ‌لاین جریان مداوم به‌روزرسانی‌های توسعه‌دهنده‌هاست که ممکنه بارها و بارها در روز اتفاق بیفته.

خب حالا یه سری اصطلاحاتی که در مراحل پایپ‌لاین اتفاق میفته رو توضیح بدیم و بررسی کنیم:

یکپارچه‌سازی و استقرار مداوم یا Continuous Integration / Continuous Deployment) CI/CD):
مجموعه‌ای از ابزارهایی که به‌روزرسانی‌ها رو از توسعه‌دهنده‌ها می‌گیره و اون رو به صورت خودکار در کنار سایر قسمت‌های برنامه مورد تست و آزمایش قرار می‌ده. بعد از این که مطمئن شد به‌روز‌رسانی داره درست کار می‌کنه و کل برنامه هم با این به روزرسانی کارشون خراب نمیشه، برنامه رو با به روزرسانی‌های جدیدش کنار هم می‌ذاره و پکپارچه‌سازی می‌کنه و نرم‌افزار معتبر و نهایی رو تولید ‌میکنه.

تضمین کیفیت یا Quality Assurance) QA):
قسمتی از پایپ‌لاین هست که مسئولیت تست و آزمایش کیفیت برنامه رو به عهده داره. این خیلی مهمه که قبل از این که برنامه تولید بشه و در اختیار مشتری قرار بگیره، خطاها و ایراداتش پیدا و برطرف بشه.

نمایش (صحنه‌سازی) یا Staging: 
یکی از مراحل پایپ‌لاینه که بین مرحله‌ی تضمین کیفیت و تولید قرار داره. در این مرحله، کار برنامه رو با هدف بررسی میزان قدرت و تواناییش در یک محیط واقعی تقلید یا Emulate می‌کنن. Emulate یه مرحله‌ی جدی‌تر و واقعی‌تر از Simulate یا همون شبیه‌سازیه.
شبیه‌سازی رو می‌شه تشبیه کرد به تمرینای عادی و معمولی که بازیگرای تئاتر انجام میدن؛ ولی تقلید یا Emulate مثل وقتیه که بازیگرای تئاتر با لباس‌هایی که میخوان واقعا روی صحنه اون‌ها رو بپوشن یک بار نمایششون رو به طور کامل و بی‌وقفه تمرین و اجرا کنن.

توسعه‌ی آبی/سبز (Blue/Green Deployment):
حتی بعد از تست برنامه توسط تضمین کیفیت، وقتی که یک به‌روز‌رسانی انجام میشه، باید مطمئن بشیم که این نسخه‌ی جدید درست کار می‌کنه و بعد نسخه قدیمی رو حذف کنیم. Blue/Green روشی برای تأیید صحت کارایی به‌روزرسانی برنامه قبل از حذف نسخه قدیمیه. این باعث میشه اگر در نسخه‌ی جدید مشکلی وجود داشته باشه، بتونیم به راحتی به نسخه‌ی قدیمی برگردیم.

مرحله‌ی سوم: تعامل کاربر و برنامه

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

توضیح این مرحله برای مدیر عامل: 
تجربه‌ی کاربر و اپلیکیشن نمای بیرونی محصول و کسب‌وکاره، درست مثل یک فروشگاه. این‌که مشتری چه‌جوری با محصول شما ارتباط برقرار می‌کنه، خیلی مهمه. محصول شما باید یک تجربه عالی رو به مشتری بده و علاوه بر این بتونه تمامی خدماتتون رو هم به اون نمایش بده.

دمو: 
خب تا اینجا، برنامه نوشته شده و مورد تست و بررسی هم قرار گرفته و در نتیجه برای این‌که تولید بشه آماده است. با توسعه‌ی محصول روی یک کانتینر می‌تونین، امکان تعامل واقعی مشتری با برنامه‌تون رو فراهم کنین. برنامه رو بر روی یک کانتینر ابری مثل سکو توسعه بدین و تعامل واقعی مشتری با برنامه‌تون رو در لحظه مشاهده و بررسی کنین.

تجربه‌ی مشتری می‌تونه شامل چندین میکرو سرویس مختلف از قبیل احراز هویت و ورود، تایید اعتبار، پروفایل کاربر، سطح دسترسی، استفاده از داشبورد و… باشه. که هر کدوم از این‌ها می‌تونن بدون اینکه اختلالی در کار کل برنامه ایجاد کنن، در صورت نیاز به‌روزرسانی بشن.

مرحله‌ی چهارم: عملیات پلتفرم

همه‌ی مراحلی که تا الان گفتیم در صورتی به خوبی اجرا میشن و نتیجه‌ی خوبی دارن که زیرساخت‌های مورد نیاز برای اجرای درستشون وجود داشته باشه، این مرحله وظیفه‌ش مدیریت زیرساخت‌هاست.

توضیح برای مدیرعامل: 
همون‌طور که گفتیم وظیفه‌ی این مرحله، مدیریت زیرساخت‌هاست. در واقع شما باید همواره بررسی کنین که سیستم‌ها به درستی در حال کار کردن باشن و با توجه به هزینه‌ای که برای هر بخش شده با بیشترین کارایی و کیفیت، کارها در حال انجام باشن. 

مهمتر از همه‌، این مرحله وظیفه‌ی حفظ امنیت رو هم بر عهده داره. یعنی اطمینان از این که داده‌های ارزشمند شما در برابر تهدیدهای سایبری قرار نداشته باشه و در امنیت کامل باشن. 

همه‌ی این کارها برای اینه که مطمئن باشین، مشتری‌ها خدمات مورد نظرشون رو به طور مستمر و با کیفیت بالا دریافت می‌کنن.

دمو: 
تیم عملیاتی پلتفرم (تیم شبکه/ذخیره‌سازی/سرور و زیرساخت) قبل از این‌که هر اپلیکیشنی شروع به کار بکنه، باید تمام سیستم‌های مورد نیاز برای اون‌ها رو تنظیم بکنه. در این بخش، اون‌ها چندین عنصر مهم عملیاتی رو مشخص می‌کنن:

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

مرحله‌ی پنجم: تحلیل بازار

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

توضیحی برای مدیرعامل:
سیستم تحلیل بازار به شما این امکان رو میده که بتونین بازار و تقاضاها رو در لحظه بررسی کنین. وقتی که نسبت به بازار دید خوبی داشته باشین، می‌تونین از خودتون بپرسین که "خب برای بهبود محصولم چه کارهایی رو باید انجام بدم؟"

اگر چیزی رو نتونین اندازه‌گیری کنین، نمی‌تونین اون رو مدیریت کنین.

W. Edwards Demming

دمو:

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

سیستم تحلیل بازار می‌تونه مدل داده‌های برنامه رو ببینه و در صورت نیاز روابط و مدل‌سازی اون‌ها رو تغییر بده. اعضای تیم تجاری می‌تونن قوانین تجارت رو تغییر بدن و اون رو به تیم توسعه منتقل کنن تا در مدل برنامه با توجه به نیاز بازار تغییراتی رو ایجاد کنن.

مرحله‌ی ششم: تست A/B بازار 

مهم نیست که تیم‌های بازاریابی، مدیریت محصول یا تجزیه‌وتحلیل کسب‌وکار شما چه‌قدر توانایی پیش‌بینی بازار رو دارن؛ چون در واقع نمی‌تونن مستقیما و به‌طور کامل بازار رو بشناسن و احتیاج هست کارهای عملی‌تری رو برای تحلیل درست بازار انجام بدن.

توضیحی برای مدیرعامل:
تست A/B به تیم‌های شما این امکان رو می‌ده تا با سرعت بالا ایده‌های جدید رو در بازار مورد آزمایش قرار بدن و در صورت لزوم تنظیمات و تغییراتی رو اعمال کنن تا محصول یا خدمت ارائه‌شده با نیازها و سلیقه‌ی بازار هماهنگ بشه. 

دمو:
در بخش اول این پست گفتیم که چه‌جوری به‌روزرسانی‌های برنامه می‌تونه از طریق پایپ‌لاین عبور بکنه و بدون ایجاد هیچ‌گونه خطایی در محیط تجربه‌ی کاربری مستقر بشه.

برای جمع‌آوری بازخورد درباره‌ی یک تغییر، ویژگی یا سرویس جدید میشه یه سری  آزمایش‌ یا تست A/B بازار رو روی مجموعه‌ای از کاربران انجام داد.

در این تست، دو نوع پیاده‌سازی مختلف از یک ویژگی یا سرویس رو انجام می‌دن: پیاده سازی A و پیاده‌سازی B. بعد این دو نوع پیاده‌سازی رو به دو گروه از کاربرها ارائه می‌دن، با توجه به اینکه بازخورد کاربرهای کدوم گروه بهتر بوده، تصمیم می‌گیرن که کدوم پیاده‌سازی، پیاده‌سازی نهایی محصول باشه.

مرحله‌هفتم: پیاده‌سازی رویکرد چابک یا Agile

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

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

توضیحی برای مدیر عامل:
به همون اندازه که تیم‌ها برای رسیدن به موفقیت برنامه‌ریزی می‌کنن و سعی می‌کنن کارها به درستی انجام بشه، گاهی اوقات در روند پیشرفت کار مشکلاتی به وجود میاد و لازمه که توانایی لازم برای رفع سریع این مشکلات رو داشته باشن تا عملکردهای فنی و تجاری با مشکلی رو‌به‌رو نشه. 

هر آسیب و خرابی هزینه‌بر و مشکل‌سازه. رویکرد Agile تضمین می‌کنه اشتباهات و مشکلات پیش آمده در معرض دید مشتریان قرار نمی‌گیرن و در سریع‌ترین زمان ممکن کنترل می‌شن.  

دمو: 
همون‌طور که توسعه‌دهنده‌های نرم‌افزار در تلاش هستن با سرعت زیادی به کارشون ادامه بدن تا بتونن تقاضای تجاری رو برآورده کنن، تیم‌های زیرساخت، تجاری و عملیاتی هم باید بتونن سریع‌تر عمل کنن و با توسعه‌دهنده‌ها هماهنگ باشن. 

همون‌طور که توسعه‌دهنده‌های نرم‌افزار در تلاش هستن با سرعت زیادی به کارشون ادامه بدن تا بتونن تقاضای تجاری رو برآورده کنن، تیم‌های زیرساخت، تجاری و عملیاتی هم باید بتونن سریع‌تر عمل کنن و با توسعه‌دهنده‌ها هماهنگ باشن. 

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

خلاصه اینکه...

برای دموی یک برنامه در هر مرحله از تولید محصول، ابزارهای مختلفی مورد نیازه. از نظر فنی می‌تونیم ابزارها رو اینجوری خلاصه کنیم و برای هر‌کدوم یک مثال بیاریم:

• کانتینرهایی مثل (Docker)
• پلتفرم‌های کانتینری مثل (Openshift/Kubernetes)  
• میان افزار مثل (JBoss)
• زبان‌های توسعه و برنامه‌نویسی مثل (Java, nodeJS, .NET)
• میکرو سرویس‌ها و برنامه‌های ابری
• پایگاه‌داده‌هایی مثل (SQL databases)
• یکپارچه‌سازی مستمر (Jenkins)
• خودکارسازی (Ansible)
• و… 

امیدواریم با خوندن این پست و شناختن و استفاده کردن از این ابزارهای جدید بتونین خیلی سریع‌تر و با انعطاف و کیفیت بالاتری برنامه‌ها و محصولاتتون رو تولید کنین و با ایجاد ارتباطی نزدیک بین تیم تجاری و تیم توسعه بتونین یک تجربه‌ی کاربری عالی برای کاربران نهایی‌تون به وجود بیارین.