Repozytorium w chmurze – NoSQL

Wprowadzenie

Coraz czę­ściej czy­ta­my o śro­do­wi­skach chmu­ro­wych” (nadal nie mogę się prze­ko­nać do pisa­nia tego bez cudzy­sło­wu). Nawet tak zaawan­so­wa­ne jak Amazon WS czy AZURE, są nadal bar­dzo czę­sto wyko­rzy­sty­wa­ne tyl­ko jako hosting apli­ka­cji. Oba te ser­wi­sy moż­na wyko­rzy­sty­wać jako sie­cio­wy dysk, śro­do­wi­sko sys­te­mo­we (Windows, Linux), bazę danych SQL, ale tak­że jako bazy NoSQL. 

Jednym z naj­istot­niej­szych ele­men­tów sys­te­mów infor­ma­cyj­nych (patrz: infor­ma­tion scien­ce) jest utrwa­la­nie danych (pamię­taj­my, że dane to zapi­sy, a infor­ma­cja to to, co rozu­mie czło­wiek, któ­ry je czy­ta). Niedawno nawią­zy­wa­łem do pro­ble­mu utrwa­la­nia danych.

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! (źr.: Dokument a kumu­la­cja fak­tów: OOAD i model dzie­dzi­ny sys­te­mu) Prosty dia­gram po lewej stro­nie poka­zu­je pro­blem opi­sa­ny przez Smith’a jako Computers, Models, and the Embedding World, The Limits of Correctness.” 

Komputer (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram) sta­no­wi dla czło­wie­ka narzę­dzie pracy. 

Cechą kom­pu­te­ra jest w ogrom­nej więk­szo­ści przy­pad­ków odwzo­ro­wy­wa­nie tego co zastę­pu­je­my kom­pu­te­rem, a tak zwa­ne sys­te­my biz­ne­so­we, zastę­pu­ją papie­ro­we for­my prze­twa­rza­nia i prze­cho­wy­wa­nia infor­ma­cji. Systemy ERP, CRM, Workflow, Sklepy inter­ne­to­we, Archiwa, i wie­le innych to tak na praw­dę doku­men­ty i ich treść. 

Istota pro­ble­mu pole­ga na tym, że okre­ślo­ne, dostęp­ne tech­no­lo­gie same z sie­bie czę­sto stwa­rza­ją ogra­ni­cze­nia tego co mogą (potra­fią) odwzo­ro­wać, i mimo upły­wu cza­su i postę­pu tech­no­lo­gii, ana­li­za i pro­jek­to­wa­nie zarzą­dza­nia infor­ma­cją nadal jest jed­nym z naj­więk­szych pro­ble­mów wdro­żeń systemów. 

SQL vs. NoSQL

SQL

Skrót NoSQL jest inte­pre­to­wa­ny jako nie SQL” lub nie tyl­ko SQL” (Not only SQL). SQL (Structured Query Language) to język zapy­tań do baz danych o rela­cyj­nym mode­lu danych (ang. RDBMS: Relational Data Base Management System). Cechą tego mode­lu danych jest usu­wa­nie redun­dan­cji i podział danych na tabe­le i słow­ni­ki pól tych tabel, oraz związ­ki mię­dzy nimi (rela­cje). W efek­cie otrzy­mu­je­my sche­ma­ty tabel i rela­cji mię­dzy nimi np. takie:

A nawet takie:

(model danych pew­ne­go sys­te­mu ERP)

Odtworzenie doku­men­tu (for­mu­la­rza) będą­ce­go np. fak­tu­rą lub dekla­ra­cją podat­ko­wą, wyma­ga wyko­na­nia sze­re­gu bar­dzo skom­pli­ko­wa­nych ope­ra­cji łącze­nia danych z tych tabel i odwzo­ro­wa­nia ich pier­wot­nej posta­ci np. fak­tu­ry. W tego typu bazach danych fizycz­nie nie ma żad­nych dokumentów. 

Drugim pro­ble­mem jaki stwa­rza model rela­cyj­ny, jest koniecz­ność jego prze­bu­do­wy prak­tycz­nie zawsze, gdy zmie­ni się struk­tu­ra prze­cho­wy­wa­nych w nim doku­men­tów (opra­co­wa­nie nowe­go mode­lu, migra­cja danych do nowe­go mode­lu – bywa że nie­moż­li­wa w 100%, aktu­ali­za­cja zapy­tań SQL do nowej struk­tu­ry bazy danych). 

Biorąc pod uwa­gę fakt, że real­ny świat to cią­głe zmia­ny, model rela­cyj­ny jest w tym przy­pad­ku po pro­stu nieadekwatny. 

Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów zarza­dza­nia dany­mi (i apli­ka­cja­mi, któ­re je wyko­rzy­stu­ją) w mode­lu rela­cyj­nym, są wie­lo­krot­nie wyż­sze niż pier­wot­ne ich wdro­że­nie .

Po co więc wymy­ślo­no te rela­cyj­ne bazy? To były cza­sy gdy pamięć była naj­kosz­tow­niej­szym zaso­bem kom­pu­te­ra zaś dane mię­dzy sys­te­ma­mi w zasa­dzie nie były wymie­nia­ne! Było kil­ka zalet, np. brak błę­dów nazew­nic­twa itp. wię­cej o nich w sie­ci moż­na poczy­tać, jed­nak moim zda­niem baza danych będą­ca imple­men­ta­cją tak zwa­nych związ­ków poję­cio­wych (tym są rela­cyj­ne mode­le danych) nie spraw­dza się bo nie mode­lu­je obiek­tów świa­ta rze­czy­wi­ste­go a jedy­nie ich nazwy i powią­za­nia mię­dzy nimi a to ogrom­na róż­ni­ca. (źr.: SQL albo NoSQL, oto jest pyta­nie – 2011 r.)

NoSQL

Jednym z typo­wych przy­kła­dów bazy danych typu NoSQL są bazy typu key-value i ich odmia­ny . Z uwa­gi na ich cechy i powszech­ność sku­pię się na tego typu bazach. 

Wśród tego typu baz są tak zwa­ne bazy doku­men­to­we. Idea tego typu baz danych reali­zu­je jed­no pod­sta­wo­wych zało­żeń obiek­to­we­go para­dyg­ma­tu (role obiek­tów): repo­zy­to­rium nie słu­ży do prze­twa­rza­nia tre­ści a jedy­nie do jej utrwa­la­nia i szyb­kie­go przy­wo­ły­wa­nia (dostę­pu). Przetwarzaniem danych (tre­ści) zaj­mu­ją kom­po­nen­ty odpo­wie­dzial­ne wyłącz­nie za reali­za­cję logi­ki apli­ka­cji. Skoro repo­zy­to­rium nie prze­twa­rza tre­ści, jest ono – prze­cho­wy­wa­na treść i jej struk­tu­ra – neu­tral­nym ele­men­tem. Dlatego ope­ru­je­my tu czę­sto poję­ciem plik, któ­rym zależ­nie od typu bazy, może być np. ciąg zna­ków XML lub JSON albo po pro­stu ciąg binar­ny (czy­li cokol­wiek”). Taka baza to hipo­te­tycz­ne dwie kolum­ny: pierw­sza zawie­ra iden­ty­fi­ka­to­ry wier­szy a dru­ga prze­cho­wy­wa­ną treść. I teraz zależ­nie od typu bazy i logi­ki apli­ka­cji, któ­ra ją wyko­rzy­stu­je, tą tre­ścią może by ciąg zna­ków (np. XML, JSON) lub dowol­ny ciąg zna­ków binar­ny (czy­li XML tak­że, ale tak­że np. zdję­cie lub plik edy­to­ra tekstów). 

Przykładem bazy doku­men­to­wej jest Amazon DynamoDB. Poniższy dia­gram poka­zu­je w uprosz­cze­niu idee tej bazy i porów­na­nie z typo­wą mode­lem rela­cyj­nym: odtwo­rze­nie doku­men­tu z bazy rela­cyj­nej (po lewej) wyma­ga skom­pli­ko­wa­nych ope­ra­cji łącze­nia tabel, po pra­wej stro­nie mamy zaś zestaw cią­gów zna­ków, każ­dy sta­no­wi sobą kom­plet­ny już doku­ment, mogą one mieć róż­ną struk­tu­rę. Pobranie doku­men­tu z bazy po pra­wej odby­wa się zawsze pro­stym zapy­ta­niem, takim samym„ bez wzglę­du na struk­tu­rę tych danych. 

