Cloud provayderinin API-ni açması ilk baxışda çox cəlbedici vəd verir: infrastrukturu kodla idarə et, istənilən alətdən qoşul, lazım gələndə də başqa yerə keç. İlk iki hissə doğrudur. Üçüncüsü isə bu qədər rahat deyil.
Açıq cloud API xidmətlə danışığın qaydasını görünən edir. Hansı request göndərilir, hansı sahələr tələb olunur, cavab və xəta necə görünür, bunları bilmək üçün provayderin daxili koduna ehtiyac qalmır. OpenAPI Specification də HTTP API-ləri proqramlaşdırma dilindən asılı olmayan təsvirlə insan və proqram üçün anlaşılan etməyə xidmət edir. Bu, client generatoru, test, sənədləşmə və üçüncü tərəf alətləri üçün möhkəm başlanğıcdır.
Amma açıq olmaqla eyni olmaq ayrı şeylərdir. İki provayder API sənədini hamıya göstərə bilər, hər ikisi virtual maşın yaratmağa imkan verər, yenə də image formatı, şəbəkə modeli, disk snapshot-ı, rol sistemi və xəta davranışı bir-birinə uyğun gəlməz. Müqaviləni oxumaq mümkündür, müqavilələr isə fərqlidir.
Açıq API əslində nəyi açır?
API müqaviləsi dörd əsas sualı cavablandırır: hansı əməliyyat mövcuddur, giriş məlumatı nədir, uğurlu cavab necə görünür və xəta hansı formada qaytarılır. Maşın tərəfindən oxunan təsvir bu müqaviləni alətlər üçün də işlək edir. İş bununla bitmir. OpenAPI HTTP endpoint-lərini, parametrləri, request və response strukturunu ifadə edir; spesifikasiya mənbə koduna və şəbəkə trafikini əl ilə araşdırmağa ehtiyac olmadan servisin imkanlarını anlamağı hədəfləyir.
Bu səviyyədə açıqlıq real fayda verir. Provayderin öz SDK-sı yeganə giriş qapısı olmur. Komanda öz client-ini yarada, müqavilə testləri qura, dəyişiklikləri diff edə və idarəetməni mövcud automation alətlərinə bağlaya bilər. API versiyası və deprecation qaydası aydın yazılıbsa, upgrade zamanı sürpriz də azalır.
Lakin API təsviri servisin davranışını tam standartlaşdırmır. Eyni adlı createServer əməliyyatı bir sistemdə saniyələr içində hazır resurs qaytara, digərində isə sonradan izlənməli asinxron job yarada bilər. Rate limit, eventual consistency, retry təhlükəsizliyi və kvota modeli sxemdə qismən görünür, bəzən heç görünmür. Burada məsələ qəlizləşir: sintaksis uyğun olsa da semantika fərqli qala bilər.
Portativlik bir neçə qatın birlikdə işləməsidir
Tətbiqi daşımaq üçün təkcə API çağırışlarını dəyişmək kifayət etsəydi, migration layihələri xeyli darıxdırıcı olardı. Əsl yük aşağı qatlarda üzə çıxır. Tətbiqin topologiyası, komponentlər arasındakı əlaqələr, deployment artifact-ları və lifecycle əməliyyatları da təsvir olunmalıdır. TOSCA 2.0 məhz komponentləri, onların əlaqələrini və yaradılma ilə dəyişdirilmə prosedurlarını service topology və orchestration vasitəsilə ifadə edir.
Aşağıdakı sxemdə açıq API yalnız üst qapıdır. Request adapterdən keçib provayderin resurs modelinə çevrilir; workload həmin resurslarda işləyir, data isə ayrıca köçürülür. Identity və observability bütün bu axına toxunur. Buna görə hər yolun ortaq portability testindən keçməsi lazımdır.
Diaqram — orijinal məqalədə
Provayder adapteri ortaq daxili model ilə konkret cloud API-si arasındakı tərcümə qatıdır. Compute, şəbəkə və storage modeli resursların nə demək olduğunu müəyyən edir. Workload və lifecycle hissəsi deploy, scale, patch və shutdown kimi əməliyyatları əhatə edir. Data ixracı və idxalı vəziyyətin yeni mühitə aparılmasıdır; identity rol və icazələrin, observability isə log, metric və tracing axınının yenidən qurulmasını tələb edir. Portability testi bunları birlikdə sınamırsa, kağız üzərindəki uyğunluq production keçidini sübut etmir.
TOSCA-nın model-driven yanaşması da bu boşluğu hədəfləyir: modeldəki dependency, connection və composition məlumatı avtomatlaşdırılmış prosesləri idarə edə bilir. Üstəlik CSAR adlı arxiv formatı service template ilə deployment və implementation artifact-larını eyni konteynerdə daşımağa imkan verir. Bu, hər cloud-un eyni davranacağı demək deyil. Standart təsvir olunan hissəni portativ edir; tətbiqin içindəki provayderə məxsus komponent ayrıca həll tələb edir.
Vendor lock-in harada qalır?
Ən görünən bağlılıq xüsusi API əməliyyatıdır. Məsələn, tətbiq yalnız bir provayderdə olan managed database funksiyasına söykənirsə, adapter yazmaq həmin funksiyanın alternativini yaratmır. Daha sakit bağlılıqlar da var: böyük həcmdə datanın çıxarılma vaxtı və qiyməti, IAM siyasətlərinin fərqli semantikası, region topologiyası, secret idarəetməsi, metric adları və incident zamanı komandanın istifadə etdiyi runbook-lar.
Lock-in həmişə pis qərar deyil. Provayderə məxsus servis daha az əməliyyat yükü, daha yaxşı latency və sürətli məhsul inkişafı verə bilər. Bağlılığı görməmək səhvdir. Həm də bahalı. Komanda qazancı ölçüb çıxış planının xərcini qəbul edirsə, bu şüurlu trade-off-dur; yalnız API açıqdır deyə çıxışın pulsuz olduğunu düşünürsə, hesab yarımçıqdır.
API-nin lisenziyası da ayrıca məsələdir. Spesifikasiyanı oxumaq və client yaratmaq hüququ vacibdir, amma uyğun alternativ implementasiyanın bazarda mövcud olacağına zəmanət vermir. Kağız üzərində tam açıq interfeys ola bilər, onu eyni semantika ilə təqdim edən ikinci servis isə olmaya bilər. Bu halda hüquqi və texniki açıqlıq var, praktik çıxış yolu yoxdur.
Fərq məhz budur.
Ortaq abstraction qatının da qiyməti var. Bütün cloud-ları ən kiçik ortaq məxrəcə salanda fərqləndirici imkanlar itir. Həddindən artıq ümumi model isə xüsusi hallarla dolur və bir müddət sonra öz kiçik cloud platformanıza çevrilir. Adətən daha sağlam sərhəd tətbiqin istifadə etdiyi dar imkan dəstini abstraktlaşdırmaq, provayderə məxsus optimizasiyaları isə açıq şəkildə adapterin arxasında saxlamaqdır.
Portativliyi necə sınaqdan keçirmək olar?
Yaxşı ölçü “ikinci provayder üçün kodumuz var” deyil. Eyni workload təmiz mühitdə qurula, lazımi data bərpa oluna, identity siyasətləri tətbiq edilə və observability siqnalları görünə bilirmi? Failover və rollback işləyirmi? Bunlar müntəzəm sınaqdan keçmirsə, alternativ deployment çox vaxt köhnəlmiş YAML və nikbin wiki səhifəsindən ibarət qalır.
API contract testləri request və response uyğunluğunu yoxlayır. Integration testləri adapterin real provayder davranışını tutmalıdır. Sonra data restore testi, icazə testi və əməliyyat ssenariləri gəlir. TOSCA service lifecycle idarəetməsini yaradılma ilə məhdudlaşdırmır; model deploy-dan sonrakı dəyişiklikləri də ifadə edir. Portativlik də yalnız ilk deployment anı deyil, scale, patch, monitor və dayandırma kimi bütün ömür dövründə qorunmalıdır.
Belə sınağın tezliyi biznesin həssaslığından asılıdır. İldə bir dəfə masa arxasında sənədə baxmaqla canlı migration məşqi eyni sübut deyil. Kritik sistemdə müvəqqəti ikinci mühit qurmaq baha görünə bilər, amma DNS keçidi, sertifikatlar, queue-da qalan mesajlar və write zamanı yaranan data fərqi yalnız real axında üzə çıxır. Daha az kritik workload üçün isə periodik restore və smoke test kifayət edə bilər. Məqsəd multi-cloud nişanı toplamaq yox, qəbul edilmiş bərpa müddətinin texniki olaraq mümkün olduğunu görməkdir.
Açıq cloud API buna görə son həll yox, yoxlanıla bilən sərhəddir. O, qapını və qapının dilini göstərir. Qapıdan keçəndən sonra resurs semantikası, data, identity və əməliyyat vərdişləri hələ də sizinlə gəlməlidir.
Tez-tez verilən suallar
Açıq API istifadə etmək vendor lock-in-i aradan qaldırır?
Xeyr. Açıq müqavilə inteqrasiyanı və alternativ client yazmağı asanlaşdırır, lakin resurs semantikası, data köçürməsi, identifikasiya və əməliyyat davranışı yenə provayderə bağlı qala bilər.
OpenAPI ilə cloud API eyni şeydir?
Xeyr. Cloud API xidməti idarə edən interfeysdir, OpenAPI isə HTTP API-nin əməliyyatlarını və strukturunu maşın tərəfindən oxuna bilən formada təsvir edən standartdır.
Multi-cloud üçün bütün provayderləri ortaq interfeys arxasında gizlətmək lazımdır?
Yalnız tətbiqin həqiqətən istifadə etdiyi sabit imkanlar üçün. Ən kiçik ortaq məxrəc yanaşması provayderlərin faydalı fərqli imkanlarını gizlədə və mürəkkəbliyi adapter qatına daşıya bilər.
Top comments (0)