દરેક એન્જિનિયરિંગ ટીમ એવી સિસ્ટમ ઈચ્છે છે જે કોઈપણ અવરોધ વગર વિસ્તરી શકે. આપણે કલ્પના કરીએ છીએ કે ટ્રાફિક સરળતાથી વધી રહ્યો છે અને સર્વર્સ સુવ્યવસ્થિત રીતે ચાલી રહ્યા છે.

દરેક એન્જિનિયરિંગ ટીમ એવી સિસ્ટમ ઈચ્છે છે જે કોઈપણ અવરોધ વગર વિસ્તરી શકે. આપણે કલ્પના કરીએ છીએ કે ટ્રાફિક સરળતાથી વધી રહ્યો છે, સર્વર્સ બરાબર ચાલી રહ્યા છે અને આવક સતત વધી રહી છે. પછી વાસ્તવિકતા સામે આવે છે. એક વાયરલ માર્કેટિંગ કેમ્પેઈન યુઝર્સનો મોટો મોજા લાવે છે, ડેટાબેઝ લોક થઈ જાય છે, અને કોઈ સવારે ત્રણ વાગ્યે ગભરાટમાં સર્વિસ રિસ્ટાર્ટ કરી રહ્યું હોય છે. આપણી પ્રતિક્રિયા સાધનોને દોષ આપવાની હોય છે. આપણે આપણી જાતને કહીએ છીએ કે આપણને વધુ કોર્સ, ઝડપી ડિસ્ક અથવા અન્ય કેશિંગ લેયરની જરૂર હતી. પરંતુ વૃદ્ધિ હાર્ડવેરથી નથી આવતી. તે માળખા (structure) થી આવે છે. જો તમારો પાયો વજન વહેંચી શકતો નથી, તો દરેક નવો યુઝર વિજયને બદલે બોજ બની જાય છે.

શા માટે સાધનો તૂટેલા પાયાને બચાવી શકતા નથી

તમે સો ક્લાઉડ ઇન્સ્ટન્સ શરૂ કરી શકો છો, ભૌગોલિક પ્રદેશો વચ્ચે લોડ બેલેન્સર ઉમેરી શકો છો અને ગ્લોબલ કન્ટેન્ટ ડિલિવરી નેટવર્કમાં દરેક સ્ટેટિક એસેટ કેશ કરી શકો છો. આ બધું કામ કરવાની ક્ષમતા વધારે છે. છતાં, શૂન્યને ગુણવાથી પણ શૂન્ય જ મળે છે. જટિલ નિર્ભરતાઓ (dependencies) ધરાવતી મોનોલિથિક એપ્લિકેશન તેના પોતાના વજન નીચે દબાઈ જશે, ભલે તેની નીચે ગમે તેટલું હાર્ડવેર હોય.

એક ઓનલાઇન સ્ટોરની કલ્પના કરો જ્યાં પ્રોડક્ટ કેટલોગ, પેમેન્ટ પ્રોસેસિંગ અને યુઝર ઓથેન્ટિકેશન બધું જ એક જ કોડબેઝમાં હોય. જ્યારે ચેકઆઉટ પ્રક્રિયા ધીમી પડે છે, ત્યારે આખી સાઇટ ધીમી પડી જાય છે. લોગિન પેજ અટકી જાય છે. બ્રાઉઝિંગનો અનુભવ બગડે છે. તમે બાકીની બધી વસ્તુઓ સાથે તેને સ્કેલ કર્યા વગર બોટલનેક (bottleneck) ને સ્કેલ કરી શકતા નથી. તે ખર્ચાળ, બિનકાર્યક્ષમ અને નાજુક છે. તમે એવા કમ્પ્યુટ પાવર માટે ચૂકવણી કરો છો જેનો કોઈ ફાયદો થતો નથી, જ્યારે તમારા યુઝર્સ એવા પેજ માટે રાહ જોઈ રહ્યા હોય છે જે તરત જ લોડ થઈ જવું જોઈએ હતું.

