ღია კოდი vendor lock-in-ის წინააღმდეგ: დეველოპერის პერსპექტივა

ტექნოლოგიურ მომწოდებლებზე დამოკიდებულება დიდი ხანია არქიტექტურის განხილვის თემაა, თუმცა ახლა ბიუჯეტსა და შესაბამისობის მოთხოვნებსაც ეხება. The New Stack-ზე SUSE-ის მხარდაჭერით გამოქვეყნებულ ანალიზში ავტორები ამტკიცებენ, რომ vendor lock-in იშვიათად იწყება ერთი ცუდი გადაწყვეტილებით, ის ბევრი გონივრული არჩევანის დაგროვებით იზრდება.

რა ღირს vendor lock-in სინამდვილეში

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

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

ღია ლიცენზიები და წესების შეცვლის უფლება

ღია კოდი ამ ტესტს კარგად უძლებს, რადგან სისტემები შემოწმებადი, გადატანადი და შესაცვლელია, თუმცა ავტორები ხაზს უსვამენ, რომ გარანტია არ არსებობს: მჭიდრო კავშირი ღია საფუძველზეც შეიძლება აშენდეს. ლიცენზია ერთ რამეს მაინც ცვლის: ვის აქვს პირობების გადაწერის უფლება. Linux-ის ბირთვი საავტორო უფლებების მიკუთვნებას არ ითხოვს, ამიტომ დამატებული კოდი პირვანდელ მფლობელს რჩება და ბირთვს ათასობით მფლობელი ჰყავს. Kubernetes Apache 2.0-ის ლიცენზიით ვრცელდება და Cloud Native Computing Foundation-ის მიერ იმართება, ამიტომ ვერც ერთი კომპანია ვერ წაართმევს პროექტს უკვე მინიჭებულ უფლებებს.

Terraform-იდან OpenTofu-მდე ფორკი ამის პრაქტიკული მაგალითია. 2023 წელს, HashiCorp-მა Terraform-ის ლიცენზია Mozilla Public License 2.0-იდან Business Source License 1.1-ზე შეცვალა, საზოგადოებამ ბოლო ღია კოდის ბაზა ფორკად აიღო და OpenTofu შექმნა, რომელიც დღეს Linux Foundation-ის პროექტია და MPL 2.0-ის ქვეშ რჩება.

ციფრული სუვერენიტეტი: პრიორიტეტი, მაგრამ არა მოქმედება

ციფრული სუვერენიტეტი, ანუ კონტროლი ინფრასტრუქტურაზე, მონაცემებსა და ტექნოლოგიურ არჩევანზე, იმავე კითხვებს კიდევ უფრო აქტუალურს ხდის. სტატიაში მოყვანილი SUSE-ის კვლევის მიხედვით, თითქმის ყველა საწარმო ამას პრიორიტეტად მიიჩნევს, თუმცა მხოლოდ 52% დგამს რეალურ ნაბიჯებს.

ავტორები სუვერენიტეტს ცალკე რეგულაციურ მიმართულებად კი არა, არქიტექტურის თვისებად განიხილავენ: გადატანადი დატვირთვები, სუფთა ინტერფეისები, გამრავლებადი განლაგება და შემოწმებადი ქცევა თავისთავად იმსახურებს ინვესტიციას. სუვერენიტეტი ახალ სამუშაოს არ ქმნის, ვადას უწესებს იმას, რაც თავიდანვე ღირდა გაკეთებას.

ოთხი უნარი შექცევადობის შესამოწმებლად

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

დასკვნა მარტივია: „ნებისმიერი პლატფორმის ნამდვილი ფასი მისი დატოვების ღირებულებასაც მოიცავს და გუნდებმა ეს ღირებულება ვალდებულების აღებამდე უნდა გაიგონ“.