स्टार्टअप में 4 साल तक इंफ्रास्ट्रक्चर चलाते हुए अच्छी लगीं/पछतावा हुईं (लगभग) सभी इंफ्रा फैसले

xguru · 2024-02-28T11:16:02+09:00

हर चुनाव को Endorse(समर्थन) और Regret(पछतावा) के रूप में चिह्नित किया गया है AWS का चयन AWS बनाम Google Cloud: AWS चुनने का समर्थन करता हूँ। AWS ग्राहकों पर केंद्रित है। Google Cloud में रोबोट और ऑटोमेशन पर निर्भरता ज़्यादा महसूस होती है। EKS: EKS के उपयोग का समर्थन करता हूँ। EKS, AWS सेवाओं के साथ गहरा इंटीग्रेशन देता है, और Kubernetes भी कई मामलों में काफी परिपक्व हो चुका है (जैसे externaldns का उपयोग कर Route53 के साथ इंटीग्रेशन)। EKS managed add-ons: EKS managed add-ons के उपयोग पर पछतावा है। इंस्टॉलेशन को कस्टमाइज़ करने की ज़रूरत थी, और helm chart पर स्विच करने के बाद बेहतर संचालन अनुभव मिला। डेटाबेस और कैशिंग RDS: RDS के उपयोग का समर्थन करता हूँ। डेटा इंफ्रास्ट्रक्चर का सबसे महत्वपूर्ण हिस्सा है, और RDS की लागत इसके लायक है। Redis ElastiCache: Redis के उपयोग का समर्थन करता हूँ। Redis कैश और सामान्य उपयोग दोनों के लिए बहुत प्रभावी है। ECR: quay.io से ECR पर माइग्रेट करने का समर्थन करता हूँ। ECR ज़्यादा स्थिर है और परमिशन इंटीग्रेशन भी गहरा है। नेटवर्क और सपोर्ट AWS VPN: AWS VPN के उपयोग का समर्थन करता हूँ। VPN को सेट करना और समझना बहुत आसान है। VPN access को मैनेज करने के लिए Okta का उपयोग कर रहे हैं और अनुभव बहुत अच्छा रहा। AWS Premium Support: इस पर पछतावा है। AWS Premium Support बहुत महंगा है, और अगर आपकी आंतरिक AWS समझ कमजोर नहीं है तो इसकी कीमत वसूल नहीं होती। Control Tower Account Factory for Terraform: AFT इंटीग्रेशन का समर्थन करता हूँ। यह अकाउंट creation को ऑटोमेट करता है और tagging को standardize करने में मदद करता है। प्रोसेस ऑटोमेशन Slack bot से postmortem automation: postmortem process automation का समर्थन करता हूँ। इससे लोगों को postmortem लिखने के लिए प्रेरित करने में मदद मिलती है। PagerDuty incident templates: incident के समय templates के उपयोग का समर्थन करता हूँ। Notion की flexibility की वजह से थोड़ी customization संभव होती है। PagerDuty tickets की नियमित समीक्षा: alert settings की नियमित समीक्षा का समर्थन करता हूँ। इससे कम महत्वपूर्ण alerts भी पूरी तरह अनदेखे नहीं होते। Datadog या PagerDuty में postmortem management: postmortem के लिए integrated management tool के उपयोग पर पछतावा है। दोनों में post process को customize करना मुश्किल है। Notion जैसे ताकतवर टूल का उपयोग करना बेहतर लगता है। अन्य मासिक cost-tracking मीटिंग: SaaS लागतों की समीक्षा के लिए मासिक मीटिंग का समर्थन करता हूँ। इससे पता चलता है कि खर्च उचित है या नहीं और ज़रूरी कार्रवाई की जा सकती है। AWS में आइटम्स को tag के आधार पर group किया जाता है और account के आधार पर अलग देखा जाता है। सिर्फ AWS तक सीमित न रहें, कंपनी के सभी बड़े खर्च स्रोतों को देखना चाहिए। FaaS का ज़्यादा उपयोग न करना: इस बात पर पछतावा है कि GPU workloads के लिए FaaS विकल्प नहीं था, इसलिए FaaS को पूरी तरह अपनाया नहीं जा सका। कई CPU workloads को FaaS से संभाला जा सकता था। Lambda का एक छिपा हुआ फायदा यह भी है कि उसकी लागत को बहुत सटीकता से ट्रैक करना आसान होता है। GitOps: GitOps के उपयोग का समर्थन करता हूँ। इंफ्रास्ट्रक्चर के कई हिस्सों में GitOps का उपयोग हो रहा है, और deployment status को समझने में मदद के लिए tooling development में निवेश किया गया। टीम efficiency को प्राथमिकता: टीम की efficiency बढ़ाने को प्राथमिकता देने का समर्थन करता हूँ। automation या documentation पर समय लगाने का कभी पछतावा नहीं हुआ। कई applications का एक database साझा करना: कई applications द्वारा एक ही database साझा करने पर पछतावा है। इससे कई समस्याएँ पैदा हुईं। SaaS अपनाना Identity platform देर से अपनाना: permissions assign करने के लिए Google Workspace का उपयोग करते थे, लेकिन Okta जैसे identity solution को और पहले अपनाना चाहिए था—इस पर पछतावा है। Okta का इंटीग्रेशन अच्छा है और यह security तथा compliance से जुड़ी समस्याएँ हल करता है। Notion: documentation के लिए Notion के उपयोग का समर्थन करता हूँ। Notion बेहतरीन चुनाव साबित हुआ और पहले इस्तेमाल किए गए विकल्पों (Wikis, Google Docs, Confluence आदि) की तुलना में कहीं आसान रहा। page organization के लिए database concept उपयोगी है। Slack: Slack के उपयोग का समर्थन करता हूँ। communication के लिए यह मुख्य टूल के रूप में प्रभावी है। डेवलपमेंट टूल्स और सेवाएँ JIRA से Linear पर जाना: JIRA की जगह Linear के उपयोग का समर्थन करता हूँ। JIRA बहुत जटिल और भारी लगता है। Terraform Cloud का उपयोग न करना: Terraform Cloud की लागत को सही नहीं ठहरा पाने के कारण उसका उपयोग न करने पर पछतावा नहीं है। Atlantis पर गए, और आवश्यक automation को CI/CD pipeline में जोड़ा। GitHub Actions for CI/CD: GitHub Actions के उपयोग का कुछ हद तक समर्थन (Endorse-ish) करता हूँ। marketplace के actions और syntax का उपयोग आसान है। कमी यह है कि self-hosted workflows के लिए support सीमित है। तकनीकी चयन Datadog: Datadog के उपयोग पर पछतावा है। इसकी लागत बहुत ज़्यादा है, और Kubernetes cluster तथा AI कंपनियों के लिए इसका cost model उपयुक्त नहीं है। PagerDuty: PagerDuty के उपयोग का समर्थन करता हूँ। प्रोडक्ट अच्छा है और इसकी कीमत उचित है। Schema migration by Diff: schema migration टूल्स के उपयोग का कुछ हद तक समर्थन करता हूँ। डेटा महत्वपूर्ण है और schema migration जोखिम भरा हो सकता है। Ubuntu for dev servers: dev servers के लिए Ubuntu के उपयोग का समर्थन करता हूँ। यह अच्छी तरह supported है और ज़रूरी ज़्यादातर packages इसमें मिल जाते हैं। AppSmith: internal engineers के लिए process automation में AppSmith के उपयोग का समर्थन करता हूँ। इसे self-host करते हैं और अनुभव पर्याप्त संतोषजनक है। शुरुआत में retool का उपयोग कर गहरे इंटीग्रेशन की कोशिश की, लेकिन उस समय केवल कुछ integrations के लिए उसकी कीमत उचित नहीं लगती थी। helm: Helm v3 के उपयोग का समर्थन करता हूँ। CRD deployment और developer training में कुछ समस्याएँ हैं, लेकिन Kubernetes objects को package और deploy करने के लिए यह पर्याप्त रूप से अच्छा है। helm charts in ECR (oci): OCI repository में helm charts स्टोर करने का समर्थन करता हूँ। S3 और plugins वाली पुरानी विधि की तुलना में इसमें समस्याएँ नहीं रहीं। bazel: bazel को लेकर निश्चित नहीं हूँ। Go services deploy करने के लिए यह कुछ ज़्यादा भारी लगता है, और GitHub Actions अधिक engineers के लिए उपयोग में आसान है। OpenTelemetry का उपयोग न करना: सीधे DataDog API का उपयोग कर metrics भेजने पर पछतावा है। शुरुआत से ही OpenTelemetry अपनाने की सिफारिश करता हूँ। dependencyabot की जगह renovatebot चुनना: dependencies को up-to-date रखने के बारे में और पहले सोचना चाहिए था—इस पर पछतावा है। Renovatebot काफ़ी customizable है, लेकिन इसकी setup और debugging जटिल है। Kubernetes: Kubernetes के उपयोग का समर्थन करता हूँ। लंबे समय तक चलने वाली services को host करने का कोई तरीका चाहिए था, और Kubernetes लोकप्रिय भी है और अच्छी तरह काम करता है। अपना IP खरीदना: बाहरी partners के साथ काम करते समय अपना IP block खरीदने का समर्थन करता हूँ। इससे external partners को whitelist के लिए बड़ा CIDR block देना आसान होता है। k8s GitOps के लिए Flux चुनना: Kubernetes के लिए GitOps टूल के रूप में Flux चुनने पर पछतावा नहीं है। deployment status समझने में मदद करने वाले tools बनाने की ज़रूरत होती है। Node management के लिए Karpenter: EKS उपयोग करते समय Karpenter के उपयोग का समर्थन करता हूँ। यह दूसरे autoscalers की तुलना में अधिक reliable और cost-efficient है। SealedSecrets का उपयोग: SealedSecrets के उपयोग पर पछतावा है। यह developers के लिए जटिल है और AWS में मौजूद password rotation automation का फायदा खो जाता है। ExternalSecrets का उपयोग: AWS -> Kubernetes password sync के लिए ExternalSecrets के उपयोग का समर्थन करता हूँ। यह developers के लिए समझने में आसान है और terraform का उपयोग कर AWS के भीतर passwords को आसानी से generate/update किया जा सकता है। ExternalDNS का उपयोग: ExternalDNS के उपयोग का समर्थन करता हूँ। यह Kubernetes -> Route53 DNS entries को sync करता है और पिछले 4 साल में इसमें लगभग कोई समस्या नहीं आई। cert-manager का उपयोग: SSL certificate management के लिए cert-manager के उपयोग का समर्थन करता हूँ। Let's Encrypt certificates बनाने के लिए यह बहुत intuitive है और इसमें कोई समस्या नहीं रही। Bottlerocket for EKS: Bottlerocket के साथ EKS cluster चलाने पर पछतावा है। networking CSI समस्याएँ अक्सर होती थीं और debugging मुश्किल थी। Terraform बनाम CloudFormation: Terraform के उपयोग का समर्थन करता हूँ। इससे अन्य SaaS providers तक विस्तार करना आसान है, और इसका syntax CloudFormation की तुलना में पढ़ने में आसान है। Code-based IaC solutions का उपयोग न करना: इस पर पछतावा नहीं है। Terraform और CloudFormation data files का उपयोग करते हैं, जबकि Pulumi या CDK code के रूप में infrastructure को describe करते हैं। Terraform के HCL की सीमित प्रकृति जटिलता कम करने में मदद करती है। Network mesh का उपयोग न करना: इस पर पछतावा नहीं है। Network mesh आकर्षक है, लेकिन कंपनियाँ इसकी जटिलता को कम आँकती हैं। इंफ्रास्ट्रक्चर के लिए सामान्य सलाह है: "कम ही बेहतर है"। EKS ingress के लिए Nginx load balancer: इस पर पछतावा नहीं है; Nginx के उपयोग का समर्थन करता हूँ। यह पुरानी लेकिन स्थिर और परखी हुई तकनीक है। company scripts के लिए homebrew: कंपनी scripts distribute करने के लिए homebrew के उपयोग का समर्थन करता हूँ। Linux और Mac, दोनों users तक scripts और binaries पहुँचाने के लिए यह पर्याप्त रूप से अच्छा है। services के लिए Go: services के लिए Go भाषा के उपयोग का समर्थन करता हूँ। नए engineers के लिए इसे सीखना आसान है और कुल मिलाकर यह अच्छा चुनाव है।

