فرض کنید یک روز که مشغول کارهای خودتون هستید، یکی از دوستانتون باهاتون تماس می‌گیره و بهتون پیشنهاد یک شغل رو میده. شغلی با عنوان معمار نرم‌افزار در یک شرکت استارتاپی با بودجه خیلی زیاد.
شما این شغل رو قبول می‌کنید و پس از چند هفته توی یک جلسه طراحی قرار می‌شود یک سایت eCommerce طراحی کنید که از نظر نرم افزار توانایی رقابت با بقیه رقبای تراز اول رو داشته باشه.
شما چجوری می‌سازید؟
اگر مثل متدهای ۱۵ سال پیش بخواهید بسازید، شبیه به شکل زیر خواهید ساخت.
یک برنامه که یک هسته بسیار بزرگ نرم‌افزاری شامل احراز هویت، دسته بندی محصولات، ثبت سفارش،سبد خرید و خیلی امکانات دیگه رو داخل خودش جا داده و با یک دیتابیس بزرگ relational برای ذخیره دیتا ارتباط برقرار می‌کنه.
تبریک! شما یک برنامه مونولیتیک ساختید.
همه چیز اینطور که می‌گن بد نیست. برنامه های مونولیتیک یک سری مزایای مشخص دارن. اگر بخوایم به چندتا مزیت سرراستش اشاره کنیم:
- بیلد آسان
- تست آسان
- دیپلوی آسان
- نگهداری آسان
بسیاری از برنامه‌های موفق امروز به صورت مونولیتیک نوشته شدن. برنامه ساخته می‌شود و توسعه ادامه پیدا می‌کند، بزرگ و بزرگ‌تر می‌شود و قابلیت های بیشتری بهش اضافه می شود.
با این حال شما بعد از مدتی احساس ناراحتی می‌کنید. شما می‌بینید که برنامه از کنترل‌تون خارج شده. با گذشت زمان این حس شدیدتر می شود و در نهایت وارد حالتی می‌شوید که به چرخه ترس معروف است.
- این برنامه به قدری بزرگ شده که کسی قادر به درک کامل‌ش نیست.
- تغییر دادن این برنامه ترسناکه، هر تغییر عوارض جانبی زیادی داره.
- اضافه کردن فیچر جدید یا حل یک باگ خیلی سخت، زمان‌بر و پیاده‌سازی‌ش پرهزینه هست.
- یک تغییر کوچیک نیازمند بیلد و دیپلوی کل برنامه هست.
- یک کامپوننت unstable می‌تونه منجر به کرش کردن کل برنامه بشه.
- دیگه از تکنولوژی‌های جدید یا فریم‌ورک های جدید نمیشه استفاده کرد.
- متدولوژی اجایل روی این برنامه پیاده سازی نمیشه.
- در نهایت مشاوران به شما می‌گویند این برنامه رو باید از اول بنویسید.
راهکار چیه؟
بسیاری از شرکت‌ها برای فرار از این چرخه ترس، شروع به ساخت برنامه‌ها به صورت cloud-native کردن. شکل زیر یک سیستم با استفاده از تکنیک‌ها و متدهای cloud-native رو نشون میده.
ببینید چطور برنامه شکسته شده به سرویس‌های کوچک و کاملا ایزوله. هر سرویس مستقل هست و کدها، دیتاها و وابستگی‌های خودش رو توی یک محیط ایزوله محصور می‌کنه. به‌جای یک دیتابیس بزرگ رابطه‌ای، هر سرویس دیتابیس خودش رو داره که حتی نوع این دیتابیس هم بر اساس نیاز می‌تونه متفاوت باشه. بعضی سرویس‌ها نیاز به دیتابیس‌های SQLبیس دارن و بعضی‌ها می‌تونن از NoSQLها استفاده کنن. تمام ترافیک به وسیله یک API Gateway به سرویس مورد نظر می رسه. اگر یک سرویس کرش کرد فقط همون بخش سیستم از کار میوفته. و از همه مهم‌تر این برنامه خیلی راحت اسکیل میشه و خیلی راحت میشه انتظار availability رو ازش داشت.
پ.ن: این مطلب برداشتی هست از Introduction to cloud-native applications