زیرساخت به‌مثابهٔ کنترل: CDN، DNS و کلاود واقعاً چه هستند

یک سایت در یک کشور از دسترس خارج می‌شود. تیم بررسی می‌کند. هاستینگ سالم است. DNS همه‌جایِ دیگر حل می‌شود. بیلد سبز است، داشبوردِ کلادفلر می‌گوید سالم است، چک‌های مصنوعی از فرانکفورت قبول می‌شوند. سایت بالاست. فقط، به‌طورِ مشخص، از داخلِ جزیرهٔ BGPِ یک کشور غیرقابل‌دسترسی است، و هیچ صفحهٔ حادثه‌ای بلد نیست این را بگوید.

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

پشته‌ای که بازبینیِ طراحی پوششش نمی‌دهد

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

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

این هم کیکِ لایه‌لایه، به‌طورِ خلاصه، با پرسشی که هر لایه پاسخ می‌دهد.

**DNS.** چه کسی تصمیم می‌گیرد نامِ دامنه‌ات به کجا حل شود. ثبت‌کننده کلیدها را در دست دارد. اپراتورِ TLD بالای ثبت‌کننده نشسته. کشوری که قوانینش بر اپراتورِ TLD اعمال می‌شود، بالای همان نشسته. اگر دامنه‌ات روی یک TLDِ کدِ کشوری باشد، پاسخِ عملی به «چه کسی می‌تواند این را از تو بگیرد» این است: «دولتِ همان کشور، با یک تماسِ تلفنی به دفترِ مناسب.» بیشترِ تیم‌ها TLD را انتخاب می‌کنند چون روی کارتِ ویزیت خوب به‌نظر می‌رسد، بدونِ آنکه بفهمند حاکمیتی هم که با آن می‌آید را برداشته‌اند.

**مرجعِ صدورِ گواهی.** چه کسی می‌تواند گواهی‌ای صادر کند که بگوید «این سایتِ توست». تقریباً صد CAِ ریشه در مخزنِ اعتمادی هست که مرورگرهایِ اصلی با آن عرضه می‌شوند، و مشتی از آن‌ها سابقهٔ مستندی از صدورِ گواهی تحتِ فشارِ دولتی دارند (ماجرای دیجی‌نوتار را نگاه کن، یا آنچه دربارهٔ تراست‌ویو یک دهه پیش کشف شد، یا حوادثِ گوناگونِ ریشهٔ قزاقستان). زنجیرهٔ اعتماد فقط به‌اندازهٔ ضعیف‌ترین CAای قوی است که مرورگرهایِ خواننده‌هایت می‌پذیرند، که یعنی یک حملهٔ میان‌آدمی علیهِ سایتت، در کشوری که دولتش روی CAی درست نفوذ دارد، بسته به سال، جایی بینِ یک رخدادِ ماهانه و یک خطِ‌پایهٔ منطقه‌ای است.

**CDN.** کدام گره‌های لبه محتوایت را سرو می‌کنند، و کدام دولت‌ها روی ارائه‌دهندهٔ CDN نفوذ دارند. PoPهایِ کلادفلر اشیاءِ سیاسی‌اند. آدرس دارند. آن آدرس‌ها توی کشورهایی‌اند. آن کشورها قانون دارند. PoPی که خواننده‌ات در کشورِ ایکس را سرو می‌کند، همچنین قطعه‌ای دارایی شرکتی است که دولتِ کشورِ ایکس می‌تواند توقیف، بازرسی یا تصاحبش کند. وقتی کلادفلر یک کشورِ کامل را از خدمتش قطع می‌کند — که اتفاق افتاده، و دوباره خواهد افتاد — هر سایتی که پشتش است، از منظرِ آن کشور، تاریک می‌شود، فارغ از اینکه مبدأ کجاست.

**منطقهٔ کلاد.** داده‌ات فیزیکاً کجاست و درنتیجه قانونِ کدام حوزهٔ قضایی بر آن اعمال می‌شود. AWS us-east-1 یک مختصاتِ بی‌طرف نیست؛ مجموعه‌ای است از ساختمان‌ها در ویرجینیا که تابعِ قوانینِ ویرجینیا، ایالاتِ متحده، و هر کشوری است که معاهداتِ کمکِ حقوقیِ متقابلش آن ساختمان‌ها را پوشش می‌دهد. منطقهٔ کلاد کمی مثلِ یک پاسپورت برای داده‌ات عمل می‌کند — داده‌ات یکی دارد، چه برایش درخواست داده باشی چه نه، و اینکه در نهایت کدام‌یک را در دست داری، تعیین می‌کند چه کسی بعداً می‌تواند دربارهٔ آن سؤال بپرسد.

**مسیرِ شبکه.** درخواستِ خواننده‌ات از کدام شبکه‌های واسط عبور می‌کند تا به تو برسد. خواننده در کشورِ ایکس مستقیم به سرورت وصل نمی‌شود. به ISPاش وصل می‌شود، که به یک صرافیِ peering وصل است، که به یک IX وصل است، که به یک حاملِ رده‌یک وصل است، که به CDNِ تو وصل است، که به مبدأِ تو وصل است. هر جهش یک فرصت برایِ بازرسی، تغییر، تأخیر، یا ضبط است. توپولوژیِ جهش‌ها را روابطِ اقتصادیِ میانِ اپراتورهایِ شبکه تعیین می‌کند که تو نه می‌بینی‌شان و نه می‌توانی رأیی درشان داشته باشی.

