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ść.

CHMURY – od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług

Temat clo­ud com­pu­ting jest coraz goręt­szy. Z jed­nej stro­ny pod­grze­wa­ją atmos­fe­rę fir­my ofe­ru­ją­ce róż­ne for­my dzier­ża­wy zaso­bów a z dru­giej tech­no­lo­gie i archi­tek­tu­ry zwa­ne chmu­ro­wy­mi”, pro­wa­dzą do sta­le male­ją­cych kosz­tów inte­gra­cji (chmu­ra prywatna).

Tak zwa­ne tech­no­lo­gie webo­we (np. RESTful/REST API itp.) doty­czą­ce inte­gra­cji, powsta­ły co praw­da już nawet w 2000 roku, jed­nak dopie­ro teraz moż­na mówić o dostęp­nych, prze­te­sto­wa­nych biblio­te­kach, czy­nią­cych tego rodza­ju pro­jek­ty tań­szy­mi, np. oma­wia­ne w arty­ku­le Wymagania poza­funk­cjo­nal­ne ? inte­gra­cja” inte­gra­cja z pomo­cą API to dzi­siaj już taki sam koszt jak spa­wa­nie” z pomo­cą SQL, wystar­czy, że zatrud­ni­my kogoś (fir­mę) kto potra­fi, a nie kogoś kto za nasze pie­nią­dze będzie się dopie­ro zwin­nie uczył, skła­da­jąc ofer­tę mimo bra­ku kom­pe­ten­cji. Opór wie­lu firm przed przed tymi roz­wią­za­nia­mi, z moje­go doświad­cze­nia, wyni­ka z: bra­ku wie­dzy i kom­pe­ten­cji (wie­le zna­nych firm IT nadal ope­ru­je meto­da­mi i tech­no­lo­gia­mi z przed nawet 30 lat!), kur­czo­we­go trzy­ma­nia się mode­lu biz­ne­so­we­go dostar­cza­my jeden mono­li­tycz­ny sys­tem”, któ­ry sil­nie uza­leż­nia klien­ta od dostawcy.

No i sto­so­wa­nie metod opar­tych o tak zwa­ne usłu­gi webse­rvis”, wyma­ga cał­ko­wi­te­go odej­ścia od metod struk­tu­ral­nych pro­jek­to­wa­nia (jed­no­li­te bazy danych w mode­lu rela­cyj­nym i ster­ta funk­cji) na rzecz metod obiek­to­wych i kom­po­nen­to­wych (Large sys­tem archi­tec­tu­re).

Znamienne jest to, że gdy np. prze­szu­ka­my Internet pod kątem SOA, zoba­czy­my, iż w ostat­nich kil­ku latach spo­ro publi­ka­cji poświę­co­no odej­ściu od tra­dy­cyj­ne­go spo­so­bu roz­wo­ju sys­te­mów infor­ma­tycz­nych ? od roz­bu­do­wa­nych roz­wią­zań auto­no­micz­nych do struk­tur zło­żo­nych z róż­ne­go rodza­ju roz­pro­szo­nych usług, ukie­run­ko­wa­nych na obsłu­gę wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań. Równolegle, za Oceanem dyna­micz­nie roz­wi­ja się Cloud Computing. Czymże innym jest to zja­wi­sko, jak nie moż­li­wo­ścią dobie­ra­nia do orga­ni­za­cji (infra­struk­tu­ry IT i mode­lu biz­ne­so­we­go) usług, któ­re są nie­zbęd­ne do efek­tyw­niej­szej pra­cy (?do obsłu­gi wybra­nych pro­ce­sów biz­ne­so­wych czy choć­by poje­dyn­czych dzia­łań?). I tak jak w ostat­nich latach szy­ny inte­gra­cyj­ne słu­ży­ły inte­gro­wa­niu wewnętrz­nej infra­struk­tu­ry IT, tak w naj­bliż­szej przy­szło­ści będą się roz­wi­jać do łącze­nia rów­nież zewnętrz­nych usług z Chmury. (INTEGRACJA ROZWIĄZAŃ Z CHMURY TO WYZWANIE?).

