لأشهر، قمت ببناء خط أنابيب بيانات على جهاز Windows الخاص بي باستخدام استيعاب RSS في WSL2، وPostgres في Docker، وتنسيق Kestra، وتحويلات dbt. كل شيء عمل محليًا لأن كل شيء كان يعمل على جهاز واحد. نقله إلى AWS عبر CLI كشف افتراضات مخفية.

إعداد مثيل EC2 من نوع t3.small مع Ubuntu 22.04 كان سهلاً. شملت المفاجآت قرص 8GB كان صغيرًا جدًا، مما تطلب growpart وresize2fs، لكن مثيلات Nitro الأحدث تسمي الأقراص `nvme0n1` بدلاً من `xvda`. أصبح المثيل "معطلًا" أثناء سحب صورة Kestra، وتم إصلاحه بإضافة ملف مبادلة 1GB. أضاف عنوان IP مرن وقيود مجموعة الأمان مهامًا بسيطة.

نقل خط الأنابيب باستخدام rsync وDocker وdocker compose نجح، لكن تدفقات Kestra تعيش في قاعدة بياناتها الداخلية، وليس في الملفات، لذا تدفق fetch_rss الخاص بي يحتاج إلى لصق YAML يدويًا. هذا أبرز نمطًا من الافتراضات التي تنكسر واحدًا تلو الآخر.

التحدي الحقيقي لم يكن AWS نفسه، بل الاعتماديات المخفية المبنية على افتراضات "نفس الجهاز"، مما علم أكثر من البناء الأصلي.