5 udfordringer med at gå sky-indfødt - og hvordan man løser dem

Vi lever i en sky-indfødt verden. Du kan næppe læse en tech-blog eller gå til en konference uden at høre om alle fordelene ved cloud-native teknologier eller arkitekturer, såsom containere, mikroservices og serverløse funktioner.

Alligevel midt i al spændingen ved at gå cloud-native, kan det være let at overse de udfordringer, der opstår, når du migrerer fra ældre, monolitiske applikationer til en cloud-native strategi. Disse udfordringer kan overvindes, men kun hvis du adresserer dem som en del af din cloud-native migrationsstrategi.

Lad os tage et kig på fem af de mest almindelige cloud-native udfordringer sammen med strategier for at overvinde dem.

Hvad er sky-native?

Først dog et ord om, hvad cloud-native faktisk betyder.

Med hypen omkring 'ting' til alle ting bruges 'cloud-native' undertiden af ​​folk til at betyde enhver type teknologi eller strategi, som de betragter som moderne. Fra dette perspektiv ender cloud-native som bare endnu et relativt meningsløst buzzword.

På den anden side, når det investeres med specifik og begrænset betydning, er cloud-native et nyttigt udtryk og koncept. Vi kan godt lide CNCFs definition, der understreger "løst koblede systemer" og elasticitet som egenskaber ved cloud-native computing. CNCF-definitionen peger også på en specifik og begrænset liste over teknologier og arkitekturer - “containere, servicemasker, mikroservices, uforanderlig infrastruktur og deklarative API'er” - som eksempler på cloud-native teknologier.

I denne artikel skal vi holde os til CNCFs definition af cloud-native. Lad os nu diskutere de specifikke udfordringer, der opstår, når du bruger teknologier og strategier som dem, der er beskrevet ovenfor.

Udfordringer med at vedtage Cloud Native

1) Vedvarende datalagring

En fælles udfordring med mange cloud-native teknologier er lagring af data vedvarende. Containere, serverløse funktioner og applikationer, der er implementeret ved hjælp af en uforanderlig infrastrukturmodel, har typisk ikke en måde at gemme data permanent inde i sig selv, fordi alle interne data ødelægges, når applikationen lukkes ned.

Løsning af denne udfordring kræver gentænkning af tilgange til datalagring ved at afkoble det fra applikationer og værtsmiljøer. I stedet for at gemme data i applikationsmiljøet, gemmer cloud-native arbejdsgange det eksternt og udsætter dataene som en service. Derefter forbindes arbejdsmængder, der skal have adgang til dataene, ligesom de ville oprette forbindelse til enhver anden service.

Denne tilgang - som er aktiveret af forskellige værktøjer, såsom mængder i Kubernetes - har to fordele. Ud over at aktivere vedvarende datalagring til applikationer, der ikke selv er designet til at være vedvarende, gør det det også nemt at dele en enkelt lagerpulje mellem flere applikationer eller tjenester.

2) Serviceintegration

Cloud-native applikationer er typisk sammensat af et sæt forskellige tjenester. Denne distribuerede natur er det, der hjælper med at gøre dem skalérbare og fleksible sammenlignet med monolit.

Men det betyder også, at sky-native arbejdsmængder har mange flere bevægelige stykker, der skal tilsluttes sammen problemfrit for at opnå succes.

Til dels er serviceintegration et problem, som udviklere skal adressere, når de bygger cloud-native apps. De skal sikre, at hver service er korrekt størrelse; en bedste praksis er at skabe en distinkt service for hver type funktionalitet inden for en arbejdsbyrde, snarere end at prøve at få en enkelt tjeneste til at gøre flere ting. Det er også vigtigt at undgå at tilføje tjenester bare fordi du kan. Inden du introducerer mere kompleksitet til din app i form af en anden tjeneste, skal du sørge for, at tjenesten fremmer et bestemt mål.

Ud over selve applikationens arkitektur afhænger effektiv serviceintegration også af at vælge de rigtige implementeringsteknikker. Containere er sandsynligvis den mest åbenlyse måde at distribuere flere tjenester og forene dem i en enkelt arbejdsbyrde, men i nogle tilfælde kan serverløse funktioner eller apps, der ikke er containere forbundet med API'er, muligvis være bedre metoder til distribution af tjenester.

3) Ledelse og overvågning

