Terraform یا Pulumi؛ زبان آشنا هزینهٔ مهاجرت state را حذف نمی‌کند

اگر زیرساخت موجود با Terraform اداره می‌شود، آشنایی تیم با TypeScript یا Python به‌تنهایی دلیل کافی برای انتقال آن به Pulumi نیست. زبان آشنا ممکن است نگهداری کد را آسان‌تر کند، اما منابع زنده همچنان باید مالک مشخصی داشته باشند. توضیح HashiCorp دربارهٔ state نشان می‌دهد که Terraform با آن منابع واقعی را به پیکربندی پیوند می‌دهد و تغییرات بعدی را تعیین می‌کند؛ برای همکاری تیمی نیز نگهداری state در backend راه‌دور را توصیه می‌کند.

پس انتخاب میان این دو ابزار از مقایسهٔ HCL با یک زبان برنامه‌نویسی فراتر می‌رود. باید دید چه کسی خروجی تغییر را بازبینی می‌کند، provider موردنیاز دقیقاً چه قابلیتی دارد، plan یا preview چقدر در چرخهٔ کار طول می‌کشد و پس از انتقال، کدام ابزار اجازهٔ تغییر هر منبع را خواهد داشت. اگر پاسخ پرسش آخر مبهم باشد، مزیت زبان مشترک با محصول هنوز برآورد قابل‌اتکایی از هزینهٔ مهاجرت نمی‌دهد.

زبان آشنا و خوانایی تغییرات

مزیت Pulumi برای تیمی روشن‌تر است که توسعه‌دهندگان محصول، زیرساخت همان محصول را نیز نگه می‌دارند. معرفی زبان‌های Pulumi از TypeScript، JavaScript، Python، Go، .NET، Java و YAML نام می‌برد. در این حالت می‌توان منطق نام‌گذاری، اعتبارسنجی ورودی یا اجزای تکراری را با امکانات زبان غالب تیم ساخت و از ابزارهای آشنای آن برای آزمودن کد استفاده کرد.

بااین‌حال، خوانایی کد همان خوانایی تغییر زیرساخت نیست. تابعی کوتاه می‌تواند چندین منبع بسازد و بازبین باید اثر اجرای آن را با ورودی‌های محیط مقصد در preview ببیند. در مقابل، HCL و ماژول‌های Terraform برای تیمی که سال‌ها با آن‌ها کار کرده ممکن است از یک برنامهٔ پویا روشن‌تر باشند. پرسش تعیین‌کننده این است که آیا فردی غیر از نویسنده می‌تواند از روی پیکربندی و خروجی plan یا preview بفهمد چه چیزی ساخته، جایگزین یا حذف می‌شود.

پوشش provider و زمان plan

وجود نام یک سرویس در فهرست providerها برای تصمیم کافی نیست؛ قابلیت مشخصی که زیرساخت تولیدی به آن وابسته است اهمیت دارد. راهنمای Any Terraform Provider توضیح می‌دهد که Pulumi می‌تواند providerهای Terraform یا OpenTofu را در برنامهٔ خود به کار گیرد و برای زبان‌های برنامه‌نویسی پشتیبانی‌شده SDK محلی بسازد. بنابراین فاصلهٔ یک بستهٔ آمادهٔ Pulumi با نسخهٔ Terraform، همیشه به معنای بسته بودن مسیر استفاده از قابلیت موردنیاز نیست.

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

سرعت را نیز با اجرای خود تیم بسنجید، نه با فرض سریع‌تر بودن یکی از دو زبان. زمان دریافت داده از API، شمار منابع، وابستگی میان آن‌ها و نوع اجرا بر مدت plan یا preview اثر می‌گذارد. اگر تأخیر بازبینی برای تیم مسئله‌ای واقعی است، مقایسه باید روی stack و providerهای همان تیم انجام شود؛ کوتاه‌تر شدن کد به‌تنهایی زمان محاسبهٔ تغییرات را نشان نمی‌دهد.

مالکیت state در دورهٔ همزیستی

در مهاجرت تدریجی، مرز اصلی میان مخزن‌های کد نیست؛ میان منابعی است که هر state حق مدیریتشان را دارد. Pulumi می‌تواند خروجی state متعلق به Terraform را بخواند و با شناسهٔ یک شبکه یا پایگاه داده، منبع تازه‌ای بسازد. این خواندن به معنی واگذاری مدیریت شبکه یا پایگاه داده نیست. اگر هر دو برنامه همان منبع را در فهرست منابع تحت مدیریت خود داشته باشند، هر اجرا ممکن است تنظیمات ابزار دیگر را به‌عنوان تغییری برای اصلاح ببیند.

یک مرز قابل‌فهم می‌تواند شبکه و پایگاه داده را در Terraform نگه دارد و سرویس تازه را به Pulumi بسپارد. شناسه‌ها و خروجی‌ها از مرز عبور می‌کنند، اما اختیار تغییر پیکربندی منبع عبور نمی‌کند. برای انتقال خود یک منبع موجود، باید پیوند آن با state قبلی بدون حذف منبع واقعی برداشته شود، شناسه‌اش در stack مقصد ثبت شود و نخستین preview تغییر ناخواسته‌ای نشان ندهد. صرف انتقال فایل یا تبدیل کد این ترتیب مالکیت را تعیین نمی‌کند.

