‏مهندسیِ نامرئی پشت شبکه‌ی Lambda توی AWS

ورنر فوگلز، مدیر فنی آمازون، توی این پست داستان تیم شبکه‌ی AWS Lambda رو تعریف می‌کنه؛ داستانی که نزدیک یه دهه طول کشیده و قسمت بزرگی‌اش خاموش و پشت‌پرده بوده.

نکته‌ی اصلی اینه که بیشتر بهبودهای زیرساخت توی AWS نامرئی اتفاق می‌افتن. تیم‌های مهندسی سال‌ها وقت می‌ذارن تا سیستم‌هایی رو که میلیون‌ها مشتری بهشون وابسته‌ان به‌صورت تدریجی بازسازی کنن، در حالی که همون سیستم‌ها بدون وقفه و در مقیاس کامل دارن کار می‌کنن. یکی از مهندس‌ها این رو به تبدیل هواپیمای ملخی به جت وسطِ پرواز تشبیه می‌کنه: یه اشتباه و هواپیما سقوط می‌کنه، اما اگه درست انجامش بدی، هیچ‌کس متوجه نمی‌شه.

این همون کاریه که هیچ‌وقت تیتر نمی‌شه یا براش پست منتشر نمی‌شه (دست‌کم وقتی همه‌چی طبق نقشه پیش بره)؛ کارهایی مثل بهینه‌کردن قانون‌های iptables، دور زدن قفل‌های هسته (kernel lock contention) یا بازنویسی header بسته‌ها. جایی که موفقیت ساکته و پاداش فقط دونستنِ اینه که چیزی که روش کار کردی امروز بهتر از هفته‌ی پیشه و تیم بعدی به همون محدودیتی که تو برداشتی نمی‌خوره.

فوگلز می‌گه در کنار لانچ‌های بزرگ و قابل‌دیدن مثل S3 Files، یه دسته کارِ به‌همون‌اندازه چشمگیر هست که آروم، توی بازه‌های طولانی و دور از چشم مشتری اتفاق می‌افته. داستان Lambda دقیقاً از همین جنسه: تلاش تیم شبکه چیزهایی رو که قبلاً غیرممکن به نظر می‌رسید، مثل اجرای بارهای کاریِ حساس به تأخیر روی یه تابع serverless، ممکن کرده و روی کلِ نحوه‌ی ساختن چیزها توی AWS اثر گذاشته. مقاله بعد توضیح می‌ده که توپولوژی شبکه (یعنی چیدمان دستگاه‌ها، اتصال‌ها و قانون‌هایی که مسیر حرکت داده رو تعیین می‌کنن) چیه، چون پایه‌ی همه‌چیزه.

نکات کلیدی:

• بیشتر بهبودهای زیرساخت AWS خاموش و نامرئی‌ان، نه لانچ‌های پرسروصدا
• بازسازیِ سیستمِ در حال کار مثل تبدیل هواپیمای ملخی به جت وسط پرواز است
• کار واقعی توی جزئیاتیه مثل iptables، قفل هسته و بازنویسی header بسته‌ها
• نتیجه: اجرای بارهای حساس به تأخیر روی Lambdaی serverless ممکن شد