Amazon Web Services: podstawy korzystania z chmury AWS

W tym roku uka­za­ła się książ­ka, któ­rej auto­rem jest Mark Wilkins: Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS :

Książka spra­wia wra­że­nie bar­dzo tech­nicz­nej, ale pisa­na jest jasnym języ­kiem i boga­to ilu­stro­wa­na. Na 464 stro­nach opi­sa­no usłu­gi chmu­ro­we ofe­ro­wa­ne przez Amazon. Autor na szczę­ście nie miał ambi­cji zastą­pie­nia swo­ją książ­ką ory­gi­nal­nej doku­men­ta­cji, nasta­wił się (moim zda­niem) na wyja­śnie­nie mecha­ni­zmów dzia­ła­nia poszcze­gól­nych usług i to wła­śnie wzbu­dzi­ło moją sym­pa­tię do auto­ra. Jeżeli po książ­kę się­gną deve­lo­pe­rzy to pew­nie dla­te­go, że ją po pro­stu zna­leź­li w toku zawo­do­wych poszukiwań. 

Ja pole­cam tę książ­kę archi­tek­tom bo pozwa­la zro­zu­mieć to co robią deve­lo­pe­rzy. Polecam ją tak­że ana­li­ty­kom, któ­rzy w zasa­dzie tak­że są archi­tek­ta­mi, co mecha­ni­zmów biz­ne­so­wych apli­ka­cji ale jed­nak to tak­że już archi­tek­tu­ra. Analitycy pew­nie nie małą część tej książ­ki prze­wi­ną jak taśmę fil­mu z wese­la przy­ja­ciół, jed­nak począt­ko­we roz­dzia­ły opi­su­ją­ce ogól­nie te usłu­gi, oraz te doty­czą­ce maga­zy­no­wa­nia danych, są bar­dzo poucza­ją­ce. To ostat­nie pole­cam szcze­gól­nie tym z Was, któ­rzy nadal są wyznaw­ca­mi reli­gii SQL/relacyjnej … Dowiedzą się paru cie­ka­wych rze­czy 🙂 o bazach NoSQL. 

Źródła

Wilkins, M. (2020). Amazon Web Services: pod­sta­wy korzy­sta­nia z chmu­ry AWS (J. Zatorska, Trans.). Helion SA.

UML for Java programmers

Tym razem książ­ka dla pro­gra­mi­stów (autor książ­ki jest zna­ny w sie­ci jako Uncle Bob). Długo się nad nią zasta­na­wia­łem ale w koń­cu kupi­łem i nie żału­ję mimo, że napi­sa­na ponad deka­dę temu. Po pierw­sze jako pro­jek­tant muszę (no powi­nie­nem ;)) znać ogra­ni­cze­nia oraz spe­cy­fi­kę narzę­dzia (Java). Po dru­gie jako ana­li­tyk, nie raz spra­wu­ją­cy nad­zór autor­ski nad deve­lo­pe­rem, muszę (no powi­nie­nem ;)) mieć z tymi ludź­mi wspól­ny język.

Książka dosko­na­le poka­zu­je to co zawsze mówię na szko­le­niach: UML jako nota­cja jest nad­mia­ro­wa i nie wol­no o tym zapo­mi­nać (cza­sem mam wra­że­nie, że auto­rzy wie­lu dia­gra­mów, jako zada­nie, posta­wi­li sobie uży­cie za wszel­ka cenę wszyst­kich sym­bo­li UML jakie są dostępne).

UMLforJavaProgrammersDocsCartoon

Jednym z naj­bar­dziej (po dia­gra­mie klas) nad­uży­wa­nym jest dia­gram przy­pad­ków uży­cia. Na każ­dym szko­le­niu zawsze mówię: to ma być pro­sty dia­gram, wszel­kie extends, inc­lu­de, dzie­dzi­cze­nie to dzi­siaj beł­kot UMLowy (te związ­ki powsta­ły w latach 90-tych, gdy dia­gram UC był samo­dziel­nym two­rem, nie zna­ją­cym dia­gra­mów klas czy komponentów… ).

UMLforJavaProgrammersUseCases

Po dru­gie kolej­na waż­na rzecz: w toku pro­ce­su two­rze­nia opro­gra­mo­wa­nia powsta­ją mode­le poję­cio­we (tak con­cep­tu­al zna­czy poję­cio­wy a nie kon­cep­tu­al­ny czy kon­cep­cyj­ny!), spe­cy­fi­ka­cyj­ne i imple­men­ta­cyj­ne. Autor książ­ki opi­su­je dwa ostat­nie, w koń­cu to książ­ka dla pro­gra­mi­stów, ale nie zaka­za­na dla ana­li­ty­ków. Od sie­bie dodam, że w ramach ana­liz wyma­gań powsta­ją mode­le poję­cio­we i (nie raz uprosz­czo­ne) specyfikacyjne.

Po co modelować?

UMLforJavaProgrammersWhyModel

Gorąco pole­cam pro­gra­mi­stom, by w ogó­le zaczę­li korzy­stać z UML a ana­li­ty­kom, by wyle­czy­li się z wie­lu mitów o UML roz­po­wszech­nia­nych nie­ste­ty na wie­lu, nie zawsze tanich, szko­le­niach i w wie­lu kiep­skich porad­ni­kach UML” (pisa­nych nie raz nawet przez uczel­nia­nych dok­to­rów i nie tyl­ko).…. Może wte­dy prze­sta­ną two­rzyć nie­przy­dat­ne deve­lo­pe­rom dokumentacje. 

Poniżej tak­że – o dzi­wo jest dostęp­na – wer­sja pdf do pobrania.

UML for Java Programmers, June 6, 2003 by Robert C. Martin (Author): papie­ro­we wyda­nie na Amazoniedo pobra­nia pdf (pobież­ne przej­rze­nie wer­sji pdf wska­zu­je że jest trosz­kę uboższa)

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