دسترسی‌ها هم بخشی از همین مرز هستند. فردی که تنها خروجی شبکه را برای ساخت سرویس مصرف می‌کند، لزوماً نباید اختیار تغییر شبکه را داشته باشد. در مقابل، کسی که preview یا اجرای stack مقصد را انجام می‌دهد به دسترسی‌های لازم برای همان stack و تنظیمات محرمانهٔ آن نیاز دارد. چنین تفکیکی هنگام همزیستی دو ابزار از نام‌گذاری متفاوت پروژه‌ها مؤثرتر است، زیرا مسئولیت اعمال تغییر را به منبع واقعی وصل می‌کند.

روایت شش‌ماهه چه هزینه‌ای را آشکار می‌کند؟

در روایت مهاجرت 72Technologies، تیم بخشی از زیرساخت AWS و Vercel را به Pulumi برد، شبکهٔ VPC و چند بخش دیگر را در Terraform نگه داشت و برای stack مربوط به ECS، پس از کنار گذاشتن خروجی تبدیل خودکار، حدود ۱۲۰ منبع را جداگانه وارد کرد؛ این واردسازی همراه با بررسی حدود سه روز مهندسی زمان گرفت. در ارزیابی شش‌ماههٔ همان تیم، زمان ورود مهندس تازه برای انجام یک تغییر زیرساختی تقریباً نصف شد، اما زمان plan و preview در مجموع نزدیک به هم ماند.

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

همان تجربه نشان داد که تفاوت نسخهٔ provider می‌تواند در مرز دو ابزار اثر بگذارد: Pulumi برای تنظیم رمزنگاری یک منبع S3 نزدیک به آن مرز، تغییری را پیشنهاد کرد که با تنظیم Terraform همخوان نبود. تیم همچنین stack مربوط به Vercel را به Terraform برگرداند، زیرا provider انتخابی Pulumi در زمان مهاجرت، قابلیت موردنیازش برای هدف‌گیری متغیر محیطی بر اساس شاخهٔ Git را نداشت. امکان استفادهٔ مستقیم از providerهای Terraform یک مسیر دیگر در اختیار تیم‌های امروز می‌گذارد، اما سازگاری همان فیلد و نتیجهٔ preview همچنان باید برای مورد مشخص بررسی شود.

ماندن، مهاجرت کامل یا همزیستی محدود

راهنمای مهاجرت Pulumi چند کار متفاوت را از هم جدا می‌کند: استفاده از Pulumi Cloud به‌عنوان backend برای اجرای همچنان مبتنی بر Terraform، اجرای HCL روی موتور Pulumi، تبدیل کد و واردسازی منابع موجود. تغییر محل نگهداری state در حالت نخست، مالکیت منابع را به موتور Pulumi منتقل نمی‌کند. اجرای HCL روی موتور Pulumi نیز state فعلی Terraform را در جای خود دوباره استفاده نمی‌کند و برای منابع موجود به واردسازی نیاز دارد؛ در واردسازی با گزینهٔ HCL، منابع درون ماژول‌ها جداگانه رسیدگی می‌شوند.

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

• ماندن در Terraform: وقتی providerهای لازم و بازبینی HCL و plan جاافتاده‌اند و اشتراک منطق میان برنامه و زیرساخت سود مشخصی ندارد، انتقال منابع موجود هزینه‌ای با بازده نامعلوم است. دشواری یک ماژول به‌تنهایی ضرورت جابه‌جایی همهٔ stateها را نشان نمی‌دهد.
• مهاجرت کامل: وقتی بیشتر نگه‌دارندگان زیرساخت با زبان مقصد کار می‌کنند، قابلیت‌های ضروری provider بررسی شده‌اند و preview تغییرات قابل‌فهم است، انتقال کامل می‌تواند نگهداری دو مسیر اعمال تغییر را پایان دهد. برنامهٔ مهاجرت باید خروج هر منبع از مدیریت قبلی و ورود آن به stack مقصد را پوشش دهد.
• همزیستی محدود: وقتی بخش تازه‌ای از Pulumi سود می‌برد اما منابع حساس یا providerهای خاص در Terraform بهتر اداره می‌شوند، مرز را بر اساس resource و stack مشخص کنید. عبور خروجی‌ها برای ساخت منابع وابسته مفید است؛ اختیار اعمال تغییر روی یک منبع باید نزد یک مالک بماند.

برای برآورد مهاجرت، فهرست منابعی که واقعاً باید جابه‌جا شوند از منابعی که فقط خروجی‌شان مصرف می‌شود جدا کنید. اولی به تبدیل یا import، تطبیق شناسه‌ها، بازبینی preview و تغییر مسیر دسترسی نیاز دارد؛ دومی می‌تواند زیر مالکیت فعلی بماند. همین تفاوت روشن می‌کند زبان آشنا در کدام بخش کار صرفه‌جویی می‌آورد و هزینهٔ state در کدام بخش باقی می‌ماند.

بیشتر بخوانید:

• GPT-6 Sol یا Luna؛ کیفیت بیشتر ارزش هزینهٔ ۲۰ برابری را دارد؟
• RAG یا پنجرهٔ زمینهٔ بلند؛ اسناد بیشتر همیشه پاسخ بهتر نمی‌سازند
• Shopify یا WooCommerce؛ رایگان‌بودن افزونه هزینهٔ کل را تعیین نمی‌کند