În zilele noastre, crearea unei aplicații în cloud a ajuns foarte ușoară. În doar cinci minute poți să ai un cluster Kubernetes împreună cu o bază de date, gata să ruleze aplicația ta. Totuși, alegerea unui vendor de cloud este dificilă. La aceasta se adaugă și faptul că, pe termen lung, cele mai multe organizații doresc să aibă opțiunea de a migra între diferiți vendori, fără investiții majore.
În acest articol vor fi abordate avantajele și dezavantajele pe care le are cloud lock-in . De asemenea, va fi expusă și o listă de aspecte de care trebuie să ține cont în momentul în care analizăm nivelul de cloud lock-in pe care îl dorim pentru sistemele noastre.
Există mai multe definiții pe piață, dar când vorbim despre cloud lock-in sau vendor lock-in, ne referim la costurile directe și indirecte ale unui sistem ce trebuie migrat de la un vendor de cloud la altul (de exemplu AWS -> Azure).
Cloud lock-in face clienții mai dependenți de un furnizor de cloud, iar migrarea către un alt furnizor devine costisitoare. Există mai multe dimensiuni pe care trebuie să le avem în vedere, precum:
Storage (Azure Storage);
Data (Azure SQL Elastic Pool, Azure SQL Database);
Payloads (Azure Kubernetes Services, Azure VMs, Azure Functions, Azure App Services)
Communication (Azure Service Bus, Azure Event Hub);
Infrastructure (Azure VNETs);
Trebuie să fim conștienți de faptul că cloud lock-in vine cu multe avantaje, în special din punctul de vedere al time-to-market și cloud economics. Lansarea unui produs nou pe piață se poate face mult mai ușor când este folosit un număr mare de servicii de tip SaaS, care îți permit nu doar să ai acces la funcționalitate într-un timp foarte scurt dar și la un preț mult mai bun.
Cloud Managed Services, cum ar fi Azure App Services, Azure Service Bus, Azure Redis Cache, ne ajută să construim o platformă în cel mai scurt timp posibil. Efortul necesar pentru construirea infrastructurii și implementarea NFR-urilor (de exemplu, vailability, redundancy, backup and recovery) este redus drastic, iar SLA, pe care fiecare vendor de cloud le oferă la serviciile din oferta SaaS și PaaS, ne dă siguranța că serviciile folosite respectă anumite standarde. Este mult mai ușor pentru echipa de suport să gestioneze serviciile care sunt oferite out-of-the-shelve, precum Azure Functions, AWS Lambda, AWS RDS sau Azure SQL Database.
All-in pentru un vendor de cloud oferă un nivel ridicat de agilitate. Mai mult, efortul necesar pentru a gestiona infrastructura, servicii precum cache sau DB și middleware este foarte mic. Folosind această abordare există mai mult timp pentru a investi în capabilitățiile de securitate, scalabilitate, DR și HA și cloud managed services.
Cele mai luate în considerare dezavantaje ale cloud lock-in sunt:
Dependency outages - Folosirea unui număr mare de servicii gestionate de un vendor de cloud crește șansele ca unul din servicii să aibă probleme de availability. Chiar dacă suntem susținuți de SLA și de un istoric înregistrat a availability, trebuie să fim conștienți de acest lucru. Există diferite mecanisme prin care putem să ameliorăm această situație.
Leverage - Când aveți un nivel ridicat de dependență față de un furnizor de cloud, este mai greu să negociați costurile sau să obțineți mai mult pentru aceeași sumă de bani.
O parte din avantajele cloud-lock-inului sunt:
Speed to market- Cloud Managed Services ne scutește de săptămâni de muncă grea pentru a implementa și gestiona diferite componente ale sistemelor noastre ( de exemplu, Azure SQL Database, Azure Storage, Azure ML Studio).
Technical Dept - Datorită serviciilor SaaS și pachetelor de integrare, technical dept de la sistemele noastre este mult mai redus.
Innovation - Este mult mai ușor să integrați o soluție serverless sau o soluție NoSQL atunci când poți să ai infrastructură la două clickuri distanță, cu ZERO efort în instalare și configurare. Cel mai bun exemplu este Azure ML Studio, pe care îl puteți rula în doar câteva minute.
Consistency - Aveți aceeași abordare în întregul sistem. Din punct de vedere al securității sau al monitorizării, puteți utiliza aceeași abordare pentru toate componentele sistemului.
Organizațiile mari au o strategie pentru a evita cloud lock-in. Acest lucru poate fi realizat la nivel de program, asigurându-se că diferite părți ale sistemelor rulează pe diferiți furnizori de cloud sau prin construirea soluțiilor a.i. care să ruleze fără probleme (mai mult sau mai puțin) pe mai mulți furnizori de cloud.
Adevărata provocare este să găsești echilibrul corect între serviciile pe care un vendor de cloud le oferă din suita SaaS și PaaS și cele pe care le-ai gestionat singur.
În ultimii ani, adoptarea de soluții de containerizare precum Docker și Kubernetes combinate cu diferite soluții precum Dapr ne-a permis să atingem un nivel mai înalt de interoperabilitate cu mai puțin efort și un grad ridicat de loosely couples între serviciile cloud și sisteme.
Nivelul de integrare și abstractizare oferit de soluții precum Dapr ne acordă posibilitatea de a comuta între AWS SNS și Azure Services Bus fără a face modificări la nivel de aplicație. Iar la nivel computațional, Kubernetes ne permite să rulăm aceeași aplicație în AWS EKS sau Azure AKS fără probleme.
Există multe alte modalități de gestionare a cloud lock-in și fiecare dintre ele va fi discutată într-un articol separat.
DA și NU
Există multe aspecte care trebuie luate în considerare atunci când decideți nivelul de cloud lock-in pe care doriți să îl aveți. Nu există formula perfectă și s-ar putea ca direcția și strategia pe care o aveți să se schimbe în timp.
Mai jos puteți găsi o listă cu elementele de care trebuie să țineți cont atunci când luați o astfel de decizie. (Am preferat să le expun cu denumirile în engleză, deoarece traducerea completă în română ar putea conduce la inadecvări și modificări ale sensului.)
Organization strategy related to cloud vendors
Regulation and Compliance
Time-to-market
Learning curve
Infrastructure skills to manage all the components (e.g. DB, Storage, Cache, FW, ...)
System lifecycle (1-3-5-15y)
Geographical deployments locations
Cost of managing the platform
Functional requirements
NFRs
Architecture approach and design
Running costs (high volume of consumption on a cloud provider can facility getting a better price - Azure Reserved Virtual Machine Instances)
Transfer costs across cloud vendors
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
