क्या startup को वाकई जटिल cloud infrastructure की ज़रूरत है?
(hadijaveed.me)- शुरुआती startup के लिए पहले दिन से Kubernetes या auto-scaling लगाने के बजाय, product बनाने और product-market fit खोजने में समय लगाना ज़्यादा बेहतर हो सकता है
- 20~30 Lambda functions, SQS और CloudWatch में बिखरे logs ने debugging, बदलाव और deployment को मुश्किल बना दिया, जबकि एक single NodeJS container या Flask/FastAPI app और Redis से चीज़ें सरल हो सकती थीं
- EKS पर चल रहे 7 microservices में CRUD और business logic को अलग-अलग बाँटने वाले उदाहरण में, feature development से ज़्यादा समय infra चलाने में गया
- एक single VM भी EC2, GCP VM, Hetzner, latitude.sh जैसे विकल्पों और 40GB RAM·multi-core सर्वर के साथ शुरुआती service के लिए काफ़ी computing दे सकता है
- सरल setup में भी HTTPS, सीमित SSH/SSM, CI/CD, DNS, DB backup, standby VM, disaster recovery, security rules और backup retention policy जैसी चीज़ें होनी चाहिए ताकि उसे production में इस्तेमाल किया जा सके
शुरुआती startup में ज़रूरत से ज़्यादा infra कैसे बन जाता है
- Pieter Levels को ऐसे उदाहरण के रूप में पेश किया गया है, जो कई micro-SaaS को एक single server पर चलाते हैं, cloud infra की जटिलता से बचते हैं और product-market fit पर ध्यान देते हैं
- यह तरीका हर team के लिए सही जवाब नहीं है, लेकिन यह अच्छी तरह दिखाता है कि deployment और infra management कैसे जटिलता के लिए ही जटिल बन सकते हैं
- MVP के बाद की छोटी development team deployment और database management में मुश्किल झेल सकती है, लेकिन हर project को पहले दिन से Kubernetes, जटिल distributed systems और auto-scaling की ज़रूरत नहीं होती
- सरल infra team को अच्छा product बनाने और market fit खोजने में ज़्यादा समय देता है
- enterprise scale की कंपनियों के compliance और बड़े manpower जैसे अलग सवाल होते हैं, लेकिन शुरुआती startup को वही जटिलता हूबहू अपनाने की ज़रूरत नहीं है
वास्तविक उदाहरण: जटिलता से पैदा हुआ operational burden
-
Lambda overload
- अलग-अलग services के लिए 20~30 Lambda functions मौजूद थीं
- SQS और कई background jobs भी Lambda-based थीं
- logs CloudWatch में बिखरे होने से root cause tracking मुश्किल हो गया
- debugging तकलीफ़देह हो गई, बदलाव कठिन हो गए, और monorepo होने पर भी deployment जटिल बना रहा
- एक single NodeJS container या Python Flask/FastAPI app, और Redis-based background jobs से इसे काफ़ी सरल बनाया जा सकता था
-
microservices की अति
- Kubernetes EKS पर 7 छोटे microservices चल रहे थे
- CRUD और business logic को अलग services में बाँटा गया था
- Kubernetes शक्तिशाली है, लेकिन उस team ने feature development से ज़्यादा समय infra पर खर्च किया
- उस scale पर इतने स्तर की service separation सच में ज़रूरी थी या नहीं, यह सवाल बना रहा
single server approach व्यावहारिक क्यों है
- single server setup आधुनिक VM performance का पूरा लाभ उठाने का तरीका है
- Hetzner, latitude.sh पर budget-friendly और शक्तिशाली VM मिल सकते हैं
- GCP VMs, EC2 instances भी उचित कीमत पर उपलब्ध हैं
- 40GB RAM और कई cores वाला server कई distributed services, कई Lambda, या कई ECS tasks से बेहतर विकल्प हो सकता है
- सब कुछ एक ही जगह होने से operations और management आसान हो जाते हैं
- millions QPS तक scale करने की समस्या तब संभाली जा सकती है जब वह समय वास्तव में आए, और तब तक शायद infra team भी होगी
- स्थिर single VM संचालन के लिए बुनियादी operational controls ज़रूरी हैं
- EC2, GCP VM, Hetzner जैसी मज़बूत machine
- web के लिए HTTPS, deployment के लिए IP-restricted SSH या SSM जैसी सुरक्षित access
- zero-downtime deployment के लिए CI/CD
- DNS configuration
- नियमित database backup
- redundancy के लिए standby VM
- मज़बूत disaster recovery strategy और tested recovery time की ज़रूरत होती है, जिसे backup VM से हासिल किया जा सकता है
Docker Compose और Docker Compose Anywhere
- Docker Compose local development में कई services को एक command से manage करने के लिए अच्छा है, लेकिन production में इसका कम उपयोग होता है
- Docker Swarm को deprecated बताया गया है
- Docker Compose में updates के दौरान downtime आ सकता है
- production deployment guide मौजूद है, और simplicity व production readiness के बीच संतुलन चाहिए
- Docker Compose Anywhere एक weekend project है, जिसका मकसद single VM setup को और सरल बनाना है
- GitHub Actions के ज़रिए Linux server को one-click setup किया जाता है
- GitHub Container Registry और Docker Rollout का उपयोग करके zero-downtime continuous deployment को support करता है
- environment variables और secrets management देता है, और security बेहतर करने के लिए age या sops पर विचार किया जा रहा है
- GitHub Actions-based automatic Postgres backup देता है
- एक single VM पर कई apps को support करता है
- Traefik और Let’s Encrypt से SSL automation करता है
- Next.js, Go, Python, Node.js apps आदि deploy किए जा सकते हैं
सरल होने पर भी ज़रूरी security और operations सिद्धांत
- security और data protection को simple setup में भी छोड़ा नहीं जा सकता
- सिर्फ़ ज़रूरी ports खोलने वाले सख़्त firewall rules चाहिए
- SSH keys को सुरक्षित रखना चाहिए, और AWS में SSM, GCP में CLI को प्राथमिकता दी जाती है
- security बढ़ाने के लिए bastion host का इस्तेमाल किया जा सकता है
- secrets को सुरक्षित रखना चाहिए और WAF या Cloudflare के उपयोग पर विचार करना चाहिए
- encrypted database backups को S3 या उसके बराबर सुरक्षित cloud storage में भेजना चाहिए
- अतिरिक्त redundancy के लिए नियमित disk snapshots बनाने चाहिए
- backups और snapshots के लिए retention policy लागू करनी चाहिए
- engineer की प्राथमिकता setup की simplicity बनाए रखना और core product पर फ़ोकस करना है
- Google engineering या बड़े enterprise तरीकों की नकल करने वाले जटिल setup, और नए tools, आसानी से ध्यान भटका सकते हैं
- startup हो या न हो, सबसे महत्वपूर्ण काम users से बात करना और product-market fit खोजना है
1 टिप्पणियां
Hacker News की राय
कई प्रोजेक्ट्स में चलन में चल रही तकनीक की वजह से बहुत परेशान होना पड़ा
टीम छोटी होने के बावजूद “अनंत scalability” चाहिए कहकर अविश्वसनीय रूप से कम गुणवत्ता वाले नतीजे बनाती थी, और LTS क्या होता है यह भी ठीक से न समझने वाली अनुभवहीन टीम Kubernetes की ज़रूरत है ऐसा तय कर देती थी
अब मेरे पास ऐसा संक्षिप्त Puppet code है जो किसी भी provider पर मनचाहे size की hardened VM बना सकता है, और उसके ऊपर Docker service, Python backend, static file serving चला सकता है
Hetzner VM 2-core हो या 48-core, 5 मिनट के अंदर service बना लेता हूँ, source-controlled manifest से configuration को नियंत्रित करता हूँ, और custom Naemon plugin से configuration compliance की निगरानी करता हूँ
यह पूरी तरह reproducible process है, लेकिन startup टीमें cloud में snowflake जैसी one-off configuration बनाते हुए हर महीने हज़ारों euro खर्च करती हैं और फिर भी 2017 के DevOps pioneers जो करते थे उससे भी खराब नतीजे देती हैं
इस विषय पर The Emperor's New clouds नाम से एक लेख भी लिखा था: https://logical.li/blog/emperors-new-clouds/
“Docker या दूसरी तकनीक के बिना configuration को reproduce कैसे करते हो?” यह सवाल मुझे कभी समझ नहीं आया
script deterministic थीं, dependency versions pinned थीं, configuration, input arguments और execution order भी वही रहते थे, और सब deterministic compute device पर चलता था
reproduce न होने की कोई वजह ही नहीं थी
hardened VM में Docker है यह कहने के बजाय kubelet है यह कह सकते हैं, और कई जुगाड़ू “docker services” की जगह बहुत कम overhead वाले k8s control plane से उन सभी VM को नियंत्रित किया जा सकता है
यह तरीका बेहतर क्यों है, मुझे समझ नहीं आता, बल्कि यह और खराब लगता है
खराब cloud infrastructure वह है जहाँ AWS जो कुछ भी बेचता है वह सब इस्तेमाल करने की कोशिश में पूरा infrastructure बहुत ऊँची abstraction layer में फँस जाता है और फिर दूसरे platform पर migrate नहीं हो पाता
k8s उससे बिल्कुल अलग है
अगर इनमें से किसी एक का भी जवाब “खुद बनाया है” या “बस एक script लिख लो” है, तो वही ठीक कारण है कि k8s की अहमियत है
अगर Python backend है, तो VPS पर build script को वैसे ही reproduce कर सकते हैं:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> बसinstance scaling के लिए इन commands को bash script
build_my_app.shमें डाल दें, और वही किसी नए Dockerfile जैसा काम करेगी, जो किसी भी server पर कुछ ही दसियों सेकंड में install हो सकती हैअगर IaaS की तरह इस्तेमाल करें, तो यह दूसरे तरीकों, यहाँ तक कि दूसरे provider के VPS से भी, prototype बहुत तेज़ी से बनाने देता है
खासकर Google Cloud में lock-in कम है, और यह principle of least surprise के भी ज़्यादा करीब है
लेकिन prototype बन जाने के बाद यह पूछना चाहिए कि क्या इसे किसी सस्ते स्थान पर फिर से बनाया जाए
disk को लगभग अनंत तक scale कर सकते हैं और snapshot भी ले सकते हैं, यह अच्छा है, और cloud prototype को production load तक scale करके असल में कितनी capacity चाहिए यह मापने देता है
लेकिन Cloud Run, Lambda जैसी “cloud magic” पर निर्भर होने पर सीखने और debugging में उतना ही समय लगा जितना आखिरकार पुराने तरीके से करने में लगता
छोटे startup में लगभग इसी तरह काम किया जाता है
GPU-मिश्रित job queue auto-scaling जैसे कुछ जटिल हिस्से हैं, लेकिन मूल बात एक single VM पर nginx, web app, Postgres, Redis है
B2B होने की वजह से traffic भी लगभग नहीं के बराबर है
developers अपने Linux laptop या दूसरे platform के Linux VM पर यही configuration जैसा-का-तैसा चला सकते हैं, और demo या test के लिए चाहें तो अपनी-अपनी cloud VM भी रख सकते हैं
नए system का bootstrap करना बस SSH key को check-in करने और shell script चलाने जितना है
debug करना आसान है, यह जटिल या महंगा नहीं है, और horizontal scaling की ज़रूरत पड़ने से पहले काफ़ी हद तक vertical scaling की जा सकती है
यह सबके लिए सही नहीं है, लेकिन seed stage से पहले के लिए यह पूरी तरह उपयुक्त लगता है
यह “public key को check-in” करने वाले तरीके से एक स्तर ज़्यादा indirect है, और इससे user Git change के बिना अपनी key बदल सकता है
और यह मूल विवरण से काफ़ी अलग बात है, लेकिन SSH key leasing offboarding की स्थितियों को कहीं बेहतर संभालती है, इसलिए यह वास्तव में बढ़िया है: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
लिंक ढूँढ़ते-ढूँढ़ते मुझे यह documentation भी मिली जिसमें दावा है कि Vault one-time password भी देता है <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
लेकिन मैं पक्का “PasswordLogin no” पक्ष का हूँ, इसलिए उस तरफ़ हर किसी को सावधानी से बढ़ना चाहिए
Postgres सब कुछ कर सकता है
ऐसी configuration में VM की settings और updates को कैसे track करते हैं?
जवाब है “नहीं, ज़रूरी नहीं”
मेरा SaaS शुरुआत में single server पर चलता था, और product-market fit मिलने के बाद उसे कई server पर शिफ्ट किया गया
ये Hetzner के bare metal server हैं, इनमें microservice नहीं हैं और न ही Kubernetes से जूझना पड़ता है, लेकिन हम distributed database चलाते हैं
cloud provider की virtual machine की तुलना में ये bare metal server बेहद ज़्यादा शक्तिशाली हैं
मैंने कुछ साल पहले इसका प्रत्यक्ष measurement भी किया था: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
कुल मिलाकर यह approach हैरान करने वाली हद तक प्रभावी है
Kubernetes जैसी जटिलता से नहीं जूझना पड़ता, जटिल systems में अनिवार्य रूप से आने वाले cascading failure से भी बचाव होता है, और development time, maintenance और monthly server cost की बचत होती है
आम सवाल होता है “लेकिन scale कैसे करोगे”, जबकि अभी यह भी नहीं पता कि scale की ज़रूरत पड़ेगी या नहीं, और इतने शक्तिशाली computer तथा समझदारी भरे design के साथ सिर्फ़ 3~5 server में भी बहुत दूर तक जाया जा सकता है
इसका मतलब यह नहीं कि business को घर की अलमारी में चलाना चाहिए
server management के लिए automation अब भी ज़रूरी है, और मैं ansible और terraform इस्तेमाल करता हूँ
यह इस आशावाद को उकसाती है कि software बहुत कम समय में बहुत बड़ी सफलता पा लेगा, और लोग उस पर विश्वास करना चाहते हैं
पता नहीं आपने लेख पढ़ा भी है या सिर्फ़ शीर्षक देखा है
नीचे A few considerations सेक्शन तक स्क्रोल करें, फिर हँसना मुश्किल होगा
वे “कुछ विचार” ख़ास तौर पर तब काफ़ी भारी security work बन जाते हैं जब आप बहुत संवेदनशील जानकारी store या transmit कर रहे हों
ऐसी स्थिति में HIPAA जैसी compliance requirements को कैसे handle करेंगे?
programmers दो तरह के होते हैं
एक वे जो सोचते हैं कि उन्होंने सब कुछ देख लिया है, और दूसरे वे जो जानते हैं कि उन्होंने लगभग कुछ भी नहीं देखा
इसलिए ऐसी पूर्णतावादी घोषणाएँ थका देती हैं
Kubernetes का मुख्य 20% हिस्सा Deployment, Pod, Service, blue-green deployment का handling, declarative definition, namespace isolation जैसी चीज़ें हैं, और यह वाकई अच्छा है
बस यही सरल बुनियाद बनाए रखें, managed cloud Kubernetes service इस्तेमाल करें, और stateful database को cluster के बाहर रखें, तो अनुभव अच्छा रहता है
समस्या तब शुरू होती है जब आप “cloud native” खरगोश के बिल में घुस जाते हैं और तरह-तरह के niche open source systems, operators, ambassador, sidecar pattern वगैरह इस्तेमाल करने लगते हैं
वे चीज़ें ऐसे environments के लिए हैं जहाँ कई technology teams और अलग-अलग programming languages साथ मौजूद हों, जो आपस में स्वतंत्र भी हों और जुड़े हुए भी
मुझे लगता है कि इस तरह की चर्चा में लोग अक्सर दो अलग चीज़ों की बात कर रहे होते हैं
मेरे लिए यह Docker Compose से बेहतर, एक समान deployment तरीका भर है
control plane के लिए मैं बहुत कम लागत देता हूँ, और workers तो kubelet वाले सामान्य VM हैं
लेकिन बहुत से लोगों के लिए “Kubernetes” शायद ऊपर वाले दूसरे paragraph का मतलब होता है
इसे उस तरह इस्तेमाल करना बिल्कुल ज़रूरी नहीं है
k3s cluster सेट करके सिर्फ workload, service, ingress सीख लेना भी काफ़ी है
अस्थायी VM और Docker configs को replace करने के लिए बस इतना ही चाहिए
99% मामलों में लोगों को बस docker-compose++ जितना चाहिए या वही चाहिए होता है
अगर zero-downtime deployment default रूप से मिले, और replica sets या दूसरे replication/distribution mechanisms के लिए एक simple configuration system हो, तो लगभग काम पूरा हो जाता है
काश ऐसा कुछ होता जो बस यही करता
Kubernetes बहुत भारी-भरकम है, और Docker Compose महत्वपूर्ण production requirements के लिए थोड़ा ज़्यादा basic है
Kubernetes में लगभग हर use case के लिए समायोजित किए जा सकने वाले लाखों knobs और dials हैं, लेकिन आप चाहें तो उन्हें नज़रअंदाज़ करके सिर्फ core features का इस्तेमाल कर सकते हैं और चीज़ों को सरल रख सकते हैं
आप जल्दी ही ऐसा setup बना सकते हैं जिसमें ठीक-ठाक deployments, बेहद आसान logs और metrics, और अच्छा developer experience हो
इसकी reputation इतनी खराब थी और मैंने इसे पहले कभी इस्तेमाल भी नहीं किया था, इसलिए जब मैंने पूछा कि क्या मैं internal tools के लिए server सेट कर सकता हूँ, तो मैंने सबसे बुरे की उम्मीद की थी
लेकिन असल में इसे सेट करने वाले व्यक्ति ने मुझे 30 मिनट का tutorial दिया, पूरे concept को समझाया, और server deploy करने भर की जानकारी दे दी; मैंने बिना किसी परेशानी के deploy कर दिया
git pushसे automatic deployment हो जाए, यह सेट करने में भी बहुत कम समय लगामुझे तो यह बहुत ही स्वाभाविक choice लगी
अगर आपका service सचमुच सिर्फ एक ही नहीं है, तो यह काफ़ी ज़्यादा आसान हो जाता है
हालाँकि मैंने इसे खुद install नहीं किया, इसलिए इसकी खराब reputation शायद उसी हिस्से से आती हो
अगर résumé में k8s नहीं है, तो नई नौकरी कौन पाएगा :)
गंभीरता से कहूँ तो, मुझे लगता है कि बहुत से लोग बड़े पैमाने के infrastructure को सीखने के लिए जानबूझकर कठिन रास्ता चुनते हैं
एक और आम वजह यह होती है कि “अगर ग्राहक बहुत ज़्यादा हो जाएँ तो यह काफ़ी आसान हो जाता है” या “माँग के हिसाब से dynamically scale किया जा सकता है”
बनाने वाले व्यक्ति के लिए यह सब तर्कसंगत हो सकता है, लेकिन किसी founder या पेशेवर CTO के लिए उतना तर्कसंगत नहीं होता
कुछ लोग संभावित ग्राहकों की ज़रूरतों और timelines की परवाह किए बिना, दिखावटी बेकार चीज़ें बनाते हुए पैसा जला देते हैं
यह वैसा है जैसे आप tyre बदलवाने garage जाएँ और mechanic अपनी growth की इच्छा के कारण उसमें lowrider hydraulics और spinning wheel caps लगा दे, और इसमें 3 हफ़्ते लगा दे
सबसे बुरी बात यह है कि अगली बार आने वाले व्यक्ति के लिए चीज़ें मूलतः अस्पष्ट हो जाती हैं
यह पता ही नहीं चलता कि कोई चीज़ वहाँ सच में ज़रूरत से है या सिर्फ चमकदार सजावट है
पता नहीं लोग यह दिलचस्पी की वजह से करते हैं, tech पसंद होने की वजह से, या जैसा कहा गया, résumé में k8s डालने के लिए तकनीकी नौकरशाही के अंदाज़ में अपनी skill बढ़ाने के लिए
मुझे तो बस यही लगता है, “इसे manage करना दर्दनाक होगा”
इसलिए मुझे लगता है कि k8s infrastructure को बेहतर होगा कि अपेक्षाकृत संकरे दायरे के वास्तविक experts, या कम-से-कम ऐसे experts जो mentees को lead कर सकें, design करें और उस पर काम करें
और जहाँ इसकी ज़रूरत न हो — यानी ज़्यादातर startups, छोटे व्यवसाय, और सामान्य आकार की कंपनियाँ — वहाँ ज़्यादा आसान मौजूदा paradigm पर टिके रहना ठीक है
वे अपने चुनाव से बहुत संतुष्ट थे, और इस पर उन्होंने blog में विस्तार से लिखा है
यह ऐसा मामला है जहाँ “अगर ग्राहक बहुत ज़्यादा हो जाएँ तो यह काफ़ी आसान हो जाता है” सच में सही साबित हुआ
यह पुरानी और अक्सर थका देने वाली बहस है, लेकिन फिर भी मैं अपने 2 cents जोड़ना चाहूँगा
क्या पहले दिन से ही कोई जटिल framework चुनना चाहिए? जब तक टीम के पास उसका पर्याप्त अनुभव न हो, शायद नहीं
लेकिन जिस बात का मैं विरोध करता हूँ, वह यह सोच है कि custom process और custom tools से infra मैनेज करना हमेशा proven tools की तुलना में कम maintenance effort लेगा
यह रवैया कि खुद के बनाए process बिल्कुल भी सरल नहीं हैं और core product से बहुत समय खींच लेते हैं, फिर भी “complexity” के पुतले को ज़िद से ठुकराया जाता है
सभी को binaries को VPS पर कॉपी करके service restart करने वाली सादगी पसंद है
लेकिन जल्द ही config और secrets management की ज़रूरत पड़ती है, और availability व redundancy के लिए जैसे ही कई server हो जाते हैं, progressive deployment, load balancing, rollback जैसी चीज़ें चाहिए होती हैं
staging environment भी चाहिए होगा, और इस workflow को आसानी से replicate करना भी ज़रूरी होगा
जैसे-जैसे टीम बड़ी होती है, यह भी साफ़ होता है कि production-जैसा environment local में चलाना संभव नहीं है
और इस तरह requirements जुड़ती ही जाती हैं
आखिरकार हर नई requirement पर, दूसरों द्वारा पहले से हल किए गए standard solution पर निर्भर होने के बजाय, आपको अपने ही किसी खास तरीके से उसे हल करना पड़ता है
बाद में यह sunk cost की समस्या बन जाती है
क्या आप अपने जाने-पहचाने custom tools छोड़कर किसी अनजानी “complexity” की ओर जाएँगे?
जितना ज़्यादा निवेश करेंगे, बाद में उतना ही मुश्किल होगा शिफ्ट करना
मेरा सुझाव है कि शुरुआत से ही ऐसी practices अपनाएँ, जिनसे बाद में standard tools पर जाना आसान हो
यानी day 1 से containers के साथ deploy करना, और 12-factor methodology अपनाना
और जब ज़रूरी features की कमी से दिक्कत शुरू हो, तो देर करने से बेहतर है कि जल्दी proven tools पर चले जाएँ
बहुत संभव है कि अनजाने का डर बेबुनियाद निकले, और लंबे समय में infra पर लगने वाला समय कम हो जाए
एक approach जिस पर मैंने विचार किया है, वह है day 1 से standard tools, यानी k8s + gitops, से शुरू करना, लेकिन फिर भी उसे single VM पर चलाना
आप क्या सोचते हैं?
जबकि ऐसे “cloud engineer” आसानी से मिल जाते हैं जो इन “complex” cloud systems को समझते हों और terraform से deploy व maintain कर सकें
यह एक ऐसा skill set है जिसे तुरंत काम में लगाया जा सकता है
VM, block/blob storage, DNS, IdP, domain registrar
cloud में मैंने आराम से बस इतना ही इस्तेमाल किया है
जैसे ही FaaS और उसके दोस्तों की तरफ़ जाते हैं, मेरे लिए चीज़ें सचमुच अजीब हो जाती हैं
यह बात सहना मुश्किल है कि production environment चलाने वाली machines के अंदर झाँक भी नहीं सकते
cloud dashboard से debugging करने का अनुभव बहुत खराब है
मुझे लगता है Microsoft का approach वास्तव में “काम करने” के सबसे क़रीब है, लेकिन फिर भी वह सचमुच भयानक है और मैं उसे दोबारा छूना नहीं चाहूँगा
10 साल बाद भी मेरी ideal architecture वही है: एक single VM पर monolithic codebase, जो local SQLite instances से बात करता हो
NVMe storage के आने से इस तरीके को काफ़ी मज़बूती मिली है
backups को block storage snapshots से संभालो, और transactional durability चाहिए तो WAL replication से करो
बेवकूफी की हद तक सरल
इससे business और customers पर ध्यान केंद्रित कर पाता हूँ
customers को इन चीज़ों से कोई मतलब नहीं होगा, और वे इसके लिए पैसे भी नहीं देंगे
सारा code और infra असल में शुद्ध negative factor है, इसलिए इसे जितना कम रखा जाए उतना बेहतर
जब लोग कहते हैं कि cloud on-premise से महँगा है, तो अक्सर वजह यही होती है
अगर आप VM को 24x7 चलाने वाले हैं, तो इससे बेहतर विकल्प मौजूद हैं
microservices की किताबों में भी कहा जाता है कि पहले monolith बनाओ
असली user feedback मिलने से पहले यह पता नहीं होता कि system को कैसे बाँटना चाहिए, और services को फिर से reorganize करने की तुलना में monolith को तोड़ना आसान होता है
यह भी हो सकता है कि monolith को कभी तोड़ने की ज़रूरत ही न पड़े
Stripe ने भी आखिरकार Rails monolith से कुछ हिस्से अलग किए, लेकिन monolith उम्मीद से कहीं ज़्यादा दूर तक जाता है
Django/Rails जैसे monolith से आसान debugging मिलना मुश्किल है
हाँ, infra आगे किस दिशा में जा सकता है, इसका थोड़ा अनुमान रखना मददगार होता है
हमारी कंपनी का शुरुआती version एक single VM पर Django Docker container में बना था, और deployment हाथ से
docker pull; docker stop; docker startकरके होता थायह setup हमारी उम्मीद से ज़्यादा लंबे समय तक चला
Docker dependency packaging की समस्याओं से बचने का अच्छा तरीका है
शुरुआती दौर में यह झंझट हो सकता है कि नया DB driver install करने पर server में ज़रूरी C header files हैं या नहीं, या Mac के मुकाबले config अलग है या नहीं
हम seed extension round के बाद reliability और scalability जैसी business requirements के कारण k8s पर गए, और k8s ने series B तक अच्छा साथ दिया
सब कुछ Dockerize कर देने की वजह से transition भी आसान रहा, लेकिन शुरुआती चरण में हमने complexity को आक्रामक तरीके से कम रखा
और framework जो सुविधाएँ देता है, उनका घटिया version दोबारा बनाने के बजाय framework का सही इस्तेमाल करना चाहिए
इस मामले में एक skilled व्यक्ति 10 unskilled लोगों से बेहतर नतीजे देता है
समय के साथ यह फ़र्क जमा होता जाता है
मुझे लगता है कि लोगों के monolith से ऊबने की असली वजहों में आधी वजह खराब और गलत ढंग से चलाए गए monolith हैं
data को उसके अपने service में store किया जाना चाहिए, और अगर relational, full-text search जैसी multi-paradigm approach चाहिए, तो कई services भी हो सकती हैं
user experience को भी अपने service का इस्तेमाल करना चाहिए
कम से कम बीच में एक और service तो होनी ही चाहिए, और आमतौर पर Django और Rails यहीं आते हैं
वैकल्पिक रूप से authentication, financial transactions जैसी अतिरिक्त services की भी ज़रूरत हो सकती है
मैंने एक project को लगभग 6 साल तक महीने के $10 VPS पर चलाया
lowendtalk से मिले lifetime discount की वजह से मैंने वास्तव में इससे भी कम चुकाया, और वह एक गेम server-केंद्रित VPS provider था
एक बार मैं अपनी configuration खराब कर बैठा और clean OS reinstall करना पड़ा, जिससे पूरा दिन downtime रहा, और दूसरी बार provider ने पहले से सूचना देकर IP address बदल दिया; इन दो घटनाओं को छोड़ दें तो reliability लगभग 99.999 जैसी थी
VPS technology सचमुच बहुत आगे बढ़ चुकी है और काफ़ी stable है
node disks RAID 1 में थीं, और node maintenance के समय VM को दूसरे machine पर आसानी से live migrate भी किया जा सकता था
snapshots भी लिए जा सकते थे
मेरे लिए cloud infra चुनने की वजह ज़्यादा reliability नहीं होगी, बल्कि IAM, secrets management, infrastructure as code जैसी collaboration और operations management सुविधाएँ, या HIPAA जैसे datacenter compliance कारण होंगे
यह स्थिति पर निर्भर करता है
व्यक्तिगत रूप से, मुझे cloud-आधारित समाधान पसंद हैं क्योंकि वे बहुत समय बचाते हैं
हालांकि, क्या इस्तेमाल करना है इसे बहुत चुनकर तय करना पड़ता है, और कुछ समाधान इतने जटिल होते हैं कि साफ़ तौर पर उल्टा नुकसान करते हैं
मैं एक छोटा bootstrapped startup चलाता हूँ
हमारे पास खुद को वेतन देने लायक भी पर्याप्त पैसा नहीं है, और मैं side consulting करके अपना गुज़ारा करता हूँ
बजट और समय दोनों सीमित होने की वजह से, क्या इस्तेमाल करना है इसे लेकर हमें बहुत सावधान रहना पड़ता है
इसलिए मुझे Google Cloud जैसी चीज़ें पसंद हैं
GCP का बिल महीने का कुछ सौ euro ही आता है, जो काफ़ी कम है
हम किसी और सस्ते provider पर जा सकते हैं, लेकिन उसके लिए समय लगाना सही ठहराना मुश्किल है, और पहले इस्तेमाल किए गए AWS की तुलना में मुझे Google का UI और tools भी पसंद हैं
Kubernetes की हमें कोई ज़रूरत नहीं है
सिर्फ़ एक खाली cluster चलाने की लागत ही हमारे मौजूदा मासिक GCP बिल से ज़्यादा होगी
और क्योंकि हम microservices वाले जाल में नहीं फँसे, इसकी ज़रूरत भी नहीं है
लेकिन मुझे Docker पसंद है
यह software deploy करना बेहद आसान बना देता है
हमारी website एक Google Storage bucket है, जिसे load balancer और Google CDN के ज़रिए serve किया जाता है
वही load balancer REST calls को हमारे monolith को चलाने वाली दो VM तक route करता है
ये VM managed DB, managed Elasticsearch, और managed Redis से बात करती हैं
DB और Elasticsearch महंगे हैं, लेकिन managed रूप में इस्तेमाल करने से बहुत समय और मेहनत बचती है
हमारे पास लगभग बस यही सब है, और यह सरल है और इतना महंगा भी नहीं
अगर हम सब कुछ Hetzner जैसी जगह पर ले जाएँ, तो लागत शायद लगभग 50% कम हो सकती है
यह करने लायक हो सकता है, लेकिन मेरे लिए यह अभी बहुत urgent नहीं है
उन managed services को खो देने पर मेरी ज़िंदगी और मुश्किल हो जाएगी
कुछ ग्राहकों को AWS पसंद आता है, इसलिए हो सकता है कि किसी दिन हमें फिर AWS पर लौटना पड़े, तो वह पहलू भी है