(cep.dev)

87 पॉइंट द्वारा xguru 2024-02-28 | 4 टिप्पणियां | WhatsApp पर शेयर करें

हर चुनाव को Endorse(समर्थन) और Regret(पछतावा) के रूप में चिह्नित किया गया है

AWS का चयन

AWS बनाम Google Cloud: AWS चुनने का समर्थन करता हूँ। AWS ग्राहकों पर केंद्रित है। Google Cloud में रोबोट और ऑटोमेशन पर निर्भरता ज़्यादा महसूस होती है।
EKS: EKS के उपयोग का समर्थन करता हूँ। EKS, AWS सेवाओं के साथ गहरा इंटीग्रेशन देता है, और Kubernetes भी कई मामलों में काफी परिपक्व हो चुका है (जैसे externaldns का उपयोग कर Route53 के साथ इंटीग्रेशन)।
EKS managed add-ons: EKS managed add-ons के उपयोग पर पछतावा है। इंस्टॉलेशन को कस्टमाइज़ करने की ज़रूरत थी, और helm chart पर स्विच करने के बाद बेहतर संचालन अनुभव मिला।

डेटाबेस और कैशिंग

RDS: RDS के उपयोग का समर्थन करता हूँ। डेटा इंफ्रास्ट्रक्चर का सबसे महत्वपूर्ण हिस्सा है, और RDS की लागत इसके लायक है।
Redis ElastiCache: Redis के उपयोग का समर्थन करता हूँ। Redis कैश और सामान्य उपयोग दोनों के लिए बहुत प्रभावी है।
ECR: quay.io से ECR पर माइग्रेट करने का समर्थन करता हूँ। ECR ज़्यादा स्थिर है और परमिशन इंटीग्रेशन भी गहरा है।

