ہر پروڈکشن انجینئرنگ ٹیم پیٹرن کو جانتی ہے۔ نئے منصوبے توانائی سے شروع ہوتے ہیں۔ مصنوعات کے مقاصد واضح ہیں۔ ڈیڈ لائن مہتواکانکشی ہیں۔ ٹیم تیزی سے آگے بڑھنا چاہتی ہے اور ایسی چیز فراہم کرنا چاہتی ہے جسے صارفین استعمال کر سکیں۔
پھر اصل کام شروع ہوتا ہے۔ آپ کو انفراسٹرکچر فراہم کرنے کی ضرورت ہے۔ آپ کو ایک CI/CD پائپ لائن قائم کرنے کی ضرورت ہے۔ راز انتظام کی ضرورت ہے. نگرانی کے لیے وائرنگ کی ضرورت ہوتی ہے۔ ڈیٹا بیس کی تعیناتی کی ضرورت ہے۔ لاگنگ کنفیگریشن کی ضرورت ہے۔ سیکیورٹی پالیسیوں پر عمل درآمد کیا جائے۔ آپ کو اپنے نیٹ ورکنگ کے قوانین کا جائزہ لینا چاہیے۔
صارفین کو مفید معلومات دیکھنے میں کئی ہفتے لگ سکتے ہیں۔ بہت سی تنظیمیں اس کو معمول سمجھتی ہیں۔ وہ اسے انجینئرنگ سختی کہتے ہیں۔ وہ فرض کرتے ہیں کہ یہ آپریشنل سیٹ اپ مرحلہ صرف سافٹ ویئر ڈویلپمنٹ کا حصہ ہے۔
یہ سچ نہیں ہے۔
پہلے سے پروڈکشن سسٹم چلانے والی ٹیموں کے لیے، ہر نئے پروجیکٹ کے لیے بنیادی ڈھانچے کی بنیاد کو دوبارہ بنانا تنظیم کے لیے ایک نالی ہے۔ یہ انجینئرنگ کے نظم و ضبط کے بھیس میں دہرائی جانے والی آپریشنل لیبر ہے۔
غیر آرام دہ سوال یہ نہیں ہے کہ "میں اس سیٹ اپ کو تیزی سے کیسے حاصل کر سکتا ہوں؟” اصل سوال یہ ہے کہ: ہم اب بھی اپنے ساتھ ایسا کیوں کر رہے ہیں؟
یہ وہ جگہ ہے جہاں پلیٹ فارم بطور سروس گفتگو کو تبدیل کرتا ہے۔ ایک اچھا PaaS نقطہ آغاز کو "فاؤنڈیشن کی تعمیر نو” سے "شپنگ شروع کریں” میں منتقل کرتا ہے۔ کیونکہ نئے پراجیکٹس کو انفراسٹرکچر اسمبلی کے بجائے کسٹمر ویلیو کے قریب سے شروع ہونا چاہیے۔
اس آرٹیکل میں، ہم دیکھیں گے کہ کیوں بہت سی پروڈکشن ٹیمیں ہر نئے پروجیکٹ کے لیے ایک ہی انفراسٹرکچر کو دوبارہ بنانے میں وقت ضائع کرتی ہیں، PaaS اس کام کو ختم کرنے میں کس طرح مدد کر سکتا ہے، اور انجینئرنگ ٹیموں کو یہ کیوں پوچھنا چاہیے کہ کیا پیچیدہ انفراسٹرکچر مینجمنٹ اب بھی زیادہ تر پروجیکٹس کے لیے موزوں ہے۔
ہم کیا احاطہ کریں گے:
بنیادی ڈھانچے کی تعمیر کے لیے زیادہ تر ٹیم کی خدمات حاصل نہیں کی گئیں۔
کاروباری مسائل کو حل کرنے کے لیے سافٹ ویئر ٹیمیں موجود ہیں۔ صارفین کو اس بات کی پرواہ نہیں ہے کہ آیا ان کا کبرنیٹس مینی فیسٹ خوبصورتی سے بنایا گیا ہے۔ انہیں احتیاط سے ڈیزائن کیے گئے ٹیرافارم ماڈیولز کا کوئی احترام نہیں ہے۔ وہ ہاتھ سے تیار کردہ نیٹ ورکنگ پالیسیوں کا خیرمقدم نہیں کرتے ہیں۔
صارفین نتائج کی پرواہ کرتے ہیں۔ وہ تیزی سے آن بورڈنگ میں دلچسپی رکھتے ہیں۔ بہتر تجویز۔ ہموار ادائیگی۔ کم کیڑے۔ آسان ورک فلو۔
تاہم، بہت سی انجینئرنگ تنظیمیں کام کرنے میں بہت زیادہ وقت صرف کرتی ہیں جو صارفین کبھی نہیں دیکھتے ہیں۔
ٹیمیں بار بار تعیناتی پائپ لائنز بناتی ہیں۔ اپنے ماحول کو ترتیب دیں۔ سرٹیفکیٹس کا نظم کریں۔ مشاہداتی اسٹیک قائم کریں۔ بنیادی ڈھانچے کے قواعد کو ایڈجسٹ کریں۔ کلاؤڈ پرائمیٹو کو جمع کریں۔
بنیادی ڈھانچہ اہم ہے۔ وشوسنییتا اہم ہے۔ سیکیورٹی اہم ہے۔
مسئلہ نقل کا ہے۔ اگر ہر پروجیکٹ آزادانہ طور پر ایک ہی آپریٹنگ سسٹم کو دوبارہ بناتا ہے، تو تنظیم اسے تسلیم کیے بغیر اپنے اندرونی پلیٹ فارم کی تعمیر نو جاری رکھتی ہے۔
یہ رویہ اتنا عام ہو گیا ہے کہ ٹیمیں اس پر بمشکل توجہ دیتی ہیں۔ لیکن ایک ہی بنیاد کو بار بار دوبارہ بنانا آپریشنل میچورٹی نہیں ہے۔ اس سے پورے ادارے میں ناکارہیاں پیدا ہوتی ہیں۔
AWS پرائمیٹوز ایک مسابقتی فائدہ نہیں ہیں۔
بہت سی ٹیمیں کلاؤڈ کی ملکیت کو اسٹریٹجک فوائد کے ساتھ الجھاتی ہیں۔ Kubernetes کلسٹر کا مالک ہونا آپ کو مختلف نہیں بناتا ہے۔ IAM اصول کا انتظام گاہک کی قدر پیدا نہیں کرتا ہے۔ انفراسٹرکچر گلو کوڈ لکھنے سے آپ کی مارکیٹ کی پوزیشن مضبوط نہیں ہوگی۔
نفاذ کی تفصیلات۔ تاہم، بہت سی تنظیمیں ان کا انتظام کرنے میں بہت زیادہ توانائی خرچ کرتی ہیں گویا وہ بنیادی کاروباری اثاثے ہیں۔
کچھ ٹیمیں انجانے میں پارٹ ٹائم انفراسٹرکچر کمپنیاں بن جاتی ہیں۔ انجینئرز آہستہ آہستہ آپریشنل ذمہ داریاں جمع کرتے ہیں جب تک کہ نظام کی دیکھ بھال پروڈکٹ کی ترسیل کے مقابلے میں زیادہ محنت نہ کرے۔
نتائج متوقع ہو جاتے ہیں۔ انفراسٹرکچر پھیلتا ہے۔ آپریشنل پیچیدگی بڑھ جاتی ہے۔ ترسیل کی رفتار سست ہے۔ کوئی بھی نوٹس نہیں کرتا کیونکہ درد آہستہ آہستہ آتا ہے۔
ٹیم ایک Kubernetes کلسٹر کے ساتھ شروع ہوتی ہے۔ پھر ایک اور ماحول نظر آئے گا۔ مزید تعیناتی پائپ لائنیں ابھر رہی ہیں۔ اضافی ٹولز سب سے اوپر اسٹیک ہیں۔ لاگنگ سسٹم بکھرا ہوا ہے۔ نگرانی ہر پروڈکٹ کے لیے مختلف طریقے سے تیار ہوتی ہے۔
بالآخر، آپ کی ٹیم ایسے نظاموں کو برقرار رکھنے میں زیادہ سے زیادہ وقت صرف کرتی ہے جس کا ان کا کبھی ارادہ نہیں تھا۔
بنیادی ڈھانچے کی ملکیت اکثر حکمت عملی نہیں ہوتی ہے۔ یہ جڑتا ہے۔
زیادہ تر ٹیموں کو کبرنیٹس کا انتظام نہیں کرنا چاہیے۔
Kubernetes ایک انجینئرنگ ثقافت بن گیا ہے. یہ فن تعمیر کے خاکوں، کانفرنس کے مذاکرات، ملازمت کی ضروریات، اور اندرونی روڈ میپس میں ظاہر ہوتا ہے۔ گود لینا اکثر ناگزیر محسوس ہوتا ہے۔
لیکن باقاعدگی اور ضرورت ایک چیز نہیں ہے۔ بہت سی تنظیموں نے Kubernetes کو اپنایا ہے کیونکہ صنعت کی رفتار نے اسے پہلے سے طے شدہ راستہ بنا دیا ہے۔ یہ اس لیے نہیں تھا کہ میرے پاس کام کا بوجھ تھا جس میں پیچیدگی کی ضرورت تھی۔ لیکن نتائج متوقع ہیں۔
چھوٹے سے درمیانے درجے کی ٹیمیں بڑے پیمانے پر آپریشنل ماحول کے لیے ڈیزائن کیے گئے آرکیسٹریشن سسٹم کا انتظام کرتی ہیں۔
بامعنی پروڈکٹ ویلیو ڈیلیور کرنے سے پہلے YAML کنفیگریشن، نیٹ ورکنگ پرت، وصول کرنے والے نظام، تعیناتی کی حکمت عملی، اور آپریشنل ٹول اسٹیک کو برقرار رکھیں۔ یہ بات عجیب سمجھی جاتی تھی۔
10 افراد پر مشتمل ایک انجینئرنگ ٹیم جو بنیادی ڈھانچے کے نمونوں کو برقرار رکھتی ہے جو انٹرنیٹ کے پیمانے پر تنظیم کے لیے ڈیزائن کیا گیا ہے، سنجیدہ سوالات پوچھنا چاہیے۔ پلیٹ فارم ٹیموں کا بہانہ کرنے والی چھوٹی ٹیمیں ایک آپریشنل مسئلہ ہیں۔
بہت سی کمپنیاں مختلف سائز میں کام کرنے والی تنظیموں کے لیے بنائے گئے بنیادی ڈھانچے کی پیچیدگی کو اپنا رہی ہیں۔ وہ وراثت کے فوائد کے بغیر بوجھ کے وارث ہوتے ہیں۔
PaaS نقطہ آغاز کو تبدیل کرتا ہے۔
روایتی بنیادی ڈھانچے کا نقطہ نظر ٹیموں کو نیچے سے سوچنے پر مجبور کرتا ہے۔ سرور پہلے آتا ہے۔ پھر آپریٹنگ سسٹم۔ پھر نیٹ ورکنگ۔ پھر تقسیم کا نظام۔ پھر اس کی نگرانی کریں۔ درخواست آخرکار پہنچ جاتی ہے۔
PaaS اس حکم کو الٹ دیتا ہے۔ ڈویلپرز ایپلیکیشن اور کاروباری اہداف کے ساتھ شروع کرتے ہیں۔ پلیٹ فارم آپریشنل پیچیدگی کو جذب کرتا ہے۔
ٹیمیں نہیں پوچھتی ہیں، "میں وسائل کیسے فراہم کروں؟” وہ پوچھنے لگتے ہیں، "ہم کون سا مسئلہ حل کر رہے ہیں؟” یہ ایک چھوٹی سی تبدیلی کی طرح لگتا ہے۔ اصل میں، یہ سب کچھ بدل دیتا ہے.
میچور PaaS ماحول اکثر تعیناتی پائپ لائنز، مربوط مشاہدہ، ڈیٹا بیس، اسکیلنگ کے رویے، سیکورٹی کنٹرول، اور آپریشنل معیارات فراہم کرتے ہیں اس سے پہلے کہ ٹیمیں بامعنی ایپلیکیشن منطق لکھ سکیں۔
منصوبے بنیادی ڈھانچے کی تعمیر کے بجائے مصنوعات کی ترقی سے شروع ہوتے ہیں۔ یہ ڈرامائی طور پر وقت کی قدر کو تبدیل کرتا ہے۔
تکرار سے پوشیدہ بافتوں کا فضلہ پیدا ہوتا ہے۔
تنظیمیں اکثر آپریشنل فضلہ کو کم سمجھتی ہیں کیونکہ دہرائے جانے والے کام واقف محسوس ہوتے ہیں۔ ایک تعیناتی پائپ لائن کو ترتیب دینے میں صرف چند دن لگ سکتے ہیں۔ لاگنگ کو ترتیب دینا معمول کا احساس کر سکتا ہے۔ حفاظتی اصول بنانا قابل انتظام لگ سکتا ہے۔
انفرادی آپریشن مہنگا نہیں لگتا۔ لاگتیں ابھرتی ہیں جب تکرار پھیلتی ہے۔
اگر 10 پروجیکٹ آزادانہ طور پر تقریباً ایک جیسے آپریٹنگ سسٹمز کو دوبارہ بنانے میں دو ہفتے صرف کرتے ہیں، تو مہینوں کی انجینئرنگ کی صلاحیت ضائع ہو جاتی ہے۔ وہ انجینئر صارفین کو صلاحیتیں بھی فراہم کر سکتے ہیں۔ رگڑ کو بھی کم کیا جا سکتا ہے۔ وہ نئے خیالات کی جانچ بھی کر سکتے تھے۔ اس کے بجائے، انہوں نے پائپ دوبارہ بنائے۔
ہماری انجینئرنگ ٹیم تقریباً ہر شعبے میں اثرات کو سمجھتی ہے۔ کوئی بھی ہر درخواست کے لیے چھانٹنے والے الگورتھم کو دوبارہ نہیں لکھنا چاہتا ہے۔ کوئی بھی شروع سے ڈیٹا بیس انجن کو دوبارہ نہیں بنا رہا ہے۔ کوئی بھی اپنے نیٹ ورکنگ اسٹیک کو تکراری طور پر نہیں بناتا ہے۔
دوبارہ استعمال کو انجینئرنگ کی بنیادی حکمت کے طور پر قبول کیا جاتا ہے۔ بنیادی ڈھانچے کو خصوصی علاج نہیں ملنا چاہئے۔ اسے ایک بار بنائیں۔ کئی بار دوبارہ استعمال کریں۔
PaaS آپریٹنگ سسٹمز پر سافٹ ویئر انجینئرنگ کے اصولوں کو آسانی سے لاگو کرتا ہے۔
معیاری کاری عام طور پر لچک سے زیادہ تیز ہوتی ہے۔
انجینئرنگ ٹیمیں اکثر کنٹرول کھونے کے خوف سے معیاری بنانے کی مزاحمت کرتی ہیں۔ ہر پروجیکٹ منفرد محسوس ہوتا ہے۔ ہر نظام مختلف نظر آتا ہے۔ لچک کی خواہش معقول لگتی ہے۔
تاہم، مکمل لچک اکثر آپریشنل افراتفری کا باعث بنتی ہے۔ مختلف ٹیمیں ایپلیکیشنز کو مختلف طریقے سے تعینات کرتی ہیں۔ لاگنگ متضاد کام کرتی ہے۔ مانیٹرنگ سسٹم سے سسٹم میں مختلف ہوتی ہے۔ حفاظتی عمل درآمد میں اضافہ۔
دستاویز کا ٹکڑا۔ آن بورڈنگ سست ہے۔ واقعہ کا جواب مشکل ہو جاتا ہے۔ پیچیدگی خاموشی سے جمع ہوتی ہے۔
چونکہ PaaS رکاوٹوں کے ساتھ آتا ہے، بہت سے انجینئرز فطری طور پر ان کی مزاحمت کرتے ہیں۔ آپ کو ایسا نہیں کرنا چاہیے۔ مفید رکاوٹیں اکثر رفتار میں اضافہ کرتی ہیں۔
متوقع تعیناتی کے پیٹرن الجھن کو کم کرتے ہیں۔ مشترکہ نگرانی کے معیارات ٹربل شوٹنگ کو آسان بناتے ہیں۔ ایک مستقل ماحول علمی اوور ہیڈ کو کم کرتا ہے۔
ڈویلپرز بنیادی ڈھانچے کے فرق کو سمجھنے میں کم توانائی خرچ کرتے ہیں اور مصنوعات کی خصوصیات کی فراہمی میں زیادہ وقت صرف کرتے ہیں۔
مستقل مزاجی کا مرکب۔
پلیٹ فارم ٹیم ایک ضرب بن جاتی ہے۔
بہت سی تنظیمیں PaaS کو وینڈر پروڈکٹ کی خریداری سے تعبیر کرتی ہیں۔ اس سے بڑا خیال غائب ہے۔
PaaS بنیادی طور پر دوبارہ قابل استعمال افعال بنانے کے بارے میں ہے۔ کچھ تنظیمیں پلیٹ فارم خریدتی ہیں۔ دوسرے اندرونی پلیٹ فارم بناتے ہیں۔
اصول وہی رہتے ہیں۔
پلیٹ فارم ٹیم ایک بار سسٹم بناتی ہے اور اس بات کو یقینی بناتی ہے کہ باقی سب اس سے فائدہ اٹھا سکیں۔ آپریشنل مسائل کو آزادانہ طور پر حل کرنے والی درجنوں پروڈکٹ ٹیموں کے بجائے، ایک سرشار گروپ مہارت کو مرکزی بناتا ہے اور دوبارہ قابل استعمال حل تیار کرتا ہے۔
اثر نمایاں ہو جاتا ہے۔ ایک تعیناتی میں بہتری مستقبل کی تمام ریلیز کو تیز کرتی ہے۔ ایک مرئیت میں بہتری آپ کی تمام ایپلیکیشنز کو بہتر بناتی ہے۔ اپنی پوری ٹیم کو ایک حفاظتی اضافہ کے ساتھ محفوظ رکھیں۔
پلیٹ فارم ٹیمیں تنظیمی اثر پیدا کرتی ہیں۔ اس ماڈل کے بغیر، مہارت بکھری رہتی ہے۔ یہ ماہر علم کی ترکیب کرتا ہے۔
آسانی سے شروع کریں، مزید جدت پیدا کریں۔
آپریشنل رگڑ رویے کو تبدیل کرنے کا سبب بنتا ہے۔ جب کوئی پروجیکٹ شروع کرنا مہنگا ہوتا ہے تو تنظیمیں محتاط ہوجاتی ہیں۔ ٹیم تجربات سے گریز کرتی ہے۔ چھوٹے خیالات خطرناک محسوس کرتے ہیں۔ پروٹو ٹائپ کا جواز پیش کرنا مشکل ہو جاتا ہے۔
وقت گزرنے کے ساتھ، جدت کم ہوتی جاتی ہے۔ ایسا نہیں ہے کہ آپ کی تنظیم میں آئیڈیاز کی کمی ہے، یہ ہے کہ شروع کرنا بہت مہنگا ہے۔
بالغ پلیٹ فارم چلانے والی ٹیمیں ان تعلقات کو سمجھتی ہیں۔ شروع ہونے والی رگڑ کو کم کرنے سے تجربات میں اضافہ ہوتا ہے۔ چھوٹے منصوبے حقیقت بن جاتے ہیں۔ سیکھنے کا چکر چھوٹا ہو جاتا ہے۔
نئے خیالات زیادہ کثرت سے ابھرتے ہیں کیونکہ ان کی جانچ کی لاگت ڈرامائی طور پر گر گئی ہے۔ کسی چیز کو شروع کرنا جتنا آسان ہوگا، آپ کی تنظیم اتنے ہی زیادہ مواقع پیدا کرے گی۔
PaaS اسٹارٹ اپ رگڑ کو کم کرتا ہے۔ یہ زوال ثقافت کو بدل دیتا ہے۔
جب خصوصی کنٹرول واقعی اہمیت رکھتا ہے۔
مستثنیات ہیں. بڑے ڈیٹا پلیٹ فارمز، انتہائی مخصوص مشین لرننگ سسٹم، اور انتہائی حسب ضرورت ماحول کے لیے بنیادی ڈھانچے کی ملکیت کی کم سطح کی ضرورت ہو سکتی ہے۔
کچھ کام کے بوجھ کو درحقیقت گہرے آپریشنل کنٹرول کی ضرورت ہوتی ہے۔ تاہم، یہ منظرنامے مستثنیٰ ہیں، طے شدہ نہیں۔ بہت ساری ٹیمیں بنیادی ڈھانچے کی پیچیدگی کو وراثت میں رکھتی ہیں جنہیں ایج کیسز کے لیے ڈیزائن کیا گیا ہے اور اسے معیاری مشق کے طور پر پیش کیا جاتا ہے۔
زیادہ تر پروڈکشن ایپلی کیشنز کو حسب ضرورت آرکیسٹریشن پرت کی ضرورت نہیں ہوتی ہے۔ زیادہ تر ٹیموں کو Kubernetes کے مالک ہونے کی ضرورت نہیں ہے۔ زیادہ تر انجینئرنگ گروپس کو سافٹ ویئر جاری کرنے سے پہلے انفراسٹرکچر کو جمع کرنے میں ہفتوں گزارنے کی ضرورت نہیں ہوتی ہے۔
پہلے سے طے شدہ مفروضہ اس کے برعکس ہونا چاہیے۔
0 سے شروع کرنا ایک عمل کی ناکامی ہے۔
بہت سی تنظیمیں غیر ضروری آپریشنل تاخیر کو معیاری بناتی ہیں۔ طویل سیٹ اپ سائیکلوں کی اجازت ہے۔ انفراسٹرکچر کی نقل عام ہو گئی ہے۔ بادل کی پیچیدگی متوقع ہے۔
آخر کار ٹیم اس کے بارے میں سوالات پوچھنا چھوڑ دیتی ہے۔ وہ فرض کرتے ہیں کہ انجینئرنگ اس طرح کام کرتی ہے۔ یہ سچ نہیں ہے۔
نئی ایپلیکیشن کو رول آؤٹ کرنے کے لیے کسٹمر ویلیو کے سامنے آنے سے پہلے بیس لائن سیٹ اپ کے ہفتوں کی ضرورت ہوتی ہے، لیکن یہ انجینئرنگ نہیں ہے۔
مقصد کبھی بھی انفراسٹرکچر کمپنی نہیں بننا تھا۔ یہ سافٹ ویئر بھیجنا تھا۔