ہیروکو پرانی یادوں کا نقصان: کیوں آسان تعیناتی واحد جواب نہیں ہے

یہ ایک ایسا جذبہ ہے جسے میں نے لاتعداد بار سلیک تھریڈز، ہیکر نیوز کے تبصروں، اور رات گئے ڈسکارڈ میں دیکھا ہے۔

"میں صرف ہیروکو جیسا کچھ چاہتا ہوں۔”

میں نے خود کہا۔ اور میں غلط تھا۔

یہ کہنا غلط نہیں ہوگا کہ ہیروکو اچھا تھا۔ یہ واقعی بہت اچھا تھا، اور جن لوگوں نے اسے بنایا وہ کچھ سمجھ گئے جسے زیادہ تر انفراسٹرکچر کمپنیوں نے ابھی تک اندرونی نہیں بنایا ہے۔

لیکن جب سیلز فورس نے 2022 میں اپنے مفت درجے کو ختم کیا (اور حال ہی میں نئے انٹرپرائز صارفین کو فروخت کے خاتمے کا اعلان کیا) اور ہجرت کا جھگڑا شروع ہوا تو کچھ دلچسپ ہوا۔ تقریباً سب نے غلط سبق سیکھا۔

انہوں نے سوچا کہ ہیروکو کے بارے میں لوگوں کو جو چیز پسند آئی وہ یہ تھی کہ اسے تعینات کرنا کتنا آسان تھا۔ لہذا انہوں نے ایک آسان تعیناتی بنائی۔

لیکن ایسا نہیں تھا۔

ہیروکو نے اصل میں کیا کیا۔

جب میں 2019 کے آس پاس ہیروکو پر ایک سائیڈ پروجیکٹ چلا رہا تھا، میں نے انفراسٹرکچر کے بارے میں بالکل نہیں سوچا تھا۔ میں نے اسے گٹ کی طرف دھکیل دیا اور اسے تعینات کیا۔ میرا پوسٹگریس وہاں تھا۔ اگر آپ کو قطار کی ضرورت ہو تو میں نے ایک پلگ ان شامل کیا۔ سب کچھ ایک ہی ذہنی ماڈل کے مطابق رہتا تھا، اور اس ذہنی ماڈل نے عام کام کے اوقات میں میرے سر میں بہت کم جگہ لی تھی۔

ہیروکو نے جو فروخت کیا وہ تعیناتی پائپ لائن نہیں تھی۔ بیداری صفر تھی۔ انفراسٹرکچر کی کمی جس کے بارے میں آپ کو سوچنے کی ضرورت ہے۔

فرق اس کی آواز سے زیادہ اہم ہے۔ کیونکہ اگر آپ کو انفراسٹرکچر کے بارے میں بالکل بھی سوچنا ہے تو اس سے ہر چیز متاثر ہوتی ہے۔

پروڈکٹ کے فیصلے اس بنیاد پر کریں کہ کیا لگانا آسان ہے، نہ کہ کیا صحیح ہے۔ ڈیلیوری میں تاخیر ہوئی ہے کیونکہ ہمیں یقین نہیں ہے کہ ٹکڑے کیسے جڑتے ہیں۔ تین نئے گاہک لانے والی خصوصیت بنانے کے بجائے، آپ جمعہ کی دوپہر ڈیبگ کرنے میں صرف کرتے ہیں کہ آپ کی ایپ دو وینڈر نیٹ ورکس پر آپ کے اپنے ڈیٹا بیس سے کیوں نہیں جڑ سکتی۔

ہیروکو ان سب کو ہٹا دیتا ہے۔ ایک پلیٹ فارم، سب کچھ پہلے سے منسلک، ایک بل، ایک جگہ چیک کرنے کے لیے کہ آیا کچھ غلط ہو رہا ہے۔

متبادل کو ایک چیز ٹھیک ہو جاتی ہے اور باقی بات یاد آتی ہے۔

ہیروکو کی مفت سروس بند ہونے کے بعد، رینڈر، ریلوے، اور Fly.io ابھرے۔ یہ تینوں EC2 سے براہ راست نمٹنے سے بہت بہتر ہیں۔ میں نے ان سب کو استعمال کیا۔ مجھے ان میں سے کسی کے ساتھ ناانصافی کرنے میں کوئی دلچسپی نہیں ہے۔

لیکن یہ وہی ہوتا ہے جب آپ اسے اصل میں استعمال کرتے ہیں۔

اپنی ایپ کو رینڈر پر تعینات کریں۔ پھر رینڈر میں بھی پوسٹگریس ڈیٹا بیس کی فراہمی کریں اور کنکشن سٹرنگ کو ماحولیاتی متغیر میں چسپاں کریں۔

پھر آپ کو احساس ہوگا کہ آپ کو کچھ پس منظر کے کام کی ضرورت ہے، لہذا آپ Upstash کے لیے سائن اپ کریں یا کہیں Redis مثال شامل کریں۔ پھر ہمیں آبجیکٹ اسٹوریج کی ضرورت ہے، لہذا ہم AWS میں S3 بالٹی بناتے ہیں کیونکہ رینڈر کے پاس نہیں ہے۔

اب آپ کے پاس تین ڈیش بورڈز، تین بلنگ ریلیشنز، چیزوں کو درست طریقے سے ترتیب دینے کے لیے نیٹ ورک کے قوانین کے تین سیٹ، اور تین دکانداروں کا ذہنی اوور ہیڈ ماحولیاتی متغیرات اور دعاؤں کے ساتھ منسلک ہے۔

ریلوے اصل نقطہ نظر کے قریب اور زیادہ مربوط محسوس ہوتا ہے۔ لیکن اس کے نیچے، یہ AWS پر چلتا ہے۔ آپ ایمیزون کے مارجن کے علاوہ ریلوے کا مارجن ادا کریں گے۔ اس کا مطلب ہے کہ آپ دو بار ہائپر اسکیلر ٹیکس ادا کرتے ہیں۔ آپ اصل کمپیوٹنگ کے لیے ایک بار Amazon کو اور ایک بار Railway کو Amazon سے براہ راست بات نہ کرنے کے استحقاق کے لیے ادائیگی کریں گے۔

Fly.io نے سب سے دلچسپ شرط لگائی۔ ہم نے صرف ننگی دھات پر تبدیل کیا. ہم ساختی طور پر AWS کے بغیر اصلی ہارڈ ویئر کے ساتھ ڈبل مارجن کے مسئلے کو حل کرتے ہیں۔ لیکن انضمام کی کہانی کسی بھی طرح ختم نہیں ہوئی۔ پوسٹگریس آن فلائی اب بھی ایک الگ کنکشن ہے۔ "سب کچھ جڑا ہوا ہے” کا احساس جس نے ہیروکو کو جادوئی محسوس کیا وہاں نہیں ہے۔ آپ ابھی بھی تار پکڑے ہوئے ہیں۔

جس کے بارے میں کوئی بات نہیں کر رہا ہے: آپ کی اپنی خدمات کے درمیان ایگریس فیس

مجھے اسے مکمل طور پر اندرونی بنانے میں اس سے زیادہ وقت لگا جتنا اسے یہاں ہونا چاہئے۔

اگر آپ کی ایپس، ڈیٹا بیس، اور سٹوریج کی بالٹیاں کلاؤڈ فراہم کنندہ کے اندر مختلف وینڈرز یا مختلف سروسز پر ہیں، تو ان کے درمیان ڈیٹا منتقل کرنے پر لاگت آتی ہے۔ بہت زیادہ نہیں، لیکن عام طور پر اس سے پہلے کہ یہ بہت ہو جائے۔

ایک ایپ جو ڈیٹا بیس سے دن میں 10,000 بار پڑھتی ہے، کچھ نتائج پر کارروائی کرتی ہے، اور S3 پر لکھتی ہے ڈیٹا کو مسلسل تین سمتوں میں منتقل کرتی ہے۔ ہائپر اسکیلر سے چلنے والے پلیٹ فارمز پر، ان میں سے کچھ حرکتیں بلنگ کی حدود کو عبور کرتی ہیں۔

ایک پلیٹ فارم پر جہاں کمپیوٹ، پوسٹگریس، اسٹوریج اور قطاریں سب ایک ہی ننگے میٹل نیٹ ورک پر ہیں؟ اس کی نقل و حرکت آزاد ہے کیونکہ یہ عمارت کو کبھی نہیں چھوڑتا ہے۔

یہ کوئی مفروضہ نہیں ہے۔ یہ ایک ساختی فرق ہے کہ پلیٹ فارم کو کس طرح ڈیزائن کیا گیا ہے، اور وقت کے ساتھ ساتھ ان طریقوں سے زیادہ پیچیدہ ہوتا جاتا ہے جو انفرادی رسیدوں پر واضح طور پر نظر نہیں آتے۔

"رائے” یہاں اصل کام کرتی ہے، مارکیٹنگ کا کام نہیں۔

میں نے ایک ایسی ٹیم کے ساتھ کام کیا جس نے انجینئرنگ کا حقیقی وقت اس بات پر گزارا کہ کون سا قطار لگانے والا نظام استعمال کرنا ہے۔ لاگو نہیں ہوا۔ ہم اس پر بحث کر رہے ہیں۔ SQS بمقابلہ BullMQ بمقابلہ RabbitMQ بمقابلہ یہ وہ چیز ہے جسے کسی نے تین سال پہلے ایک بلاگ پر پڑھا تھا۔

خود پسند پلیٹ فارمز کی دلیل یہ نہیں ہے کہ آپ وہ فیصلے نہیں کر سکتے۔ سچ تو یہ ہے کہ فیصلے اتنے اہم نہیں ہوتے جتنے آپ سوچتے ہیں، اور جو وقت آپ ان کو بنانے میں صرف کرتے ہیں وہ وقت ہے کہ آپ اپنی پروڈکٹ میں فرق کرنے میں خرچ نہیں کر رہے ہوتے۔

Postgres وجود میں تقریباً ہر سٹارٹ اپ کے لیے موزوں ڈیٹا بیس ہے۔ S3-مطابقت رکھنے والا ذخیرہ تقریباً کسی بھی فائل اسٹوریج کے استعمال کے کیس کو ہینڈل کرتا ہے۔ ایک قابل اعتماد قطار ایک قابل اعتماد قطار ہے۔ یہ کوئی دلچسپ فیصلہ نہیں ہے۔ انہوں نے تقریباً 10 سال پہلے دلچسپ ہونا چھوڑ دیا۔ ایک دلچسپ فیصلہ مصنوعات میں ہے.

خود پسند پلیٹ فارم ہمیں حل شدہ مسائل پر نظرثانی کرنا بند کرنے پر مجبور کرتے ہیں۔ یہ کوئی حد نہیں ہے۔ یہی بات ہے۔

لاک ڈاؤن کے سوالات کا ایمانداری سے جواب دیا گیا۔

سب سے عام پش بیک جو میں سنتا ہوں جب کوئی عمودی طور پر مربوط پلیٹ فارم کو دیکھتا ہے، "اگر میں چھوڑنا چاہوں تو کیا ہوگا؟”

یہ ایک منصفانہ سوال ہے، اور میں خود سے یہ سوال کرتا تھا۔ یہ ہے جو میں نے محسوس کیا: لاک ان کے بارے میں خدشات تقریبا ہمیشہ نظریاتی ہوتے ہیں اور ان لوگوں کے ذریعہ اٹھائے جاتے ہیں جنہوں نے حقیقت میں کبھی کسی پلیٹ فارم سے ہجرت نہیں کی۔

ایک حقیقی تالے کے لیے ملکیتی چیز کی ضرورت ہوتی ہے جس پر آپ کا کوڈ منحصر ہوتا ہے۔ یہ ایک حسب ضرورت SDK ہے جو صرف اس وینڈر کے ساتھ کام کرتا ہے۔ ایک استفسار کی زبان جو کہیں اور موجود نہیں ہے۔ یہ ایک تعیناتی ماڈل ہے جس کی ضرورت ہے کہ آپ اپنی ایپ کو چھوڑنے کے لیے دوبارہ لکھیں۔

اگر آپ کی ایپ ایک کنٹینر میں چلتی ہے، معیاری Postgres کنکشن سٹرنگز کا استعمال کرتی ہے، S3 کے ساتھ مواصلت کرنے کے لیے AWS SDKs کا استعمال کرتی ہے، اور معیاری پروٹوکولز کے ذریعے نوکریوں کو قطار میں شائع کرتی ہے، تو آپ مقفل نہیں ہیں۔ یہ بس کہیں تقسیم ہے۔ ہجرت کا راستہ ہے۔ pg_dumpبالٹی کاپی اور نیا docker push. ہم نے ایک ہفتے کے آخر میں ایسی ہجرت کی۔

وہ پلیٹ فارم جو درحقیقت لاک ان تخلیق کرتا ہے وہ ہے جو ہر چیز کو اپنی ملکیتی پرت میں خلاصہ کرتا ہے۔ اپنی مرضی کے مطابق رن ٹائم کے ساتھ سرور لیس افعال۔ ملکیتی استفسار کی صلاحیتوں کے ساتھ وینڈر کے لیے مخصوص ڈیٹا بیس۔ ایج کمپیوٹنگ جو صرف ایک نیٹ ورک پر موجود ہے۔ یہ سوال کرنے کے لائق چیزیں ہیں۔

جہاں ہر متبادل واقعی ٹوٹ جاتا ہے۔

رینڈر تجویز کرنے میں سب سے آسان اور بڑھانا آسان ہے۔ Next.js ایپس کو تعینات کریں اور نظم شدہ پوسٹگریس حاصل کریں۔

مسئلہ 3 ماہ کے آس پاس ظاہر ہوتا ہے جب پس منظر کے کام اور آبجیکٹ اسٹوریج کی ضرورت ہوتی ہے۔ رینڈرنگ میں ایک یا دوسرا بطور ڈیفالٹ نہیں ہوتا ہے۔

لہذا قطاروں کے لیے Upstash اور اسٹوریج کے لیے AWS S3 استعمال کریں۔ اب آپ کے پاس 3 ڈیش بورڈز، 3 بلنگ تعلقات، اور 3 نیٹ ورکس ہیں جن کو ایک دوسرے پر بھروسہ کرنے کی ضرورت ہے۔ تعیناتی کے مرحلے میں چند منٹ لگتے ہیں۔ آس پاس کی ہر چیز میں ایک دوپہر لگتی ہے۔

ریلوے رینڈر سے زیادہ مربوط محسوس ہوتا ہے اور DX واقعی اچھا ہے۔ لیکن یہ AWS پر چلتا ہے۔ میں ٹیم پر تنقید نہیں کر رہا ہوں۔ یہ ایک ساختی حقیقت ہے جو بہاو کو متاثر کرتی ہے۔ جیسا کہ پہلے ذکر کیا گیا ہے، آپ Amazon مارجن کے اوپر ریلوے مارجن ادا کریں گے، اور آپ کے ایپس اور ڈیٹا بیس کے درمیان منتقل ہونے والا ڈیٹا اس بات پر منحصر ہے کہ ریلوے نے چیزوں کو کس طرح فراہم کیا ہے۔ ایک انوائس پر، اخراجات حیران کن نہیں لگتے۔ لیکن یہ مصنوعی ہے۔

Fly.io نے سب سے دلچسپ آرکیٹیکچرل شرطوں میں سے ایک بنایا۔ ہم ساختی طور پر دوہری مارجن کے مسئلے کو حقیقی ہارڈ ویئر کے ساتھ ہائپر اسکیلر کے بغیر حل کرتے ہیں۔ \