नेटवर्क और सपोर्ट

AWS VPN: AWS VPN के उपयोग का समर्थन करता हूँ। VPN को सेट करना और समझना बहुत आसान है। VPN access को मैनेज करने के लिए Okta का उपयोग कर रहे हैं और अनुभव बहुत अच्छा रहा।
AWS Premium Support: इस पर पछतावा है। AWS Premium Support बहुत महंगा है, और अगर आपकी आंतरिक AWS समझ कमजोर नहीं है तो इसकी कीमत वसूल नहीं होती।
Control Tower Account Factory for Terraform: AFT इंटीग्रेशन का समर्थन करता हूँ। यह अकाउंट creation को ऑटोमेट करता है और tagging को standardize करने में मदद करता है।

प्रोसेस ऑटोमेशन

Slack bot से postmortem automation: postmortem process automation का समर्थन करता हूँ। इससे लोगों को postmortem लिखने के लिए प्रेरित करने में मदद मिलती है।
PagerDuty incident templates: incident के समय templates के उपयोग का समर्थन करता हूँ। Notion की flexibility की वजह से थोड़ी customization संभव होती है।
PagerDuty tickets की नियमित समीक्षा: alert settings की नियमित समीक्षा का समर्थन करता हूँ। इससे कम महत्वपूर्ण alerts भी पूरी तरह अनदेखे नहीं होते।
Datadog या PagerDuty में postmortem management: postmortem के लिए integrated management tool के उपयोग पर पछतावा है। दोनों में post process को customize करना मुश्किल है। Notion जैसे ताकतवर टूल का उपयोग करना बेहतर लगता है।

