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

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

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

فرض کنیم برای اینکه 1000 تا کانتینر یا مسافر رو با یک کشتی خیلی خیلی بزرگ جابجا کنیم این کشتی خیلی بزرگ رو بشکنیم به قایق‌های تندروی کوچک، اما تعداد زیاد. شاید از این مثال بشه با مفهوم scalability یا دقیقتر با مفاهیمی همچون Horizontal Scalability یا scale out هم مقایسه کرد. (بعدا توی یک نوشته دیگه راجع به این دو مفهوم در معماری‌های نرم‌افزاری، توضیح خواهم داد) توی این معماری جدید شما میتونی چندتا کار انجام بدی: