Lietuviškai „debesija“ arba „debesų kompiuterija“ verčiamas anglų kalbos žodis „cloud computing“, kuris reiškia specialaus duomenų centro suteikiamus didelius serverių pajėgumus (žr čia). Paprastai naudojamas JAV Nacionalinio standartų ir technologijų instituto apibrėžimas (žr čia).

Pagal šį apibrėžimą, „debesys“ skirstomi į

• IaaS („Infrastructure as a service“, t.y. infrastruktūra kaip paslauga), kai duomenų centras suteikia aparatūrinės infrastruktūros pajėgumus. Populiariausias pavyzdys yra Amazon AWS.
• PaaS („platform as a service“, t.y. „platforma kaip paslauga“), kai nuomojami nebe aparatūriniai pajėgumai, bet programinė platforma programinei įrangai kurti. Pavyzdžiui – Microsoft Sharepoint Online.
• SaaS – (Software as a service, „programinė įranga kaip paslauga“), kai duomenų centre įdiegta speciali programinė įranga, kuri paskirstyta per daugelį serverių ir todėl gali aptarnauti labai daug klientų vienu metu. Pavyzdžiui – SalesForce arba Gmail for Business.

Šiame įraše pasakosiu daugiausia apie SaaS debesiją, o tiksliau – apie tai, kaip kuriamos SaaS programos, ir kuo toks programavimas skiriasi nuo tradicinio internetinių programų kūrimo.

Multitenancy

Paprastai tariant, SaaS programos yra tokios web aplikacijos, kurios: a) paskirstytos po kelis serverius duomenų centre (angl. elastic scallability) ir b) suteikia virtualią dedikuotą paskyrą kiekvienam užsakovui (angl. multitenancy; lietuviško vertinio šiam terminui nežinau, bet pažodinis vertimas matyt būtų „daugia-nuomininkiškumas“, „daugia-užsakovininkiškumas“ ar kaip nors panašiai).

Paprasčiausias būdas tai pasiekti yra dublikuoti turimą web programą, kiekvienam klientui sukuriant po atskirą programos ir duomenų bazės kopiją. Pavyzdžiui, jeigu jūs suprogramavote nuosavą e-parduotuvę, tai kiekvienam e-parduotuvės norinčiam užsakovui savo produktą diegtumėte į atskirą serverį su atskiromis duomenų bazėmis.

Toks programų dublikavimas yra paprastas, greitas, ir… labai sunkiai palaikomas būdas. Kuo daugiau klientų, tuo daugiau programos kopijų bei duomenų bazių serverių, ir tuo sunkiau diegti atnaujinimus, prižiūrėti kiekvienos kopijos veikimą. Ilgainiui daugėjant klientų, tokio būdo teks atsisakyti.

Geresnis būdas yra numatyti tokį poreikį dar prieš kuriant programą, ir programuoti visą sistemą remiantis vienokia ar kitokia multitenancy strategija (daugiau informacijos čia) :

• Alternatyva A. Atskirti užsakovus duomenų bazės eilučių lygmenyje. Kiekvienam užsakovui suteikti individualų numerį – taip vadinamą tenant_id – ir kiekviename duomenų bazės įraše žymėti, kuriam užsakovui šis įrašas taikytinas. Dėmesio! Kiekviena užklausa į duomenų bazę privalo nurodyti tenant_id ir teisingai filtruoti duomenis, o tai sunkiau nei atrodo. Patarčiau pasidomėti, ar jūsų naudojama ORM arba duomenų bazė palaiko multitenancy, ir vis tiek labai gerai suvokti netipinius atvejus. Bet kuriuo atveju, kils sunkumų duomenis archyvuojant ir atstatinėjant.
• Alternatyva B. Vienas bendras aplikacijų serveris, tačiau daug duomenų bazių schemų. Šiuo atveju tenant_id nurodo, kurią duomenų bazės schemą naudoti kiekvienoje užklausoje. Duomenų atskyrimas bei archyvavimas išlieka santykinai paprastas, tačiau negalėsite turėti užsakovų hierarchijų. Duomenų bazės struktūros keitimas taps sudėtinga procedūra.

Mano patarimas – jokiu būdu, jokiais atvejais neatskleiskite tenant_id! Šis kodas turi likti sistemos vidine „paslaptimi“, ir negali būti perduodamas kliento naršyklei nei slapukuose, nei HTTP užklausų antraštėse, nei parametruose. Duomenų atskyrimas (tenant isolation) turi būti labai aiškiai numatytas visoje architektūroje ir išbandytas automatiniais testais.

„Security first“ architektūra

Kompiuteryje veikiančias programas reikia ginti nuo tinklo įsilaužėlių, nesąžiningų kolegų bei virusų. Internetinės programos turi būti apsaugotos ir nuo nesąžiningų vartotojų, ir nuo programišių iš viso Interneto. SaaS programos turi būti pradedamos kurti nuo saugumo užtikrinimo mechanizmų, funkcionalumą pridedant tik užtikrinus saugumą – taip vadinama „security first“ architektūra (pavyzdžių žr čia).