આ જાળમાંથી બહાર નીકળવાનો જવાબ આર્કિટેક્ચર છે. તે એક અદ્રશ્ય હાડપિંજર જેવું છે જે નક્કી કરે છે કે તમારા સાધનો મદદ કરશે કે નુકસાન.

મજબૂત આર્કિટેક્ચરનો વાસ્તવિક અર્થ શું છે

મજબૂત આર્કિટેક્ચર એ ફક્ત જવાબદારીઓ ક્યાં રહેશે તેનો એક પ્લાન છે. તે શરૂઆતમાં જ અગવડતાભર્યા પ્રશ્નો પૂછે છે. જ્યારે એક ભાગ તૂટે ત્યારે શું થાય? શું તમે રેકમેન્ડેશન એન્જિનને અડક્યા વગર બિલિંગ લોજિક બદલી શકો છો? શું તમારી એપ્લિકેશનના એક ખૂણે ટ્રાફિકમાં વધારો થવાથી બાકીની સિસ્ટમ સામાન્ય રીતે કામ કરી શકે છે? આ પ્રશ્નો તમારી પ્રોગ્રામિંગ લેંગ્વેજ, ફ્રેમવર્ક અથવા ક્લાઉડ પ્રોવાઈડરના પસંદગી કરતા ઘણો વધારે મહત્વના છે.

સારું આર્કિટેક્ચર તમને તમારો નિર્ણય બદલવાની તક આપે છે. તે સ્પષ્ટ સીમાઓ વ્યાખ્યાયિત કરે છે જેથી એક ટીમનો પ્રયોગ બીજી ટીમના પ્રોડક્શન વર્કલોડને અસ્થિર ન કરે. તે નિષ્ફળતાને આશ્ચર્યને બદલે એક સામાન્ય ઓપરેટિંગ કન્ડિશન તરીકે જુએ છે. જ્યારે તમે નિષ્ફળતાને ધ્યાનમાં રાખીને ડિઝાઇન કરો છો, ત્યારે તમે કાચના ઘરો બનાવવાનું બંધ કરો છો અને એવી રચનાઓ બનાવવાનું શરૂ કરો છો જે વળી શકે.

પ્રેક્ટિકલ પેટર્ન તરીકે માઇક્રોસર્વિસીસ

આ પ્રકારનું માળખું પ્રાપ્ત કરવાનો એક વ્યવહારુ રસ્તો તમારી એપ્લિકેશનને માઇક્રોસર્વિસીસમાં વિભાજિત કરવાનો છે. એક વિશાળ કોડબેઝને બદલે, તમે એપને નાના ભાગોમાં વિભાજિત કરો છો. દરેક ભાગ એક ચોક્કસ કામ સંભાળે છે. પેમેન્ટ સર્વિસ ટ્રાન્ઝેક્શન પ્રોસેસ કરે છે. ઇન્વેન્ટરી સર્વિસ સ્ટોક ટ્રેક કરે છે. નોટિફિકેશન સર્વિસ ઈમેલ અને ટેક્સ્ટ મેસેજ મોકલે છે. તેઓ ડાયરેક્ટ મેમરી એક્સેસ અથવા શેર કરેલા ડેટાબેઝ ટેબલ્સને બદલે વ્યાખ્યાયિત ઇન્ટરફેસ દ્વારા વાતચીત કરે છે.

આ અલગતા ટેકનિકલ અને સંગઠનાત્મક રીતે કામ કરવાની વાસ્તવિક તક આપે છે.

આખી સિસ્ટમને તોડ્યા વગર નાના ભાગોને અપડેટ કરો