Ja pisa­łem o tym już w 2011 roku (Biznes wycho­dzi .…).

Osobiście nie demo­ni­zo­wał bym koniecz­no­ści posia­da­nia szy­ny inte­gra­cyj­nej”, jak auto­rzy cyto­wa­ne­go powy­żej arty­ku­łu (fir­ma TIBCO jest dostaw­cą takie­go pro­duk­tu), jed­nak trend w kie­run­ku rezy­gna­cji z mono­li­tycz­nych apli­ka­cji już się zazna­cza, a to czy taka szy­na” będzie, raczej jest kon­se­kwen­cją archi­tek­tu­ry. Dobrze zapro­jek­to­wa­na archi­tek­tu­ra całe­go sys­te­mu apli­ka­cji (kom­po­nen­tów) to struk­tu­ra hie­rar­chicz­na: tak zwa­ny front end” to apli­ka­cje, któ­rych odpo­wie­dzial­no­ścią jest zarzą­dza­nie pro­ce­sa­mi, prze­pły­wem pra­cy (wpro­wa­dza­nie danych i korzy­sta­nie z nich). Głębiej są dzie­dzi­no­we apli­ka­cje sta­no­wią­ce refe­ren­cyj­ne skła­dy i źró­dła danych. W takiej archi­tek­tu­rze komu­ni­ka­cja (wywo­ła­nia) jest jed­no­stron­na (zawsze mamy jasny podział usłu­go­bior­ca-usłu­go­daw­ca. Szyny inte­gra­cyj­nej, jako dodat­ko­we­go kom­po­nen­tu, wyma­ga­ją skom­pli­ko­wa­ne sys­te­my i raczej doty­czy to więk­szych kor­po­ra­cji, fir­my nasze­go sek­to­ra MSP rzad­ko kiedy.

Internetowe meto­dy inte­gra­cji (np. wspo­mnia­ny REST) to wymia­na pole­ceń i obiek­tów a nie funk­cja vs. baza danych” (patrz wspo­mnia­ny arty­kuł o inte­gra­cji, dzi­wią mnie deve­lo­pe­rzy narze­ka­ją­cy np. na skom­pli­ko­wa­ne mapo­wa­nie obiek­to­wo-rela­cyj­ne”, bo ono nie ma pra­wa być skom­pli­ko­wa­ne, a jeże­li jest, to jest to pierw­szy sygnał, że to zły projekt!).

Tak więc chmu­ry owszem, to chy­ba przy­szłość, bez wni­ka­nia w to czy to chmu­ry publicz­ne czy pry­wat­ne. Autonomiczne, duże sys­te­my ERP? Nie wró­żę im karie­ry, w obec­nej posta­ci mega-apli­ka­cje umrą, odwle­ka­nie tej śmier­ci z pomo­cą per­swa­zyj­nych reklam i kam­pa­nii dużych kor­po­ra­cji i ich sprze­daw­ców, to tyl­ko sztucz­ne prze­dłu­ża­nie życia inwe­sty­cji w duże ERP, przez pro­du­cen­tów tych roz­wią­zań, dawa­nie sobie cza­su na (mam nadzie­ję) ich refak­to­ring. Mamy np. takie kolo­sy jak Google czy Amazon, któ­re poka­zu­ją, że chmu­ro­we, wyso­ce ska­lo­wal­ne archi­tek­tu­ry zaso­bo­we mają sens. Systemy ERP opar­te na rela­cyj­nych bazach danych i ich wewnętrz­na inte­gra­cja poprzez współ­dzie­le­nie danych, nie mają nawet szan­sy z tego skorzystać.

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).

Przepływ pracy w chmurze – czyli cudzy worlkflow