अन्य

मासिक cost-tracking मीटिंग: SaaS लागतों की समीक्षा के लिए मासिक मीटिंग का समर्थन करता हूँ। इससे पता चलता है कि खर्च उचित है या नहीं और ज़रूरी कार्रवाई की जा सकती है। AWS में आइटम्स को tag के आधार पर group किया जाता है और account के आधार पर अलग देखा जाता है। सिर्फ AWS तक सीमित न रहें, कंपनी के सभी बड़े खर्च स्रोतों को देखना चाहिए।
FaaS का ज़्यादा उपयोग न करना: इस बात पर पछतावा है कि GPU workloads के लिए FaaS विकल्प नहीं था, इसलिए FaaS को पूरी तरह अपनाया नहीं जा सका। कई CPU workloads को FaaS से संभाला जा सकता था। Lambda का एक छिपा हुआ फायदा यह भी है कि उसकी लागत को बहुत सटीकता से ट्रैक करना आसान होता है।
GitOps: GitOps के उपयोग का समर्थन करता हूँ। इंफ्रास्ट्रक्चर के कई हिस्सों में GitOps का उपयोग हो रहा है, और deployment status को समझने में मदद के लिए tooling development में निवेश किया गया।
टीम efficiency को प्राथमिकता: टीम की efficiency बढ़ाने को प्राथमिकता देने का समर्थन करता हूँ। automation या documentation पर समय लगाने का कभी पछतावा नहीं हुआ।
कई applications का एक database साझा करना: कई applications द्वारा एक ही database साझा करने पर पछतावा है। इससे कई समस्याएँ पैदा हुईं।

