પ્રિય Google ક્લાઉડ, પાછળની તરફ સુસંગત ન હોવું એ તમને મારી નાખે છે.

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

તો ચાલો આ સાથે મળીએ.

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

પ્રથમ, થોડી પૃષ્ઠભૂમિ: ગૂગલ પાસે ડેટા સ્ટોરેજ ટેક્નોલોજી છે જેને કહેવાય છે બિગટેબલ. તે એક નોંધપાત્ર તકનીકી સિદ્ધિ હતી, જે પ્રથમ (જો પ્રથમ ન હોય તો) “અનંત રીતે સ્કેલેબલ” કી-વેલ્યુ સ્ટોર (K/V): અનિવાર્યપણે NoSQL ની શરૂઆત હતી. આ દિવસોમાં બિગટેબલ હજી પણ ગીચ K/V સ્ટોરેજ સ્પેસમાં સારું પ્રદર્શન કરી રહ્યું છે, પરંતુ તે સમયે (2005) તે આશ્ચર્યજનક રીતે ઠંડુ હતું.

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

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

કોઈપણ રીતે, અહીં મારી વાર્તા છે.

તે સમયે, હું ગૂગલમાં માત્ર બે વર્ષથી કામ કરતો હતો, અને એક દિવસ મને બિગટેબલ એન્જિનિયરિંગ ટીમ તરફથી એક ઇમેઇલ મળ્યો જે કંઈક આના જેવું હતું:

પ્રિય સ્ટીવ,

Bigtable ટીમ તરફથી હેલો. અમે તમને જણાવવા માંગીએ છીએ કે [ડેટા સેન્ટર નામ] પર તમે ખૂબ જ જૂની Bigtable દ્વિસંગીનો ઉપયોગ કરી રહ્યાં છો. આ સંસ્કરણ હવે સમર્થિત નથી અને અમે તમને નવીનતમ સંસ્કરણ પર અપગ્રેડ કરવામાં સહાય કરવા માંગીએ છીએ.

કૃપા કરીને મને જણાવો કે તમે આ મુદ્દા પર સાથે કામ કરવા માટે થોડો સમય શેડ્યૂલ કરી શકો છો.

તમામ શ્રેષ્ઠ,
બિગટેબલ ટીમ

Google પર તમને ઘણા બધા મેઇલ મળે છે, તેથી પ્રથમ નજરમાં મેં આના જેવું કંઈક વાંચ્યું:

પ્રિય પ્રાપ્તકર્તા,

અમુક ટીમ તરફથી હેલો. અમે તે બ્લા બ્લા બ્લા બ્લા બ્લા બ્લા વાતચીત કરવા માંગીએ છીએ. બ્લા બ્લા બ્લા બ્લા બ્લા બ્લા, અને બ્લા બ્લા બ્લા તરત જ.

કૃપા કરીને અમને જણાવો કે શું તમે તમારા કિંમતી સમયમાંથી કેટલાક બ્લા બ્લા બ્લાહ માટે શેડ્યૂલ કરી શકો છો.

તમામ શ્રેષ્ઠ,
અમુક પ્રકારનો આદેશ

મેં તેને લગભગ તરત જ કાઢી નાખ્યું હતું, પરંતુ મારી ચેતનાના કિનારે મને એક પીડાદાયક, સતાવનારી લાગણી અનુભવાઈ હતી કે તે ખરેખર નથી જોકે ઔપચારિક પત્ર જેવો દેખાય છે દેખીતી રીતે, કે પ્રાપ્તકર્તાની ભૂલ થઈ હતી કારણ કે મેં Bigtable નો ઉપયોગ કર્યો નથી.

પરંતુ તે વિચિત્ર હતું.

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

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

છેવટે, જિજ્ઞાસા મારામાં વધુ સારી થઈ અને હું તેઓએ ઉલ્લેખિત ડેટા સેન્ટરમાં બોર્ગ કન્સોલ જોવા ગયો.

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