Wczorajsza kon­fe­ren­cja EOIF GigaCon była dla mnie kolej­ną oka­zją do podzie­le­nia się z jej gość­mi, moimi oraz cudzy­mi doświad­cze­nia­mi, cudzy­mi czy­li tymi, któ­rych bywam nie raz świad­kiem. Poproszono mnie o wygło­sze­nie refe­ra­tu na temat sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i kon­se­kwen­cja­mi korzy­sta­nia z nich w tak zwa­nej chmu­rze (clo­ud com­pu­ting). Przy oka­zji, dla porząd­ku i tytu­łem wpro­wa­dze­nia, powie­dzia­łem kil­ka słów o tym, czym w ogó­le tego typu sys­te­my są i jakie są ryzy­ka ich wdrażania.

BPM – czym jest

Krótkie pod­su­mo­wa­nie tego czym jest BPM (Business Process Management). BPM to przede wszyst­kim zarzą­dza­nie, a nie tyl­ko jed­no czy kil­ka zadań połą­czo­nych w logicz­ny ciąg”. BPM to cała dys­cy­pli­na zaj­mu­ją­ca się pod­no­sze­niem efek­tyw­no­ści orga­ni­za­cji poprzez opty­ma­li­za­cję pro­ce­sów w niej zacho­dzą­cych. Proces to coś co zacho­dzi w gra­ni­cach orga­ni­za­cji łącząc ludzi, zaso­by, prze­pływ infor­ma­cji, two­rzy okre­ślo­ną wartość.

Powyżej mamy defi­ni­cję zaczerp­nię­tą ze stron fir­my Gartner, któ­rą uwa­żam, że jed­ną z peł­niej­szych. Dalej mój dia­gram, któ­ry czę­sto pre­zen­tu­ję, obra­zu­ją­cy kom­plet wie­dzy jaką nale­ży posia­dać by móc mówić o tym, że pro­ces został udo­ku­men­to­wa­ny i zro­zu­mia­ny. Są to ogra­ni­cze­nia (pra­wo, wewnętrz­ne regu­ły biz­ne­so­we) oraz wyko­naw­ca pro­ce­su dys­po­nu­ją­cy okre­ślo­na wie­dzą, upraw­nie­nia­mi i narzę­dzia­mi pracy.

Trzeci dia­gram, waż­ny dla zro­zu­mie­nia tego czym jest wspo­ma­ga­nie prze­pły­wu pra­cy i doku­men­tów”, poka­zu­je ogól­na archi­tek­tu­rę opro­gra­mo­wa­nia work­flow”. Oprogramowanie takie skła­da się, naj­ogól­niej rzecz bio­rąc, z repo­zy­to­rium doku­men­tów oraz tak zwa­ne­go sil­ni­ka pro­ce­so­we­go (zarzą­dza pro­ce­sem). Repozytorium to nic inne­go jak archi­wum doku­men­tów elek­tro­nicz­nych. Silnik pro­ce­so­wy to kom­po­nent odpo­wie­dzial­ny za zarzą­dza­nie kolej­no­ścią wyko­ny­wa­nia zadań i ich przy­dzie­la­niem do wła­ści­wych osób. Należy tak­że pamię­tać, że prze­pływ pra­cy w orga­ni­za­cji jest nad­zo­ro­wa­ny postę­pem efek­tów tych prac, te zaś to nic inne­go jak powsta­ją­ce tre­ści (doku­men­ty, tak­że w posta­ci pól róż­nych formularzy).

