स्वायत्तता एक architecture है, वादा नहीं

कोई भी vendor यह पैराग्राफ़ लिख सकता है कि वह आपके data की कितनी इज़्ज़त करता है। इसमें ख़र्च कुछ नहीं होता और बचाव भी कुछ नहीं होता। इस दावे का एक ही ढंग का रूप है — ढाँचे वाला: प्रोडक्ट ऐसा बनाओ कि vendor के पास आपके रिकॉर्ड रखने की तकनीकी क्षमता ही न हो। नीचे लिखा हर फ़ैसला इसी शर्त से निकला है।

तीन बातें जो हमने शुरू में ही तय कर लीं

एक ही प्रोडक्ट लाइन, fork कभी नहीं। जिस दिन आपने हर ग्राहक की deployment को अलग-अलग बहने दिया, उस दिन आप प्रोडक्ट नहीं, प्रोडक्ट का भेस पहने consultancy हैं — और जिस ग्राहक का environment सबसे पुराना है, उसे चुपचाप fixes मिलना बंद हो जाते हैं। हर account पर वही tested release चलती है। फ़र्क़ सिर्फ़ configuration का होता है — region, domain, integrations, feature flags — code का कभी नहीं।

Managed का मतलब वाकई managed होना चाहिए। किसी को एक repository थमा देना और उसे सम्प्रभुता कह देना, असल में operations का बिल ग्राहक पर डाल देना है। Pipeline हमारे पास रहती है: releases, schema migrations, secret rotation, monitoring, upgrades। आपके engineers को business logic लिखनी चाहिए, platform नहीं चलाना चाहिए।

बाहर निकलने का रास्ता असली हो, तभी कोई मतलब है। ऐसा migration path जो सिर्फ़ तब तक चलता है जब तक रिश्ता ठीक है, migration path नहीं है। अगर हम कल गायब हो जाएं, तो infrastructure चलता रहेगा, database writes लेता रहेगा और आपका domain resolve होता रहेगा — क्योंकि इनमें से कुछ भी कभी हमारा नहीं था।

प्रोडक्ट, पास से

मालिकाना हक़ नींव है। यह वह हिस्सा है जिसे आपकी टीम हर सुबह खोलती है — और यह हर cloud account में बिल्कुल एक जैसा रहता है।

एक जगह जहाँ पूरा context रहता है

Pipelines, रिकॉर्ड, content और ownership एक ही view में, बजाय एक spreadsheet के जिसे पाँच browser tabs से मिलाना पड़े। लीडरशिप को status पूछना नहीं पड़ता। काम करने वालों को बताना नहीं पड़ता कि अगला ध्यान कहाँ चाहिए।

ढाँचा जो हक़ीक़त से टकराकर बच जाता है

पहले दिन का आपका data model एक अंदाज़ा होता है। यहाँ tables, filters और relationships इसीलिए बने हैं कि अंदाज़ा जैसे-जैसे सुधरे, आप उन्हें बदलते रहें — और वही underlying रिकॉर्ड app के हर CRM view, task और workflow को feed करते हैं, इसलिए आकार एक जगह बदलने पर हर जगह बदल जाता है।

आंकड़े, आप जहाँ भी हों

दो meetings के बीच फ़ोन पर असली रिपोर्टिंग, वही definitions से बनी जिन पर finance और operations डेस्कटॉप पर पहले से सहमत हैं। Live आंकड़े, किसी मंगलवार को export की गई spreadsheet नहीं।

जब rows से ज़्यादा stages मायने रखते हैं

जब सवाल यह हो कि चीज़ किस stage पर है, तो उन्हीं रिकॉर्ड को kanban view में पलट दें। Deals, tasks और content एक ही pipeline पर, जिससे यह बहस ख़त्म हो जाती है कि आख़िरी export किसका था।

जो आप पहले से चला रहे हैं, उससे जुड़ा हुआ

Billing, CRM, productivity tools, AI services। Data दोनों तरफ़ अपने आप आता-जाता है, जिससे copy-paste की परत हटती है और दो systems के बीच की वह धीमी असहमति भी, जिनमें से हर एक ख़ुद को असली स्रोत मानता है।

यह कैसे बना है

Bring-your-own-cloud प्रोडक्ट में दिलचस्प engineering features नहीं है। दिलचस्प यह है कि वही release हर हफ़्ते दर्जनों ऐसे accounts में पहुँचाई जाए जो आपके नहीं हैं, और कोई भी टूटे नहीं।

दो backend, एक platform

Relational और analytical काम के लिए postgraph — Django और PostgreSQL पर। Live data और eventing के लिए nodegraph — Node और RethinkDB पर। दोनों एक ही contract निभाते हैं, इसलिए ग्राहक कोई एक चला सकता है या दोनों, और front end को फ़र्क़ पता ही नहीं चलता।
Infrastructure एक artifact की तरह

पूरा footprint — networking, database, containers, load balancing, CDN, certificates, DNS, secrets, config — Terraform है। एक command से खड़ा होता है और एक command से हट जाता है, और यही बात बाहर निकलने के रास्ते को भरोसेमंद बनाती है।
तय क्रम में deploy

पहले infrastructure, फिर दोनों backend साथ-साथ, और कोई नई image live होने से पहले migrations एक gated one-shot task की तरह। Migration fail हुई तो नई image चालू service तक पहुँचती ही नहीं।
सबूत, भरोसा दिलाने वाली बातें नहीं

“Production में क्या चल रहा है” का जवाब एक pinned version, एक image digest और एक deployment history है, जिसे आपकी platform टीम auditor के हाथ में दे सकती है। हर environment release train पर उस रफ़्तार से चलता है जो आप चुनते हैं।

यह आगे कहाँ जा रहा है

हम अगले कुछ सालों को लेकर एक साफ़ शर्त पर काम कर रहे हैं।

AI ने मालिकाना हक़ के सवाल को किताबी से तात्कालिक बना दिया। काम का होने के लिए model को असली रिकॉर्ड पढ़ने पड़ते हैं — deals, दस्तावेज़, इतिहास। हर टीम को अब यह पता चलने वाला है कि मौजूदा architecture पर काम के AI की क़ीमत यह है कि आप अपनी कंपनी का पूरा कामकाजी इतिहास किसी तीसरे पक्ष को भेज दें। Model को वहीं चलाना, जहाँ data पहले से है — यही एक रूप है जो गंभीर security review से बचकर निकलता है।

इसलिए roadmap का लक्ष्य यह है कि यह काम करने की सबसे अच्छी जगह आपका ही account बने: model का चुनाव आपके हाथ में, retrieval जो आपकी सीमा से बाहर न जाए, और agents जो आपके रिकॉर्ड पर उसी permissions और audit trail के साथ काम करें जिसके साथ एक इंसानी user करता है। आपका data, आपका compute, आपकी policy।

बड़ा लक्ष्य इससे भी सादा है और ज़्यादा ज़रूरी। हम चाहते हैं कि ऐसा सीधा-सादा, ठीक से चलाया गया software हो जिसे एक regulated टीम छह महीने के कानूनी चक्कर के बिना अपना ले — और हम वह वजह बनें जिससे कोई founder data residency को deal रोकने वाली चीज़ समझना बंद कर दे।

अगर आपको पूरी तरह संचालित platform चाहिए जो आपके data पर कब्ज़ा कभी न ले, तो बात करें।

Platform खोलें बात करें