Dzięki temu osią­ga­my dwie klu­czo­we korzy­ści: zmie­nia­ją­ca się w cza­sie struk­tu­ra doku­men­tów nie wpły­wa na bazę danych, czas pobra­nia doku­men­tu jest bar­dzo krót­ki i nie zale­ży od struk­tu­ry doku­men­tu . Różnicę efek­tyw­no­ści poka­za­no poniżej:



Dokument jako struktura danych

Opisane bazy NoSQL mają sze­reg zalet w sto­sun­ku do baz danych w mode­lu rela­cyj­nym. Jednak pro­blem two­rze­nia mode­li rela­cyj­nych jest zastę­po­wa­ny pro­ble­mem mode­lo­wa­nia struk­tur doku­men­tów . Nie jest to jed­nak pro­blem budo­wa­nia znor­ma­li­zo­wa­nych rela­cyj­nych struk­tur danych. Jest to pro­blem natu­ry czy­sto seman­tycz­nej: rzecz w tym czym jest doku­ment i czym są pola, z któ­rych on się skła­da. Jest wie­le podejść do tego zagad­nie­nia, uwa­żam, że klu­czo­we jest odkry­cie i zro­zu­mie­nie co opi­su­je dany doku­ment. Po dru­gie istot­ne jest umie­jęt­ne zapro­jek­to­wa­nie logi­ki apli­ka­cji. Dlatego repo­zy­to­ria NoSQL z zasa­dy nie bio­rą udzia­łu w logi­ce biz­ne­so­wej ale struk­tu­ra doku­men­tów deter­mi­nu­je logi­kę ich prze­twa­rza­nia. Rolą repo­zy­to­rium jest wyłącz­nie utrwa­la­nie i udo­stęp­nia­nie. Poniżej przy­kład dość typo­wy: fak­tu­ry i opi­sy pro­duk­tów (opis pro­duk­tu jako Karta Produktu): mimo tego, że oba te typy doku­men­tów mają inną struk­tu­rę, mogą być prze­cho­wy­wa­ne w jed­nej i tej samej bazie danych NoSQL. 

Rejestry sepa­ru­ją­ce doku­men­to­wą bazę danych od logi­ki apli­ka­cyj­nej, dia­gram pocho­dzi z wyda­nej wła­śnie publi­ka­cji, w któ­rej dokład­nie opi­sa­no zasa­dy pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych i tego typu repo­zy­to­riów: .

Baza doku­men­to­wa słu­ży wyłącz­nie do prze­cho­wy­wa­nia danych. Kontekstowy i seman­tycz­ny dostęp do danych zapew­nia­ją dzie­dzi­no­we reje­stry: dodat­ko­we pro­ste tabe­le umiesz­czo­ne przez repo­zy­to­rium, w czę­ści apli­ka­cyj­nej. Z uwa­gi na to, że bazy doku­men­to­we nie nada­ją się do reali­za­cji wyra­fi­no­wa­nych zbio­ro­wych obli­czeń na tre­ści doku­men­tów, wyko­rzy­stu­je się do tego typo­we hur­tow­nie danych. 

[uzu­peł­nie­nie mie­siąc póź­niej] Z tego wzglę­du bar­dzo przy­dat­ny jest tu dobrze zna­ny wzo­rzec pro­jek­to­wy Repozytorium (Repository). Istotą tego wzor­ca jest sepa­ra­cja kolek­cji obiek­tów (np. nośni­ków doku­men­tów) od logi­ki apli­ka­cji za pomo­cą kla­sy reali­zu­ją­cej inter­fejs do tej kolek­cji. Poniżej wer­sja adre­so­wa­na do chmury:

Realizacja utrwa­la­nia (zapis danych) to obiek­ty prze­cho­wu­ją­ce («Storage» Repozytorium danych) oraz dane («docu­ment» Zestaw danych) prze­cho­wy­wa­ne jako doku­men­ty (XML, JSON) lub pli­ki (baza key value). Dostęp do tej kolek­cji zapew­nia kla­sa «Management» Kontrola dostę­pu do danych, sta­no­wią­ca zara­zem inter­fejs do tej kolek­cji. Interfejsów do jed­ne­go repo­zy­to­rium może być wię­cej, reali­zu­ją one wte­dy kon­tek­sto­we udo­stęp­nia­nie danych z tej samej kolek­cji. Tak więc Realizacja usłu­gi to dzie­dzi­no­wy kod apli­ka­cji, zaś Realizacja utrwa­la­nia to chmu­ro­wa usłu­ga taka jak bazy NoSQL dostęp­ne w chmurze. 