چرا این نامرئی است تا وقتی که دیگر نیست

اینترنت به‌اندازهٔ کافی خوب کار می‌کند، بیشترِ اوقات، برایِ بیشترِ آدم‌ها، طوری که کیکِ لایه‌لایه نامرئی است. سایت بار می‌شود. گواهی معتبر است. DNS حل می‌شود. صورت‌حسابِ کلاد می‌رسد. معماریِ زیرِ همهٔ این‌ها مثلِ چیزی محیطی رفتار می‌شود — مثلِ لوله‌کشی — نه مثلِ مجموعه‌ای از تصمیم‌های سیاسی که واقعاً هست.

این نامرئی‌بودن همان لحظه‌ای تمام می‌شود که یکی از لایه‌ها ذاتش را اعمال می‌کند. یک دولت روی یک ثبت‌کننده فشار می‌آورد. یک CA گواهیِ جعلی صادر می‌کند. یک ارائه‌دهندهٔ کلاد از یک بازار خارج می‌شود. گرهِ لبهٔ یک CDN توقیف می‌شود. یک مسیرِ BGP ربوده می‌شود. ناگهان، همان لایهٔ نامرئی تنها چیزی است که دارد اتفاق می‌افتد، و تیمی که آن معماری را انتخاب کرده، دارد به پیامدهایِ تصمیم‌هایی خیره می‌شود که بر اساسِ قیمت و راحتی گرفته.

تیم برای این تقصیرکار نیست. تقریباً هیچ‌چیز در آموزش‌شان آماده‌شان نکرده بود که به آن فکر کنند. صفحاتِ فروشنده به آن اشاره نمی‌کنند. برنامهٔ درسیِ بوت‌کمپ پوششش نمی‌دهد. سیستمِ طراحی توکنی برایش ندارد.

مخاطبانی که اول از همه هزینه را می‌پردازند

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

کاربری که اول از همه می‌شکند، تقریباً بدونِ استثنا، همان کاربری است که بیشتر از همه به محصول نیاز داشت. روزنامه‌نگاری در کشوری که حکومتش روی مرجعِ گواهی نفوذ دارد. فعالی که ISPاش متعلق به وزارتِ کشور است. خواننده‌ای روی یک شبکهٔ موبایل که دولت می‌تواند وقتی تصمیم بگیرد اوضاع از کنترل خارج شده، خاموشش کند. کاربرِ مهاجری که اتصالش به خانه، پیش از رسیدن به مبدأِ تو در فرانکفورت، از سه حوزهٔ قضاییِ خصمانه عبور می‌کند.

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

چه کاری متفاوت انجام می‌دهم وقتی مخاطب در یک محیطِ پرتنش است

اولین کار این است که محدودیت را بلند نام می‌برم. خواننده‌ها فیزیکاً کجایند. از کدام اپراتورها استفاده می‌کنند. چه زیرساختِ سانسوری بینِ آن‌ها و اینترنتِ باز نشسته. بدترین حالت برایشان چیست اگر سیستمِ ما نشت کند. تقریباً هیچ پروژه‌ای که با مخاطبِ «جهانی» کار کرده‌ام، وقتی این پرسش‌ها را پرسیدم، پاسخِ جدی‌ای برایشان نداشته. پرسش‌ها خودِ کارند.

دومین کار این است که زیرساختی انتخاب می‌کنم که هم از سانسورچی و هم از رژیمِ تحریم جان سالم به‌در ببرد. این همیشه ممکن نیست. وقتی هست، معمولاً یعنی: یک TLD بیرون از حوزهٔ قضاییِ پرتنش؛ یک CA با سابقهٔ پاک؛ فیل‌آورِ چندمنطقه‌ای، نه به‌عنوانِ بهینه‌سازیِ کارایی، بلکه به‌عنوانِ بهینه‌سازیِ بقا؛ یک CDN که اقامتگاهِ شرکتی‌اش در برابرِ فشارهایِ مشخصی که دولتِ مخاطب می‌تواند اعمال کند، پایدار است؛ یک مبدأ که حتی وقتی درِ ورودی مسدود است از طریقِ تونل قابل‌دسترسی است؛ دامنه‌های آینه‌ای برای وقتی که اصلی توقیف می‌شود.

سومین کار این است که حالت‌های شکست را در سندی می‌نویسم که تیم موظف است هنگام دامنه‌بندیِ ویژگیِ بعدی نگاهش کند. سند طولانی نیست. نیازی هم نیست باشد. فقط باید وجود داشته باشد، و باید مکالمهٔ بعدی‌ای را که نادیده‌اش می‌گرفت، قطع کند.

این حوزه هنوز به چه چیزی نیاز دارد

طراحان معمولاً توی اتاق نیستند وقتی تصمیم‌های زیرساختی گرفته می‌شود، و مهندسانِ زیرساخت معمولاً توی اتاق نیستند وقتی تصمیم‌های طراحی گرفته می‌شود. این دو اتاق از طریقِ تیکت با هم حرف می‌زنند، و قالبِ تیکت فیلدی برایِ پیامدِ سیاسی ندارد — پس پیامد، بی‌نام، همراهِ کار سفر می‌کند، و بعداً به‌شکلِ چیزی سطح می‌آید که رتروسپکتیوِ حادثه به‌عنوانِ مشکلِ فروشنده قاب‌بندی‌اش می‌کند.

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

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