Tak więc opro­gra­mo­wa­nie nazy­wa­ne work­flow (nie raz docu­ment­flow) to nie to samo co opro­gra­mo­wa­nie wspo­ma­ga­ją­ce BPM. Mam nadzie­ję, że kon­fron­ta­cja defi­ni­cji BPM i archi­tek­tu­ry tych apli­ka­cji, jasno to poka­zu­je. Na co nale­ży uwa­żać? Kilka ele­men­tów, na któ­re war­to zwró­cić uwa­gę w ofer­tach przed wybo­rem rozwiązania:

  1. Aplikacja rekla­mo­wa­na jako obieg fak­tur kosz­to­wych” (wnio­sków urlo­po­wych i innych kon­kret­nych typów doku­men­tów) to naj­praw­do­po­dob­niej pro­ste repo­zy­to­rium z wbu­do­wa­nym sys­te­mem prze­ka­zy­wa­nia dostę­pu do doku­men­tu kolej­nym oso­bom z usta­lo­nej listy. Tego typu apli­ka­cje nada­ją się do zarzą­dza­nia (zatwier­dza­nie i archi­wi­za­cja) np. dowo­da­mi księ­go­wy­mi, bar­dzo praw­do­po­dob­ne, że jed­nak nie pora­dzą sobie, bez duże­go nakła­du pra­cy po stro­nie dostaw­cy, np. z pro­ce­sem obsłu­gi zapy­tań ofer­to­wych czy np. rekla­ma­cji, gdyż tu poza doku­men­tem otrzy­ma­nym z zewnątrz, powsta­ją nowe powią­za­ne doku­men­ty, ich prze­twa­rza­nie może zacho­dzić wie­lo­ma róż­ny­mi dro­ga­mi, a sam moduł repo­zy­to­rium (archi­wum doku­men­tów) naj­czę­ściej nie nada­je się do tego typu zasto­so­wań. Tego typu apli­ka­cje bar­dzo czę­sto, poza moni­to­wa­niem ter­mi­nów, nie pozwa­la­ją na budo­wa­nie roz­bu­do­wa­nych rapor­tów na potrze­by BPM.
  2. Narzędzia do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wbu­do­wa­ne w tego typu opro­gra­mo­wa­nie, pra­wie zawsze mają ogra­ni­cze­nia wyni­ka­ją­ce z archi­tek­tu­ry dane­go opro­gra­mo­wa­nia i zasto­so­wa­nych wewnętrz­nych wzor­ców, czę­sto są to tyl­ko tak zwa­ne maszy­ny sta­no­we”, któ­re pozwa­la­ją jedy­nie na budo­wa­nie pro­ce­sów pole­ga­ją­cych na prze­łą­cza­niu sta­tu­sów kon­kret­nych doku­men­tów (for­mu­la­rzy) w odpo­wie­dzi na defi­nio­wa­ne zda­rze­nia. Stosowanie takie­go narzę­dzia np. na eta­pie ana­li­zy przed-wdro­że­nio­wej, pro­wa­dzi czę­sto do znacz­ne­go ogra­ni­cze­nia zakre­su takiej ana­li­zy, do wie­lu zadań są to narzę­dzia po pro­tu nie­przy­dat­ne. Zastosowanie przed wdro­że­niem (a zale­ca się nawet przed wybo­rem dostaw­cy i roz­wią­za­nia) narzę­dzia do ana­li­zy i mode­lo­wa­nia pro­ce­sów, pozwa­la­ją­ce­go na sko­rzy­sta­nie z wszyst­kich zalet nota­cji np. BPMN (obec­nie prak­tycz­nie już stan­dard w takich pro­jek­tach) pozwa­la oce­nić na ile ogra­ni­cze­nia kon­kret­ne­go opro­gra­mo­wa­nia wpły­ną na utra­tę moż­li­wo­ści zaspo­ko­je­nia wszyst­kich potrzeb organizacji.
  3. Repozytorium doku­men­tów powin­no pozwa­lać na auto­ma­tycz­ne wer­sjo­no­wa­nie doku­men­tów, nie powin­no pozwa­lać na przy­pad­ko­we usu­nię­cie doku­men­tu, powin­no pozwa­lać na budo­wa­nie wie­lu, wła­snych, roz­bu­do­wa­nych sys­te­mów meta­da­nych (cechy doku­men­tów), gdyż jest to stan­dar­do­wy spo­sób na kla­sy­fi­ko­wa­nie doku­men­tów (bez tego np. trud­no je póź­niej wyszu­kać czy pogrupować).
  4. Narzędzie tego typu powin­no pozwa­lać użyt­kow­ni­kom na samo­dziel­ne budo­wa­nie kolej­nych nowych sche­ma­tów pro­ce­sów prze­pły­wu pra­cy bez koniecz­no­ści anga­żo­wa­nia pro­gra­mi­stów. Workflow, jako apli­ka­cja, powin­no być plat­for­mą budo­wy takich prze­pły­wów a nie opro­gra­mo­wa­niem zawie­ra­ją­cym wyłącz­nie zamó­wio­ne” pro­ce­sy. Brak tej cechy, samo­dziel­ne budo­wa­nie kolej­nych prze­pły­wów, to prak­tycz­nie dys­kwa­li­fi­ka­cja narzę­dzia w rozu­mie­niu BPM.