SaaS अपनाना

Identity platform देर से अपनाना: permissions assign करने के लिए Google Workspace का उपयोग करते थे, लेकिन Okta जैसे identity solution को और पहले अपनाना चाहिए था—इस पर पछतावा है। Okta का इंटीग्रेशन अच्छा है और यह security तथा compliance से जुड़ी समस्याएँ हल करता है।
Notion: documentation के लिए Notion के उपयोग का समर्थन करता हूँ। Notion बेहतरीन चुनाव साबित हुआ और पहले इस्तेमाल किए गए विकल्पों (Wikis, Google Docs, Confluence आदि) की तुलना में कहीं आसान रहा। page organization के लिए database concept उपयोगी है।
Slack: Slack के उपयोग का समर्थन करता हूँ। communication के लिए यह मुख्य टूल के रूप में प्रभावी है।

डेवलपमेंट टूल्स और सेवाएँ

JIRA से Linear पर जाना: JIRA की जगह Linear के उपयोग का समर्थन करता हूँ। JIRA बहुत जटिल और भारी लगता है।
Terraform Cloud का उपयोग न करना: Terraform Cloud की लागत को सही नहीं ठहरा पाने के कारण उसका उपयोग न करने पर पछतावा नहीं है। Atlantis पर गए, और आवश्यक automation को CI/CD pipeline में जोड़ा।
GitHub Actions for CI/CD: GitHub Actions के उपयोग का कुछ हद तक समर्थन (Endorse-ish) करता हूँ। marketplace के actions और syntax का उपयोग आसान है। कमी यह है कि self-hosted workflows के लिए support सीमित है।

तकनीकी चयन