આ વાર્તાના કેટલાક નોંધપાત્ર પાસાઓ છે. સૌપ્રથમ, બિગટેબલનું કાર્ય ગૂગલના સ્કેલ પર એટલું નજીવું હતું કે માત્ર બે વર્ષ પછી કોઈએ વધારાના સ્ટોરેજની નોંધ લીધી, અને માત્ર એટલા માટે કે બાઈનરીનું સંસ્કરણ જૂનું હતું. સરખામણી માટે, મેં એકવાર ઉપયોગ કરવાનું વિચાર્યું Google Cloud પર Bigtable મારી ઑનલાઇન રમત માટે. તે સમયે, આ સેવાનો ખર્ચ દર વર્ષે આશરે $16 હતો. ખાલી GCP પર બિગટેબલ. હું એમ નથી કહેતો કે તેઓ તમારી સાથે છેતરપિંડી કરી રહ્યા છે, પરંતુ મારા અંગત મતે, તે ખાલી અશ્લીલ ડેટાબેઝ માટે ઘણા પૈસા છે.

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

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

મેં તેમનો આભાર માન્યો, સ્ટોરેજ કાઢી નાખ્યું અને જીવન રાબેતા મુજબ ચાલ્યું. પરંતુ તેર વર્ષ પછી, હું હજી પણ તે પત્ર વિશે વિચારું છું. કારણ કે કેટલીકવાર મને Google Cloud તરફથી સમાન ઇમેઇલ્સ પ્રાપ્ત થાય છે. તેઓ આના જેવા દેખાય છે:

પ્રિય Google ક્લાઉડ વપરાશકર્તા,

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

અમે એ સુનિશ્ચિત કરવા માટે પ્રતિબદ્ધ છીએ કે આ ફેરફારની Google Cloud પ્લેટફોર્મના તમામ વપરાશકર્તાઓ પર ન્યૂનતમ અસર પડે.

શ્રેષ્ઠ મિત્રો કાયમ,
ગૂગલ ક્લાઉડ પ્લેટફોર્મ

પરંતુ હું લગભગ ક્યારેય આવા પત્રો વાંચતો નથી, કારણ કે તેઓ ખરેખર શું કહે છે તે છે:

પ્રિય પ્રાપ્તકર્તા,

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

અમે એ સુનિશ્ચિત કરવાના પ્રયાસો ચાલુ રાખીએ છીએ કે તમારા તમામ વિકાસ એક વર્ષમાં બિનઉપયોગી બની જાય.

કૃપા કરીને બંધ વાહિયાત
ગૂગલ ક્લાઉડ પ્લેટફોર્મ

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

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

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

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

હું જે પ્રથમ સિસ્ટમ પસંદ કરીશ તે સૌથી જૂની છે: GNU Emacs, જે વિન્ડોઝ નોટપેડ, OS કર્નલ અને ઇન્ટરનેશનલ સ્પેસ સ્ટેશન વચ્ચે એક પ્રકારની હાઇબ્રિડ છે. તે સમજાવવું થોડું મુશ્કેલ છે, પરંતુ ટૂંકમાં, Emacs એ 1976 (હા, લગભગ અડધી સદી પહેલા) માં બનાવવામાં આવેલ એક પ્લેટફોર્મ છે જે તમને વધુ ઉત્પાદક બનાવવા માટે પ્રોગ્રામિંગ માટે છે, પરંતુ ટેક્સ્ટ એડિટર તરીકે માસ્કરેડ કરે છે.

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

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

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

પરંતુ Emacs વિશ્વમાં એક અલગ કાર્યકારી વ્યાખ્યા હોય તેવું લાગે છે. એક અલગ અંતર્ગત ફિલસૂફી, જો તમે ઈચ્છો.

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

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

તે વપરાયેલી કાર વેચવા જેવું છે જે ચોક્કસપણે 1500 કિમી પછી તૂટી જશે.

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

સમસ્યા તેઓ વિચારે છે તેના કરતાં ઘણી મોટી છે, અને તે આવતા વર્ષો સુધી ચાલુ રહેશે કારણ કે ગ્રાહક સંભાળ તેમના ડીએનએમાં નથી. નીચે આ વિશે વધુ.

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

ખરેખર, મારે Android નો ટૂંકમાં ઉલ્લેખ કરવો જોઈએ કારણ કે તમે કદાચ તેના વિશે વિચારી રહ્યાં છો.

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

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

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

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

