Cloud native environment के लिए software design करें

जरूरी व्यवहार तय करें

Cloud native practices public, private या hybrid environments में दोहराने योग्य development और संचालन में मदद करती हैं। CNCF ऐसी systems पर जोर देता है जो बदलते समय भी manage और observe की जा सकें तथा विफलताओं से उबर सकें। Containers और orchestration इसमें मदद कर सकते हैं। वे अकेले ये सभी गुण सिद्ध नहीं करते।

काल्पनिक report service से शुरू करें। AI tool endpoint, worker और container image बनाता है। Demo सही PDF बनाता है। Production से पहले team को दूसरा प्रश्न हल करना है: job के दौरान platform worker बदल दे तो क्या होता है?

यह infrastructure के साथ application design का प्रश्न भी है। Restart process बहाल कर सकता है, जबकि उसका अधूरा काम खो जाए।

Process और durable state अलग रखें

Prototype queued jobs और तैयार reports container disk पर रखता है। Container बदलने से दोनों हट सकते हैं। अधिक workers जोड़ने पर भी अलग उत्तर मिल सकते हैं, इस आधार पर कि request किस worker को मिलती है।

सुधरा design durable job store और स्वीकृत object store इस्तेमाल करता है। Request job identity दर्ज करती है। Worker job लेता है, परिणाम बनाता है और उसकी जगह दर्ज करता है। उपयोगकर्ता report download करे, तब भी access checks लागू होती हैं।

Secrets image से बाहर रखें। उन्हें स्वीकृत secret system से दें। दर्ज करें कि कौन-से configuration changes पर नया release या process restart चाहिए।

Workers जोड़ने से पहले retries design करें

मान लें worker PDF save करता है और job acknowledge करने से पहले रुक जाता है। Queue job दोबारा देती है। दूसरे प्रयास से customer पर दूसरा charge नहीं लगना चाहिए या विरोधी completion messages नहीं जाने चाहिए।

जहाँ उचित हो idempotent operation इस्तेमाल करें। वही logical request दोहराने पर इच्छित प्रभाव बना रहना चाहिए। स्थिर request identity तय करें, परिणाम durable रूप में दर्ज करें और हर failure point पर होने वाला व्यवहार जाँचें। AWS अपनी सुरक्षित retries की गाइड में यह तरीका बताता है।

Retries को भी सीमाएँ चाहिए। Timeout, retry limit और एक साथ बार-बार requests आने से बचाने वाला delay इस्तेमाल करें। Failed work को अनंत retries देने के बजाय निरीक्षण के लिए बनाए रखें।

Desired state का review संभव बनाएँ

Declarative configuration इच्छित deployment बताता है। Controller उस state को बनाए रखने का प्रयास करता है। उदाहरण के लिए, Kubernetes Deployment application replicas और नियंत्रित updates सँभालता है। Application को replacement सही सँभालना फिर भी जरूरी है।

Infrastructure और application configuration का version रखें। सामान्य delivery प्रक्रिया से बदलावों का review करें। वास्तविक job completion, queue age, failures और dependency limits देखें। चलता हुआ process भी report बनाने में असमर्थ हो सकता है।

ऐसा platform चुनें जिसे team चला सके

Cloud native का अर्थ यह नहीं कि हर application microservices बने। Managed runtime पर modular application अपनी requirements पूरी कर सकता है। अधिक services से interfaces, deployment decisions और संचालन का काम बढ़ता है।

Development agent को वास्तविक platform contract दें: supported runtime, identity method, data services, deployment rules और जरूरी प्रमाण। सफल requests के साथ interruption और replacement का व्यवहार जाँचें। आगे availability और failure boundaries पढ़ें।