किसी काम के लिए Terraform, configuration management टूल और cloud native विकल्प में से आप कैसे चुनते हैं?

टूल को lifecycle से मिलाइए। cloud resources बनाने और खत्म करने के लिए state मॉडल वाला declarative provisioning टूल जैसे Terraform इस्तेमाल करें। मशीन के अंदर क्या होता है, उसके लिए configuration management, जब आप immutable images नहीं इस्तेमाल कर सकते। जब गहरी integration चाहिए हो या आपका पूरा संगठन एक ही provider पर हो, तब cloud native टूलिंग। पर बड़ा कारक आमतौर पर टीम की जानकारी और यह होता है कि काम करने का एक ही ज़ाहिर तरीका हो।

मैं इसे lifecycle से बांटता हूं। cloud resources का provisioning, यानी networks, clusters, डेटाबेस, state मॉडल वाला declarative काम है, और वहां Terraform मेरा डिफ़ॉल्ट है क्योंकि provider coverage चौड़ा है और plan step मुझे कुछ भी बदलने से पहले असली रिव्यू करने लायक चीज़ देता है। मशीन के अंदर की configuration अलग काम है, और सच कहूं तो मैं images बेक करके और instances को फेंकने लायक मानकर उसकी ज़रूरत ही खत्म करने की कोशिश करता हूं, तो configuration management सिमटकर image बनाने या उन पुरानी मशीनों तक रह जाता है जिन्हें मैं अभी बदल नहीं सकता। cloud native टूलिंग असली विकल्प है जब संगठन पूरी तरह एक provider पर हो और गहरी integration को कीमत देता हो, और Terraform के लिए multi cloud portability वाली दलील उतनी मज़बूत नहीं जितनी लोग कहते हैं, क्योंकि modules तो provider के हिसाब से ही लिखे जाते हैं। तकनीकी मेरिट से ज़्यादा अक्सर यह तय करता है कि टीम पहले से क्या जानती है और मौजूदा कोड किसमें लिखा है। एक ही resources के लिए दूसरा provisioning टूल लाना असली गलती है, क्योंकि अब drift किसी भी तरफ से आ सकता है और किसी को पता नहीं कि कौन सा टूल असली मालिक है।