Terraform თუ Pulumi: სწრაფ preview-ს ლიცენზია და გუნდის ენა ცვლის

თუ გუნდი უკვე HCL-ით წერს ინფრასტრუქტურის კონფიგურაციას და Terraform-ის მოდულებს იყენებს, Terraform პრაქტიკული არჩევანია. თუ ინფრასტრუქტურის კოდს დეველოპერები ნაცნობ პროგრამირების ენაზე შეინარჩუნებენ, Pulumi უფრო შესაფერისი შეიძლება იყოს. გამოქვეყნებულ ერთ შედარებაში Pulumi-ის preview უფრო სწრაფია, მაგრამ ეს შედეგი სხვა გარემოში იმავე უპირატესობას არ იძლევა.

არჩევანს ცვლის ისიც, ვის ეკუთვნის არსებული კოდი, როგორ ინახება state, რომელი წესები უნდა აღსრულდეს ცვლილებამდე და როგორ ითვლის მართვადი სერვისი რესურსებს. Terraform-ის გამოყენების ლიცენზია HCP Terraform-ის გამოწერისგან უნდა გაიმიჯნოს; Pulumi-ის ღია კოდის ინსტრუმენტიც ცალკეა Pulumi Cloud-ის გეგმებისგან. ამიტომ მარტო ბრძანების შესრულების დრო ან გეგმის საწყისი ფასი გუნდის ხარჯს ვერ აღწერს.

ენა და ეკოსისტემა: ვინ შეინარჩუნებს კოდს

Terraform რესურსებს HCL-ით აღწერს. გუნდისთვის, რომელსაც უკვე აქვს ამ ენაზე დაწერილი მოდულები, მათი შენარჩუნება ხშირად უფრო მარტივი საწყისი წერტილია, ვიდრე იმავე ინფრასტრუქტურის ხელახლა აღწერა. Pulumi-ის არქიტექტურის აღწერაში მხარდაჭერილია TypeScript, JavaScript, Python, Go, .NET, Java და YAML: პროგრამა რესურსებს შესაბამისი SDK-ით აცხადებს, ხოლო ძრავა საჭირო ცვლილებებს ადგენს.

პროგრამირების ენა საშუალებას აძლევს გუნდს გამოიყენოს მისთვის ნაცნობი ტესტები, პაკეტები და კოდის მიმოხილვის პრაქტიკა. ამ სარგებელს მოჰყვება runtime-ის, ბიბლიოთეკებისა და მათი ვერსიების მოვლაც. HCL-ში ნაკლები პროგრამული მოქნილობა ზოგ გუნდს ინფრასტრუქტურის განზრახვის წაკითხვას უადვილებს; სხვებისთვის ნაცნობ ენაზე პირობითი ლოგიკისა და ხელახლა გამოსაყენებელი კომპონენტების დაწერა უფრო მოსახერხებელია. არსებითი კითხვა ისაა, ვის შეუძლია არსებული კონფიგურაციის უსაფრთხოდ შეცვლა და ვინ უპატრონებს მას შემდეგ.

პროვაიდერების სახელების უბრალო შედარებაც არასაკმარისია. მნიშვნელობა აქვს კონკრეტული რესურსის მხარდაჭერას, იმ მოდულებსა და კომპონენტებს, რომლებიც გუნდს უკვე აქვს, და იმას, როგორ ახლდება მათი დამოკიდებულებები. ინსტრუმენტის შეცვლისას ამ სამუშაოს ფასი შეიძლება უფრო დიდი აღმოჩნდეს, ვიდრე ერთი preview-ის დაზოგილი დრო; ეს გუნდის არსებული კოდის მიხედვით შესაფასებელი შედეგია.

ლიცენზია: შიდა გამოყენება და კომერციული შეთავაზება

HashiCorp-ის ლიცენზირების განმარტებით, Terraform-ის შემდგომი გამოშვებები Business Source License-ის პირობებშია. ორგანიზაციის შიგნით, მათ შორის საწარმოო ინფრასტრუქტურისთვის, მისი გამოყენება ნებადართულია. შეზღუდვა ეხება მესამე პირებისთვის ისეთ კონკურენტულ პროდუქტს, რომელიც Terraform-ს ჰოსტავს ან საკუთარ შეთავაზებაში აერთიანებს.

ეს ზღვარი განსაკუთრებით ეხება კომპანიას, რომელიც მომხმარებლებს IaC სერვისს აწვდის; საკუთარი ინფრასტრუქტურის მართვის ჩვეულებრივი შემთხვევა მას ავტომატურად არ კვეთს. Pulumi-ის CLI და SDK ღია კოდის ინსტრუმენტებია, ხოლო Pulumi Cloud ცალკე მართვადი სერვისია. შესაბამისად, ორივე მხარეს ჯერ გამოყენების უფლება უნდა შეფასდეს და შემდეგ — გუნდური სერვისის გადასახადი. კონკრეტული კომერციული პროდუქტის შემთხვევაში ლიცენზიის შეფასება მისი რეალური მიწოდების ფორმაზეა დამოკიდებული.

