ہر کمپنی کہتی ہے کہ وہ رفتار چاہتے ہیں۔
روڈ میپ رفتار کے بارے میں بات کرتے ہیں۔ قیادت کے اجلاسوں میں، ہم سائیکل کے اوقات کو کم کرنے کے بارے میں بات کرتے ہیں۔ سہ ماہی اہداف تیزی سے عملدرآمد اور تیز ریلیز کے بارے میں بات کرتے ہیں۔
ہر کاروبار چاہتا ہے کہ اس کی ٹیمیں تیزی سے آگے بڑھیں۔
اور پھر ان میں سے بہت سی کمپنیاں خاموشی سے ایسے فیصلے کرتی ہیں جو ہر چیز کو سست کر دیتی ہیں۔ مصنوعات کی ترسیل کے بجائے بنیادی ڈھانچے کی لچک کو بہتر بنائیں۔
یہ سب سے پہلے معقول لگتا ہے۔ ٹیمیں کنٹرول چاہتی ہیں۔ انجینئرز آپشن چاہتے ہیں۔ پلیٹ فارم ڈیزائنرز ایسے نظام چاہتے ہیں جو مستقبل کے تمام منظرناموں کو سپورٹ کر سکیں۔
لہذا، پروڈکشن ٹیمیں اپنے ارد گرد ایک بنیادی ڈھانچے کا ماحولیاتی نظام بنانا شروع کر دیتی ہیں۔
تعیناتی پائپ لائن شروع سے بنائی گئی ہے۔ کلاؤڈ وسائل انتہائی حسب ضرورت ہیں۔ اندرونی پلیٹ فارم میں لامتناہی نوبس، سوئچز اور کنفیگریشن کی پرتیں ہیں۔ نئے منصوبے فن تعمیر کے مباحثوں سے شروع ہوتے ہیں، نہ کہ کسٹمر کے مسائل سے۔
کچھ مہینوں کے بعد، سافٹ ویئر کی ترسیل سست ہو جاتی ہے۔
پروڈکٹ ٹیم کا شیڈول غائب ہے۔ ریلیز سہ ماہی ہوتی ہے۔ کسٹمر کی رائے بعد میں آتی ہے۔ حریف شپنگ کرتے رہتے ہیں۔
ان سب کے پیچھے تجارت آسان ہے۔ ٹیمیں اصل میں ڈیلیور کرنے پر لچک کا انتخاب کرتی ہیں۔
اور ایک خاص نقطہ سے آگے، لچکدار سب سے مہنگے تنظیمی خلفشار میں سے ایک بن جاتا ہے جو کمپنی پیدا کر سکتی ہے۔
ہم کیا احاطہ کریں گے:
یہ افسانہ کہ زیادہ لچک ایک بہتر پیداواری نظام بناتی ہے۔
انجینئرنگ ٹیموں کو اختیار پسند ہے۔ منطق قائل معلوم ہوتی ہے۔
اپنے بنیادی ڈھانچے کو مکمل طور پر اپنی مرضی کے مطابق بنانے کے قابل ہونا آپ کی ٹیم کو مستقبل کی ضروریات کے مطابق ڈھالنے کی اجازت دیتا ہے۔ گھر میں تعیناتی کے نظام کی تعمیر ہمیں استعمال کے تمام معاملات میں مدد کرنے کی اجازت دیتی ہے۔ تمام پرتوں کو ترتیب دینے کے قابل ہونا انجینئرز کو اپنی منفرد صورتحال کے لیے بہتر بنانے کی اجازت دیتا ہے۔
یہ ذمہ دار انجینئرنگ کی طرح محسوس ہوتا ہے۔ تاہم، یہ اکثر ایک مہنگا کاروباری عمل ہوتا ہے۔
زیادہ تر پروڈکشن ٹیمیں اس بات کا زیادہ اندازہ لگاتی ہیں کہ انہیں کتنی بار بنیادی ڈھانچے کی گہری لچک کی ضرورت ہے۔
اصل میں جو کچھ ہوتا ہے وہ پیشین گوئی بن جاتا ہے۔
پروڈکٹ ٹیم ایک نئی پہل شروع کرتی ہے۔ ابتدائی ورژن جاری کرنے اور صارفین سے سیکھنے کے بجائے، بات چیت شروع ہو جاتی ہے۔
-
کیا Kubernetes کلسٹرز کو ٹیم یا سروس کے ذریعہ منظم کیا جانا چاہئے؟
-
کیا CI/CD کو GitHub ایکشنز یا جینکنز استعمال کرنا چاہئے؟
-
کیا مجھے اپنے رازوں کا انتظام کرنے کے لیے والٹ یا کلاؤڈ بیسڈ ٹول استعمال کرنا چاہیے؟
-
کیا مجھے مرئیت کے لیے Prometheus یا Datadog استعمال کرنا چاہیے؟
-
کیا آپ کی تعیناتی کی حکمت عملی میں کینری ریلیز، ٹیل کی تعیناتی، یا اپنی مرضی کے مطابق تعیناتیوں کا استعمال کرنا چاہیے؟
ریاست غائب ہو جاتی ہے۔ کوئی گاہک کچھ نہیں دیکھے گا۔ کسی مفروضے کی جانچ نہیں کی جاتی۔ کوئی پڑھائی نہیں ہوتی۔
دریں اثنا، پروڈکٹ مینیجر انتظار کرتے ہیں۔ قیادت منتظر ہے۔ صارفین انتظار کریں۔
یہاں تک کہ ایجنٹ کوڈنگ ٹولز جیسے کلاڈ جنریٹڈ کوڈ، اسکافولڈنگ سسٹمز، اور عمل درآمد میں سرعت کے ساتھ، ٹیمیں اب بھی رفتار کھو دیتی ہیں جب ہر آؤٹ پٹ انفراسٹرکچر کے فیصلوں اور تعیناتی کے مباحث سے متصادم ہوتا ہے۔
مسئلہ ٹیکنالوجی کا نہیں ہے۔ چیلنج موجودہ کاروباری نتائج کی بجائے نظریاتی مستقبل کی لچک کو بہتر بنانا ہے۔
جب صارفین اسے استعمال کرتے ہیں تو سافٹ ویئر قدر پیدا کرتا ہے۔ باقی سب کچھ سپورٹ کا کام ہے۔
بنیادی ڈھانچے کی ملکیت خاموشی سے ایک ثانوی کاروبار بن جاتا ہے۔
روایتی تعیناتی ماڈل نادانستہ طور پر خطرناک نمونے بناتے ہیں۔ کمپنیاں سوچتی ہیں کہ وہ پروڈکٹ بنا رہی ہیں۔ آہستہ آہستہ وہ ایک انفراسٹرکچر تنظیم بنانا شروع کر دیتے ہیں۔
پروڈکشن ٹیم سرورز کی فراہمی کرتی ہے۔ پھر نیٹ ورکنگ۔ پھر IAM سسٹم۔ پھر تعیناتی پائپ لائن. پھر مشاہداتی پرت۔ پھر خفیہ انتظام۔ پھر یہ آٹو اسکیلنگ کرتا ہے۔ پھر رول بیک سسٹم۔
ہر فیصلہ آزادانہ طور پر عقلی محسوس ہوتا ہے۔ لیکن اجتماعی طور پر، ٹیم ایک آپریٹنگ سسٹم بناتی ہے جسے اب وہ ہمیشہ کے لیے اپنے پاس رکھ سکتے ہیں۔
اور ملکیت وہ جگہ ہے جہاں پوشیدہ اخراجات ظاہر ہوتے ہیں۔
کیونکہ انفراسٹرکچر کا کام شروع ہونے کے بعد ختم نہیں ہوتا۔ یہ پھیلتا ہے۔ پائپ لائنوں کو دیکھ بھال کی ضرورت ہے۔ سیکیورٹی پالیسی میں تبدیلی۔ نگرانی کے نظام کو ٹیوننگ کی ضرورت ہوتی ہے۔ پلیٹ فارم پر انحصار ٹوٹ گیا ہے۔ اندرونی آلات کو اپ گریڈ کرنے کی ضرورت ہے۔
پروڈکشن ٹیمیں سافٹ ویئر کو بہتر بنانے کے بجائے سافٹ ویئر سے متعلقہ سسٹمز کو برقرار رکھنے میں زیادہ وقت صرف کرتی ہیں۔
اس کی وجہ سے ایک عجیب صورتحال پیدا ہوتی ہے۔ زیادہ معاوضہ لینے والے انجینئرز کسٹمر ویلیو بنانے کے بجائے انفراسٹرکچر کے رکھوالے بن جاتے ہیں۔
کوئی بھی گاہک آپ کا پروڈکٹ نہیں خریدتا کیونکہ آپ کی تعیناتی پائپ لائن زیادہ خوبصورت ہو گئی ہے۔ IAM پالیسیاں خوبصورتی سے ڈیزائن کی گئی ہیں، اس لیے کسٹمر اپ گریڈ کی ضرورت نہیں ہے۔ چونکہ Kubernetes YAML نفیس دکھائی دیتا ہے، کوئی بھی مدمقابل مارکیٹ شیئر نہیں کھوتا۔
صارفین ان مصنوعات میں دلچسپی رکھتے ہیں جو ان کے مسائل کو حل کرتی ہیں۔ انفراسٹرکچر صرف اس صورت میں اہم ہے جب یہ مصنوعات کی ترسیل کو سست کرتا ہے۔
اور بنیادی ڈھانچے کی ملکیت ایسا کرنے کے لامتناہی مواقع پیدا کرتی ہے۔
اصل قیمت کسٹمر سیکھنے میں تاخیر ہے۔
بنیادی ڈھانچے کی پیچیدگی کی سب سے بڑی قیمت انجینئرنگ کی کوشش نہیں ہے۔ سیکھنے میں تاخیر ہوتی ہے۔
سافٹ ویئر کمپنیاں فیڈ بیک لوپس کے ذریعے جیت جاتی ہیں۔ ٹیم کچھ بھیجتی ہے۔ صارفین جواب دیتے ہیں۔ ٹیم سیکھتی ہے۔ مصنوعات کو بہتر بناتا ہے.
یہ سائیکل جتنی تیزی سے جاتا ہے، کمپنی اتنی ہی مضبوط ہوتی جاتی ہے۔
انفراسٹرکچر کا کام اس لوپ کو توڑ دے گا۔ تعیناتی کے نظام کی تعمیر میں خرچ ہونے والا ہر مہینہ ایک ایسا مہینہ ہے جس میں صارفین کے ذریعہ نئی خصوصیات استعمال نہیں کی جاتی ہیں۔ کسٹمر کے تاثرات میں ہر سہ ماہی میں تاخیر ہوتی ہے کیونکہ ہم اپنا اندرونی پلیٹ فارم ڈیزائن کرتے ہیں۔ تمام آرکیٹیکچر مباحثے حقیقی مارکیٹ سگنلز میں تاخیر کرتے ہیں۔
یہ وہ جگہ ہے جہاں بہت سی تنظیمیں رفتار کو غلط سمجھتی ہیں۔
وہ سپرنٹ میٹرکس کو دیکھتے ہیں۔ مکمل شدہ ٹکٹوں کی پیمائش کریں۔ وہ انجینئرنگ کی کامیابیوں کا حساب لگاتے ہیں۔
لیکن کاروبار کی رفتار کو اندرونی سرگرمی سے نہیں ماپا جاتا ہے۔ کاروبار کی رفتار اس رفتار کی پیمائش کرتی ہے جس سے آپ کے خیالات آپ کے صارفین کے لیے حقیقت بن جاتے ہیں۔
بنیادی ڈھانچے کی ملکیت اس عمل کو نمایاں طور پر سست کر دیتی ہے۔ اور سست سیکھنے سے سست کمپنیاں بنتی ہیں۔
PaaS اصلاح کی صلاحیتوں کو تبدیل کرتا ہے۔
یہ وہ جگہ ہے جہاں پلیٹ فارم بطور سروس مساوات کو تبدیل کرتا ہے۔
PaaS تنظیموں کو بنیادی ڈھانچے کی ملکیت کے بجائے نقل و حمل کو بہتر بنانے پر مجبور کرتا ہے۔ یہ تبدیلیاں زیادہ تر ٹیموں کے احساس سے زیادہ اہم ہیں۔
تعیناتی کے فن تعمیر کو ڈیزائن کرنے میں ہفتوں گزارنے کے بجائے، پروڈکشن ٹیمیں ریپوزٹریوں کو مربوط اور تعینات کرتی ہیں۔
پائپ لائن کو دستی طور پر بنانے کے بجائے، پائپ لائن پہلے سے موجود ہے۔
اسکیلنگ سسٹم کو ڈیزائن کرنے کے بجائے، اسکیلنگ انجینئرنگ کے کام کے بجائے بنیادی ڈھانچے کا رویہ بن جاتی ہے۔
بار بار بنیاد بنانے کے بجائے، انفراسٹرکچر ایک افادیت بن جاتا ہے۔
یہ سادہ لگتا ہے۔ یہ سادہ ہونا چاہیے۔ تعیناتی تھکاوٹ محسوس کرنا چاہئے. تاہم، یہ حقیقت کہ تعیناتیاں اکثر کسی تنظیم کے لیے ایک بڑا منصوبہ ہوتا ہے، عام طور پر ناگزیر پیچیدگی کے بجائے غیر ضروری پیچیدگی کا ثبوت ہوتا ہے۔
PaaS فراہم کرنے والے فیصلوں کے پورے زمرے کو ختم کر دیتے ہیں۔ بہت سے انجینئرز اسے ایک سمجھوتے کے طور پر دیکھتے ہیں، لیکن اکثر اس کے برعکس ہوتا ہے۔
رکاوٹیں رفتار پیدا کرتی ہیں۔ رفتار سیکھنے کو جنم دیتی ہے۔ سیکھنا بہتر مصنوعات تیار کرتا ہے۔
اعلی پروڈکشن ٹیمیں فیصلوں کو ختم کرتی ہیں۔
ایک عام غلط فہمی ہے کہ اشرافیہ انجینئرنگ تنظیمیں اختیارات کو زیادہ سے زیادہ کرتی ہیں۔ اکثر اس کے برعکس سچ ہوتا ہے۔
اعلی کارکردگی کا مظاہرہ کرنے والی پروڈکشن ٹیمیں فعال طور پر فیصلوں کو چھوڑ دیتی ہیں۔ وہ معیاری بناتے ہیں۔ وہ ڈیفالٹس بناتے ہیں۔ غیر ضروری انتخاب کو ہٹا دیں۔
کیونکہ ہر فیصلہ قیمت کے ساتھ آتا ہے۔
علمی بوجھ بڑھتا ہے۔ ہم آہنگی بڑھ جاتی ہے۔ ملاقاتیں بڑھ رہی ہیں۔ انحصار بڑھا رہے ہیں۔ بالآخر، حل سافٹ ویئر خود سافٹ ویئر سے بڑا ہو جاتا ہے.
PaaS نظام ایک مختلف فلسفے کی پیروی کرتے ہیں۔ جان بوجھ کر انتخاب کو کم کرتا ہے۔
یہ کمی توجہ پیدا کرتی ہے۔ اور توجہ مصنوعات میں رفتار پیدا کرتی ہے۔ مصنوعات کی رفتار کاروباری نتائج کو آگے بڑھاتی ہے۔
سلسلہ سادہ ہے۔ بہت ساری تنظیمیں بنیادی ڈھانچے کی ملکیت کو بہت جلد اپنا کر اس اصول کو توڑ دیتی ہیں۔
حسب ضرورت بنیادی ڈھانچہ عام طور پر ایسے مسائل کو حل کرتا ہے جنہیں ابھی تک کسی نے حل نہیں کیا ہے۔
سافٹ ویئر کمپنیوں میں سب سے مہنگی عادات میں سے ایک موجودہ مسائل کے موجود ہونے سے پہلے مستقبل کے مسائل کو حل کرنا ہے۔
ٹیمیں اسکیل موجود ہونے سے پہلے اسکیل بناتی ہیں۔ بین الاقوامی صارفین کے آنے سے پہلے ایک کثیر علاقائی فن تعمیر بنائیں۔ تعیناتی کے مسائل ظاہر ہونے سے پہلے ایک تعیناتی فریم ورک بنائیں۔
یہ عام طور پر اچھے ارادوں سے آتا ہے۔ انجینئرز مستقبل میں دوبارہ لکھنے سے بچنا چاہتے ہیں۔ لیکن ستم ظریفی یہ ہے کہ ابتدائی لچک فوری طور پر کاروباری سست روی کا باعث بنتی ہے۔
20 انجینئروں کے ساتھ اسٹارٹ اپ کو 10,000 انجینئروں والی کمپنی کی طرح کام نہیں کرنا چاہئے۔ تاہم، بہت سی پروڈکشن ٹیمیں بڑی ٹیک کمپنیوں کے بنیادی ڈھانچے کے نمونوں کی نقل کرتی ہیں۔
جس چیز کو نظر انداز کیا جاتا ہے وہ سیاق و سباق ہے۔ بڑی ٹیکنالوجی کمپنیوں کے پاس پلیٹ فارم کی پوری ٹیمیں ہیں جو اپنے اندرونی نظام کو برقرار رکھتی ہیں۔ ہمارے پاس ہزاروں انجینئرز ہیں جو انفراسٹرکچر کی سرمایہ کاری کی حمایت کرتے ہیں۔
زیادہ تر کمپنیاں ایسا نہیں کرتی ہیں۔
تنظیم کے سائز کو کاپی کیے بغیر تکنیکی فن تعمیر کو کاپی کرنا بڑے پیمانے پر نااہلیاں پیدا کرتا ہے۔
PaaS اس رویے کے خلاف تحفظ کے طور پر کام کرتا ہے۔ یہ آپ کی ٹیم کو ایک کامیاب پروڈکٹ کمپنی بننے سے پہلے غلطی سے انفراسٹرکچر کمپنی بننے سے روکتا ہے۔
حقیقی مسابقتی فائدہ تیز ترسیل ہے۔
بنیادی ڈھانچے کی لچک کی کمی کی وجہ سے کمپنیاں شاذ و نادر ہی رقم کا نقصان کرتی ہیں۔ وہ ہار گئے کیونکہ ان کے حریف تیزی سے سیکھتے تھے۔
رفتار اہم ہے۔ یہ سپرنٹ یا لکیری ڈیش بورڈز میں تیز نہیں ہے۔ یہ کہانی کے پوائنٹس کی رفتار نہیں ہے۔
اصل رفتار۔ خیالات کو تیزی سے پیداوار میں منتقل کرنے کی صلاحیت۔ مفروضوں کو تیزی سے جانچنے کی صلاحیت۔ مسلسل سیکھنے کی صلاحیت۔
ترسیل سیکھنے کو جنم دیتی ہے۔ سیکھنے سے بہتری پیدا ہوتی ہے۔ بہتری فوائد پیدا کرتی ہے۔
بنیادی ڈھانچے کی پیچیدگی اس لوپ کو توڑ دیتی ہے۔ PaaS اسے مضبوط کرتا ہے۔
یہی وجہ ہے کہ تعیناتی کے فیصلوں کو خالصتاً تکنیکی بات چیت کے طور پر نہیں سمجھا جانا چاہیے۔ یہ ایک کاروباری فیصلہ ہے۔
انفراسٹرکچر کی ملکیت کمپنی کی رفتار کو متاثر کرتی ہے۔ رفتار مارکیٹ کے نتائج کو متاثر کرتی ہے۔
بحث سرورز کے بارے میں نہیں ہے۔ بحث مسابقتی رفتار کے بارے میں ہے۔
جب PaaS صحیح انتخاب نہیں ہوسکتا ہے۔
ایسے حالات ہیں جہاں PaaS محدود ہو سکتا ہے۔
انتہائی خصوصی بنیادی ڈھانچے کی ضروریات کے ساتھ تنظیموں کو نیٹ ورکنگ، سیکورٹی پرتوں، ہارڈ ویئر کی اصلاح، یا تعیناتی کے رویے پر براہ راست کنٹرول کی ضرورت ہوسکتی ہے.
کچھ صنعتوں میں ریگولیٹری تقاضے ہوتے ہیں جو غیر معمولی طور پر مخصوص بنیادی ڈھانچے کی ضروریات پیدا کرتے ہیں۔
بالغ پلیٹ فارم انجینئرنگ ٹیموں کے ساتھ بڑی تنظیمیں بھی اپنی مرضی کے مطابق انفراسٹرکچر میں سرمایہ کاری کا جواز پیش کر سکتی ہیں۔
کچھ معاملات میں، پلیٹ فارم کے اخراجات بہت بڑے پیمانے پر اہم ہو سکتے ہیں۔
یہ منظرنامے موجود ہیں۔ تاہم، بہت سی کمپنیاں اس کا استعمال انتہائی کیسز کے متعلقہ بننے سے کئی سال قبل جواز فراہم کرنے کے لیے کرتی ہیں۔ اگرچہ وہ آج باقاعدہ پروڈکٹ ریلیز کرنے کے لیے جدوجہد کر رہے ہیں، وہ بنیادی ڈھانچے کے چیلنجوں کے لیے تیاری کر رہے ہیں جن کا انھیں کبھی سامنا نہیں ہو سکتا۔
یہ ترتیب غیر ضروری رگڑ پیدا کرتی ہے۔
حادثاتی طور پر اپنے بنیادی ڈھانچے کے کاروبار کی تعمیر بند کر دیں۔
انجینئرنگ ثقافتیں اکثر لچک کو اہمیت دیتی ہیں۔
لچکدار نفیس لگتا ہے۔ یہ مستقبل لگتا ہے۔ اچھا نظام سوچ کی طرح لگتا ہے.
لیکن لچک ایک قیمت پر آتی ہے۔ ہر اضافی آپشن پیچیدگی متعارف کراتا ہے۔ آپ کا ہر اضافی فیصلہ آپ کی نقل و حرکت کو سست کر دیتا ہے۔ ہر اضافی پرت دیکھ بھال کا کام تخلیق کرتی ہے۔
پروڈکشن ٹیموں کو آسان سوالات کرنے کی ضرورت ہے۔ کیا اس سے آپ کو اپنے صارفین کے لیے تیزی سے مارکیٹ میں سافٹ ویئر حاصل کرنے میں مدد ملے گی؟ اگر جواب نفی میں ہے، تو یہ قریب سے دیکھنے کے قابل ہے۔
بہت ساری کمپنیاں غلطی سے انفراسٹرکچر ایکو سسٹم بنا رہی ہیں جو فرضی مستقبل کی ضروریات کو بہتر بناتی ہیں۔
ایک ہی وقت میں، حریف مصنوعات تعینات کر رہے ہیں، گاہکوں سے سیکھ رہے ہیں، اور تیزی سے بہتری لا رہے ہیں۔
ڈیلیوری لچکدار ہے۔ اور بہت سی پروڈکشن ٹیموں کے لیے، PaaS کا انتخاب اس کو ثابت کرنے کے واضح ترین طریقوں میں سے ایک ہے۔
مجھے امید ہے کہ آپ نے اس مضمون کا لطف اٹھایا۔ آپ مجھ سے LinkedIn پر رابطہ کر سکتے ہیں۔