આ માટે હું એન્ડ્રોઇડને પ્રતિષ્ઠિત "યુ આર નોટ ગૂગલ" એવોર્ડથી સન્માનિત કરું છું. તેઓ ખરેખર Google બનવા માંગતા નથી, જે ટકાઉ પ્લેટફોર્મ કેવી રીતે બનાવવું તે જાણતા નથી, પરંતુ Android જાણે છે, તે કેવી રીતે કરવું. અને તેથી Google એક બાબતમાં ખૂબ જ સ્માર્ટ બની રહ્યું છે: લોકોને Android પર પોતાની રીતે વસ્તુઓ કરવા દે છે.

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

પરંતુ એક તફાવત છે. પછાત સુસંગતતા ઊંચી કિંમતે આવે છે. એન્ડ્રોઇડ પોતે આ ખર્ચનો બોજ ઉઠાવે છે, જ્યારે ગૂગલ ભારપૂર્વક ભાર મૂકે છે તમે છો, ચૂકવણી ગ્રાહક.

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

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

લેડી એસ્કોટ:
- એલિસ, શું તમે જાણો છો કે મને સૌથી વધુ શું ડર લાગે છે?
- કુલીન વર્ગનો પતન?
- મને ડર હતો કે મારી પાસે હશે કદરૂપું પૌત્રો.

સુંદર અને વ્યવહારુ વચ્ચેના વેપારને સમજવા માટે, ચાલો ત્રીજા સફળ પ્લેટફોર્મ પર એક નજર કરીએ (Emacs અને Android પછી) અને જુઓ કે તે કેવી રીતે કાર્ય કરે છે: Java પોતે.

Javaમાં ઘણાં જૂના API છે. જાવા પ્રોગ્રામરોમાં અવમૂલ્યન ખૂબ જ લોકપ્રિય છે, જે મોટાભાગની પ્રોગ્રામિંગ ભાષાઓ કરતાં પણ વધુ લોકપ્રિય છે. જાવા પોતે, મુખ્ય ભાષા અને પુસ્તકાલયો સતત API ને અવમૂલ્યન કરે છે.

હજારો ઉદાહરણોમાંથી માત્ર એક જ લેવા માટે, બંધ થ્રેડો અપ્રચલિત ગણવામાં આવે છે. ડિસેમ્બર 1.2 માં જાવા 1998 ના પ્રકાશન પછીથી તે નાપસંદ કરવામાં આવ્યું છે. આ નાપસંદ થયાને 22 વર્ષ થઈ ગયા છે.

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

ઓરેકલ કદાચ પ્લેટફોર્મ પણ સમજે છે. કોણ જાણે.

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

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

ચાલો અનુમાનિત રીતે માની લઈએ કે Apple એ મૂર્ખતાપૂર્વક Guido van Rossum પાસેથી સંકેત લીધો અને જાહેર કર્યું કે સ્વિફ્ટ 6.0 સ્વિફ્ટ 5.0 સાથે પાછળની તરફ અસંગત છે, જેમ કે પાયથોન 3 પાયથોન 2 સાથે અસંગત છે.

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

જો તમે Google Cloud Platform SDK (“gcloud”) ઇન્સ્ટોલ કરો છો, તો તમને નીચેની સૂચના પ્રાપ્ત થશે:

પ્રિય પ્રાપ્તકર્તા,

અમે તમને યાદ અપાવવા માંગીએ છીએ કે પાયથોન 2 માટે સમર્થનને નાપસંદ કરવામાં આવ્યું છે, તેથી તમને વાહિયાત

… અને તેથી વધુ. જીવનનું વર્તુળ.

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

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

તો ચાલો કહીએ કે Apple Guido પાસેથી સંકેત લે છે અને સુસંગતતા તોડે છે. તમને લાગે છે કે આગળ શું થશે? ઠીક છે, જો શક્ય હોય તો 80-90% વિકાસકર્તાઓ તેમના સૉફ્ટવેરને ફરીથી લખશે. બીજા શબ્દોમાં કહીએ તો, 10-20% યુઝર બેઝ આપમેળે અમુક સ્પર્ધાત્મક ભાષામાં જાય છે, જેમ કે ફ્લટર.

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

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