Chmury Amazon i AZURE

Ciekawym przy­kła­dem bazy doku­men­to­wej jest DynamoDB. Jest to par­ty­cjo­no­wa­na baza NoSQL mają­ca dwie kolum­ny z klu­czem: jeden to stan­dar­do­wy dla tego typu bazy iden­ty­fi­ka­tor, dru­gi to klucz wska­zu­ją­cy na struk­tu­rę defi­niu­ją­cą for­mat danych w trze­ciej kolum­nie prze­cho­wu­ją­cej dane (doku­men­ty). Jest to baza prze­cho­wu­ją­ca dane w for­ma­cie JSON, więc ich inter­pre­ta­cja wyma­ga defi­ni­cji kon­kret­nej struk­tu­ry danych. dodat­ko­wa kolum­na (SortKey) peł­ni rolę defi­ni­cji typu (iden­ty­fi­ka­tor struk­tu­ry). Jest to wygod­ne bo w sys­te­mach obiek­to­wych łatwo defi­niu­je się typy zło­żo­ne, nada­jąc każ­de­mu rekor­do­wi dodat­ko­wy iden­ty­fi­ka­tor, moż­na inte­pre­to­wać pobra­ne dane. 

(https://​aws​.ama​zon​.com/​b​l​o​g​s​/​d​a​t​a​b​a​s​e​/​c​h​o​o​s​i​n​g​-​t​h​e​-​r​i​g​h​t​-​d​y​n​a​m​o​d​b​-​p​a​r​t​i​t​i​o​n​-​k​ey/)

Więcej infor­ma­cji o repo­zy­to­riach Amazon, tak­że Amazon S3 (bar­dzo szyb­ka baza pli­ków) znaj­dzie­cie w książ­ce wydaw­nic­twa Helion: Amazon Web Services . Analogiczne roz­wią­za­nie ofe­ru­je AZURE.

Na zakończenie

Osobiście pole­cam roz­wa­że­nie opi­sa­nych tu roz­wią­zań w swo­ich pro­jek­tach. W obsza­rze doku­men­tów i zarzą­dza­nia ich tre­ścią są wręcz dosko­na­łe. Model rela­cyj­ny, dosko­na­ły do obli­czeń, nie­ste­ty prze­gry­wa z kre­te­sem w apli­ka­cjach biz­ne­so­wych, gdzie zaczy­na się liczyć przede wszyst­kim szyb­kość dostę­pu do ogrom­nej ilo­ści danych oraz odpor­ność na szyb­ko zmie­nia­ją­ce się wyma­ga­nia co do struk­tu­ry danych.

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation.

C.d. czy­taj Bazy NoSQL jako imple­men­ta­cje wzor­ców struk­tur infor­ma­cji.

Źródła

Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Wilkins, M. (2020). Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS (J. Zatorska, Trans.). Helion SA.
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Chmura wykończy wdrożenia ?on-premises?. Ich śmierć ma być powolna…

Niedawno prze­czy­ta­łem, że:

Chmura obli­cze­nio­wa sztur­mem zdo­by­wa rynek IT. Liczba wdro­żeń opro­gra­mo­wa­nia w mode­lu SaaS rośnie w tem­pie 20,1 proc. rdr ? poda­ją ana­li­ty­cy z fir­my Gartner. Na naszych oczach odby­wa się rewo­lu­cja, któ­rej naj­więk­szą ofia­rą jest opro­gra­mo­wa­nie insta­lo­wa­ne na wła­snej, fir­mo­wej infra­struk­tu­rze. Agonię wdro­żeń ?on-pre­mi­ses? wie­ści Eric Kimberling, part­ner zarzą­dza­ją­cy w fir­mie dorad­czej Panorama Consulting. Jego zda­niem chmu­ra obli­cze­nio­wa posia­da tak wie­le zalet, że porzu­ce­nie przez przed­się­bior­stwa roz­wią­zań sta­cjo­nar­nych jest jedy­nie kwe­stią czasu.”

Źródło: Chmura wykoń­czy wdro­że­nia ?on-pre­mi­ses?. Ich śmierć ma być powol­na, ale defi­ni­tyw­na ? Fintek​.pl

Po pierw­sze: to, że dzi­siaj rośnie 20,1% rdr nie zna­czy (ehh, ta wia­ra w tren­dy..), że tak będzie zawsze. Po dru­gie, nie tyl­ko z uwa­gi na pra­wa autor­skie i ochro­nę know-how, zawsze będzie kla­sa sys­te­mów, któ­re w chmu­rze nigdy nie wylą­du­ją. Ten arty­kuł w moich oczach, to kla­sy­ka PR-owców two­rzą­ca sztucz­ną rze­czy­wi­stość w mediach i tak zwa­ne samo­speł­nia­ją­ce się prze­po­wied­nie”, bazu­ją­ce w 100% na kon­for­mi­zmie czy­tel­ni­ków takich prognoz.

Swego cza­su, 2016 rok, mia­łem refe­rat na kon­fe­ren­cji doty­czą­cej archi­tek­tu­ry w chmu­rze. Kilka tez, któ­re pomo­gą oce­nić wróż­by upad­ku wdro­żeń u siebie”.

Każdy pro­jekt wdro­że­nio­we ma dwa klu­czo­we, oczy­wi­ste, para­me­try: czas wdro­że­nia i łącz­ny koszt (pozy­ska­nie i posia­da­nie – utrzy­ma­nie). Jednak w dobie zmien­no­ści ryn­ku jaką mamy obec­nie, war­to brać pod uwa­gę tak­że ryzy­ko tego, że zmie­ni­my decy­zję bo zmie­ni­ły się warun­ki. Dlatego poja­wia się para­metr jakim jest czas wyj­ścia z inwe­sty­cji, co sta­je się coraz waż­niej­szym para­me­trem, z uwa­gi na ryzy­ko takich wdro­żeń i ryzy­ko wyni­ka­ją­ce ze zmien­no­ści rynku.

Co wiemy o wdrożeniach?

Pomijając, deta­licz­ne kwo­ty, wła­sna insta­la­cja jest naj­tań­sza w utrzy­ma­niu jed­nak trze­ba ponieść rela­tyw­nie duże kosz­ty pozy­ska­nia i wdro­że­nia. Na prze­ciw­nym koń­cu jest typo­wa insta­la­cja w tak zwa­nej chmu­rze, któ­ra nie wyma­ga prak­tycz­nie żad­ne­go okre­su roz­ru­chu”. Po środ­ku jest out­so­ur­cing, któ­ry ma niż­sze kosz­ty ini­cja­cji w porów­na­niu z insta­la­cją na wła­ność, ale wyż­sze kosz­ty utrzy­ma­nia (mar­ża na zaso­by ludzkie).

Na tym tle mamy typo­we, dla obec­ne­go ryn­ku, wyma­ga­nia biznesowe:

Nazwałem je impli­ku­ją­ce zasto­so­wa­nie chmu­ry”, bo jak widać są to dość typo­we wyma­ga­nia w dobie szyb­kiej zmien­no­ści oto­cze­nia ryn­ko­we­go. Jednak jest pewien haczyk: wszyst­ko w chmu­rze to naj­kosz­tow­niej­sza w utrzy­ma­niu wer­sja. Dlatego fir­my, po usta­le­niu tego co jest tak­ty­ką a co stra­te­gią, powin­ny roz­wa­żyć decy­zję: odpo­wied­nio co powin­no dać się szyb­ko zmie­nić, a co będzie jed­nak sta­łym zaso­bem. Zasoby uzna­ne za sta­łe bez­piecz­nie (jako inwe­sty­cje) moż­na pozy­skać na wła­sność co w dłuż­szej per­spek­ty­wie daje odczu­wal­ne oszczęd­no­ści. Tam gdzie ryzy­ko zmia­ny jest zbyt duże, pono­si­my wyż­sze kosz­ty chmu­ry ale rekom­pen­su­je­my sobie to tym, że kosz­ty wyj­ścia z takiej inwe­sty­cji są bli­skie zera.

Na zakoń­cze­nie kil­ka słów o archi­tek­tu­rze. Warto pamię­tać, że – pomi­ja­jąc pro­por­cje – każ­da fir­ma ma opro­gra­mo­wa­nie u sie­bie i może mieć w chmu­rze, w efek­cie ich inte­gra­cja zawsze wyma­ga, by podej­mo­wa­nie decy­zji o korzy­sta­niu z chmu­ry, było w peł­ni świa­do­me. Każda decy­zja archi­tek­to­nicz­na na swo­je konsekwencje.

Dlatego, moim zda­niem, nie gro­zi nam jed­nak nigdy cał­ko­wi­ta rezy­gna­cja z opro­gra­mo­wa­nia na własność.

złodziej

Backup – chmura czy u siebie?

W ubie­głym tygo­dniu mia­ła miej­sce kon­fe­ren­cja, na któ­rej zapo­wia­da­łem swój refe­rat. Niestety z powo­dów zdro­wot­nych nie mogłem się poja­wić na tej kon­fe­ren­cji (za co bar­dzo prze­pra­szam, wszyst­kich na tej kon­fe­ren­cji i tych któ­rzy zakła­da­li, że mnie na niej spotkają).

Postanowiłem jed­nak podzie­lić się tu jed­nym z wąt­ków moje­go refe­ra­tu, a mia­no­wi­cie jed­ny­mi z częst­szych przy­czyn: oce­ny ryzy­ka i kosz­tów kopii zapa­so­wych in house” (lokal­nie we wła­snej fir­mie) i w chmu­rze (kopia zapa­so­wa jako usłu­ga dostęp­na zdal­nie na cudzej infrastrukturze).

Najczęściej pod­no­szo­ne róż­ni­ce pomię­dzy wyko­ny­wa­niem i prze­trzy­my­wa­niem kopii zapa­so­wych lokal­nie i w chmurze:

Slajd8

Porównanie kosz­tów (linia czer­wo­na to kosz­ty wdrożenia):

Slajd7

Biorąc pod uwa­gę fakt, że kopie zapa­so­we to raczej dłu­go­ter­mi­no­we inwe­sty­cje, powyż­sze skła­nia do tezy, by mieć swo­je”, jed­nak jed­nym z ryzyk jest kra­dzież lub pożar. Zasoby w chmu­rze” są jed­nak w dłu­giej per­spek­ty­wie najkosztowniejsze.

To tyl­ko mały frag­ment moje­go refe­ra­tu jed­nak chcia­łem się podzie­lić pew­nym pomy­słem, któ­ry poja­wił się nie­daw­no na ryn­ku. Skoro klu­czo­we ryzy­ka to:

Slajd11

System bac­kup odpor­ny na kra­dzież i pożar i mimo to u siebie”

Na ryn­ku poja­wi­ło się cie­ka­we roz­wią­za­nie: WOOXO. System mamy u sie­bie”, więc mamy do dys­po­zy­cji wła­sną admi­ni­stra­cję i brak ogra­ni­cze­nia na prze­pu­sto­wość łączą (nie pła­ci­my dodat­ko­wo za usłu­gę, mamy do dys­po­zy­cji pasmo sie­ci lokal­nej). Warto tak­że pamię­tać, że wyko­ny­wa­nie kopii zapa­so­wych lokal­nie uwal­nia od wie­lu pro­ble­mów praw­nych (np. dane oso­bo­we) jak i czy­sto stra­te­gicz­nych (dostęp do danych sta­no­wią­cych tajem­ni­ce przedsiębiorstwa).

Z co z kra­dzie­żą i poża­rem? Urządzenie wytrzy­mu­je: pożar (843 st. Celsjusza przez 30 minut), moco­wa­nie do pod­ło­ża wytrzy­mu­je 4 tony cią­gu (co na to zło­dzie­je?:)). Wytrzymuje tak­że 8 godz. pod wodą (głę­bo­kość 60 cm) i upa­dek z 9 metrów. Oprogramowanie urzą­dze­nia zapew­nia bar­dzo duży poziom auto­ma­ty­za­cji i kom­pa­ty­bil­no­ści (stan­da­ry­za­cja), róż­ne mode­le archi­tek­tu­ry pra­cy w sie­ci (tak­że chmu­ra, w tym pry­wat­na). (źr. infor­ma­cji o WOOXO: przed­sta­wi­ciel pro­du­cen­ta: Łukasz Wróblewski, stro­na pro­du­cen­ta: WOOXO).