მართვადი რესურსი და გეგმის ფასი

HCP Terraform-ის გეგმებში Free-ის ზღვარი 500 მართვადი რესურსია; Essentials-ში რესურსები საათობრივად ირიცხება. დათვლა ეხება HCP Terraform-ის მიერ მართულ state-ში აღრიცხულ რესურსებს, ხოლო საათის პიკური რაოდენობა იმ საათის გადასახადს განსაზღვრავს. ამიტომ თვის ბოლოს დარჩენილი რესურსების რიცხვი ანგარიშის გამოსათვლელად საკმარისი არ არის. იმავე გეგმებში პოლიტიკის აღსრულება და ხარჯის შეფასება Standard-სა და Premium-შია, აუდიტის ჟურნალი კი Premium-ში.

Pulumi-ის ფასების გვერდზე გუნდური Essentials თვეში $40 ღირს და 40 კრედიტს მოიცავს; გვერდი ამავე დროს „500-მდე მართვად რესურსს“ ასახელებს. გამოქვეყნებული Essentials ტარიფი თითო რესურსზე საათში $0.00025-ია, ანუ სრული თვისთვის დაახლოებით $0.1825. ამ ტარიფით 500 რესურსის უწყვეტი მართვა დაახლოებით $91.25 გამოდის და 40 კრედიტში არ ეტევა. ამიტომ „500-მდე“ არ უნდა წაიკითხოთ როგორც სრული თვის გარანტირებული მოცულობა საბაზო გადასახადში. კრედიტები Pulumi-ის სხვა მომსახურებებზეც იხარჯება, ხოლო ზედმეტი მოხმარება დამატებით ირიცხება.

Pulumi-ის დათვლაში შეიძლება შევიდეს პროვაიდერის რესურსი, კომპონენტური რესურსი და stack. ერთი და იმავე ღრუბლოვანი ინფრასტრუქტურისთვის ეს რიცხვი Terraform-ის მართვადი რესურსების რიცხვს ყოველთვის არ დაემთხვევა. Pulumi Cloud-ის Free გეგმა ერთ მომხმარებელს ემსახურება და მართვადი რესურსების რაოდენობას არ ზღუდავს; გუნდური თანამშრომლობისთვის აღწერილი გეგმა Essentials-ია. ფასების შედარებისას ჯერ ორივე სისტემაში დასათვლელი ობიექტები უნდა დააზუსტოთ.

სამი პირობითი მასშტაბი გუნდისთვის

• 500 რესურსი: თუ ყველა მათგანი HCP Terraform-ის დათვლის წესით მართვადია, გუნდი Free-ის ზღვარზეა. Pulumi Essentials-ში იმავე სახელობითი რაოდენობის სრული თვის ხარჯი შეიძლება საბაზო კრედიტებს გასცდეს; კომპონენტებისა და stack-ების დამატება დათვლილ მოცულობასაც შეცვლის.
• 1 000 რესურსი: HCP Terraform-ის Free ზღვარი გადალახულია, ამიტომ Essentials-ის საათობრივი მოხმარება შესაფასებელია. Pulumi Essentials-ისთვისაც საჭიროა საათების, კრედიტებისა და დამატებითი მომსახურებების ცალ-ცალკე დათვლა. ეს პირობითი სცენარია და გამოქვეყნებული სისწრაფის ტესტის ფასი არ არის.
• 5 000 რესურსი: ხანგრძლივი მოხმარებისას მცირე სხვაობაც საათობრივ ტარიფში მნიშვნელოვან საბიუჯეტო სხვაობად იქცევა. ამ მასშტაბზე საბაზო რესურსების გადასახადთან ერთად შეადარეთ სავალდებულო პოლიტიკის, აუდიტისა და წვდომის მართვისთვის საჭირო გეგმა.

საქართველოს გუნდის ბიუჯეტში დოლარში მოცემული ტარიფის პირდაპირ ლარად გადაყვანა სრულ სურათს არ იძლევა. რეალური გადახდა დამოკიდებულია ბილინგის პერიოდზე, გამოყენებულ კრედიტებზე, გაცვლის კურსსა და ანგარიშზე მოქმედ საგადასახადო პირობებზე. შედარებისთვის გამოსადეგი საფუძველია საათების მიხედვით დათვლილი საკუთარი რესურსები და ზუსტად ის ფუნქციები, რომელთა შეძენაც გუნდს სჭირდება.

State და სავალდებულო კონტროლი