Grok એ Googlers ને તેમના સમગ્ર કોડબેઝ (શાબ્દિક રીતે સમગ્ર Google) પર સ્વચાલિત રિફેક્ટરિંગ કરવા માટે એક શક્તિશાળી માળખું પૂરું પાડ્યું. સિસ્ટમ ફક્ત તમારી અપસ્ટ્રીમ અવલંબન (જેના પર તમે નિર્ભર છો) જ નહીં, પણ ગણતરી કરે છે ઉતરતા (જે તમારા પર છે) તેથી જ્યારે તમે APIs બદલો છો ત્યારે તમે દરેકને જાણો છો કે તમે તોડી રહ્યાં છો! આ રીતે, જ્યારે તમે ફેરફારો કરો છો, ત્યારે તમે ચકાસી શકો છો કે તમારા API ના દરેક ઉપભોક્તા નવા સંસ્કરણ પર અપડેટ થયા છે, અને વાસ્તવમાં, ઘણીવાર તેઓએ લખેલા રોઝી ટૂલ સાથે, તમે પ્રક્રિયાને સંપૂર્ણપણે સ્વચાલિત કરી શકો છો.

આ Google ના કોડબેસને આંતરિક રીતે લગભગ અલૌકિક રીતે સ્વચ્છ રહેવાની મંજૂરી આપે છે, કારણ કે તેમની પાસે આ રોબોટિક નોકરો ઘરની આસપાસ ફરતા હોય છે અને જો તેઓ SomeDespicablyLongFunctionName નામ બદલીને SomeDespicablyLongMethodName કરે છે, કારણ કે કોઈએ નક્કી કર્યું છે કે તે એક નીચ પૌત્ર છે અને તેને ઊંઘવાની જરૂર છે.

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

જ્યારે તેઓ તેમના ક્લાઉડ ક્લાયંટ અને અન્ય API ના વપરાશકર્તાઓ પર આ વલણ લાદવાનો પ્રયાસ કરે છે ત્યારે સમસ્યા શરૂ થાય છે.

મેં તમને Emacs, Android અને Java સાથે થોડો પરિચય કરાવ્યો છે; ચાલો નવીનતમ સફળ લાંબા ગાળાના પ્લેટફોર્મ જોઈએ: વેબ પોતે. શું તમે કલ્પના કરી શકો છો કે જ્યારે અમે ફ્લેશિંગ ટૅગ્સનો ઉપયોગ કર્યો હતો ત્યારે 1995 થી HTTP કેટલા પુનરાવર્તનોમાંથી પસાર થયા છે? અને વેબ પેજ પર "અંડર કન્સ્ટ્રક્શન" ચિહ્નો.

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

હું ઓપરેટિંગ સિસ્ટમ ડેવલપર્સમાં અમારા મિત્રોનો પણ આભાર માનવા માંગુ છું: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, વગેરે, તેમના સફળ પ્લેટફોર્મ્સ પર બેકવર્ડ કમ્પેટિબિલિટીનું આટલું સારું કામ કરવા માટે (Apple ને શ્રેષ્ઠમાં C મેળવે છે. નુકસાન એ છે કે તેઓ કોઈ યોગ્ય કારણ વિના દરેક સમયે બધું તોડી નાખે છે, પરંતુ કોઈક રીતે સમુદાય દરેક પ્રકાશન સાથે તેની આસપાસ જાય છે, અને OS X કન્ટેનર હજી પણ સંપૂર્ણપણે અપ્રચલિત નથી... હજુ સુધી).

પણ રાહ જુઓ, તમે કહો છો. શું આપણે સફરજનની સરખામણી નારંગી સાથે નથી કરી રહ્યા - એકલ મશીન પર એકલ મશીન જેમ કે Emacs/JDK/Android/Chrome વિરુદ્ધ મલ્ટિ-સર્વર સિસ્ટમ્સ અને ક્લાઉડ સેવાઓ જેવી APIs?

ઠીક છે, મેં ગઈકાલે આ વિશે ટ્વીટ કર્યું હતું, પરંતુ લેરી વૉલની શૈલીમાં (પ્રોગ્રામિંગ ભાષા પર્લના નિર્માતા - આશરે પ્રતિ.) "સક્સ/રૂલ્સ" ના સિદ્ધાંત પર મેં આ શબ્દ જોયો અપ્રચલિત Google અને Amazon ડેવલપર સાઇટ્સ પર. અને જોકે AWS પાસે છે સેંકડો GCP કરતાં ગણી વધુ સેવા ઓફર, Google ના વિકાસકર્તા દસ્તાવેજીકરણમાં લગભગ સાત ગણી વધુ વખત અવમૂલ્યનનો ઉલ્લેખ છે.