Pirmasis patarimas – turėkite saugumo ekspertų savo programuotojų komandoje. Rinkitės stiprų, gerai saugumą išmanantį programinės įrangos architektą. Be to, visa komanda turi žinoti gerąsias programavimo praktikas. Štai kelios iš jų:

1. Nepasitikėkite įvedamais duomenimis! SQL injection ir nesaugios simbolių koduotės yra tik keletas iš programišių mėgstamų įrankių.
2. Apsaugokite sesijas! Ar žinote kaip konfigūruoti slapukus, kam reikalingas CSRF ir ar viską žinote apie JWT?
3. Ar viską žinote apie XSS pažeidžiamumą?
4. Žinokite visus jūsų programoje naudojamus šifravimo algoritmus, ir venkite silpnų šifruočių.
5. Naudokite deklaratyvų programavimą apsaugoti visoms internetu pasiekiamoms funkcijoms.
6. Šiuolaikinės programos naudoja daugybę bibliotekų. Ar žinote visas jas, ir ar žinote kurios iš jų yra saugios?

Antrasis patarimas – negailėkite pinigų išoriniam saugumo auditui. Net jei ir turite saugumo ekspertą savo komandoje, išorinis žmogus gali pateikti daug įdomių įžvalgų.

Trečiasis patarimas – sudarykite tikslias saugumą užtikrinančias procedūras, kruopščiai vadovaukitės jomis ir nuolatos jas atnaujinkite. Jei neturite solidžios patirties šioje srityje, visuomet galite kreiptis į kolegas IT įmones.

Galiausiai – pasitarkite su teisininku, nes duomenų valdymas yra didelė atsakomybė. Mūsų įmonė nemažai lėšų skyrė teisinėms konsultacijoms, ir jų pastabos buvo labai vertinga informacija programuotojams, kuriantiems adekvačias saugumo priemones.

Nuolatinis diegimas, nuolatinė integracija

SaaS programuotojai gali leisti sau tai, apie ką tradicinės programinės įrangos gamintojai tik svajodavo – išleisti savo programos atnaujinimus į gamybinę aplinką kelis kartus per dieną. Taigi, jeigu jūsų infrastruktūra sutvarkyta teisingai, tai vos užbaigus naujo funkcionalumo kūrimą, prasidės automatinis procesas: bus sukurta bandomoji programos versija ir duomenys, paleisti integraciniai ir modulių testai, ir sėkmės atveju įdiegiama į prieš-produkcinę aplinką – visa tai be menkiausio žmogaus įsikišimo ir rankų darbo.

Jeigu norite turėti tokią infrastruktūrą (angl. vadinama „continuous delivery“), jums pirmiausia būtini išsamūs automatiniai testai, kurie kiekvieną sykį patikrins esmines produkto funkcijas be žmogaus įsikišimo. Pavyzdžiui, mūsų produkto atveju apie 90% viso programinio kodo eilučių yra padengta bent vienu automatiniu testu, o svarbiausios produkto dalys padengtos ir visu 100%. Tokių testų rašymas ir nuolatinis palaikymas iš tiesų kainuoja, todėl norimą kokybės lygį reikia pasirinkti atsižvelgiant į programos specifiką. Dažnai net ir 10-20% kodo padengiamumo visai pakankama.

Mikroservisai

Mikroservisai (angl. microservices) yra būdas išskaidyti vieną didelę monolitinę programą į kelias mažesnes savarankiškas programas, kurios visos bendradarbiauja tarpusavyje. Pavyzdžiui, Amazon.com puslapio užkrovimas naudoja net 100-150 mikroservisų.

Kiekvienas mikroservisas idealiu atveju turėtų turėti savo paskirtį ir nuosavą duomenų bazę. Pavyzdžiui, mūsų produktas turi tokius mikroservisus: vartotojų autorizacijai, personalo informacijos valdymui, elektroninių atostogų užsakymui, dokumentų cirkuliacijai, sinchronizacijai su išorinėmis sistemomis, audito žurnalams ir t.t.

Išskaidžius monolitinę programą į mikroservisus, geriau išnaudojami duomenų centro pajėgumai, nes kelis mažiau apkrautus mikroservisus galima laikyti viename fiziniame serveryje, o labiau apkrautus – atskiruose. Resursų virtualizacija yra labai svarbi, tikrai rekomenduoju visus sistemos mikroservisus iškelti į Docker virtualias mašinas.

Antra vertus, programuoti paskirstytos architektūros sistemą nėra paprasta. Kaip pastebėjo didieji prancūzų mąstytojai, „didelė galia ateina su didele atsakomybe“.

Apie autorių

Danas Jukna paskutinius 10 metų programuoja dideles, saugias internetines sistemas pasaulinėms finansinėms institucijoms. Pastaruoju metu Danas dirba programinės įrangos architektu HCM.LT– tai, ko gero, moderniausias SaaS personalo valdymo produktas Lietuvos rinkai.

Daugiau mano blogo įrašų galite rasti http://blog.hcm.lt

Norite pasidalinti savo darbais ir pasiekiamais? Rašykite info@technologijos.lt 

Komentarai ()