- Microsoft Azure पर हर दिन होने वाली अजीब घटनाओं को साझा करने वाला एक अकाउंट। यह अब 400 दिनों से आगे बढ़ चुका है
- Day 403: हाल ही में #Microsoft Cloud for Sustainability Technical Summit हुआ। लेकिन असल में यह स्थिरता पर थोड़े-से फोकस वाले #Copilot Summit जैसा ज़्यादा लगा। (यह स्क्रीनशॉट सिर्फ शुरुआती तीन sessions से लिया गया है)
- Day 402: Azure CLI की नई #AI सुविधा अब तक शानदार तरीके से काम कर रही है (एरर स्क्रीनशॉट)
- Day 401: लिंक एरर इमेज। यह उन अनगिनत #Azure docs links के उदाहरणों में से सिर्फ एक है जो ऐसे section पर ले जाते हैं जो मौजूद ही नहीं है
...
1 टिप्पणियां
Hacker News टिप्पणियाँ
पहले जब मैं Mojang में काम करता था, Microsoft द्वारा अधिग्रहण के बाद हमने AWS से Azure पर जाने की कोशिश की थी
ऊपर-ऊपर से यह समझ में आता था, और जहाँ AWS की लागत महीने में छह अंकों वाले डॉलर में थी, वहीं Azure मुफ्त में इस्तेमाल किया जा सकता था
लेकिन करीब 1 साल बाद, हमारी टीम और Azure संगठन द्वारा लगाए गए solution experts के अनगिनत घंटे खर्च होने के बाद, सभी इस बात पर सहमत हुए कि Microsoft के बड़े प्रतिस्पर्धियों में से एक को दी जा रही छह अंकों की लागत जारी रखनी पड़ेगी
उसके बाद से मैंने Azure को असल इस्तेमाल के लायक cloud provider के रूप में देखना बंद कर दिया, और शायद किसी दिन फिर से आकलन करना पड़े, लेकिन यह पहली बार नहीं होगा जब मैं गलत साबित होऊँ
कुल मिलाकर ठीक था, लेकिन जब हमने CosmosDB, उस समय के नाम DocumentDB, का इस्तेमाल शुरू किया तो समस्याएँ आने लगीं
शुरुआती DocumentDB सचमुच बेहद खराब था, pricing का अनुमान लगाना इतना मुश्किल था कि हर weekend बेतुके bill आते थे, और दिया गया .NET SDK भी bugs से भरा और भयानक था
सबसे बुरा यह था कि web UI किसी खास CosmosDB instance से सीधे बँधा हुआ लगता था
अगर database resources कम रखे जाते, तो वह धीमा हो जाता, और resources बढ़ाने के लिए जिस web interface का इस्तेमाल करना पड़ता था, वह भी साथ-साथ lag करने लगता था
इसलिए Cosmos resources बढ़ाने के लिए पूरी application बंद करनी पड़ती थी, और Microsoft पूरी तरह amateur जैसा लगता था
समझता हूँ कि अब Cosmos काफी बेहतर हो गया है, लेकिन उस समय का अनुभव बहुत कड़वा था
अगर free credits जैसी कोई चीज मिले तो Azure को फिर आजमा सकता हूँ, लेकिन अभी तो बिल्कुल recommend नहीं करूँगा
दुनिया की सबसे बड़ी email service को Windows stack पर चलाना बहुत बड़ी endorsement साबित होता, लेकिन सफल होने में कई साल लग गए
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
मेरा अंदाज़ा है कि शायद AWS की serverless processing जैसी कोई AWS-specific capability रही होगी जिसे सीधे Azure पर नहीं ले जाया जा सकता था, लेकिन X से Y में migration क्यों failed हुआ, इससे सीखना हमेशा अच्छा लगता है
इस बीच game-side technologies के और तैयार हो जाने से भी मदद मिली होगी
edit: AWS -> Azure :)
चूँकि AWS कुल मिलाकर आगे था, उस समय एक technology gap था, और लगता है बाद में वह gap भर गया
कोई बात नहीं, Microsoft अगले हफ्ते इसका नाम बदल देगा और admin UI और API को पूरी तरह बदल देगा
अब इसका नाम Dynamics CoPilot OneAI 365 for Business OneCloud होगा
live.com, कुछoutlook.com, और कुछsharepoint.com,msbinbows.comजैसे ही रहेंगेलेकिन docs और बाकी सभी references पुराने नाम ही बनाए रखेंगे
मेरे अनुभव में, on-premises server racks से लेकर Linode, AWS और Azure तक इस्तेमाल करने वाले संगठनों को देखा है, और cloud infrastructure को लेकर शिकायतें managed services के usage के अनुपात में बढ़ती थीं
जो teams मुख्य रूप से virtual machines, और बहुत हुआ तो managed relational database, पर निर्भर थीं, वे लगभग शिकायत नहीं करती थीं
कुछ extra scripts maintain करनी पड़ती हैं, लेकिन managed services की समस्याओं और अजीब behaviours से लड़ने की तुलना में यह मामूली असुविधा है
जाहिर है साधारण virtual machines को managed services की तुलना में maintain करना आसान होता है, और इसी वजह से खुद यह काम न करना पड़े इसलिए cloud provider को managed services के लिए कहीं अधिक पैसा दिया जाता है
तो क्या मतलब यह है कि यह कोशिश मूल रूप से बेकार है?
कई कंपनियों के cloud पर जाने की मुख्य वजह managed services ही होती हैं, इसलिए यह कहना बिल्कुल विवादरहित नहीं माना जा सकता
एक customer को production servers वाले VPC तक IPsec tunnel चाहिए था, और सिर्फ एक customer के लिए ऐसा setup खुद maintain नहीं करना चाहते थे, इसलिए AWS की provided service देखी तो managed IPsec solution मौजूद था
लेकिन customer ने बताया कि tunnel down हो गया है, और समाधान यह था कि connection फिर शुरू करने के लिए customer side से restart करना होगा
क्यों हुआ यह देखने के लिए S3 logging चालू कर सकते थे, लेकिन AWS की तरफ से explanation के मुताबिक सब कुछ normal होना चाहिए था
केवल EC2 इस्तेमाल करने पर भी अजीब चीजें होती हैं
हाल ही में एक EC2 instance ने respond करना बंद कर दिया, लेकिन Auto Scaling Group ने उसे replace नहीं किया, और कोई भी action करने पर error आता था कि instance running नहीं है, जबकि status running था
सौभाग्य से boss सहमत हैं, लेकिन उनके पास पूरा अधिकार नहीं है
vendor lock-in और open source से लगभग मेल खाने वाली, लेकिन पूरी तरह नहीं मिलने वाली API compatibility की वजह से, जितनी ज्यादा teams इसे अपनाती हैं, उतनी चिंता बढ़ती है
वे कहते हैं, “लेकिन यह आसान है!” — देखते हैं
करीब 2014 से पहले AWS प्रमुख services की कीमतें समय-समय पर घटाता था और technology cost में आई कमी को आगे pass on करता था
Azure को यह पसंद नहीं था, इसलिए उसने AWS की कीमतों को match करना शुरू किया, और समान services पर समान discounts को तुरंत follow किया
इसका मकसद यह था कि competitor कीमत कम करे तब भी उसे market share न मिले, जिससे price cuts की incentive खत्म हो जाए; यह predatory pricing का एक रूप है
टूल्स के साथ अच्छे integration की वजह से मैं सच में Azure को पसंद करना चाहता था, लेकिन बार-बार virtual machine availability limits और UX की अजीब बातों से टकराया
AWS में कभी ऐसा नहीं लगा कि machine नहीं मिलेगी या मैंने जो action किया है वह सच में लागू होगा या नहीं
Azure के FaaS पर भी कई बार सोचा, लेकिन अब मेरा रुख साफ़ है: “मत इस्तेमाल करो और जल्दी भागो”
Azure Functions के आसपास का experience इतना अजीब है कि उसके साथ सहज होना मुश्किल है, और logs या दूसरे binary artifacts तक पहुंचना भी बेहद दर्दनाक है
खाली Windows/Linux virtual machine पर self-contained .NET build चलाना इतना आसान है कि इस सारी अतिरिक्त complexity में फंसने की कोई वजह नहीं है
और SQL Server असल में 20 मिनट बाद तैयार होता है, फिर भी running का callback भेज देता है—इस तरह के automation तोड़ने वाले behavior भी हैं
मुझे आधा यकीन है कि
terraform time_sleepखास तौर पर Azure की समस्याओं से बचने के लिए ही बनाया गया होगाजब function app को simple functions से आगे बढ़कर लंबा execution time या cold start delay न होना चाहिए, तो आखिरकार यही वही service इस्तेमाल होती है
App Services को समझने में समय लगता है, लेकिन यह built-in FTPS, self-healing के लिए health check endpoint, storage specify करने वाली deployment, auto-scaling options और 99.95% SLA वाला locked-down Win Server/IIS container है
कुछ साल पहले performance के लिहाज से यह खास नहीं था, लेकिन नए CPU वाले 2 या ज्यादा vCPU Premium SKU में कोई दिक्कत नहीं आई
virtual machine से महंगा है, लेकिन web server virtual machine की security और updates संभालना बहुत बड़ा काम है
हमने एक company acquire की थी जो Azure पर hosted थी
वे hosted Postgres और Windows पर .NET services इस्तेमाल कर रहे थे, और infrastructure छोटा था—करीब 200~300 cores और 1TB memory
हर कुछ दिनों में Microsoft maintenance के नाम पर random instances को मनमाने ढंग से down कर देता और network को 10 मिनट से ज्यादा के लिए काट देता
hosted Postgres की performance त्रासद थी, इसलिए migration किया; India-based expert ने दूसरा volume type इस्तेमाल करने को कहा, और instance restart के बाद I/O latency की वजह से database ऊपर ही नहीं आया
वह expert busy बताकर लगातार 3 दिन meetings से बचता रहा, और RCA शायद LLM से लिखा हुआ आधा-अधूरा document था जिसमें कहा गया था कि गलती उनकी नहीं थी, लेकिन charts कुछ और कहानी बता रहे थे
GCP और AWS से Azure जिस एक चीज़ में आगे है, वह बस dashboard का जल्दी load होना है
हालांकि अगर दो मिलते-जुलते network operations parallel चलाएं, तो वे fail हो जाते हैं या sequential execution से 10 गुना ज्यादा समय लेते हैं—जो दुखद है
भागो, और इस्तेमाल मत करो
सभी PaaS providers में Azure की abstractions और services सबसे खराब हैं
दुख की बात है कि लोग आम तौर पर ऐसी अजीब services consume करने पर सहमत हो जाते हैं, और cloud architects व experts की jobs बनती हैं
partners को लगातार relevant बनाए रखना होता है, इसलिए खराब design और loose coupling को पोषण मिलता है
सच कहूं तो enterprise IT के बारे में मेरी कुल राय भी यही है
करीब 30 developers वाली एक छोटी company में हमें Azure की गड़बड़ी विरासत में मिली; जिन services की जरूरत थी उनके लिए developer tools में industry standard के करीब abstractions बनाए, और कुछ साल बाद Hetzner पर चले गए
यहां developers को असल में फर्क पता भी नहीं चलता
हमारे tools workflow और service abstractions संभालते हैं, और provider बदलने पर ये चीजें बदलनी नहीं चाहिए
monthly bill दसवें हिस्से पर आ गया, और उस पैसे का कुछ हिस्सा हमने बेहतरीन developer experience बनाने में लगाया जिसकी कल्पना की जा सकती थी
मेरे हिसाब से यह बहुत अच्छा exchange था
बड़े cloud का इस्तेमाल करने लायक सिर्फ दो cases हैं
या तो सचमुच बहुत छोटा MVP scale हो, या फिर elasticity की जरूरत वाला बहुत बड़ा globally distributed environment
ज्यादातर companies के संदर्भ में दोनों ही लगभग exceptions हैं
लगता है कोई भी Azure user Azure इस्तेमाल न करने के 100 कारण बना सकता है, और ज्यादातर बड़े software के साथ भी यही होगा
दूसरे clouds का exposure कम होने के बावजूद, यह आसानी से दिखता था कि Azure user experience ठीक से managed नहीं है और पीछे रह जाता है
जिन pages पर filter bar ठीक से काम करने के लिए “और देखें” दबाना पड़े, उनकी संख्या अब साफ़ तौर पर 0 होनी चाहिए
यह objectively खराब pattern है, सालों से मौजूद है, और इसे ठीक करना “आसान होना चाहिए”, लेकिन शायद यह कभी priority नहीं बनेगा
आखिरकार ऐसी दिक्कतें तभी ठीक होती हैं जब उन्हें सुलझाना organization की core value हो या revenue पर साफ़ चोट पहुंचा रहा हो
user community के लिए ऐसी समस्याओं की public visibility और openness हमेशा महत्वपूर्ण होती है
मैं AWS और Azure दोनों इस्तेमाल करता हूं, और Azure में जो एक चीज मुझे सच में पसंद है वह portal है
AWS 2.0 की तरह cloud की उलझनें abstract हो जाती हैं, और केवल वे settings बचती हैं जिन्हें सच में manipulate करना है और उनके आपसी relationships
AWS भी पसंद है, लेकिन हर बार किसी अनजान environment में जाकर सारे connections reverse-engineer करने पड़ें, तो अंत में drink की जरूरत महसूस होती है
मैंने Azure कुछ दिनों तक इस्तेमाल किया था, और portal सच में painful था
हर click पर response आने में 5~10 सेकंड लगते थे, और basic setting बदलने पर भी कभी-कभी Ajax spinner को 2 मिनट से ज्यादा देखना पड़ता था
कोई इस तरह काम करना कैसे enjoy कर सकता है?
ऐसा लगता है जैसे कोई जानबूझकर इन्हें जितना हो सके उतना confusing बना रहा है, लेकिन मकसद का अंदाजा भी नहीं लगता
मेरा मतलब यह नहीं कि राय invalid है या झूठ है, लेकिन Azure ecosystem के अंदर हर घंटे रहने वाले लोगों तक को शामिल कर लें, तो भी मैंने Azure portal को पसंद करने वाला कोई नहीं देखा
अगर नहीं, तो मजेदार है
मैं पूरी तरह opposite side पर हूं, तो इसे अपनी-अपनी पसंद मानना पड़ेगा
दोनों को काफी इस्तेमाल किया है, और Azure dashboard अब भी annoying है, लेकिन usability के लिहाज से यह AWS से कहीं बेहतर है
इसके अलावा Microsoft साफ़ तौर पर documentation पर समय और पैसा लगाता है, जबकि AWS docs हमेशा कमजोर रहे हैं
अगर आप छोटी कंपनी हैं और containers नहीं चला रहे हैं, तो Cloudflare काफी underrated cloud है
मुझे पता है कि अन्य वजहों से इसकी आलोचना होती है, लेकिन अगर आप big 3 या 4 से थक चुके हैं, तो developer experience सच में बेहतरीन है
[1]: https://blog.cloudflare.com/container-platform-preview/
Svelte sites के लिए मुझे पसंद है, लेकिन language और request-response आधारित constraints से बंध जाना बहुत बड़ी सीमा है
कम से कम containers और persistent volumes हों, तभी दिलचस्पी होगी
मुझे Azure से सचमुच जुनून की हद तक नफ़रत है
मैं उस team में हूँ जो cloud provider के हिसाब से project/account/subscription creation को automate करने वाले tools बनाती है
मुख्य provider GCP है, और implementation काफी आसान था
कुछ traps थे, लेकिन उन्हें आसानी से पार किया जा सका
अब multi-cloud के लिए Azure support करना है
पहले हम AWS पर थे, लेकिन 95% बाहर निकल चुके हैं, और अभी भी कुछ teams बची हैं, मगर Terraform modules के अलावा tools लगभग नहीं बनाते
लेकिन Azure API, MS Graph API, और दोनों के Go SDK अब तक जिन चीज़ों से निपटा हूँ उनमें सबसे बड़ा कूड़े का ढेर हैं
सब कुछ pointer है, यहाँ तक कि string literals को भी pointer बनाना पड़ता है, लेकिन कभी-कभी ऐसा भी नहीं होता
documentation गलत है, कुछ APIs सिर्फ ID लेते हैं जबकि दूसरे पूरे path लेते हैं
कुछ documented हैं, लेकिन कई APIs में गलत format लिखा है
कोई भी API related resource ID return नहीं करता, इसलिए सब कुछ search करना पड़ता है, और name-based searches बहुत ज़्यादा हैं
creation के दौरान उसी resource को बार-बार query करने से बचने के लिए ID caching layer तक जोड़नी पड़ी
हम creation के लिए state machine इस्तेमाल करते हैं और बीच से resume कर सकते हैं, इसलिए verification और resume आधारित code काफी चाहिए
कुल मिलाकर यह design और implementation के लिहाज़ से सबसे खराब cloud provider है, और अगर मेरे पास choice हो तो मैं इसे कभी recommend या choose नहीं करूँगा
अंदर Go में लिखी चीज़ें आमतौर पर बढ़िया होती हैं
हमने अपने यहाँ एक बनाया है, लेकिन third-party options में भी रुचि है
हालांकि internal business rules की वजह से खरीदने के बजाय खुद बनाना ही सही हो सकता है