Cloud computing

Regularnie spo­ty­kam defi­ni­cje tego ter­mi­nu, więk­szość z nich bazu­je na róż­nych for­mach out­so­ur­cin­gu. Proponuje defi­ni­cję, któ­ra obec­nie chy­ba naj­traf­niej odda­je to czym jest clo­ud com­pu­ting (prze­twa­rza­nie w chmurze):

Slajd10

Ta uogól­nio­na defi­ni­cja pod­kre­śla, że clo­ud com­pu­ting to przede wszyst­kim pro­sto­ta, wrę­cza auto­ma­ty­za­cja, roz­po­czę­cia i rezy­gna­cji z korzy­sta­nia z zaso­bu. To głów­na, moim zda­niem, cecha odróż­nia­ją­ca chmu­rę” od zna­nych już usług w rodza­ju SaaS (Software as a Service) czy ASP (Application Service Provider). Warto tak­że zwró­cić uwa­gę na to, że z per­spek­ty­wy praw­nej czym innym jest dzier­ża­wa opro­gra­mo­wa­nia” a czym innym jest usłu­ga prze­twa­rza­nia”. Innymi sło­wy czym innym jest wypo­ży­cze­nie od kogoś (dzier­ża­wa) kal­ku­la­to­ra a czym inny­mi pła­ce­nie komuś za wyko­ny­wa­nie obli­czeń, to nie jest to samo. Cloud Computing to czę­sto wła­śnie opła­ta za przetwarzanie.

Ważna rzecz to bez­pie­czeń­stwo. Spotykam się z wie­lo­ma opi­nia­mi praw­ny­mi na temat tego kto prze­twa­rza dane i kie­dy. Samo posia­da­nie danych i mani­pu­lo­wa­nie nimi to ich prze­twa­rza­nie. Jednak prze­twa­rza­nie pli­ku nie musi ozna­czać prze­twa­rza­nia (dostę­pu do) jego tre­ści. Zarządca prze­strze­ni dys­ko­wej nie­wąt­pli­wie prze­twa­rza nasze pli­ki, ale czy aby na pew­no zawsze prze­twa­rza dane w nich zawar­te? Składowanie danych w posta­ci zako­do­wa­nej powo­du­je, że usłu­go­daw­ca prze­twa­rza nasze pli­ki (np. wyko­nu­je ich regu­lar­ne kopie zapa­so­we), ale czy prze­twa­rza zawar­te w tych pli­kach tre­ści? Nie, jeże­li są to więc np. zako­do­wa­ne dane oso­bo­we (typo­we tak zwa­ne wraż­li­we dane) to usłu­go­daw­ca nie prze­twa­rza tych danych (nie ope­ru­je dany­mi osób) a jedy­nie pli­kiem zawie­ra­ją­cym te dane w posta­ci zako­do­wa­nej, więc nie ma on dostę­pu do danych osobowych.

Slajd14