Jo flere tjenester du kører som en del af en applikation, desto vanskeligere bliver det at overvåge og administrere dem. Dette er sandt, ikke kun på grund af det store antal tjenester, du er nødt til at spore, men også fordi det garanterer ansøgningssundhed kræver overvågning af forbindelser mellem tjenester, ikke kun tjenesterne i sig selv.

For at kunne overvåge og styre tjenester i et cloud-native miljø kræves det derefter en tilgang, der kan forudsige, hvordan en fiasko i en tjeneste vil påvirke andre, samt forstå hvilke fejl, der er mest kritiske. Dynamisk baselining, som betyder at erstatte statiske tærskler med dem, der kontinuerligt revurderer applikationsmiljøer for at bestemme, hvad der er normalt og hvad der er en anomali, er også kritisk.

4) Unngå sky lock-in

Lock-in-risici er ikke unikke for skyen; de kan stamme fra næsten enhver type teknologi, og de har været en trussel mod smidighed i årtier. I tilfælde af cloud-native applikationer eller arkitekturer kan truslen om at blive for afhængig af en bestemt skyudbyder eller -tjeneste dog være særlig stor på grund af den lethed, hvormed arbejdsmængder kan implementeres på en sådan måde, at de kræver en bestemt service fra en bestemt sky.

Heldigvis er det let nok at afbøde denne cloud lock-in risiko, så længe du planlægger fremover. At holde sig til samfundsbaserede standarder (som dem, der fremmes af OCCI), vil gøre meget for at sikre, at du nemt kan flytte dine arbejdsmængder fra en sky til en anden. Ligeledes, når du planlægger, hvilke cloud-tjenester du vil bruge til at blive cloud-native, skal du overveje, om nogen af ​​de tjenester, du overvejer, har funktioner, der virkelig er unikke og ikke tilgængelige fra andre skyer. Hvis de gør det, skal du undgå disse funktioner, fordi de kan låse dig ind.

For eksempel varierer de specifikke sprog og rammer understøttet af de serverløse databehandlingsplatforme i forskellige offentlige skyer noget. AWS Lambda understøtter for eksempel Go, men Azure gør det ikke. Af den grund ville du være klog at undgå at skrive dine serverløse funktioner i Go. Selv hvis du planlægger at bruge AWS til at være vært for dem oprindeligt, vil denne afhængighed gøre det vanskeligt at migrere til en anden sky i fremtiden. Hold fast ved et sprog som Java, som du sikkert kan satse vil blive understøttet overalt.

5) Opbygning af apps til cloud-native levering af rørledninger

Per definition kører cloud-native apps i skyen. Mens skyen enten kan være den offentlige sky eller private, on-prem eller hybrid sky run i din organisations miljøer - betyder det uforanderlig infrastruktur og cloud management processer. Men mange applikationsleveringsrørledninger kører stadig stort set i traditionelle lokale miljøer, der måske ikke er blevet overskyet eller er klodsede, når de integreres med applikationer og tjenester, der kører på offentlige skyer eller på containere.

Dette skaber en udfordring i flere henseender. Den ene er, at implementering af kode fra et lokalt miljø til et lokalt sted kan indføre forsinkelser. En anden er, at udvikling og test lokalt gør det sværere at efterligne produktionsbetingelser, hvilket kan føre til uventet applikationsadfærd og postdistribution.

Den mest effektive måde at overvinde disse forhindringer er at flytte din CI / CD-rørledning til et skymiljø - ikke kun for at drage fordel af uforanderlig infrastruktur og skyens skalerbarhed og andre fordele, men også at efterligne produktionsforhold og bringe din rørledning tættere - lige så meget som muligt - til dine apps. På den måde skrives kode tættere på, hvor den er implementeret, hvilket gør installationen hurtigere. Det bliver også lettere at spin op testmiljøer, der er identiske med produktionsomgivelserne.

Selvom udvikling, der er helt skybaseret, ikke er for alle, og nogle udviklere foretrækker lokale IDE'ers kendskab og lydhørhed frem for skybaserede, skal du prøve at sikre, at dine CI / CD-rørledninger kører i et skymiljø i videst muligt omfang.

Konklusion

Uanset hvordan du snurrer det, er det at gå cloud-native er svært. Sammenlignet med ældre applikationer er cloud-native applikationer mere komplekse og har mange flere steder, hvor ting kan gå galt. Når det er sagt, kan cloud-native computing-udfordringer overvindes - og implementering af strategier, der kan tackle udfordringerne, er nøglen til at låse op for agility, pålidelighed og skalerbarhed, som kun cloud-native arkitekturer kan levere.