5 väljakutset oma loomuliku pilve loomiseks - ja kuidas neid lahendada

Me elame pilvemaises maailmas. Vaevalt saate lugeda tehnikablogi või minna konverentsile, ilma et oleksite kuulnud pilve loomulike tehnoloogiate või arhitektuuride, näiteks konteinerite, mikroteenuste ja serverita funktsioonide eelistest.

Kuid kogu põnevusega pilve-natiivseks muutumisest võib olla lihtne jätta tähelepanuta väljakutsed, mis tekivad siis, kui rändate pärandilt monoliitsetelt rakendustelt pilvepõhisele strateegiale. Nendest väljakutsetest saab üle, kuid ainult siis, kui käsitlete neid oma pilvepõhise rände strateegia osana.

Sel eesmärgil vaatame viit kõige levinumat pilvekeelega seotud väljakutset koos nende ületamise strateegiatega.

Mis on pilvepõhine?

Esiteks, aga sõna selle kohta, mida pilv-emakeel tegelikult tähendab.

Kõigi pilvede ümber esineva hüpe korral kasutavad inimesed mõnikord pilv-pärismaalasi mis tahes tüüpi tehnoloogia või strateegia jaoks, mida nad peavad tänapäevaseks. Sellest vaatenurgast saab pilvekeelne loodus lihtsalt veel ühe suhteliselt mõttetu sõna.

Teisalt, kui investeerida spetsiifilise ja piiratud tähendusega, on pilvekeelena kasulik termin ja mõiste. Meile meeldib CNCF-i määratlus, mis rõhutab pilv-loomuliku andmetöötluse omadustena „lõdvalt ühendatud süsteeme“ ja vastupidavust. CNCF-i määratlus osutab ka pilvepõhiste tehnoloogiate näidetele tehnoloogia ja arhitektuuri konkreetsele ja piiratud loetelule - „konteinerid, teenuse võrgud, mikroteenused, muutumatu infrastruktuur ja deklaratiivsed API-liidesed”.

Selle artikli kohaldamisel peame kinni CNCF-i pilvepõhise määratlusest. Nüüd arutame konkreetseid väljakutseid, mis tekivad ülalkirjeldatud tehnoloogiate ja strateegiate kasutamisel.

Väljakutsed sünnipärase pilve vastuvõtmisel

1) püsiv andmete salvestamine

Paljude pilvepõhiste tehnoloogiate üks tavaline väljakutse on andmete püsiv salvestamine. Muutumatut infrastruktuurimudelit kasutavatel konteineritel, serverita funktsioonidel ja rakendustel pole tavaliselt võimalust andmeid püsivalt endasse salvestada, sest kogu sisemine teave hävitatakse rakenduse väljalülitamisel.

Selle väljakutse lahendamine nõuab andmete salvestamise lähenemisviiside ümbermõtestamist, eraldades need rakendustest ja hostikeskkondadest. Rakenduskeskkonnas andmete salvestamise asemel salvestavad pilvepõhised töövood seda väliselt ja paljastavad andmed teenusena. Seejärel ühendatakse andmetele juurde pääseda vajavad töömahud sellega, nagu nad ühenduksid mõne muu teenusega.

Sellel lähenemisviisil - mida võimaldavad mitmesugused tööriistad, näiteks Kuberneteses olevad mahud - on kaks eelist. Lisaks püsiva andmesalvestuse võimaldamisele rakenduste jaoks, mis ise pole püsivad, on see hõlpsaks ka ühe salvestusruumi jagamine mitme rakenduse või teenuse vahel.

2) Teenuste integreerimine

Pilvepõhised rakendused koosnevad tavaliselt erinevatest teenustest. See hajutatud olemus aitab muuta neid monoliitsete toodetega skaleeritavaks ja paindlikuks.

Kuid see tähendab ka, et pilvepõhistes töökoormustes on palju rohkem liikuvaid detaile, mis tuleb edu saavutamiseks omavahel sujuvalt ühendada.

Osaliselt on teenuse integreerimine probleem, millega arendajad peavad tegelema, kui nad loovad pilvepõhiseid rakendusi. Nad peavad tagama, et iga teenus oleks õigesti mõõdetud; Parim tava on luua koormuse piires igat tüüpi funktsioonide jaoks eraldi teenus, selle asemel et proovida panna ühte teenust tegema mitu asja. Samuti on oluline vältida teenuste lisamist ainult seetõttu, et saate. Enne kui tutvustate oma rakendusele mõne muu teenuse näol keerukamat, veenduge, et teenus edendaks konkreetset eesmärki.

Lisaks rakenduse enda ülesehitusele sõltub tõhus teenuste integreerimine ka õigete juurutamistehnikate valimisest. Konteinerid on ilmselt kõige ilmsem viis mitme teenuse juurutamiseks ja koondamiseks ühte töökoormusse, kuid mõnel juhul võivad teenuse paremaks kasutuselevõtmiseks olla serverita funktsioonid või API-dega ühendatud konteinerita rakendused.

3) juhtimine ja seire