જો Google પર કોઈ આ વાંચી રહ્યું હોય, તો તેઓ કદાચ ડોનાલ્ડ ટ્રમ્પ-શૈલીના ચાર્ટને બહાર કાઢવા માટે તૈયાર છે જે દર્શાવે છે કે તેઓ વાસ્તવમાં બધું બરાબર કરી રહ્યાં છે, અને મારે અયોગ્ય સરખામણીઓ કરવી જોઈએ નહીં જેમ કે "અવરોધિત શબ્દના ઉલ્લેખોની સંખ્યા વિરુદ્ધ સેવાઓની સંખ્યા" "

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

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

તો આ રાજકારણ છે. અને સંભવતઃ મારા ભાષણ પર ગુસ્સે જવાબો આવશે.

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

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

અને જ્યારે પણ હું AWS ને જોઉં છું, ત્યારે હું મારી જાતને પૂછું છું કે શા માટે હું હજુ પણ GCP પર છું. તેમને સ્પષ્ટપણે ગ્રાહકોની જરૂર નથી. તેઓ ને જરૂર છે ખરીદદારો. શું તમે તફાવત સમજો છો? મને સમજાવા દો.

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

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

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

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

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

સપોર્ટ કલ્ચરનો આ અભાવ, "ચાલો તેને વધુ સુંદર બનાવવા માટે તોડીએ" માનસિકતા સાથે, વિકાસકર્તાઓને વિમુખ કરે છે.

અને જો તમે લાંબા સમય સુધી ચાલતું પ્લેટફોર્મ બનાવવા માંગતા હોવ તો તે સારી વાત નથી.

ગૂગલ, જાગો, શાબ્દિક. હવે 2020 છે. તમે હજુ પણ હારી રહ્યા છો. અરીસામાં સખત દેખાવ કરવાનો અને તમે ખરેખર ક્લાઉડ બિઝનેસમાં રહેવા માગો છો કે કેમ તે જવાબ આપવાનો આ સમય છે.

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

કારણ કે ત્યાં ઓછામાં ઓછા ત્રણ વધુ ખરેખર સારા વાદળો છે. તેઓ ઈશારો કરે છે.

અને હવે હું મારી બધી તૂટેલી સિસ્ટમને ઠીક કરવા આગળ વધીશ. એહ.

આવતા સમય સુધી!

આ લેખ પરની કેટલીક ચર્ચાઓ વાંચ્યા પછી PS અપડેટ કરો (ચર્ચા મહાન છે, btw). ફાયરબેઝ સપોર્ટ બંધ કરવામાં આવ્યો નથી અને એવી કોઈ યોજના નથી કે જેના વિશે હું જાણું છું. જો કે, તેમની પાસે બીભત્સ સ્ટ્રીમિંગ બગ છે જેના કારણે Java ક્લાયંટ એપ એન્જિનમાં અટકી જાય છે. તેમના એક એન્જિનિયરે મને આ સમસ્યા ઉકેલવામાં મદદ કરી, જ્યારે મેં Google માં કામ કર્યું, પરંતુ તેઓ વાસ્તવમાં ક્યારેય બગને ઠીક કરી શક્યા નથી, તેથી મારી પાસે દરરોજ GAE એપ્લિકેશનને પુનઃપ્રારંભ કરવાની જરૂર છે. અને આમ તો ચાર વર્ષ થઈ ગયા! તેમની પાસે હવે ફાયરસ્ટોર છે. તેમાં સ્થાનાંતરિત કરવા માટે તેને ઘણું કામ લાગશે કારણ કે તે સંપૂર્ણપણે અલગ સિસ્ટમ છે અને ફાયરબેઝ બગ ક્યારેય ઠીક કરવામાં આવશે નહીં. શું નિષ્કર્ષ દોરી શકાય છે? તમે મદદ મેળવી શકો છો જો તમે કંપનીમાં કામ કરો છો. હું કદાચ GAE પર ફાયરબેઝનો ઉપયોગ કરનાર એકમાત્ર વ્યક્તિ છું કારણ કે હું 100% મૂળ એપ્લિકેશનમાં 100 થી ઓછી કી લોગ કરું છું અને તે જાણીતી બગને કારણે દર બે દિવસે કામ કરવાનું બંધ કરે છે. તમારા પોતાના જોખમે તેનો ઉપયોગ કરવા સિવાય હું શું કહી શકું. હું Redis પર સ્વિચ કરી રહ્યો છું.

