در مخالفت با چندابری بودن بهصورت پیشفرض
چندابری یک راهبرد نیست، یک هزینه است. گاهی هزینهای که باید پرداخت، اما نه پیش از آنکه بدانید بابت چه چیزی میپردازید.
تقریباً هر تیمی که با آن کار میکنیم، در جایی از سند معماریاش نوشته است «قفل شدن به یک ارائهدهنده را میپذیریم؟ خیر». و تقریباً هیچکدام هزینهی این جمله را حساب نکردهاند.
هزینهای که دیده نمیشود
چندابری بودن یعنی شما دیگر نمیتوانید از هیچ سرویس مدیریتشدهای استفاده کنید که معادل دقیقش در ابر دیگر وجود ندارد. یعنی صف پیام، پایگاهداده، مدیریت اسرار و مسیریابی همه باید خودتان اجرا کنید. عملاً بهجای دو ابر، یک ابر سوم میسازید و آن را روی دو تای دیگر نگه میدارید.
سه تیم مهندسی که این مسیر را رفتند و ما بعداً کارشان را تحویل گرفتیم، در هر سه مورد یک الگو داشتند:
- زیرساخت مشترک به کمترین وجه اشتراک دو ارائهدهنده تنزل کرده بود.
- استقرار در ابر دوم هر بار «بهزودی» انجام میشد و هرگز آزموده نشده بود.
- تیم برای انتزاعی که خودش نوشته بود، مستندات نداشت.
یک محیط پشتیبان که هرگز ترافیک واقعی ندیده، پشتیبان نیست. یک فرضیه است.
کِی منطقی است
چند حالت واقعی وجود دارد و همهشان دلیل تجاری دارند، نه معماری:
- الزام قانونی برای نگهداری داده در یک حوزهی قضایی خاص.
- مشتری بزرگی که در قرارداد، استقرار در ابر خودش را میخواهد.
- یک بار کاری کاملاً مستقل — مثلاً پردازش دستهای شبانه — که جای دیگری ارزانتر تمام میشود.
توجه کنید که هیچکدام از اینها «اگر ارائهدهنده از کار بیفتد» نیست. قطعی سراسری یک ارائهدهندهی بزرگ، در عمل نادرتر از قطعیهایی است که خودتان با لایهی انتزاع اضافهی خودتان میسازید.
پیشنهاد عملی
بهجای چندابری بودن، «آمادهی مهاجرت» باشید. زیرساخت را با Terraform تعریف کنید، وضعیت را قابل حمل نگه دارید، و برای هر سرویس مدیریتشدهای که استفاده میکنید بنویسید که جایگزینش چیست و مهاجرت چند هفته طول میکشد.
# نه انتزاع، فقط صراحت: کدام منابع قابل حمل نیستند و چرا.
resource "aws_sqs_queue" "ingest" {
name = "ingest"
# exit-plan: rabbitmq via helm, ~2 weeks, see docs/migrations/sqs.md
}این کار چند روز طول میکشد. چندابری واقعی چند فصل. و اگر آن روز واقعاً رسید، شما بهجای یک انتزاع پوسیده، یک برنامهی بهروز دارید.