જ્યારે સર્વિસીસ નાની અને કેન્દ્રિત હોય છે, ત્યારે તમે કેસ્કેડ ફેલ્યોર (cascade failure) નું જોખમ લીધા વિના એક ભાગને પેચ કરી શકો છો. જો તમારી ટીમને શિપિંગ કેલ્ક્યુલેશન અલ્ગોરિધમમાં કોઈ બગ મળે છે, તો તમે તે સર્વિસને ઠીક કરો છો અને તેને અલગથી ડિપ્લોય કરો છો. બાકીની એપ્લિકેશન ચાલતી રહે છે. યુઝર્સ હજુ પણ પ્રોડક્ટ્સ બ્રાઉઝ કરે છે, લોગિન કરે છે અને કાર્ટમાં વસ્તુઓ ઉમેરે છે. કોઈપણ સિંગલ ફેરફારનો અસર વિસ્તાર (blast radius) નાનો રહે છે. તેની સરખામણી મોનોલિથ સાથે કરો જ્યાં હેલ્પર ફંક્શનમાં એક ભૂલ ચેકઆઉટ, રજિસ્ટ્રેશન અને રિપોર્ટિંગ ત્રણેયને એકસાથે તોડી શકે છે.

ટ્રાફિક વધે ત્યારે ચોક્કસ ફંક્શન્સને સ્કેલ કરો

એપ્લિકેશનમાં ટ્રાફિક ક્યારેય સમાન હોતો નથી. ફ્લેશ સેલ દરમિયાન, તમારું ઓર્ડર પાઇપલાઇન દબાણ હેઠળ હોઈ શકે છે જ્યારે તમારું કન્ટેન્ટ મેનેજમેન્ટ સિસ્ટમ લગભગ નિષ્ક્રિય હોય. ખૂબ જ જોડાયેલી (tightly coupled) સિસ્ટમમાં, તમે બધું સ્કેલ કરો છો અથવા કંઈ જ નહીં. માઇક્રોસર્વિસીસ સાથે, તમે તમારા સંસાધનોને ચોક્કસ રીતે લક્ષ્ય બનાવી શકો છો. ચેકઆઉટ સર્વિસના વધુ ઇન્સ્ટન્સ શરૂ કરો. પ્રોડક્ટ કેટલોગને તેના સામાન્ય રીતે ચાલવા દો. પ્રોડક્ટ લોન્ચ દરમિયાન, તમારા ઇમેજ પ્રોસેસિંગ વર્કર્સ હજારો થંબનેલ્સ માટે કતારમાં હોઈ શકે છે જ્યારે તમારું સર્ચ ઇન્ડેક્સ શાંત રહે છે. ફક્ત ઇમેજ વર્કર્સને સંતોષવા માટે સર્ચ ક્લસ્ટરને વધારવાનું કોઈ કારણ નથી. તમે ત્યાં પૈસા ખર્ચો છો જ્યાં યુઝર્સને તેનો અનુભવ થાય છે, અને તમારું સિસ્ટમ દબાણ હેઠળ પણ પ્રતિભાવશીલ રહે છે.

લાંબા ડાઉનટાઇમ વગર નવો કોડ ડિપ્લોય કરો

નાની સર્વિસીસ એવા ડિપ્લોયમેન્ટ પેટર્ન માટે અવકાશ આપે છે જે મેન્ટેનન્સ વિન્ડોની જરૂરિયાતને જ દૂર કરી દે છે. તમે રોલિંગ ડિપ્લોયમેન્ટ્સનો ઉપયોગ કરી શકો છો, જેમાં બાકીના ઇન્સ્ટન્સ ટ્રાફિક સર્વ કરવાનું ચાલુ રાખે છે તે દરમિયાન નવા કોડને ઇન્સ્ટન્સના અમુક ભાગમાં મોકલી શકાય છે. તમારા એરર રેટ પર નજર રાખો, અને જો કંઈક ખોટું લાગે, તો સેકન્ડોમાં વિનંતીઓને (requests) પાછી અગાઉના વર્ઝન પર મોકલી દો. બ્લુ-ગ્રીન ડિપ્લોયમેન્ટ્સ તમને એક સંપૂર્ણ નવું એન્વાયરમેન્ટ ઊભું કરવા, તેને ચકાસવા અને ન્યૂનતમ જોખમ સાથે ટ્રાફિકને તેના પર સ્વિચ કરવાની સુવિધા આપે છે. જ્યારે કોઈ વ્યક્તિ મેન્યુઅલી ડેટાબેઝ માઈગ્રેશન કરી રહી હોય, ત્યારે સિસ્ટમને કલાકો સુધી બંધ કરવાની જરૂર પડતી નથી.