Moim zda­niem, Ci praw­ni­cy, któ­rzy for­su­ją tezę, że dane zako­do­wa­ne tak­że nale­ży trak­to­wać jako dane prze­twa­rza­ne, pró­bu­ją wyka­zać, że fir­ma wywo­żą­ca maku­la­tu­rę powsta­łą w nisz­czar­kach doku­men­tów, prze­twa­rza dane, któ­re tam były zawar­te… Na szczę­ście dla mnie, są tak­że praw­ni­cy zga­dza­ją­cy się ze mną. Problem ten – moim zda­niem – jest efek­tem tego, że sło­wo dane” ozna­cza zarów­no dane cyfro­we jaki­mi są jakie­kol­wiek bity na nośni­kach, jak i treść zro­zu­mia­łą dla czło­wie­ka napi­sa­ną w jakimś języ­ku (źr. słow­nik j.p. PWN):

dane 1. ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach? 2. ?infor­ma­cje prze­twa­rza­ne przez komputer?

gdzie infor­ma­cje prze­twa­rza­ne przez kom­pu­ter” to mię­dzy inny­mi ich cyfro­wa for­ma jaką jest każ­dy plik danych na dys­ku mają­cy nazwę. Tu więk­szość praw­ni­ków, nie mają­ca głę­bo­kiej wie­dzy tech­nicz­nej, myli się trak­tu­jąc uży­te w usta­wach sło­wo dane” lite­ral­nie, zapo­mi­na­jąc, że ma ono nie­ste­ty wię­cej niż jed­no znaczenie.

Na zakończenie

Tak wiec BPM to sfe­ra zarzą­dza­nia orga­ni­za­cją a nie tyl­ko jakieś opro­gra­mo­wa­nie, ono może jedy­nie wspie­rać to zarzą­dza­nie. Zły wybór opro­gra­mo­wa­nia z regu­ły pro­wa­dzi do pogor­sze­nia spraw­no­ści orga­ni­za­cji (przy­kła­dy poda­wał na tej kon­fe­ren­cji Pan Piotr Biernacki), nie raz pro­wa­dzi to do zarzu­ce­nia korzy­sta­nia z tego opro­gra­mo­wa­nia. Dlatego kolej­ność: naj­pierw wybór opro­gra­mo­wa­nia i jego dostaw­cy a potem wdro­że­nie, naj­czę­ściej koń­czy się poraż­ką lub co naj­mniej znacz­nie gor­szy­mi efek­ta­mi niż ocze­ki­wa­ne (obie­ca­ne).

Oprogramowanie work­flow, w tak zwa­nej chmu­rze, ma wie­le zalet, jed­nak ma tak­że poważ­ną wadę: kło­po­tli­wa inte­gra­cja z lokal­ny­mi sys­te­ma­mi (np. ERP) wyni­ka­ją­ca z tego, że doku­men­ty poko­nu­ją zawsze podwój­ną dro­gę od naszej loka­li­za­cji do usłu­go­daw­cy i z powro­tem. W przy­pad­ku małych firm (mała ilość danych) z regu­ły nie sta­no­wi to pro­ble­mu. Dla dużych firm może to być nawet barie­ra nie do poko­na­nia, dla­te­go tak zwa­na chmu­ra pry­wat­na” czy­li lokal­na insta­la­cja może być jedy­nym wyjściem.

Na koniec: zanim zawrze­cie Państwo umo­wę na taką usłu­gę war­to się skon­sul­to­wać z praw­ni­kiem wyspe­cja­li­zo­wa­nym w tego typu usługach.

Cloud Computing we Wrocławiu

Konferencja CloudComputing GigaCon 21 Lutego 2012 we Wrocławiu za mną, śred­nia oce­na za refe­rat 4.42 🙂 (naj­wyż­sza).

