શું ડેટાબેઝ કુબરનેટ્સમાં રહે છે?

કોઈક રીતે, ઐતિહાસિક રીતે, IT ઉદ્યોગ કોઈપણ કારણોસર બે શરતી શિબિરમાં વહેંચાયેલો છે: જેઓ "માટે" છે અને જેઓ "વિરુદ્ધ" છે. તદુપરાંત, વિવાદોનો વિષય સંપૂર્ણપણે મનસ્વી હોઈ શકે છે. કયું ઓએસ વધુ સારું છે: વિન અથવા લિનક્સ? Android અથવા iOS સ્માર્ટફોન પર? શું તમારે વાદળોમાં બધું સંગ્રહિત કરવું જોઈએ અથવા તેને ઠંડા RAID સ્ટોરેજ પર મૂકવું જોઈએ અને સ્ક્રૂને સલામતમાં મૂકવું જોઈએ? શું PHP લોકોને પ્રોગ્રામર કહેવાનો અધિકાર છે? આ વિવાદો, અમુક સમયે, માત્ર પ્રકૃતિમાં અસ્તિત્વ ધરાવતા હોય છે અને રમતગમતના રસ સિવાય તેનો કોઈ આધાર હોતો નથી.

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

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

સારી બાજુ

લાઇટ સાઇડની દલીલને ટૂંકમાં એક શબ્દસમૂહમાં વર્ણવી શકાય છે: "હેલો, 2k19 વિન્ડોની બહાર છે!" તે લોકવાદ જેવું લાગે છે, અલબત્ત, પરંતુ જો તમે પરિસ્થિતિનો વિગતવાર અભ્યાસ કરો છો, તો તેના ફાયદા છે. ચાલો હવે તેમને સૉર્ટ કરીએ.

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

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

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

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

શું તમે કેચ અનુભવો છો? અમે લોડને વિતરિત કરવા અને મુખ્ય વેબ સર્વરને ક્રેશ થવાને ટાળવા માટે k8s અથવા Swarm નો ઉપયોગ કરીએ છીએ, પરંતુ અમે ડેટાબેઝ માટે આ કરતા નથી. પરંતુ જો ડેટાબેઝ ક્રેશ થાય છે, તો પછી આપણું આખું ક્લસ્ટર્ડ ઈન્ફ્રાસ્ટ્રક્ચર કોઈ અર્થમાં નથી - ખાલી વેબ પૃષ્ઠો કે જે ડેટાબેઝ ઍક્સેસ ભૂલ પરત કરે છે તે શું સારું છે?

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

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

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

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

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

અને હવે ડેટાબેઝ ક્લસ્ટરિંગના વિરોધીઓમાં બદલવાનો સમય છે.

કાળી બાજુ

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

સંમત થાઓ, જે પ્રોજેક્ટને ખરેખર કન્ટેનરમાં આધારની જરૂર હોય છે તે શ્રેષ્ઠ મિલિંગ મશીન ઓપરેટર દ્વારા એક હાથની આંગળીઓ પર ગણી શકાય. મોટાભાગે, k8s અથવા Docker Swarm નો ઉપયોગ પણ બિનજરૂરી છે - ઘણી વાર આ સાધનોનો ઉપયોગ ટેક્નોલોજીના સામાન્ય પ્રસિદ્ધિ અને લિંગની વ્યક્તિમાં "સર્વશક્તિમાન" ના વલણને કારણે કરવામાં આવે છે. વાદળો અને કન્ટેનર. ઠીક છે, કારણ કે હવે તે ફેશનેબલ છે અને દરેક તે કરે છે.

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

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

હવે કલ્પના કરો કે આ રીતે આપણે માત્ર વેબ સર્વરનો ભાગ જ નહીં, પણ ડેટાબેઝની જાળવણી પણ કરીએ છીએ. અમે કહ્યું કે BD હૃદય છે, અને હૃદયનું નુકસાન કોઈપણ જીવંત જીવ માટે ઘાતક છે. ટૂંકમાં, સંભાવનાઓ શ્રેષ્ઠ નથી. તેથી, હાઇપ કુબરનેટીસને બદલે, ઘણા પ્રોજેક્ટ્સે AWS માટે સામાન્ય ટેરિફથી પરેશાન ન થવું જોઈએ, જે તેમની સાઇટ/પ્રોજેક્ટ પરના ભાર સાથેની તમામ સમસ્યાઓને હલ કરશે. પરંતુ AWS હવે ફેશનેબલ નથી, અને શો-ઓફ પૈસા કરતાં વધુ મૂલ્યવાન છે - કમનસીબે, IT વાતાવરણમાં પણ.

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

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

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

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

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

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

આઉટપુટને બદલે

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

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

સોર્સ: www.habr.com