નવા ફીચર્સ ઝડપથી બનાવો

મોટા કોડબેઝ સાવચેતી જન્માવે છે. એક જ ફેરફાર માટે હજારો લાઇનોના અસંબંધિત લોજિકને સમજવું, કલાકો લેતા રિગ્રેસન ટેસ્ટ અને રોકેટ લોન્ચ જેવું લાગે તેવા ડિપ્લોયમેન્ટ શેડ્યૂલની જરૂર પડે છે. નાની સર્વિસીસ આ ડરને દૂર કરે છે. એક ટીમ જે સર્વિસને સારી રીતે ઓળખતી હોય તેમાં માત્ર થોડીક સેંકડો લાઇનોમાં ફેરફાર કરીને નવું ફીચર બનાવી શકે છે. તેઓ તે જ દિવસે કોડ કમિટ, ટેસ્ટ અને શિપ કરી શકે છે. આ ઝડપ સતત વધતી જાય છે. જ્યારે સર્વિસીસ સ્પષ્ટ જવાબદારીઓ દ્વારા વહેંચાયેલી હોય, ત્યારે ટીમો એકબીજાના કામમાં દખલ કરવાનું બંધ કરે છે. તેઓ તેમના ડોમેનને અંતથી અંત સુધી (end to end) સંભાળે છે.

સ્વતંત્રતા મોટી અડચણોને અટકાવે છે

દરેક સર્વિસ પોતાની રીતે કામ કરે છે. આ સ્વતંત્રતા માત્ર સંગઠનાત્મક સુવિધા નથી; તે એક સ્ટ્રક્ચરલ ઇન્શ્યોરન્સ છે. જો રેકમેન્ડેશન એન્જિન બંધ થઈ જાય, તો પણ સ્ટોર પ્રોડક્ટ્સ વેચવાનું ચાલુ રાખવું જોઈએ. જો એનાલિટિક્સ પાઇપલાઇન કોઈ ખોટા ઇવેન્ટને કારણે અટકી જાય, તો પણ લોગિન સર્વિસે યુઝર્સને ઓથેન્ટિકેટ કરવાનું ચાલુ રાખવું જોઈએ. તમે સર્વિસીસ વચ્ચે સર્કિટ બ્રેકર્સ અને ફોલબેક પાથ ડિઝાઇન કરો છો જેથી એક નિષ્ફળતા આખી સિસ્ટમને બંધ ન કરી દે. સિસ્ટમ તમારા યુઝર્સની સાથે વધતી જાય છે કારણ કે તે તૂટ્યા વગર તણાવને સહન કરી શકે છે.

સાવચેતીનો એક શબ્દ: અંધાધૂંધ વિભાજન ન કરો

આનો અર્થ એ નથી કે તમારે પહેલા જ દિવસે તમારા કોડબેઝને વિભાજિત કરી દેવો જોઈએ. માઇક્રોસર્વિસીસ માટે સ્પષ્ટ સીમાઓની જરૂર હોય છે. જો તમારી ટીમોને હજુ એ ખબર ન હોય કે એક ડોમેન ક્યાં સમાપ્ત થાય છે અને બીજું ક્યાંથી શરૂ થાય છે, તો તેઓ ડિસ્ટ્રિબ્યુટેડ સિસ્ટમ બનાવવાને બદલે એક ડિસ્ટ્રિબ્યુટેડ અસ્તવ્યસ્તતા (mess) ઊભી કરશે. તમે કોડની જટિલતાના બદલે ઓપરેશનલ જટિલતા મેળવશો, અને અચાનક તમારે ડઝનબંધ લોગ સ્ટ્રીમ્સમાં નેટવર્ક લેટન્સી, ડિસ્ટ્રિબ્યુટેડ ટ્રાન્ઝેક્શન, રીટ્રાય સ્ટોર્મ્સ અને ઓબ્ઝર્વેબિલિટીનું સંચાલન કરવું પડશે. હવે સ્લો ચેકઆઉટને ડિબગ કરવાનો અર્થ ચાર નેટવર્ક હોપ્સ અને ત્રણ અલગ-અલગ ડેટા સ્ટોર્સમાં એક સિંગલ રિક્વેસ્ટને ટ્રેસ કરવાનો હોઈ શકે છે.