میں نے فلائی پر تعینات کیا اور کنارے پر کارکردگی حقیقی ہے۔ تاہم، کمپیوٹ اور پوسٹگریس اب بھی الگ الگ چیزیں ہیں جو آپس میں جڑتی ہیں۔ اسٹوریج اب بھی ایک بیرونی گفتگو ہے۔ یہ احساس کہ "سب کچھ منسلک ہے” موجود نہیں ہے۔ کیونکہ کنکشن اب بھی آپ کا ہے۔

"میں صرف ہیروکو جیسا کچھ چاہتا ہوں” عوام کو درحقیقت جس کی ضرورت ہے۔

میں نے اس کے بارے میں بہت سوچا ہے اور مجھے لگتا ہے کہ پرانی یادیں حقیقی ہیں لیکن غلط سمت میں ہیں۔

لوگ خاص طور پر ہیروکو نہیں چاہتے۔ وہ یہ محسوس کرنا چاہتے ہیں کہ ان کا بنیادی ڈھانچہ کسی اور کا مسئلہ ہے۔ اس لیے نہیں کہ اسے ہینڈل نہیں کیا جا سکتا، بلکہ اس لیے کہ اسے ہینڈل کرنا اس لیے نہیں ہے کہ آپ سافٹ ویئر بنانے میں کیوں گئے۔ وہ کوڈ کو آگے بڑھانا اور کام کروانا چاہتے ہیں۔ جب کچھ غلط ہو جائے تو وہ یہ سب ایک جگہ پر دیکھنے کے قابل ہونا چاہتے ہیں۔ وہ ایسی قانون سازی چاہتے ہیں جسے وہ سمجھ سکیں۔

ہیروکو کے بعد آنے والے پلیٹ فارمز کو غلط چیزوں کے لیے بہتر بنایا گیا تھا۔ ہم نے انضمام کا کام آپ پر چھوڑ کر تعیناتی کے مرحلے کو آسان بنا دیا ہے۔ انہوں نے اسی بکھری ہوئی زمین کی تزئین کی بہتر رسائی سڑکیں فراہم کیں۔

زیادہ ایماندار راستہ ایک ایسا پلیٹ فارم ہے جو تعمیراتی فیصلے کرتا ہے جسے ہیروکو مکمل طور پر کرنے میں ناکام رہتا ہے۔ اس کا مطلب ہے کہ آپ ہارڈ ویئر کے مالک ہیں، نیٹ ورک کی سطح پر خدمات کو مربوط کرتے ہیں، ایک بل کا بل دیتے ہیں، اور ڈویلپرز کو کوڈ پر توجہ مرکوز کرنے دیتے ہیں۔

یہ خوشبو نہیں ہے۔ یہ وہی ہے جو سوال واقعی پوچھتا ہے۔\

ہیروکو کا ایک اور متبادل

میں نے جو دیکھا ہے وہ یہ ہے: Atlasflow۔ اسی نیٹ ورک پر کمپیوٹ، پوسٹگریس، S3 ہم آہنگ اسٹوریج اور قطاروں سے پہلے ننگی دھات۔ اور ایک بل۔

میں نے ابھی تک کوئی پروڈکشن ورک بوجھ نہیں چلایا ہے، اس لیے میں دباؤ میں استحکام سے بات نہیں کر سکتا۔ یہ اہمیت رکھتا ہے اور میں ایسا نہیں کرنے کا بہانہ نہیں کروں گا۔

لیکن آرکیٹیکچرل مباحثے علامات کی بجائے حقیقی مسائل کو حل کرنے کی سب سے ایماندارانہ کوشش ہے۔ دیگر تمام پلیٹ فارمز پر تعیناتی آسان ہے۔ اٹلس فلو پوچھ رہا ہے کہ کیا انضمام کو پہلی جگہ مسئلہ ہونا چاہئے تھا۔

یہ کوئی چھوٹا فرق نہیں ہے۔ بس۔

میں تقریباً ایک دہائی سے پروڈکشن ایپس بنا رہا ہوں، اور ہمارے بنیادی ڈھانچے کا ماحول تقریباً ہر قابل پیمائش طریقے سے بہتر ہوا ہے۔ انضمام کے مسائل اب بھی بڑی حد تک حل طلب ہیں۔