మైక్రోసర్వీసెస్ వర్సెస్ మోనోలిథిక్ ఆర్కిటెక్చర్: మీరు దేనిని నిర్మించాలి?

ఒక వ్యవస్థాపకుడు ఒకసారి నన్ను ఒక ఆర్కిటెక్చర్ పిచ్‌ను సమీక్షించమని కోరారు.

ఆ ఏజెన్సీ పదకొండు సర్వీసులు, ఒక మెసేజ్ క్యూ మరియు ఒక సర్వీస్ మెష్‌ను ప్రతిపాదించింది. ఇది అసలు వినియోగదారులు లేని ఒక సాధారణ బుకింగ్ టూల్ కోసం.

అది ఒక ఉచ్చు.

ఆర్కిటెక్చర్ నిర్ణయాలు మీ హోస్టింగ్ బిల్లులు, మీ షిప్పింగ్ వేగం మరియు మీ హైరింగ్ ప్లాన్‌ను నిర్ణయిస్తాయి. మీరు డెవలపర్‌కు బడ్జెట్ ఇచ్చే ముందే దాని ఖర్చును మీరు తెలుసుకోవాలి.

ది మోనోలిత్ మోనోలిత్ అనేది ఒకే కోడ్‌బేస్, ఒకే డిప్లాయ్‌మెంట్ మరియు ఒకే డేటాబేస్‌ను ఉపయోగిస్తుంది. ఇది సరళంగా ఉంటుంది.

మొదటి రోజున, మీకు మీ డొమైన్ బౌండరీస్ (domain boundaries) తెలియవు. మీరు సర్వీసులను చాలా త్వరగా విడగొడితే, ఉండకూడని గోడలను మార్చడానికే సమయాన్ని వృధా చేస్తారు. మీ టీమ్ చిన్నదిగా ఉన్నప్పుడు మోనోలిత్‌ను నిర్వహించడం సులభం. మీరు ఒక APIని సెటప్ చేయడానికి బదులుగా ఒక ఫంక్షన్‌ను కాల్ చేస్తారు. తెల్లవారుజామున 2 గంటలకు బగ్ వచ్చినప్పుడు, లోపం కోడ్‌ను సూచిస్తుంది, నెట్‌వర్క్ వైఫల్యాన్ని కాదు.

మైక్రోసర్వీసెస్ మైక్రోసర్వీసెస్ సంస్థాగత సమస్యలను పరిష్కరిస్తాయి. ఇవి వేర్వేరు టీమ్‌లు తమ స్వంత షెడ్యూల్‌ల ప్రకారం కోడ్‌ను షిప్ చేయడానికి అనుమతిస్తాయి. ఒక చిన్న లోపం వల్ల మొత్తం వ్యవస్థ దెబ్బతినకుండా ఉండటానికి నెట్‌ఫ్లిక్స్ (Netflix) వీటిని ఉపయోగిస్తుంది.

అయితే, దీని కోసం మీరు ప్రతిరోజూ చెల్లించాల్సి ఉంటుంది. నెట్‌వర్క్ కాల్స్ వల్ల లేటెన్సీ (latency) పెరుగుతుంది. డేటా కన్సిస్టెన్సీ (data consistency) కష్టమవుతుంది. లాగ్స్ మరియు ట్రేసింగ్‌ను నిర్వహించడానికి మీకు ప్రత్యేకమైన సాధనాలు మరియు పెద్ద టీమ్ అవసరం. సరైన సిబ్బంది లేకపోతే, మీరు చివరకు ఒక 'డిస్ట్రిబ్యూటెడ్ మోనోలిత్' (distributed monolith) పరిస్థితిని ఎదుర్కోవాల్సి వస్తుంది. ఇది మీకు నెట్‌వర్క్ యొక్క సంక్లిష్టతను ఇస్తుంది కానీ స్వతంత్రతను ఇవ్వదు.

ది మోడ్యులర్ మోనోలిత్ ఇది మధ్యేమార్గం. ఇది కోడ్‌లోని వివిధ భాగాల మధ్య స్పష్టమైన విభజనలు కలిగిన ఒకే ఒక యాప్. బిల్లింగ్ విభాగం మీ ఆర్డర్ల అంతర్గత వివరాలను తాకలేదు.

షాపిఫై (Shopify) మరియు గిట్‌హబ్ (GitHub) ఈ విధానాన్ని ఉపయోగిస్తాయి. దీనివల్ల మీకు స్పష్టమైన బౌండరీస్ లభిస్తాయి మరియు నెట్‌వర్క్ టాక్స్ (network tax) నుండి తప్పించుకోవచ్చు. మీ యాప్‌లోని ఒక భాగం విడిగా స్కేల్ అవ్వాల్సిన అవసరం వచ్చినప్పుడు, దాని సరిహద్దులు ముందే నిర్వచించబడినందున మీరు దానిని సులభంగా విడగొట్టవచ్చు.

ఎలా నిర్ణయించుకోవాలి:

  • టీమ్ పరిమాణం: మీ వద్ద కేవలం ముగ్గురు వ్యక్తులు మాత్రమే ఉంటే, మీరు విడివిడి సర్వీసులను మరియు అవసరమైన ఆన్-కాల్ రొటేషన్‌ను నిర్వహించలేరు.
  • ఉత్పత్తి స్థిరత్వం: మీ ఉత్పత్తి ప్రతి వారం మారుతుంటే, వచ్చే నెలకు వచ్చేసరికి మీ సర్వీస్ బౌండరీస్ తప్పుగా మారుతాయి.
  • ఆపరేషన్స్: మీ వద్ద ఆటోమేటెడ్ రోల్‌బ్యాక్స్ (automated rollbacks) మరియు లాగ్ అగ్రిగేషన్ (log aggregation) ఉన్నాయా? లేకపోతే, మైక్రోసర్వీసెస్ ఇబ్బందులను కలిగిస్తాయి.
  • స్కేల్: ఊహాజనిత వృద్ధి కోసం నిర్మించకండి. మీకు కనిపిస్తున్న స్పష్టమైన మార్గం కోసం మాత్రమే నిర్మించండి.

మీ సమాధానాలు "ఇంకా లేదు" అని ఉంటే, మోడ్యులర్ మోనోలిత్‌ను నిర్మించండి.

మైక్రోసర్వీసెస్ అనే పదం ఆధునికంగా అనిపిస్తుంది కాబట్టి వాటిని కోరకండి. మీ ఉత్పత్తి ఏం చేస్తుంది మరియు దానిని ఎవరు నిర్వహిస్తారు అనే విషయాన్ని మీ భాగస్వామికి స్పష్టంగా చెప్పండి.

ఉత్పత్తులు ఎప్పుడూ విడుదల కాకపోవడం వల్ల విఫలమవుతాయి. వినియోగదారుల ముందుకు వెళ్లడానికి ఒక స్పష్టమైన మోనోలిత్ (monolith) అత్యంత వేగవంతమైన మార్గం. మొదట దానినే నిర్మించండి. వాటిని విడగొట్టాల్సిన సమయం ఎప్పుడు వచ్చిందో మీ ట్రాఫిక్ ద్వారా తెలుసుకోండి.

మూలం: https://dev.to/amara_wallis_2f533953a6ac/microservices-vs-monolithic-architecture-what-should-your-full-stack-development-partner-build-3g6

ఐచ్ఛిక అభ్యాస సమూహం: https://t.me/GyaanSetuAi