જો તમારી ટીમ આ બોજ માટે તૈયાર ન હોય, તો ઉપાય રોગ કરતાં વધુ ખરાબ હશે. ક્યારેક વધુ સ્માર્ટ નિર્ણય એ છે કે મોડ્યુલર મોનોલિથથી શરૂઆત કરવી. કોડબેઝની અંદર પેમેન્ટ લોજિકને ઇન્વેન્ટરી લોજિકથી અલગ રાખો, ભલે તેઓ સાથે ડિપ્લોય થતા હોય. ઇન્ટરનલ APIs અને એક જ એન્જિનની અંદર અલગ ડેટાબેઝ સ્કીમા સાથે સીમાઓ નક્કી કરો. જ્યારે તે સીમાઓ સ્થિર સાબિત થાય અને ટ્રાફિક પેટર્ન ઓવરહેડને યોગ્ય ઠેરવે, ત્યારે સર્વિસને અલગ કરો. આર્કિટેક્ચર એ ઇરાદાપૂર્વક બનાવેલા દરવાજાઓની શ્રેણી હોવી જોઈએ, બ્લોગ પોસ્ટ વાંચીને રાતોરાત બનાવેલી દીવાલો નહીં.

ઇરાદા સાથે શરૂઆત કરો

મજબૂત આર્કિટેક્ચર એટલે પાંચ વર્ષ પછીના ટ્રાફિકની આગાહી કરવી એવું નથી. તે તમારી જાતને વિકલ્પો આપવા વિશે છે. તમારા વેબ એપને વધારવા માટે તમે માત્ર ટૂલ્સ પર નિર્ભર રહી શકતા નથી, પરંતુ દબાણ વધે તે પહેલાં તમે મુશ્કેલીમાંથી બહાર નીકળવા માટે વિચારી શકો છો. જવાબદારીઓ વચ્ચેની સીમાઓનું સન્માન કરો. નાના, કેન્દ્રિત ભાગો બનાવો જે પોતાનું ભાગ જાતે સંભાળી શકે. ટીમોને આખી સિસ્ટમ તોડ્યા વિના ઝડપથી આગળ વધવાની સ્વાયત્તતા આપો. જ્યારે તમે મજબૂત આર્કિટેક્ચર સાથે શરૂઆત કરો છો, ત્યારે તમે પછીથી સમય અને પ્રયત્ન બચાવો છો કારણ કે જ્યારે સાઇટ પર મુશ્કેલી આવી હોય ત્યારે તમારે કોર લોજિક ફરીથી લખવું પડતું નથી.

મુખ્ય વાત (The Real Takeaway)

સ્કેલેબિલિટી એ એવી સુવિધા નથી જેને વૃદ્ધિ આવે ત્યારે તમે ઉપરથી જોડી દો. તે તમારી સિસ્ટમમાં જવાબદારી કેવી રીતે વહે છે તે વિશે તમે વહેલા લીધેલા નિર્ણયોનું કુદરતી પરિણામ છે. યોગ્ય સીમાઓ પસંદ કરો. નિષ્ફળતાને અલગ કરો. જે સમસ્યા ઊભી કરે છે તેને સ્કેલ કરો, અને જે બરાબર કામ કરે છે તેને એમ જ રહેવા દો. તેમ કરો, અને તમે પછીથી જે ટૂલ્સ ઉમેરશો તેને ખરેખર ટેકો આપવા માટે કંઈક મજબૂત મળશે.