Datadog: Datadog के उपयोग पर पछतावा है। इसकी लागत बहुत ज़्यादा है, और Kubernetes cluster तथा AI कंपनियों के लिए इसका cost model उपयुक्त नहीं है।
PagerDuty: PagerDuty के उपयोग का समर्थन करता हूँ। प्रोडक्ट अच्छा है और इसकी कीमत उचित है।
Schema migration by Diff: schema migration टूल्स के उपयोग का कुछ हद तक समर्थन करता हूँ। डेटा महत्वपूर्ण है और schema migration जोखिम भरा हो सकता है।
Ubuntu for dev servers: dev servers के लिए Ubuntu के उपयोग का समर्थन करता हूँ। यह अच्छी तरह supported है और ज़रूरी ज़्यादातर packages इसमें मिल जाते हैं।
AppSmith: internal engineers के लिए process automation में AppSmith के उपयोग का समर्थन करता हूँ। इसे self-host करते हैं और अनुभव पर्याप्त संतोषजनक है। शुरुआत में retool का उपयोग कर गहरे इंटीग्रेशन की कोशिश की, लेकिन उस समय केवल कुछ integrations के लिए उसकी कीमत उचित नहीं लगती थी।
helm: Helm v3 के उपयोग का समर्थन करता हूँ। CRD deployment और developer training में कुछ समस्याएँ हैं, लेकिन Kubernetes objects को package और deploy करने के लिए यह पर्याप्त रूप से अच्छा है।
helm charts in ECR (oci): OCI repository में helm charts स्टोर करने का समर्थन करता हूँ। S3 और plugins वाली पुरानी विधि की तुलना में इसमें समस्याएँ नहीं रहीं।
bazel: bazel को लेकर निश्चित नहीं हूँ। Go services deploy करने के लिए यह कुछ ज़्यादा भारी लगता है, और GitHub Actions अधिक engineers के लिए उपयोग में आसान है।
OpenTelemetry का उपयोग न करना: सीधे DataDog API का उपयोग कर metrics भेजने पर पछतावा है। शुरुआत से ही OpenTelemetry अपनाने की सिफारिश करता हूँ।
dependencyabot की जगह renovatebot चुनना: dependencies को up-to-date रखने के बारे में और पहले सोचना चाहिए था—इस पर पछतावा है। Renovatebot काफ़ी customizable है, लेकिन इसकी setup और debugging जटिल है।
Kubernetes: Kubernetes के उपयोग का समर्थन करता हूँ। लंबे समय तक चलने वाली services को host करने का कोई तरीका चाहिए था, और Kubernetes लोकप्रिय भी है और अच्छी तरह काम करता है।
अपना IP खरीदना: बाहरी partners के साथ काम करते समय अपना IP block खरीदने का समर्थन करता हूँ। इससे external partners को whitelist के लिए बड़ा CIDR block देना आसान होता है।
k8s GitOps के लिए Flux चुनना: Kubernetes के लिए GitOps टूल के रूप में Flux चुनने पर पछतावा नहीं है। deployment status समझने में मदद करने वाले tools बनाने की ज़रूरत होती है।
Node management के लिए Karpenter: EKS उपयोग करते समय Karpenter के उपयोग का समर्थन करता हूँ। यह दूसरे autoscalers की तुलना में अधिक reliable और cost-efficient है।
SealedSecrets का उपयोग: SealedSecrets के उपयोग पर पछतावा है। यह developers के लिए जटिल है और AWS में मौजूद password rotation automation का फायदा खो जाता है।
ExternalSecrets का उपयोग: AWS -> Kubernetes password sync के लिए ExternalSecrets के उपयोग का समर्थन करता हूँ। यह developers के लिए समझने में आसान है और terraform का उपयोग कर AWS के भीतर passwords को आसानी से generate/update किया जा सकता है।
ExternalDNS का उपयोग: ExternalDNS के उपयोग का समर्थन करता हूँ। यह Kubernetes -> Route53 DNS entries को sync करता है और पिछले 4 साल में इसमें लगभग कोई समस्या नहीं आई।
cert-manager का उपयोग: SSL certificate management के लिए cert-manager के उपयोग का समर्थन करता हूँ। Let's Encrypt certificates बनाने के लिए यह बहुत intuitive है और इसमें कोई समस्या नहीं रही।
Bottlerocket for EKS: Bottlerocket के साथ EKS cluster चलाने पर पछतावा है। networking CSI समस्याएँ अक्सर होती थीं और debugging मुश्किल थी।
Terraform बनाम CloudFormation: Terraform के उपयोग का समर्थन करता हूँ। इससे अन्य SaaS providers तक विस्तार करना आसान है, और इसका syntax CloudFormation की तुलना में पढ़ने में आसान है।
Code-based IaC solutions का उपयोग न करना: इस पर पछतावा नहीं है। Terraform और CloudFormation data files का उपयोग करते हैं, जबकि Pulumi या CDK code के रूप में infrastructure को describe करते हैं। Terraform के HCL की सीमित प्रकृति जटिलता कम करने में मदद करती है।
Network mesh का उपयोग न करना: इस पर पछतावा नहीं है। Network mesh आकर्षक है, लेकिन कंपनियाँ इसकी जटिलता को कम आँकती हैं। इंफ्रास्ट्रक्चर के लिए सामान्य सलाह है: "कम ही बेहतर है"।
EKS ingress के लिए Nginx load balancer: इस पर पछतावा नहीं है; Nginx के उपयोग का समर्थन करता हूँ। यह पुरानी लेकिन स्थिर और परखी हुई तकनीक है।
company scripts के लिए homebrew: कंपनी scripts distribute करने के लिए homebrew के उपयोग का समर्थन करता हूँ। Linux और Mac, दोनों users तक scripts और binaries पहुँचाने के लिए यह पर्याप्त रूप से अच्छा है।
services के लिए Go: services के लिए Go भाषा के उपयोग का समर्थन करता हूँ। नए engineers के लिए इसे सीखना आसान है और कुल मिलाकर यह अच्छा चुनाव है।

