تصور کنید نرم‌افزاری را که هر لحظه با نیاز شما تغییر می‌کند و دیگر نیازی به برنامه‌نویس انسانی برای به‌روزرسانی‌های کوچک ندارد. این چشم‌اندازی است که Fly.io تمام آینده‌ی خود را روی آن شرط بسته است. باور بنیادین این شرکت اکنون این است: «انسان‌ها دیگر اکثر نرم‌افزارها را نخواهند نوشت». همین باور تک‌بعدی باعث شده است که یک پلتفرم ابری عمومی، تمام آینده خود را روی جهتی کاملاً جدید متمرکز کند.
به نقل از بیانیه‌ی رسمی شرکت در ۲۵ ژوئیه ۲۰۲۶، این پلتفرم ابری یک چرخش راهبردی (Pivot) در مدل کسب‌وکار خود انجام داد تا روی Sprites تمرکز کند؛ دسته‌بندی جدیدی از کامپیوترهای «نیمه‌یک‌بار مصرف» (Semi-disposable) که به‌طور اختصاصی برای عامل‌های هوش مصنوعی (AI Agents) — مانند دستیارهای خودکاری که مثل یک کارمند مجرب، تکالیف پیچیده کدنویسی را از ابتدا تا انتها مدیریت می‌کنند — طراحی شده‌اند.
سال‌ها بود که صنعت، زیرساخت‌های ابری را ابزاری برای میزبانی برنامه‌هایی با عملکرد ثابت می‌دید که توسط انسان‌ها و با استفاده از خط‌لوله‌های سخت‌گیرانه‌ی CI/CD ساخته شده‌اند. اما اکنون وارد عصری می‌شویم که عامل‌های هوش مصنوعی نیازی به تجربه‌ی توسعه‌دهنده‌ی سازمان‌یافته یا تنظیمات پیش‌فرض نظرپذیر (Opinionated Defaults) ندارند. آن‌ها به محاسبات (Compute) خام و منعطفی نیاز دارند که بتوان آن را فوراً فعال کرد و پس از اتمام کار، تخریب نمود. این رویکرد دقیقاً شبیه به نحوه استفاده‌ی یک متخصص کسب‌وکار از یک صفحه‌گسترده (Spreadsheet) است، نه استفاده از یک مجموعه‌ی نرم‌افزاری کامل و صلب.
طبق گزارش مفصل این شرکت، این تغییر پس از یک دوره‌ی بحران شناسیت داخلی و درک این حقیقت رخ داد که سریع‌ترین گروه مشتریان آن‌ها نه انسان‌ها، بلکه ربات‌ها هستند. شرکت ادعا می‌کند تفکیک سنتی بین «حیوانات خانگی» (Pets - سرورهای اختصاصی که مراقبت می‌شوند) و «گله گاو» (Cattle - خوشه‌های یک‌بار مصرف) برای عامل‌ها کافی نیست. ربات‌ها به چیزی بین این دو نیاز دارند: یک «گاو نیمه‌یک‌بار مصرف»؛ یعنی کامپیوتری که فقط تا زمانی که تکلیف مورد نظر ایجاب می‌کند وجود داشته باشد، اما در عین حال حافظه‌ی پایدار خود را حفظ کند.
زمینه: محرک‌های تغییر
این چرخش راهبردی تا حدی توسط انتقادات بیرونی و تاملات داخلی تحریک شد. بنیان‌گذار شرکت اشاره کرد که ویدیویی از «تئو براون» که در آن «بهترین مکان برای میزبانی یک برنامه جدید در سال ۲۰۲۶» را رتبه‌بندی می‌کرد، به عنوان یک زنگ بیدارباش عمل کرد. این تحلیلات با دیدگاه‌های تئو براون درباره محدودیت‌های رابط‌های کاربری سنتی در برابر اتوماسیون AI همسو است که بر ضرورت تغییر در نحوه تعامل با ابزارهای توسعه تأکید دارد. اگرچه براون دیدگاه مثبتی درباره پلتفرم داشت، اما در نهایت نتیجه گرفت که Fly.io ارائه‌دهنده‌ای است که او کمتر از همه اطمینان دارد تا پایان سال باقی بماند.
این اظهارنظر، علیرغم اینکه شرکت فصل‌های بسیار قدرتمندی را تجربه می‌کرد و بهترین ماه‌های مالی تاریخ خود را می‌گذراند، روی یک «عصب raw» یا نقطه‌ی حساس دست گذاشت. این موضوع یک بحران شناسیت حل‌نشده را در درون شرکت آشکار کرد. بنیان‌گذار اعتراف کرد که در حالی که شرکت در حال سوختن (Smoldering) بود، او در حالت «راندن آرام» (Coasting) به سر می‌برد. همین موضوع منجر به تصمیمی شد تا کل سازمان را روی مشکلی متمرکز کنند که عامل‌های هوش مصنوعی در حال حل آن هستند.
زمینه: تکامل تناسب محصول با بازار (Product-Market Fit)
شرکت Fly.io بر اساس دو اصل محوری بنا شده بود که اکنون شرکت معتقد است به دلیل «دگرگونی» (Transmogrification) توسعه نرم‌افزار توسط هوش مصنوعی، تا حد زیادی منسوخ شده‌اند:
۱. سرعت از طریق نزدیکی (Speed through Proximity): این باور که برنامه‌ها زمانی بهترین عملکرد را دارند که نزدیک به کاربران مستقر شوند. این شعاری بود که از سال‌های حضور بنیان‌گذاردر Ars Technica نشأت گرفته بود.
۲. زیرساخت ساده شده: هدف ارائه انعطاف‌پذیری AWS با ارگونومی و سهولت Heroku.
در چشم‌انداز فعلی هوش مصنوعی، این اولویت‌ها تغییر کرده‌اند. بنیان‌گذار استدلال می‌کند که هوش مصنوعی یک تغییر پارادایم (Paradigm Shift) بزرگ‌تر از گذار از زبان C به Ruby است. او این لحظه را با اختراع صفحه‌گسترده توسط «دن بریکلین» مقایسه می‌کند؛ درست همان‌طور که در گذشته هر «سند اکسل» در واقع برنامه‌ای بود که باید توسط یک برنامه‌نویس نوشته می‌شد، اکنون هوش مصنوعی تقریباً هر کسی را قادر می‌سازد تا تقریباً هر برنامه‌ای را بسازد. در این مسیر، شرکت‌هایی مانند Anthropic نیز تجربیات مشابهی در جایگزینی مهندسی دقیق انسانی با ابزارهای AI داشته‌اند که مرزهای توانمندی کدنویسی ماشینی را به چالش می‌کشد.
در نتیجه، شرط‌بندی روی یک طراحی ابر عمومی متعلق به سال ۲۰۲۰، معادل شرط‌بندی علیه نرم‌افزارهای شخصی‌سازی شده و تطبیقی است. بنیان‌گذار ابراز امیدواری می‌کند جهانی داشته باشیم که در آن دوستان و خانواده‌هایش بتوانند کامپیوترها را دقیقاً همان‌گونه که می‌خواهند به کار بگیرند، بدون اینکه منتظر بمانند تا یک توسعه‌دهنده برنامه‌ای برای آن‌ها بسازد.
زمینه: جایگزینی تجربه‌ی توسعه‌دهنده
این باور در Fly.io در حال رشد است که یک تجربه‌ی توسعه‌دهنده‌ی انسانیِ به‌دقت سازمان‌یافته با تنظیمات پیش‌فرض، ممکن است اکنون به یک نقطه ضعف تبدیل شود. عامل‌ها زمانی بهترین عملکرد را دارند که همه چیز «صریح» (Explicit) باشد. در یک تقریب اولیه، شرکت پیشنهاد می‌کند که امروزه دیگر هیچ‌کس مستندات را نمی‌خواند.
توسعه‌دهندگان دیگر CLIهای جدید را برنمی‌دارند تا با آزمون و خطا بفهمند چگونه از آن‌ها استفاده کنند؛ در عوض، عامل‌ها این وظایف را بر عهده می‌گیرند. یک عامل می‌تواند یک استقرار در Fly.io را به‌صورت «تک‌ضربه» (One-shot) انجام دهد؛ به این صورت که سایت را به‌صورت محلی می‌سازد و صرفاً دستور می‌گیرد که «این را در Fly.io فعال کن». نکته حیاتی این است که بنیان‌گذار اشاره می‌کند یک عامل می‌تواند به همان راحتی یک استقرار در AWS را هم به‌صورت تک‌ضربه انجام دهد، که این امر خندق رقابتیِ «ارگونومی توسعه‌دهنده» را از بین می‌برد.
زمینه: بینش درباره مشتریان رباتیک
این تغییر مسیر پس از دوره‌ای رخ داد که شرکت دست از «تفسیر مجدد» (Retconning) ساخت‌های قبلی برای فهمیدن نیازهای واقعی ربات‌ها برداشت. این بینش در پستی از سال گذشته با این شناسایی به دست آمد که ربات‌ها سریع‌ترین بخش مشتریان در حال رشد هستند.
از این تجربه، شرکت سه حقیقت محوری درباره نیازهای عامل‌ها استخراج کرد:
- عامل‌های کدنویسی انتظار دارند روی ایستگاه‌های کاری (Workstations) توسعه‌دهنده اجرا شوند.
- لپ‌تاپ‌های فیزیکی ناکارآمد هستند، زیرا وقتی درب لپ‌تاپ بسته می‌شود، اجرای آن‌ها متوقف می‌شود.
- ابرهای عمومی به‌طور کلی برای اجرای عامل‌ها بیش از حد آزاردهنده هستند، زیرا فضای «نیمه‌یک‌بار مصرف» بین حیوانات خانگی و گله گاو را ندارند.
جزئیات: مکانیسم‌های Sprites
Sprites برای حل اصطکاک اجرای محیط‌های ایزوله (Sandboxes) عامل‌ها روی سخت‌افزار محلی طراحی شده‌اند. در حال حاضر، عامل‌های کدنویسی انتظار دارند روی سیستم توسعه‌دهنده اجرا شوند، اما این ناکارآمد است زیرا لپ‌تاپ با بستن درب متوقف می‌شود. بنیان‌گذار به‌شوخی می‌پرسد که آیا خوانندگان در سال جاری تا به حال با مک‌بوک باز از پله‌ها بالا یا پایین رفته‌اند؟ و اشاره می‌کند که چنین رفتاری غیرعملی است.
این موضوع توسعه‌دهندگان را مجبور می‌کند تا محیط‌های ایزوله عامل‌های خود را به ابر منتقل کنند. Sprites این مشکل را با ارائه «کامپیوترهایی برای عامل‌ها» با ویژگی‌های فنی خاص حل می‌کنند:
- ذخیره‌سازی پایدار (Durable Storage): هر Sprite مجهز به یک درایو دیسک پایدار ۱۰۰ گیگابایتی است.
- صورت‌حساب بهینه: آن‌ها از صورت‌حساب کاربردی اندازه‌گیری شده (Metered Utility Billing) استفاده می‌کنند. زمانی که Spriteها بیکار هستند، کنتور کار نمی‌کند و سیستم به‌طور هوشمند تشخیص می‌دهد که این اتفاق چه زمانی رخ می‌دهد.
- مقیاس‌پذیری سریع: کاربران می‌توانند صدها یا هزاران Sprite را به‌سرعت ایجاد کنند.
- دسترسی اینترنتی: کاربران می‌توانند یک برنامه را روی Sprite میزبانی کنند و آن را از طریق اینترنت با همکاران خود به اشتراک بگذارند.
در حالی که صنعت همچنان روی «سندباکس‌ها» وسواس دارد، Fly.io استدلال می‌کند که ربات‌ها سندباکس نمی‌خواهند، بلکه آن‌ها «کامپیوترهای واقعی» می‌خواهند. Sprites تحقق عینی فلسفه «گاو نیمه‌یک‌بار مصرف» هستند.
جزئیات: زیرسیستم‌های فنی و مهندسی
هرچند Sprites به‌عنوان یک پروژه مخفی (Skunkworks) توسط یک «تیم اسکلتی کوچک» آغاز شد، اما نسخه جدید (nu-Sprites) دو زیرسیستم حیاتی را برای تبدیل محصول به یک محصول «کامل از نظر ویژگی‌ها» (Feature-complete) معرفی می‌کند:
۱. دستگاه بلوکی اسپریت (SBD - Sprite Block Device):
- پشته ذخیره‌سازی اصلی پیش‌تر به عنوان یک «ابزار عجیب و غریب» (Goblin Contraption) توصیف شده بود که شخصاً از JuiceFS گرفته شده و از طریق Litestream بن جانسون سیم‌کشی شده بود.
- SBD جدید که توسط بن جانسون و تیم نیوشم بازسازی شده، سریع‌تر و قابل‌اعتمادتر است.
- این سیستم از «برداشت و بازگردانی فوری» (Instant Checkpoint-and-Restore) پشتیبانی می‌کند.
- این قابلیت «فورک کردن درایو» (Drive Forking) را ممکن می‌سازد که اجازه می‌دهد یک Sprite الگو به‌طور بهینه میلیون‌ها بار کلون شود.
۲. اتصال‌دهنده‌ها (Connectors):
- این‌ها بر اساس کارهای موجود برای ایمن‌سازی پلتفرم اصلی ساخته شده‌اند.
- آن‌ها به Spriteها اجازه می‌دهند درخواست‌های احراز هویت‌شده به سیستم‌های دیگر بفرستند، بدون اینکه اعتبارنامه‌هایی (Credentials) به عامل‌ها داده شود که احتمال سرقت یا نشت آن‌ها وجود دارد.
- این ابزارها نیاز به مدیریت دستی حساب‌ها و کلیدهای API توسط عامل‌ها را از بین می‌برند؛ موضوعی که دلیل اصلی پافشاری شرکت‌های عامل‌محور بر استفاده از Fly Machines در گذشته بود.
جزئیات: بتای Fancy Sprite
برای اینکه جامعه کاربری بتواند این قابلیت‌های جدید را تجربه کند، Fly.io دعوت‌نامه‌ای خاص برای بتای Fancy Sprite منتشر کرده است. این بتا به‌طور مشخص کاربران علاقه‌مند به «یک Sprite بتای عجیب که بتواند خودش را کلون کند» را هدف قرار داده تا نگاهی اولیه به مکانیسم‌های فورک کردن درایو که توسط SBD فعال شده‌اند، داشته باشند.
رهبری و بازنگری استراتژیک
این تغییر فنی با یک تغییر حاکمیتی بزرگ همزمان شده است. بنیان‌گذار شرکت از مقام مدیرعاملی کنار می‌رود تا به نقش مشاور و کرسی هیئت‌مدیره منتقل شود، جایی که روی «بخش سرگرم‌کننده» شغل خود تمرکز خواهد کرد: بحث‌های طراحی محصول و گاهی «آزار دادن» مدیرعامل جدید.
اسکات جانستون، مدیرعامل سابق Docker، سکان هدایت را در دست می‌گیرد. جانستون به دلیل هدایت داکر از بحران شناسیت خود در مورد نیازهای سازمانی در مقابل نیازهای توسعه‌دهندگان و در نهایت «گشودن درهای کسب‌وکار» (Blowing the doors off the business) شناخته می‌شود. بنیان‌گذار از سال ۲۰۲۵ ماه‌ها با جانستون درباره اینکه Fly.io تحت رهبری او چگونه خواهد بود صحبت کرده و به این نتیجه رسیده است که استراتژی (Playbook) جانستون برای این مرحله از چرخه حیات شرکت مناسب‌تر است.
برای هشت سال، بنیان‌گذار با این شرکت مانند یک پروژه علمی برخورد می‌کرد؛ جست‌وجویی آزمایش‌محور برای یافتن تناسب محصول با بازار. این مسیر شامل امتحان کردن چندین راه فنی بود، از جمله:
- Postgres مدیریت‌نشده (که بنیان‌گذار اکنون صراحتاً توصیه می‌کند از آن دوری کنید).
- CDNهای جهانی.
- User-mode WireGuard.
- ساخت یک سازمان مهندسی پایین‌به‌بالا که از نقشه‌های راه (Roadmaps) محصول اجتناب می‌کرد.
- جذب یک تیم کاملاً دورکار با اعضامی در بیش از دوازده کشور.
همچنین Fly.io فاش کرد که مقدار قابل‌توجهی سرمایه جدید جذب کرده است. در حالی که شرکت پیش از این چندین سال بدون تأمین مالی جدید فعالیت کرده بود — به این معنی که سرمایه کافی برای بقا داشتند به شرطی که هوش مصنوعی باعث «باز شدن زمین و بلعیدن همه ما» نشود — اما جهت‌گیری استراتژیک جدید نیازمند یک برنامه مالی متفاوت بود.
آینده‌ی عامل‌محور
این چرخش بر اساس یک شرط‌بندی دوقطبی است: اینکه ظرف چند سال آینده، عامل‌ها تعیین خواهند کرد که تقریباً تمام نرم‌افزارها چگونه ساخته و عرضه شوند. این بدان معناست که نرم‌افزار شخصی‌تر، تطبیقی‌تر و منعطف‌تر خواهد شد، مخاطبانی کوچک‌تر خواهد داشت و از مدل برنامه‌های «یک-اندازه-برای-همه» فاصله می‌گیرد.
در حالی که Fly.io به پشتیبانی از Fly Machines موجود و ویژگی‌های پلتفرم به عنوان سرویس (PaaS) ادامه می‌دهد، اما تخصیص منابع داخلی به‌طور تهاجمی تغییر کرده است. بنیان‌گذار اشاره کرد که بررسی git blame در کدبیس نشان می‌دهد نام او بیش از هر کس دیگری تکرار شده است، که بازتاب‌دهنده تمرکز شدید و عملی مورد نیاز برای ساخت زیرساخت Sprite است.
این یک جدایش از اصول اولیه شرکت است. در پارادایم جدید، یک تجربه‌ی توسعه‌دهنده‌ی انسانیِ سازمان‌یافته با پیش‌فرض‌های نظرپذیر ممکن است در واقع یک نقطه ضعف باشد. عامل‌ها زمانی بهترین عملکرد را دارند که همه چیز صریح باشد. از آنجایی که اکنون عامل‌ها کاربران اصلی هستند — و وظایفی مانند استقرارهای تک‌ضربه را انجام می‌دهند — مستندات سنتی و ارگونومی CLI کمتر از رابط‌های صریح و برنامه‌ریزی‌پذیر اهمیت دارند.
این تغییر نشان‌دهنده یک روند گسترده‌تر در رایانش ابری است: گذار از «زیرساخت به عنوان سرویس» (IaaS) برای انسان‌ها به «محاسبات به عنوان ابزار» (Compute as a Tool) برای هوش مصنوعی. شرکت تصمیم گرفته است که نمی‌تواند در هر دو مسیر «لنگ‌لنگان» پیش برود؛ یا باید به مقیاس‌بندی پلتفرمی برای برنامه‌های با عملکرد ثابتِ طراحی‌شده توسط انسان ادامه دهد، یا محصولی برای آینده‌ی عامل‌محور بسازد. آن‌ها دومی را انتخاب کرده‌اند و اعلام کرده‌اند که اگر شکست بخورند، این کار را با «تمام وجود» (Full Asses) انجام خواهند داد.
گام بعدی شما
- اگر از عامل‌های کدنویسی برای اتوماسیون استفاده می‌کنید، قابلیت‌های SBD را برای مدیریت وضعیت (State) بررسی کنید.
- در بتای Fancy Sprite ثبت‌نام کنید تا مکانیزم کلون‌سازی سریع را تست کنید.
- استراتژی استقرار خود را از مدل‌های صلب به سمت زیرساخت‌های پویا و متناسب با نیاز عامل‌ها تغییر دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ اثر این تغییر بر تقاضای GPUهای لبه را در گزارش بعدی بررسی خواهیم کرد.
گفتگو