ప్రతి ఇంజనీరింగ్ టీమ్ ఎటువంటి ఇబ్బందులు లేకుండా విస్తరించగలిగే వ్యవస్థను కోరుకుంటుంది. ట్రాఫిక్ సజావుగా పెరగడం, సర్వర్లు సమర్థవంతంగా పనిచేయడం మరియు ఆదాయం క్రమంగా పెరుగుతుండటం వంటి దృశ్యాలను మనం ఊహించుకుంటాము. కానీ వాస్తవం ఎదురైనప్పుడు పరిస్థితి వేరుగా ఉంటుంది. ఒక వైరల్ మార్కెటింగ్ క్యాంపెయిన్ వల్ల యూజర్లు ఒక్కసారిగా భారీగా పెరిగినప్పుడు, డేటాబేస్ లాక్ అయిపోతుంది, మరియు ఎవరో ఒకరు తెల్లవారుజామున మూడు గంటల సమయంలో ఆందోళనగా సర్వీసులను రీస్టార్ట్ చేస్తూ ఉంటారు. అప్పుడు మన సహజ ప్రతిచర్య ఏమిటంటే, సాధనాలనే (tools) నిందించడం. మనకు మరిన్ని కోర్లు (cores), వేగవంతమైన డిస్క్లు లేదా మరొక క్యాషింగ్ లేయర్ అవసరమయ్యాయని మనం మనల్ని మనం సమర్థించుకుంటాము. కానీ వృద్ధి అనేది హార్డ్వేర్ నుండి రాదు. అది నిర్మాణం (structure) నుండి వస్తుంది. మీ పునాది బరువును పంపిణీ చేయలేకపోతే, ప్రతి కొత్త యూజర్ విజయం కాకుండా ఒక భారంగా మారుతాడు.
దెబ్బతిన్న పునాదిని సాధనాలు కాపాడలేవు
మీరు వందల కొద్దీ క్లౌడ్ ఇన్స్టెన్స్లను (cloud instances) సృష్టించవచ్చు, భౌగోళిక ప్రాంతాల మధ్య లోడ్ బ్యాలెన్సర్లను జోడించవచ్చు మరియు గ్లోబల్ కంటెంట్ డెలివరీ నెట్వర్క్ (CDN) ద్వారా ప్రతి స్టాటిక్ అసెట్ను క్యాష్ చేయవచ్చు. ఇవన్నీ పని సామర్థ్యాన్ని పెంచే అంశాలే (force multipliers). అయినప్పటికీ, సున్నాను ఎంత గుణించినా ఫలితం సున్నే. చిక్కుముడి పడిన డిపెండెన్సీలతో ఉన్న ఒక మోనోలిథిక్ అప్లికేషన్ (monolithic application), దాని కింద ఎంత శక్తివంతమైన హార్డ్వేర్ ఉన్నప్పటికీ, తన స్వంత బరువుతోనే కుప్పకూలిపోతుంది.
ప్రొడక్ట్ క్యాటలాగ్, పేమెంట్ ప్రాసెసింగ్ మరియు యూజర్ అథెంటికేషన్ అన్నీ ఒకే కోడ్బేస్లో ఉన్న ఒక ఆన్లైన్ స్టోర్ను ఊహించుకోండి. చెక్అవుట్ ప్రక్రియ నెమ్మదించినప్పుడు, మొత్తం సైట్ కూడా మొద్దుబారిపోతుంది. లాగిన్ పేజీ సరిగ్గా పనిచేయదు. బ్రౌజింగ్ అనుభవం దెబ్బతింటుంది. మిగిలిన అన్నింటినీ స్కేల్ చేయకుండా కేవలం ఆ అడ్డంకిని (bottleneck) మాత్రమే స్కేల్ చేయడం సాధ్యం కాదు. ఇది ఖరీదైనది, అసమర్థమైనది మరియు ప్రమాదకరమైనది. మీ యూజర్లు పేజీలు లోడ్ అవ్వడం కోసం వేచి చూస్తుంటే, మీరు ఎవరికీ ఉపయోగపడని కంప్యూట్ పవర్ కోసం డబ్బు చెల్లిస్తూ ఉంటారు.
ఈ చిక్కుముడికి ఆర్కిటెక్చర్ (Architecture) మాత్రమే సమాధానం. మీ సాధనాలు మీకు సహాయపడతాయా లేదా హాని చేస్తాయా అనేది నిర్ణయించే అదృశ్య అస్థిపంజరం ఇది.
ఒక పటిష్టమైన ఆర్కిటెక్చర్ అంటే నిజంగా ఏమిటి
ఒక పటిష్టమైన ఆర్కిటెక్చర్ అనేది బాధ్యతలు ఎక్కడ ఉండాలో తెలిపే ఒక ప్రణాళిక మాత్రమే. ఇది ప్రారంభ దశలోనే అసౌకర్యకరమైన ప్రశ్నలను అడుగుతుంది. ఒక భాగం విఫలమైనప్పుడు ఏమవుతుంది? రికమెండేషన్ ఇంజిన్ను తాకకుండానే మీరు బిల్లింగ్ లాజిక్ను మార్చగలరా? మీ అప్లికేషన్ యొక్క ఒక మూలలో ట్రాఫిక్ పెరిగినప్పుడు, మిగిలిన వ్యవస్థ సాధారణంగా పనిచేయగలదా? మీరు ఎంచుకునే ప్రోగ్రామింగ్ లాంగ్వేజ్, ఫ్రేమ్వర్క్ లేదా క్లౌడ్ ప్రొవైడర్ కంటే ఈ ప్రశ్నలే చాలా ముఖ్యమైనవి.
మంచి ఆర్కిటెక్చర్ మీకు మీ నిర్ణయాలను మార్చుకునే అవకాశం ఇస్తుంది. ఇది స్పష్టమైన సరిహద్దులను నిర్వచిస్తుంది, తద్వారా ఒక టీమ్ చేసే ప్రయోగం మరొక టీమ్ యొక్క ప్రొడక్షన్ వర్క్లోడ్ను అస్థిరపరచదు. ఇది వైఫల్యాన్ని ఒక ఆశ్చర్యకరమైన సంఘటనగా కాకుండా, ఒక సాధారణ నిర్వహణ స్థితిగా పరిగణిస్తుంది. మీరు వైఫల్యాన్ని దృష్టిలో ఉంచుకుని డిజైన్ చేసినప్పుడు, మీరు గాజు ఇళ్లను నిర్మించడం మానేసి, వంగే గుణం ఉన్న (flexible) నిర్మాణాలను నిర్మించడం ప్రారంభిస్తారు.
ఒక ఆచరణాత్మక పద్ధతిగా మైక్రోసర్వీసెస్ (Microservices)
అటువంటి నిర్మాణాన్ని సాధించడానికి ఒక ఆచరణాత్మక మార్గం ఏమిటంటే మీ అప్లికేషన్ను మైక్రోసర్వీసెస్గా విభజించడం. ఒకే భారీ కోడ్బేస్కు బదులుగా, మీరు యాప్ను చిన్న భాగాలుగా విభజిస్తారు. ప్రతి భాగం ఒక నిర్దిష్ట పనిని నిర్వహిస్తుంది. పేమెంట్ సర్వీస్ లావాదేవీలను ప్రాసెస్ చేస్తుంది. ఇన్వెంటరీ సర్వీస్ స్టాక్ను ట్రాక్ చేస్తుంది. నోటిఫికేషన్ సర్వీస్ ఈమెయిల్స్ మరియు టెక్స్ట్ మెసేజ్లను పంపుతుంది. అవి డైరెక్ట్ మెమరీ యాక్సెస్ లేదా షేర్డ్ డేటాబేస్ టేబుల్స్ ద్వారా కాకుండా, నిర్వచించబడిన ఇంటర్ఫేస్ల ద్వారా కమ్యూనికేట్ చేస్తాయి.
ఈ విభజన సాంకేతికంగా మరియు సంస్థాగతంగా మార్పులు చేయడానికి నిజమైన అవకాశం కల్పిస్తుంది.
మొత్తం వ్యవస్థను దెబ్బతీయకుండా చిన్న భాగాలను అప్డేట్ చేయడం
సర్వీసులు చిన్నవిగా మరియు నిర్దిష్టమైనవిగా ఉన్నప్పుడు, మొత్తం వ్యవస్థ దెబ్బతినే ప్రమాదం లేకుండా మీరు ఒక భాగాన్ని మాత్రమే సరిచేయవచ్చు (patch). మీ టీమ్ షిప్పింగ్ కాలిక్యులేషన్ అల్గారిథమ్లో బగ్ను కనుగొంటే, మీరు ఆ సర్వీస్ను మాత్రమే సరిచేసి విడిగా డిప్లాయ్ చేయవచ్చు. మిగిలిన అప్లికేషన్ యథావిధిగా నడుస్తుంది. యూజర్లు ఇప్పటికీ ఉత్పత్తులను బ్రౌజ్ చేయగలరు, లాగిన్ అవ్వగలరు మరియు కార్ట్కు వస్తువులను జోడించగలరు. ఏదైనా ఒక మార్పు వల్ల కలిగే ప్రభావ పరిధి (blast radius) చాలా తక్కువగా ఉంటుంది. ఒక హెల్పర్ ఫంక్షన్లో చిన్న తప్పు జరిగినా చెక్అవుట్, రిజిస్ట్రేషన్ మరియు రిపోర్టింగ్ అన్నీ ఒకేసారి దెబ్బతినే మోనోలిత్ (monolith) తో దీనిని పోల్చి చూడండి.
ట్రాఫిక్ పెరిగినప్పుడు నిర్దిష్ట ఫంక్షన్లను స్కేల్ చేయడం
అప్లికేషన్ అంతటా ట్రాఫిక్ ఎప్పుడూ ఒకేలా ఉండదు. ఒక ఫ్లాష్ సేల్ సమయంలో, మీ కంటెంట్ మేనేజ్మెంట్ సిస్టమ్ ఖాళీగా ఉన్నప్పటికీ, మీ ఆర్డర్ పైప్లైన్ ఒత్తిడికి గురవ్వచ్చు. ఒకదానిపై ఒకటి ఆధారపడిన (tightly coupled) వ్యవస్థలో, మీరు అన్నింటినీ స్కేల్ చేయాలి లేదా ఏదీ చేయలేరు. మైక్రోసర్వీసెస్తో, మీరు మీ వనరులను (resources) ఖచ్చితంగా లక్ష్యంగా చేసుకోవచ్చు. చెక్అవుట్ సర్వీస్ యొక్క మరిన్ని ఇన్స్టెన్స్లను సృష్టించండి. ప్రొడక్ట్ క్యాటలాగ్ దాని సాధారణ సామర్థ్యంతోనే నడవనివ్వండి. ఒక ప్రొడక్ట్ లాంచ్ సమయంలో, మీ సెర్చ్ ఇండెక్స్ ప్రశాంతంగా ఉన్నప్పటికీ, ఇమేజ్ ప్రాసెసింగ్ వర్కర్లు వేలకొద్దీ థంబ్నెయిల్స్ను ప్రాసెస్ చేయాల్సి రావచ్చు. కేవలం ఇమేజ్ వర్కర్ల కోసం సెర్చ్ క్లస్టర్ను విస్తరించాల్సిన అవసరం లేదు. యూజర్లు ఎక్కడైతే ప్రభావాన్ని అనుభవిస్తారో అక్కడ మీరు డబ్బు ఖర్చు చేస్తారు, మరియు మీ వ్యవస్థ ఒత్తిడిలో కూడా స్పందించేలా ఉంటుంది.
ఎక్కువ డౌన్టైమ్ లేకుండా కొత్త కోడ్ను డిప్లాయ్ చేయడం
చిన్న సర్వీసులు డిప్లాయ్మెంట్ ప్యాటర్న్స్ను సాధ్యం చేస్తాయి, తద్వారా మెయింటెనెన్స్ విండోస్ అవసరం లేకుండా పోతుంది. మీరు రోలింగ్ డిప్లాయ్మెంట్లను (rolling deployments) ఉపయోగించవచ్చు, అంటే మిగిలినవి ట్రాఫిక్ను సర్వ్ చేస్తున్న సమయంలోనే, కొత్త కోడ్ను కొన్ని ఇన్స్టాన్స్లకు మాత్రమే పంపవచ్చు. మీ ఎర్రర్ రేట్లను గమనిస్తూ ఉండండి, ఏదైనా తేడా అనిపిస్తే, సెకన్ల వ్యవధిలోనే రిక్వెస్ట్లను పాత వెర్షన్కు మళ్లించండి. బ్లూ-గ్రీన్ డిప్లాయ్మెంట్స్ (Blue-green deployments) ద్వారా మీరు పూర్తిగా కొత్త ఎన్విరాన్మెంట్ను ఏర్పాటు చేసి, దానిని వెరిఫై చేసి, అతి తక్కువ రిస్క్తో ట్రాఫిక్ను మార్చవచ్చు. ఎవరైనా డేటాబేస్ మైగ్రేషన్లను మాన్యువల్గా చేసేటప్పుడు, సిస్టమ్ గంటల తరబడి ఆగిపోాల్సిన అవసరం లేదు.
కొత్త ఫీచర్లను వేగంగా నిర్మించండి
పెద్ద కోడ్బేస్లు అప్రమత్తతను పెంచుతాయి. ఒక చిన్న మార్పు చేయాలన్నా వేల లైన్ల సంబంధం లేని లాజిక్ను అర్థం చేసుకోవడం, గంటల తరబడి పట్టే రిగ్రెషన్ టెస్ట్లు మరియు రాకెట్ లాంచ్లలా అనిపించే డిప్లాయ్మెంట్ షెడ్యూల్లు అవసరమవుతాయి. చిన్న సర్వీసులు ఆ భయాన్ని పోగొడతాయి. ఒక టీమ్ తమకు బాగా తెలిసిన సర్వీస్లో కొన్ని వందల లైన్లను మార్చడం ద్వారా కొత్త ఫీచర్ను నిర్మించగలదు. వారు అదే రోజున కమిట్ చేసి, టెస్ట్ చేసి, షిప్ చేయగలరు. ఆ వేగం క్రమంగా పెరుగుతుంది. సర్వీసులు స్పష్టమైన బాధ్యతలతో విభజించబడినప్పుడు, టీమ్లు ఒకరి పనిలో ఒకరు జోక్యం చేసుకోవడం ఆగిపోతాయి. వారు తమ డొమైన్ను ఎండ్-టు-ఎండ్ సొంతం చేసుకుంటారు.
స్వతంత్రత పెద్ద అంతరాయాలను నివారిస్తుంది
ప్రతి సర్వీస్ తనంతట తానుగా పనిచేస్తుంది. ఆ స్వతంత్రత కేవలం సంస్థాగత సౌలభ్యం మాత్రమే కాదు; అది ఒక స్ట్రక్చరల్ ఇన్సూరెన్స్. ఒకవేళ రికమెండేషన్ ఇంజిన్ డౌన్ అయితే, స్టోర్ ఇంకా ఉత్పత్తులను విక్రయించాలి. అనలిటిక్స్ పైప్లైన్ ఏదైనా తప్పు డేటా వల్ల ఆగిపోతే, లాగిన్ సర్వీస్ ఇంకా యూజర్లను అథెంటికేట్ చేయగలగాలి. ఒక వైఫల్యం మొత్తం సిస్టమ్ ఆగిపోయేలా చేయకుండా ఉండటానికి, మీరు సర్వీసుల మధ్య సర్క్యూట్ బ్రేకర్లు మరియు ఫాల్బ్యాక్ పాత్లను డిజైన్ చేస్తారు. సిస్టమ్ మీ యూజర్లతో పాటు పెరుగుతుంది, ఎందుకంటే అది విచ్ఛిన్నం కాకుండా ఒత్తిడిని తట్టుకోగలదు.
ఒక హెచ్చరిక: గుడ్డిగా విడగొట్టకండి
దీని అర్థం మీరు మొదటి రోజే మీ కోడ్బేస్ను ముక్కలు చేయాలని కాదు. మైక్రోసర్వీస్లకు స్పష్టమైన సరిహద్దులు అవసరం. మీ టీమ్లకు ఒక డొమైన్ ఎక్కడ ముగుస్తుంది మరియు మరొకటి ఎక్కడ మొదలవుతుందో తెలియకపోతే, వారు ఒక డిస్ట్రిబ్యూటెడ్ సిస్టమ్కు బదులుగా ఒక డిస్ట్రిబ్యూటెడ్ గందరగోళాన్ని సృష్టిస్తారు. మీరు కోడ్ కాంప్లెక్సిటీకి బదులుగా ఆపరేషనల్ కాంప్లెక్సిటీని ఎదుర్కోవాల్సి వస్తుంది, అకస్మాత్తుగా మీరు నెట్వర్క్ లేటెన్సీ, డిస్ట్రిబ్యూటెడ్ ట్రాన్సాక్షన్స్, రీట్రై స్టార్మ్స్ మరియు డజన్ల కొద్దీ లాగ్ స్ట్రీమ్స్ ద్వారా అబ్జర్వబిలిటీని నిర్వహించాల్సి వస్తుంది. స్లో చెకౌట్ను డీబగ్ చేయడం అంటే ఇప్పుడు నాలుగు నెట్వర్క్ హాప్లు మరియు మూడు వేర్వేరు డేటా స్టోర్ల ద్వారా ఒకే రిక్వెస్ట్ను ట్రాస్ చేయాల్సి రావచ్చు.
మీ టీమ్ ఆ భారాన్ని మోయడానికి సిద్ధంగా లేకపోతే, పరిష్కారం కంటే సమస్యే పెద్దదిగా మారుతుంది. కొన్నిసార్లు మోడ్యులర్ మోనోలిత్తో (modular monolith) ప్రారంభించడం తెలివైన నిర్ణయం. అవి కలిసి డిప్లాయ్ అయినప్పటికీ, కోడ్బేస్లో పేమెంట్ లాజిక్ను ఇన్వెంటరీ లాజిక్ నుండి వేరుగా ఉంచండి. ఇంటర్నల్ APIs మరియు ఒకే ఇంజిన్ లోపల వేర్వేరు డేటాబేస్ స్కీమాలను ఉపయోగించి సరిహద్దులను అమలు చేయండి. ఆ విభజనలు స్థిరంగా ఉన్నాయని మరియు ట్రాఫిక్ ప్యాటర్న్స్ ఆ ఓవర్హెడ్ను సమర్థిస్తున్నాయని తెలిసినప్పుడు, ఒక సర్వీస్ను వేరు చేయండి. ఆర్కిటెక్చర్ అనేది ఉద్దేశపూర్వకమైన తలుపుల వరుసలా ఉండాలి, ఏదో ఒక బ్లాగ్ పోస్ట్ చదివి రాత్రికి రాత్రే నిర్మించిన గోడలలా ఉండకూడదు.
స్పష్టమైన ఉద్దేశ్యంతో ప్రారంభించండి
బలమైన ఆర్కిటెక్చర్ అంటే ఐదేళ్ల తర్వాత ట్రాఫిక్ ఎలా ఉంటుందో అంచనా వేయడం కాదు. అది మీకు ఎంపికలను అందించడం గురించి. మీ వెబ్ యాప్ను పెంచడానికి మీరు కేవలం టూల్స్పై మాత్రమే ఆధారపడలేరు, కానీ ఒత్తిడి పెరగకముందే మీరు సమస్యల నుండి బయటపడేలా ఆలోచించగలరు. బాధ్యతల మధ్య ఉన్న సరిహద్దులను గౌరవించండి. తమ స్వంత పనిని తామే చూసుకునే చిన్న, ఫోకస్డ్ భాగాలను నిర్మించండి. మొత్తం సిస్టమ్ను దెబ్బతీయకుండా వేగంగా కదలడానికి టీమ్లకు స్వయంప్రతిపత్తిని ఇవ్వండి. మీరు బలమైన ఆర్కిటెక్చర్తో ప్రారంభించినప్పుడు, తర్వాత సమయం మరియు శ్రమ ఆదా అవుతుంది, ఎందుకంటే సైట్ సమస్యల్లో ఉన్నప్పుడు మీరు కోర్ లాజిక్ను మళ్ళీ రాయాల్సిన అవసరం ఉండదు.
అసలైన సారాంశం
స్కేలబిలిటీ అనేది వృద్ధి వచ్చినప్పుడు అదనంగా జోడించే ఫీచర్ కాదు. మీ సిస్టమ్ ద్వారా బాధ్యత ఎలా ప్రవహిస్తుందనే దానిపై మీరు ప్రారంభంలో తీసుకున్న నిర్ణయాల సహజ ఫలితం అది. సరైన విభజనలను ఎంచుకోండి. వైఫల్యాన్ని వేరు చేయండి. సమస్యగా ఉన్న దానిని స్కేల్ చేయండి, బాగా పనిచేస్తున్న దానిని అలాగే వదిలేయండి. అలా చేస్తే, మీరు తర్వాత జోడించే టూల్స్కు నిజంగా ఒక బలమైన పునాది ఉంటుంది.