4 टिप्पणियां

xguru 2024-03-03

इससे संबंधित पढ़ने लायक पुराने GeekNews लेख

जो लोग one-person developer company चला रहे हैं, आप कौन-सा tech stack इस्तेमाल करते हैं?
one-person tech startup का architecture stack
one-person SaaS Healthchecks.io का tech stack
one-person SaaS डेवलपर के लिए टूल्स की सिफारिश
one-person महिला hardware company का tech stack
startup को सालाना 6$ में चलाना
Stack on a Budget - free tier आधारित development
न्यूनतम मेहनत से software startup चलाना
महीने के 5 लाख वॉन ($400) में 80TB ट्रैफ़िक और 5M pageviews को संभालने का तरीका

nicewook 2024-02-28

मुख्य लेख भी और टिप्पणियाँ भी, दोनों ही बहुत मूल्यवान हैं।

mhj5730 2024-02-28

वाह....यह तो इतनी व्यावहारिक जानकारी है जो कहीं और मिलना मुश्किल है

xguru 2024-02-28

Hacker News टिप्पणियाँ

RDS इस्तेमाल करने की अतिरिक्त लागत उसकी कीमत वसूल कर देती है
- RDS इस्तेमाल करने की अतिरिक्त लागत हर बार इतनी अवास्तविक रूप से महंगी लगती है कि हंसी आती है, जब भी इसे co-located SQL server cluster के विकल्प के रूप में सोचा जाता है। यह उस राशि से कहीं ज्यादा है जिसे मैं चुकाने को तैयार हूं, और इससे colocation rack, AWS Direct Connects, servers, SAN, SQL server licenses, maintenance contracts, और एक full-time in-house DBA की salary तक कवर की जा सकती है।
- 12 महीनों की कुल लागत: 547,441.85 USD
- जब markup इतना बड़ा हो जाए कि उससे एक या उससे ज्यादा full-time कर्मचारियों की salary दी जा सके, तो RDS को बस और scale करने के बजाय उस पैसे से लोगों को hire करने पर विचार करना चाहिए। RDS के लिए आप सच में बहुत ज्यादा भुगतान कर रहे होते हैं, और startup के शुरुआती दौर में लिए गए फैसलों का फिर से मूल्यांकन होना चाहिए।
यह शायद अलोकप्रिय राय हो कि Google Cloud, AWS से बेहतर है, लेकिन Google Cloud Run के साथ cloud में Docker containers चलाना सपना जैसा लगता है। Service naming सरल है, AWS की जटिल services की तुलना में महत्वपूर्ण services कम हैं, और UI ज्यादा intuitive है। कमी यह है कि community छोटी होने से tutorials कम मिलते हैं, अनुभवी लोगों को ढूंढना कठिन है, और third-party tools भी कम हैं। इसे आज़माने की सिफारिश करूंगा।
EC2 + ASG का उपयोग बहुत आनंददायक है। अवधारणा के स्तर पर यह सरल है: image को ASG में launch करो, और auto scaling policies सेट करो। चिंता करने लायक बहुत कम चीजें हैं। दूसरी ओर, k8s इस्तेमाल करना हमेशा बड़ा काम बन जाता है। k8s को manage करने के लिए पूरी टीम बना ली जाती है। k8s के दर्जनों concepts अपनाए जाते हैं, या "platform engineering" पर person-years खर्च करके k8s concepts को छिपाया जाता है। k8s को "सही तरीके से" इस्तेमाल करने के लिए guidelines, SDKs, और तरह-तरह के validators जारी किए जाते हैं। फिर भी operators लागू करने के लिए YAML और code की दसियों हजार lines लिखी जाती हैं। कभी-कभी लगता है कि k8s जरूरत से ज्यादा intrusive है।
SaaS products पर राय
- JIRA से Linear पर जाने की बात समझ नहीं आती। Linear ठीक है, लेकिन अक्सर ऐसी चीजें मिलती हैं जो यह नहीं कर सकता, या कम से कम मुझे उनका तरीका नहीं पता।
- Terraform Cloud के उपयोग की सामान्य तौर पर सिफारिश करूंगा। घर में अपना system खुद बढ़ाते जाना शुरुआती कुछ सालों तक ठीक हो सकता है, लेकिन लंबी अवधि में इसकी कीमत चुकानी पड़ सकती है।
- CI/CD के लिए GitHub Actions के पक्ष में कुछ हद तक हूं। इसके बजाय GitLab इस्तेमाल करने का सुझाव दूंगा।
- Datadog के बारे में मैं सख्ती से असहमत हूं। यह बाजार का सबसे अच्छा monitoring/observability tool है। इसकी लागत सबसे आम शिकायत है, लेकिन अधिकतर मामलों में Datadog की configuration गलत होने से ही लागत विस्फोटक रूप से बढ़ती है।
- Pagerduty के बारे में समर्थन नहीं है। Pagerduty, Opsgenie से लगभग 10 गुना महंगा है और बेहतर features भी नहीं देता। Pagerduty के साथ contract renewal के समय जब sales rep से पूछा गया कि Opsgenie में कौन-सी कमी है, तो उनका जवाब था कि वे खुद को market में premium brand के रूप में position करना चाहते हैं। इसलिए incident reporting के लिए सामान्य brand इस्तेमाल करने में मैं संतुष्ट हूं।
मैं कल्पना कर सकता हूं कि 90s/00s के developers यह सूची पढ़कर इसकी complexity और terminology से भ्रमित हो जाएं।
पढ़ने में रोचक है, लेकिन यकीन नहीं कि लेखक को इतना पछतावा है कि इस पर ब्लॉग लिखा जाए।
कभी-कभी एक विशाल $100k server पर लौटकर सब कुछ एक ही box में चलाने का प्रयोग करने का मन होता है।
मैंने Kubernetes / EKS की बुनियादी बातें सीखने में सफलता पाई, लेकिन अब ECS पर जाने पर विचार कर रहा हूं। Kubernetes हमारी जरूरतों की तुलना में बहुत ज्यादा जटिल है। इसे CloudFormation जैसी चीजों से नियंत्रित करना कठिन है। Add-ons से provision किए गए load balancers को Kubernetes के बाहर से reference करना मुश्किल है। EKS Fargate में Cloudwatch logging documentation का पालन करने पर भी काम करती नहीं लगती। EKS EC2 की तरह CPU/memory metrics काम नहीं करते, और लगता है कि ADOT की जरूरत पड़ती है। ECS में 1/10 समय में environment दोबारा बनाया और सब कुछ सही चला।
इस लेख को जिस तरीके से लिखा गया है और इसमें जो बातें हैं, वे मुझे पसंद आईं। मैं कुछ फैसलों और सिफारिशों से सहमत नहीं हूं, लेकिन तब भी उनके पीछे के कारण पढ़ना बहुत अच्छा है। काश ऐसे और लेख प्रकाशित हों और उन्हें आपस में तुलना करने का कोई तरीका हो। इससे मुझे भी कुछ ऐसा ही लिखने की प्रेरणा मिली।
सबके इस्तेमाल वाला kitchen sink database एक आम समस्या है, लेकिन यह बार-बार दोहराई जाती है। जैसे-जैसे आप बढ़ते हैं, यह बड़ी technical debt और performance bottleneck बन जाती है। RDS जैसे managed DB का उपयोग करने से मुख्य apps के हिसाब से अलग-अलग DB clusters चलाना आसान हो जाता है।