મેં કેટલાક વધુ અનુભવી AWS વપરાશકર્તાઓને પણ જોયા છે કે AWS સામાન્ય રીતે કોઈપણ સેવાઓને સમર્થન આપવાનું બંધ કરતું નથી, અને SimpleDB એ એક ઉત્તમ ઉદાહરણ છે. મારી ધારણાઓ કે AWS પાસે સમર્થન રોગનો સમાન અંત નથી જે Google કરે છે તે ન્યાયી લાગે છે.

વધુમાં, મેં નોંધ્યું છે કે 20 દિવસ પહેલા Google App Engine ટીમે એક જટિલ Go લાઇબ્રેરીના હોસ્ટિંગને તોડી નાખ્યું હતું, એક મુખ્ય Go વિકાસકર્તાઓમાંથી એક GAE એપ્લિકેશનને બંધ કરી દીધી હતી. તે ખરેખર મૂર્ખ હતો.

છેલ્લે, મેં Googlers ને પહેલેથી જ આ મુદ્દા પર ચર્ચા કરતા અને સામાન્ય રીતે મારી સાથે સંમત થતા સાંભળ્યા છે (તમને પ્રેમ કરો!). પરંતુ તેઓને લાગે છે કે સમસ્યા વણઉકેલાયેલી છે કારણ કે Google ની સંસ્કૃતિમાં ક્યારેય યોગ્ય પ્રોત્સાહન માળખું નહોતું. મેં વિચાર્યું કે ગ્રેબમાં કામ કરતી વખતે મને AWS એન્જિનિયરો સાથે કામ કરવામાં આવેલા એકદમ અદ્ભુત અનુભવની ચર્ચા કરવા માટે થોડો સમય કાઢવો સારું રહેશે. ભવિષ્યમાં કોઈ દિવસ, હું આશા રાખું છું!

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

જ્યારે મેં ચાર વર્ષ પહેલાં ક્લાઉડ બિગટેબલ પર જોયું (આપવું કે લેવું), આ તે છે જ્યાં ખર્ચ હતો. એવું લાગે છે કે હવે તે થોડું ઘટી ગયું છે, પરંતુ તે હજી પણ ખાલી ડેટા વેરહાઉસ માટે ખૂબ જ ભયાનક છે, ખાસ કરીને કારણ કે મારી પ્રથમ વાર્તા બતાવે છે કે ખાલી મોટું ટેબલ તેમના સ્કેલ પર કેટલું અસંગત છે.

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

વાંચવા બદલ આભાર.

અપડેટ 2, 19.08.2020/XNUMX/XNUMX. પટ્ટી API ને યોગ્ય રીતે અપડેટ કરે છે!

અપડેટ 3, 31.08.2020/2/2. મારો સંપર્ક ક્લાઉડ માર્કેટપ્લેસ પર એક Google એન્જિનિયર દ્વારા કરવામાં આવ્યો હતો જે મારો જૂનો મિત્ર હતો. તે જાણવા માંગતો હતો કે શા માટે CXNUMXD કામ કરતું નથી, અને અમે આખરે શોધી કાઢ્યું કે તે એટલા માટે હતું કારણ કે મેં વર્ષો પહેલા મારું નેટવર્ક બનાવ્યું હતું, અને CXNUMXD લેગસી નેટવર્ક્સ પર કામ કરતું ન હતું કારણ કે તેમના નમૂનાઓમાં સબનેટ પેરામીટર ખૂટે છે. મને લાગે છે કે સંભવિત GCP વપરાશકર્તાઓ માટે તે શ્રેષ્ઠ છે કે તેઓ Google પર પૂરતા એન્જિનિયરોને જાણે છે તેની ખાતરી કરવી...

સોર્સ: www.habr.com