O czym była mowa tym razem? Starałem się wska­zać istot­ną jakość” i nowość” jaką wno­si CloudComputing (CC) do pro­ce­su pro­jek­to­wa­nia archi­tek­tu­ry sys­te­mów IT. Zwróciłem tak­że uwa­gę, że samo poję­cie CC, jeże­li ma być czymś nowym na ryn­ku, to nie jest to typo­wy out­so­ur­cing rozu­mia­ny jako dzier­ża­wa zamiast zaku­pu apli­ka­cji. Innymi sło­wy, jeże­li CC ma coś nowe­go ozna­czać to zna­czy, że nie jest to ani ASP ani SaaS, ani inne:

Tak więc jeże­li CC to nie usłu­ga to co? CC to archi­tek­tu­ra, udo­stęp­nia­nie mocy (usług) zaso­bów. CC to kom­po­nen­ty, o któ­re moż­na wzbo­ga­cić posia­da­na apli­ka­cję, tak zwa­ne COTS ([[Commercial of the Shelf]]). W odróż­nie­niu od SaaS, CC to nie licen­cjo­no­wa­nie cze­goś a zle­ca­nie komuś przetwarzania.

Przykładem CC są np. zdal­ne repo­zy­to­ria pli­ków (celo­wo nie pisze dys­ki, np. [[repo­zy­to­ria Amazon A3]]), któ­re prze­cho­wu­ją pli­ki (a raczej jakieś obiek­ty”) albo np. zdal­ne sys­te­my ren­de­ru­ją­ce pli­ki wek­to­ro­we. W pierw­szym przy­pad­ku usłu­ga pole­ga na odda­wa­niu” np. doku­men­tów do porząd­ko­wa­nia i skła­do­wa­nia, w dru­gim nasza apli­ka­cja i sta­cja robo­cza nie musi mieć rzad­ko wyko­rzy­sty­wa­nych i kosz­tow­nych zaso­bów gene­ro­wa­nia wizu­li­za­cji. Plik wek­to­ro­wy jest wysy­ła­ny do [[ren­de­rin­gu]] i zwra­ca­ny jest obraz ([[bit­ma­pa]]) o wiel­ko­ści kil­ku mb.

Od stro­ny archi­tek­tu­ry sys­te­mu wyglą­da to tak (dia­gram w kon­wen­cji archi­tek­tu­ry kor­po­ra­cyj­nej, uży­to nota­cji ArchiMate):

Podstawową róż­ni­ca pomię­dzy CC a SaaS jest to, że opro­gra­mo­wa­nie SaaS to po por­tu zdal­ny dostęp do apli­ka­cji: użyt­kow­nik otrzy­mu­je adres w sie­ci ([[URL]]), login i hasło dostę­pu. W przy­pad­ku CC, użyt­kow­nik nie widzi nic, poza ewen­tu­al­nie nową opcją w apli­ka­cji, któ­rej uży­wa (np. poja­wi się pole­ce­nie Renderuj w pro­gra­mie do two­rze­nia gra­fi­ki wek­to­ro­wej). Gdyby cho­dzi­ło o zewnętrz­ne skła­do­wa­nie pli­ków, zapew­ne tego nie zoba­czy. Po pro­stu admi­ni­stra­to­ra prze­łą­czy” nasze opro­gra­mo­wa­nie (naszą sta­cję robo­czą) do inne­go, zdal­ne­go, sys­te­mu skła­do­wa­nia plików.

Na koniec cie­ka­wost­ka, o któ­rej wspo­mi­nam od kil­ku lat: mono­li­tycz­ne sys­tem ERP odcho­dzą. Bronią się strasz­nie 😉 ale moim zda­niem model mono­li­tycz­nych pakie­tów zin­te­gro­wa­nych odcho­dzi powo­li do lamu­sa z uwgai na ocię­ża­łość takich sys­te­mów. Bo…

Ta wyma­ga­na ela­stycz­ność ma swo­je sil­ne podłoże:

(kom­plet­na pre­zen­ta­cja do refe­ra­tu – 16 slaj­dów – do pobra­nia poniżej)