ორივე ინსტრუმენტი state-ით აკავშირებს კოდში აღწერილ რესურსებს არსებულ ინფრასტრუქტურასთან. HCP Terraform მართვად state-ს სამუშაო გარემოს უკავშირებს; Pulumi Cloud-იც state-სა და გუნდურ თანამშრომლობას მართავს. Pulumi-ს საკუთარი backend-ით მუშაობაც შეუძლია. საცავის დამოუკიდებლად მართვისას გუნდს ეკისრება მასზე წვდომის, სარეზერვო ასლებისა და აღდგენის ორგანიზება; საცავის არჩევანი ცვლილებების მიმოხილვისა და პასუხისმგებლობის წესებსაც ეხება.

Governance-ის შემთხვევაში „პოლიტიკის მხარდაჭერა“ საკმარისად ზუსტი კრიტერიუმი არ არის. უნდა გაირკვეს, წესი მხოლოდ გაფრთხილებას აჩვენებს თუ დარღვევისას ცვლილებას აჩერებს, ვის შეუძლია წესის შეცვლა და რჩება თუ არა აუდიტის ჩანაწერი. Pulumi Essentials-ში პოლიტიკის შედეგი საკონსულტაციო რეჟიმში ჩანს, ხოლო ორგანიზაციის მიერ მართული სავალდებულო წესები და drift-ის ავტომატური აღმოჩენა Pro-შია. თუ გუნდის მოთხოვნა ცვლილების ავტომატური დაბლოკვაა, მხოლოდ იაფი საწყისი გეგმის შედარება მცდარ გადაწყვეტილებამდე მიიყვანს.

რას ნიშნავს გამოქვეყნებული preview-ის დრო

SkilBrill-ის გამოქვეყნებულ AWS შედარებაში 1 000 რესურსზე Terraform plan-ის მედიანა 34 წამია, Pulumi preview-ის — 28 წამი; 200 შეცვლილი რესურსის apply-ის მედიანებია, შესაბამისად, 188 და 162 წამი. ეს იმ გვერდზე მოყვანილი შედეგებია და სხვა პროექტისთვის პროგნოზად არ გამოდგება.

გამეორების შესაძლებლობა შეზღუდულია: გამოქვეყნებული სკრიპტი ბრძანებების დროს ზომავს, მაგრამ ეკვივალენტური რესურსების კონფიგურაციებს არ ქმნის. წარმოდგენილი მასალა არც runner-ის გარემოს, backend-ს, ინსტრუმენტებისა და პროვაიდერების ვერსიებს, არც ცალკეული გაშვებების ნედლ შედეგებს აღწერს საკმარისად. შესაბამისად, დროები საინტერესო საწყისი ჰიპოთეზაა, თუმცა მათგან ვერ დგინდება, რამდენს დაზოგავს სხვა გუნდი საკუთარ ქსელსა და state-ზე.

შედარებადი შიდა გაზომვისთვის ორივე მხარეს წინასწარ უნდა განისაზღვროს ერთი რეგიონი, რესურსების ტიპები და დამოკიდებულებები. საწყისი მომზადება ცალკე იზომება, რადგან Terraform init და Pulumi პროექტისა და stack-ის გამართვა ერთსა და იმავე სამუშაოს ზუსტად არ ასრულებს. plan და preview რამდენჯერმე უნდა გაეშვას უცვლელ კონფიგურაციაზე; შემდეგ ერთნაირი წინასწარ აღწერილი ცვლილება apply და up-ით შესრულდეს. თითოეული გაშვების დრო, cache-ის მდგომარეობა და პროვაიდერის პასუხის შეფერხება შედეგთან ერთად უნდა დარჩეს.

Drift-ის შესადარებლად ორივე გარემოში ერთი და იმავე ტიპის რესურსი გარედან შეცვალეთ და ცალკე გაზომეთ ცვლილების აღმოჩენა და state-ის განახლება. ეს ციკლები ერთ ბრძანებად არ უნდა გაერთიანდეს, რადგან ინსტრუმენტები შემოწმებასა და განახლებას სხვადასხვა ეტაპზე ასრულებენ. ასეთი ტესტი აჩვენებს გუნდის რეალურ სამუშაო დროს; საბოლოო არჩევანში მას უნდა დაემატოს კოდის მოვლის, ლიცენზიისა და საჭირო მართვადი გეგმის ფასი.

ასევე წაიკითხეთ:

• QuickBooks თუ Xero: გუნდის ზრდისას მომხმარებელთა ლიმიტი ფასს ცვლის
• GitHub Actions თუ GitLab CI: იაფ წუთს გუნდის აბონემენტი შეიძლება აჯობოს
• IPO თუ direct listing: ანდერრაიტერი ფასის ფორმირებას ცვლის