Mida rohkem teenuseid rakenduse osana käitate, seda keerukamaks muutub nende jälgimine ja haldamine. See on tõsi, seda mitte ainult tänu jälgitavate teenuste arvule, vaid ka seetõttu, et rakenduse tervise tagamiseks tuleb jälgida mitte ainult teenuste endi, vaid ka teenuste suhteid.

Teenuste edukaks jälgimiseks ja haldamiseks pilvekeskkonnas on vaja lähenemisviisi, mis võimaldab prognoosida, kuidas ühe teenuse rike mõjutab teisi, samuti mõista, millised rikked on kõige kriitilisemad. Kriitiline on ka dünaamiline lähtejoon, mis tähendab staatiliste lävede asendamist sellistega, mis hindavad rakenduste keskkondi pidevalt ümber, et teha kindlaks, mis on normaalne ja mis on anomaalia.

4) Pilve lukustumise vältimine

Lukustusriskid pole pilve jaoks ainuomased; need võivad tekkida peaaegu igat tüüpi tehnoloogiast ja on aastakümneid ohustanud paindlikkust. Pilvepõhiste rakenduste või arhitektuuride puhul võib eriti suureks ohuks muutuda konkreetsest pilveteenuse pakkujast või teenusest sõltuvus seetõttu, et töökoormusi saab hõlpsasti rakendada viisil, mis eeldab konkreetset teenus konkreetsest pilvest.

Õnneks on selle pilve sisselogimisriski maandamine piisavalt lihtne, kuni te plaanite ette. Kommuunipõhiste standardite (nagu ka OCCI propageeritud standardite) järgimine aitab palju kaasa sellele, et saaksite oma töökoormust hõlpsalt ühest pilvest teise teisaldada. Samuti, kui plaanite, milliseid pilveteenuseid te pilve natiivseks muutmiseks kasutate, kaaluge, kas mõnel kaalutaval teenusel on tõeliselt ainulaadseid funktsioone, mida teised pilved ei saa. Kui nad seda teevad, vältige neid funktsioone, sest need võivad teid lukustada.

Näiteks erinevad avalike pilvede serverivabade arvutiplatvormide toetatud konkreetsed keeled ja raamistikud mõnevõrra. AWS Lambda toetab näiteks Go, kuid Azure seda ei tee. Sel põhjusel oleks mõistlik hoiduda serverita funktsioonide kirjutamisest kaustas Go. Isegi kui te kavatsete nende vastuvõtmiseks kasutada AWS-i, raskendaks see sõltuvus tulevikus teistsugusesse pilve rändamist. Pange kinni keeltega, näiteks Java, millele võite kindlalt panustada, ja seda toetatakse kõikjal.

5) Pilvepõhiste tarnejuhtmerakenduste ehitamine

Määratluse järgi töötavad pilvekeelsed rakendused pilves. Kuigi pilv võib olla teie organisatsiooni keskkonnas kas avalik pilv või privaatne, esmaesitlusel või hübriidpilv, tähendab see muutumatut infrastruktuuri ja pilvehaldusprotsesse. Kuid paljud rakenduste kohaletoimetamise torustikud töötavad endiselt suures osas traditsioonilises kohapealses keskkonnas, mis ei pruugi olla hägune või on ummistunud, kui need on integreeritud avalikes pilvedes või konteinerites töötavate rakenduste ja teenustega.

See loob väljakutse mitmes mõttes. Üks on see, et koodi juurutamine kohalikust keskkonnast kohapealsesse keskkonda võib põhjustada viivitusi. Teine on see, et kohapeal arendamine ja testimine raskendab tootmistingimuste jäljendamist, mis võib põhjustada rakenduse ootamatut käitumist, juurutamist.

Kõige tõhusam viis nendest takistustest üle saamiseks on viia CI / CD torujuhe pilvekeskkonda - mitte ainult muutumatust infrastruktuurist ja pilve skaleeritavusest ja muudest eelistest kasu saamiseks, vaid ka tootmistingimuste jäljendamiseks ja torustiku lähendamiseks - nii palju kui võimalik kui võimalik - oma rakendustele. Nii kirjutatakse kood lähemale kohale, kus seda kasutatakse, muutes juurutamise kiiremaks. Samuti muutub lihtsamaks katsekeskkondade loomine, mis on identsed tootmiskeskkondadega.

Kuigi täielikult pilvepõhine arendus ei sobi kõigile ja mõned arendajad eelistavad kohalike IDE-de tuntust ja reageerimisvõimet pilvepõhiste asemel, proovige tagada, et teie CI / CD-torujuhtmed töötaksid pilvekeskkonnas nii palju kui võimalik.

Järeldus

Pole tähtis, kuidas te seda keerutate, on pilvepõhiseks muutmine keeruline. Võrreldes pärandrakendustega on pilvepõhised rakendused keerukamad ja neil on palju rohkem kohti, kus asjad võivad valesti minna. Pilvekeelsest andmetöötlusest tulenevad probleemid saab siiski ületatud - väljakutsetele vastavate strateegiate rakendamine on võtmeks, et vabastada paindlikkus, usaldusväärsus ja mastabeeritavus, mida ainult pilvepõhised arhitektuurid suudavad pakkuda.