प्रत्येक अभियांत्रिकी टीमला अशी प्रणाली हवी असते जी विनासायास वाढू शकेल. आपण अशी कल्पना करतो की ट्रॅफिक सुरळीतपणे वाढत आहे, सर्व्हर्स व्यवस्थित चालू आहेत आणि महसूल वर जात आहे. मग वास्तव समोर येते. एखादी व्हायरल मार्केटिंग मोहीम वापरकर्त्यांची लाट घेऊन येते, डेटाबेस लॉक होतो आणि पहाटे तीन वाजता कोणीतरी वेड्यासारखे सर्व्हिसेस रीस्टार्ट करत असते. अशा वेळी दोष साधनांना (tools) देण्याची प्रवृत्ती असते. आपण स्वतःला सांगतो की आपल्याला अधिक कोअर्स (cores), वेगवान डिस्क किंवा आणखी एक कॅशिंग लेअर (caching layer) हवी होती. पण वाढ हार्डवेअरमुळे येत नाही. ती रचनेमुळे (structure) येते. जर तुमचा पाया भार पेलण्यास सक्षम नसेल, तर प्रत्येक नवीन वापरकर्ता विजयाऐवजी ओझे बनतो.
दोषपूर्ण पायाला साधने का वाचवू शकत नाहीत
तुम्ही शंभर क्लाउड इन्स्टन्सेस सुरू करू शकता, विविध भौगोलिक क्षेत्रांमध्ये लोड बॅलन्सर जोडू शकता आणि ग्लोबल कंटेंट डिलिव्हरी नेटवर्कमध्ये प्रत्येक स्टॅटिक ॲसेट कॅश करू शकता. हे 'फोर्स मल्टिप्लायर्स' आहेत. तरीही, शून्याला कितीही गुणले तरी उत्तर शून्यच येते. गुंतागुंतीच्या डिपेंडन्सीज असलेल्या मोनोलिथिक ॲप्लिकेशनला त्याच्या खाली कितीही हार्डवेअर असले तरी ते स्वतःच्या वजनाखाली दबले जाईल.
एका ऑनलाइन स्टोअरची कल्पना करा जिथे प्रोडक्ट कॅटलॉग, पेमेंट प्रोसेसिंग आणि युजर ऑथेंटिकेशन हे सर्व एकाच कोडबेसमध्ये आहेत. जेव्हा चेकआउट फ्लो मंदावतो, तेव्हा संपूर्ण साइटचा वेग मंदावतो. लॉगिन पेज अडखळते. ब्राउझिंगचा अनुभव खराब होतो. तुम्ही इतर गोष्टींसोबत त्या अडथळ्याला (bottleneck) स्केल करू शकत नाही. हे महागडे, अकार्यक्षम आणि नाजूक आहे. तुमचे वापरकर्ते ज्या पेजेससाठी त्वरित लोड होण्याची अपेक्षा करत आहेत, त्यांच्या प्रतीक्षेत असताना तुम्ही अशा कम्प्युट पॉवरसाठी पैसे मोजत असता ज्याचा कोणालाही फायदा होत नाही.
आर्किटेक्चर हे या जाळ्यातून बाहेर पडण्याचे उत्तर आहे. हे तो अदृश्य सांगाडा आहे जो ठरवतो की तुमची साधने तुम्हाला मदत करतील की नुकसान पोहोचवतील.
ठोस आर्किटेक्चरचा नेमका अर्थ काय आहे
ठोस आर्किटेक्चर म्हणजे केवळ जबाबदाऱ्या कोठे असतील याचा एक आराखडा आहे. ते सुरुवातीलाच काही कठीण प्रश्न विचारते. एखादा भाग बिघडला तर काय होईल? रेकमेंडेशन इंजिनला स्पर्श न करता तुम्ही बिलिंग लॉजिक बदलू शकता का? तुमच्या ॲप्लिकेशनच्या एका कोपऱ्यात ट्रॅफिक वाढल्यास उर्वरित सिस्टम सामान्यपणे काम करू शकेल का? हे प्रश्न तुमच्या प्रोग्रामिंग लँग्वेज, फ्रेमवर्क किंवा क्लाउड प्रोव्हायडरच्या निवडीपेक्षा कितीतरी पटीने महत्त्वाचे आहेत.
चांगले आर्किटेक्चर तुम्हाला तुमचे निर्णय बदलण्यासाठी वाव देते. ते स्पष्ट सीमा (boundaries) निश्चित करते जेणेकरून एका टीमचा प्रयोग दुसऱ्या टीमच्या प्रोडक्शन वर्कलोडला अस्थिर करणार नाही. ते अपयशाला आश्चर्याऐवजी एक सामान्य ऑपरेटिंग कंडिशन मानते. जेव्हा तुम्ही बिघाडाचा विचार करून डिझाइन करता, तेव्हा तुम्ही काचेची घरे बांधणे थांबवता आणि लवचिक संरचना बांधण्यास सुरुवात करता.
एक व्यावहारिक पॅटर्न म्हणून मायक्रोसर्व्हिसेस
अशा प्रकारची रचना साध्य करण्याचा एक व्यावहारिक मार्ग म्हणजे तुमच्या ॲप्लिकेशनचे मायक्रोसर्व्हिसेसमध्ये विभाजन करणे. एका मोठ्या कोडबेसऐवजी, तुम्ही ॲपचे लहान भागांमध्ये विभाजन करता. प्रत्येक भाग एक विशिष्ट काम हाताळतो. पेमेंट सर्व्हिस व्यवहार (transactions) पूर्ण करते. इन्व्हेंटरी सर्व्हिस स्टॉकचा मागोवा घेते. नोटिफिकेशन सर्व्हिस ईमेल आणि टेक्स्ट मेसेज पाठवते. ते थेट मेमरी ॲक्सेस किंवा शेअर्ड डेटाबेस टेबल्सऐवजी परिभाषित इंटरफेसद्वारे एकमेकांशी संवाद साधतात.
हे विभाजन तांत्रिक आणि संघटनात्मक दोन्ही दृष्टीने हालचालीसाठी खरी जागा निर्माण करते.
संपूर्ण सिस्टम न बिघडवता लहान भाग अपडेट करा
जेव्हा सर्व्हिसेस लहान आणि केंद्रित असतात, तेव्हा तुम्ही संपूर्ण सिस्टम धोक्यात न आणता एक भाग पॅच करू शकता. जर तुमच्या टीमला शिपिंग कॅल्क्युलेशन अल्गोरिदममध्ये एखादी त्रुटी (bug) आढळली, तर तुम्ही ती सर्व्हिस दुरुस्त करू शकता आणि स्वतंत्रपणे डिप्लॉय करू शकता. उर्वरित ॲप्लिकेशन चालू राहते. वापरकर्ते अजूनही उत्पादने पाहू शकतात, लॉगिन करू शकतात आणि कार्टमध्ये वस्तू जोडू शकतात. कोणत्याही बदलाचा 'ब्लास्ट रेडियस' (परिणाम क्षेत्र) अत्यंत मर्यादित राहतो. याची तुलना मोनोलिथशी करा, जिथे हेल्पर फंक्शनमधील एक स्पेलिंग चूक चेकआउट, रजिस्ट्रेशन आणि रिपोर्टिंग या सर्वांना एकाच वेळी बिघडू शकते.
ट्रॅफिक वाढल्यावर विशिष्ट फंक्शन्स स्केल करा
ॲप्लिकेशनमध्ये ट्रॅफिक कधीही सर्वत्र समान नसते. फ्लॅश सेल दरम्यान, तुमचे कंटेंट मॅनेजमेंट सिस्टम जवळजवळ शांत असताना तुमची ऑर्डर पाइपलाइन तणावाखाली येऊ शकते. टाईटली कपल्ड सिस्टममध्ये, तुम्हाला सर्व काही स्केल करावे लागते किंवा काहीच नाही. मायक्रोसर्व्हिसेससह, तुम्ही तुमच्या रिसोर्सेसना अचूकपणे लक्ष्य करू शकता. चेकआउट सर्व्हिसचे अधिक इन्स्टन्सेस सुरू करा. प्रोडक्ट कॅटलॉगला त्याच्या नेहमीच्या मर्यादेत चालू द्या. एखादे उत्पादन लाँच करताना, तुमचे सर्च इंडेक्स शांत असताना तुमचे इमेज प्रोसेसिंग वर्कर्स हजारो थंबनेल्सची रांग लावू शकतात. केवळ इमेज वर्कर्सना सांभाळण्यासाठी सर्च क्लस्टर वाढवण्याचे कोणतेही कारण नाही. तुम्ही तिथेच पैसे खर्च करता जिथे वापरकर्त्यांना त्याचा अनुभव येतो आणि तुमचा सिस्टम दबावाखालीही प्रतिसाद देण्यास सक्षम राहते.
दीर्घ डाउनटाइमशिवाय नवीन कोड डिप्लॉय करा
लहान सेवांमुळे असे डिप्लॉयमेंट पॅटर्न (deployment patterns) शक्य होतात, ज्यामुळे मेंटेनन्स विंडोची (maintenance windows) गरज उरत नाही. तुम्ही रोलिंग डिप्लॉयमेंट्स (rolling deployments) वापरू शकता, ज्यामध्ये उर्वरित सेवा ट्रॅफिक हाताळत असताना नवीन कोड उपसंच (subset) इन्स्टन्सेसवर पुश केला जातो. तुमच्या एरर रेट्सवर (error rates) लक्ष ठेवा, आणि जर काही चुकीचे वाटले, तर काही सेकंदात विनंत्या (requests) मागील व्हर्जनकडे वळवा. ब्लू-ग्रीन डिप्लॉयमेंट्स (blue-green deployments) तुम्हाला पूर्णपणे नवीन वातावरण उभे करण्यास, त्याची पडताळणी करण्यास आणि किमान जोखमीसह ट्रॅफिक वळवण्यास मदत करतात. जेव्हा कोणीतरी मॅन्युअली डेटाबेस मायग्रेशन (database migrations) करत असते, तेव्हा सिस्टीम तासनतास बंद ठेवण्याची गरज पडत नाही.
नवीन फीचर्स वेगाने तयार करा
मोठे कोडबेस सावधगिरी वाढवतात. एका बदलासाठी हजारो ओळींचा असंबंधित लॉजिक समजून घेणे, तासनतास चालणारे रिग्रेशन टेस्ट्स (regression tests) आणि रॉकेट लॉन्चिंगसारखे वाटणारे डिप्लॉयमेंट शेड्युल आवश्यक असते. लहान सेवा या भीतीला दूर करतात. एखादी टीम त्यांच्या ओळखीच्या सर्व्हिसमधील काही शेकडो ओळींमध्ये बदल करून नवीन फीचर तयार करू शकते. ते त्याच दिवशी कमिट, टेस्ट आणि शिप करू शकतात. या वेगामुळे (velocity) प्रगती वेगाने होते. जेव्हा सेवा स्पष्ट जबाबदाऱ्यांनी मर्यादित असतात, तेव्हा टीम्स एकमेकांच्या कामात अडथळा आणणे थांबवतात. ते त्यांच्या डोमेनचे शेवटपर्यंत (end to end) मालक असतात.
स्वातंत्र्य मोठ्या व्यत्ययांना रोखते
प्रत्येक सेवा स्वतंत्रपणे काम करते. हे स्वातंत्र्य केवळ संघटनात्मक सोयीसाठी नाही; तर ते एक स्ट्रक्चरल इन्शुरन्स (structural insurance) आहे. जर रेकमेंडेशन इंजिन (recommendation engine) बंद पडले, तरी स्टोअरने उत्पादने विकली पाहिजेत. जर ॲनालिटिक्स पाईपलाईन (analytics pipeline) एखाद्या चुकीच्या इव्हेंटमुळे अडकली, तरी लॉगिन सर्व्हिसने युजर्सना ऑथेंटिकेट केले पाहिजे. तुम्ही सर्व्हिसेसमध्ये सर्किट ब्रेकर्स (circuit breakers) आणि फॉलबॅक पाथ्स (fallback paths) डिझाइन करता जेणेकरून एक बिघाड संपूर्ण सिस्टीम बंद पडण्याकडे (outage) वळणार नाही. तुमची सिस्टीम तुमच्या युजर्ससोबत वाढते कारण ती विखुरण्याऐवजी ताण सहन करू शकते.
एक सावधगिरीचा इशारा: आंधळेपणाने विभागणी करू नका
याचा अर्थ असा नाही की तुम्ही पहिल्याच दिवशी तुमचा कोडबेस तुकड्यांमध्ये विभागला पाहिजे. मायक्रोसर्व्हिसेससाठी (Microservices) स्पष्ट सीमा आवश्यक आहेत. जर तुमच्या टीम्सना अजूनही एक डोमेन कुठे संपते आणि दुसरे कुठे सुरू होते हे माहित नसेल, तर ते डिस्ट्रिब्युटेड सिस्टमऐवजी एक डिस्ट्रिब्युटेड मेस (distributed mess) तयार करतील. तुम्ही कोड कॉम्प्लेक्सिटीच्या (code complexity) बदल्यात ऑपरेशनल कॉम्प्लेक्सिटी (operational complexity) स्वीकाराल आणि अचानक तुम्हाला डझनभर लॉग स्ट्रीम्समधून नेटवर्क लॅटन्सी (network latency), डिस्ट्रिब्युटेड ट्रान्झॅक्शन्स (distributed transactions), रिट्राय स्टॉर्म्स (retry storms) आणि ऑब्झर्व्हेबिलिटी (observability) व्यवस्थापित करावी लागेल. आता स्लो चेकआउट (slow checkout) डीबग करणे म्हणजे चार नेटवर्क हॉप्स आणि तीन वेगवेगळ्या डेटा स्टोअर्समधून एक सिंगल रिक्वेस्ट ट्रेस करणे असू शकते.
जर तुमची टीम त्यासाठी तयार नसेल, तर उपाय आजारापेक्षा वाईट ठरू शकतो. कधीकधी 'मॉड्युलर मोनोलिथ' (modular monolith) ने सुरुवात करणे अधिक शहाणपणाचे असते. कोडबेसमध्ये पेमेंट लॉजिक आणि इन्व्हेंटरी लॉजिक वेगळे ठेवा, जरी ते एकत्र डिप्लॉय होत असले तरीही. अंतर्गत APIs आणि एकाच इंजिनमधील स्वतंत्र डेटाबेस स्कीमा वापरून सीमा निश्चित करा. जेव्हा त्या सीमा स्थिर ठरतील आणि ट्रॅफिक पॅटर्नमुळे त्याचा फायदा होईल, तेव्हाच एखादी सर्व्हिस वेगळी करा. आर्किटेक्चर हे जाणीवपूर्वक ठेवलेले दरवाजे असावेत, रातोरात बांधलेल्या भिंती नव्हे.
हेतूने सुरुवात करा
भक्कम आर्किटेक्चर म्हणजे पाच वर्षांनंतरचा ट्रॅफिकचा अंदाज लावणे नव्हे. ते स्वतःला पर्याय उपलब्ध करून देणे आहे. तुमचा वेब ॲप वाढवण्यासाठी तुम्ही केवळ टूल्सवर अवलंबून राहू शकत नाही, परंतु ताण वाढण्यापूर्वी तुम्ही विचार करून समस्या टाळू शकता. जबाबदाऱ्यांमधील सीमांचा आदर करा. स्वतःचे अस्तित्व टिकवून ठेवणारे लहान आणि केंद्रित भाग तयार करा. संपूर्ण सिस्टीम बिघडवल्याशिवाय वेगाने काम करण्यासाठी टीम्सना स्वायत्तता (autonomy) द्या. जेव्हा तुम्ही भक्कम आर्किटेक्चरने सुरुवात करता, तेव्हा तुम्ही नंतरचा वेळ आणि श्रम वाचवता कारण साइटवर संकट असताना तुम्हाला मूळ लॉजिक पुन्हा लिहावे लागत नाही.
मुख्य निष्कर्ष
स्केलेबिलिटी (Scalability) हे वाढ झाल्यावर जोडलेले एखादे फीचर नाही. ती तुमच्या सिस्टीममधील जबाबदाऱ्या कशा विभागल्या आहेत, यावर तुम्ही सुरुवातीला घेतलेल्या निर्णयांचा नैसर्गिक परिणाम आहे. योग्य सीमा निवडा. बिघाड वेगळा करा (Isolate failure). ज्या गोष्टींमुळे अडथळा येतो त्यांचे स्केल करा आणि जे व्यवस्थित चालत आहे त्याला तसेच राहू द्या. असे केल्यास, तुम्ही नंतर जी टूल्स जोडाल त्यांना आधार देण्यासाठी एक भक्कम पाया मिळेल.