Książki/Materiały/Strony o rozwiązaniach architekturalnych systemów informatycznych

[Przemek Lewandowski]

Witam wszystkich :)

Mam takie pytanie, czy ktos zna jakieś zasoby na temat rozwiązan architekturalnych systemów informatycznych ?

Wiem ze to zazwyczaj jest indywidualne, ale może komuś cos sie obiło o uszy :)

Tutaj Pan ładnie mówi jak mozna zrownoleglic poszczegolne elementy systemu :) za pomocą wzorca Disruptor.

https://www.youtube.com/watch?v=DCdGlxBbKU4

I wymienia na przyklad Journaling, Replication (swoja drogą ciekawe po co jest replikacja).

PS. Czym zajmuje sie Architekt Systemu i jakie wiadomości powinna mieć taka osoba jesli chodzi o szukanie pracy ?

pozdrawiam

[Piotr Zajaczkowski]

Siema,

Na przykład:

Wzorce SOA - http://helion.pl/ksiazki/wzorce-soa-arnon-rotem-gal-oz,wzosoa.htm

Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe. - http://helion.pl/ksiazki/architektura-systemow-zarzadzania-przedsiebiorstwem-wzorce-projektowe-martin-fowler,szabko.htm (to jest klasyk)

Java EE. Zaawansowane wzorce projektowe. - http://helion.pl/ksiazki/java-ee-zaawansowane-wzorce-projektowe-murat-yener-alex-theedom,javeez.htm (tu co prawda są omówione głównie "zwykłe" wzorce, ale w kontekście użycia w aplikacjach korpo)

Wg mnie wymagana wiedza to:

- najlepsze praktyki stosowane w różnych rozwiązaniach

- wpływ rozwiązań na wydajność

- umiejętność przewidywania problemów technologicznych przy wzroście obciążenia

- umiejętność zaprojektowania systemu tak, aby był skalowalny (bo biznes lubi zmieniać zdanie ;) )

Ogólnie to poczytaj o mikrousługach, bo są ostatnio bardzo popularne. Ale bardzo łatwo z nimi o problemy, jeśli się źle podejdzie do problemu ;)

Na YouTube są też nagrania z wystąpień ludzi z Allegro o ich ewolucji - od monolitycznego molocha do mikrousług. Też polecam.

Pozdrawiam,

P.

--
--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Zakaz umieszczania ofert pracy, do tego celu służy oddzielna grupa, więcej na http://warszawa.jug.pl/#/cooperation
---
Otrzymujesz tę wiadomość, bo subskrybujesz grupę „Warszawa Java User Group (Warszawa JUG)” w Grupach dyskusyjnych Google.
Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na warszawa-jug...@googlegroups.com.
Aby opublikować wpis w tej grupie, wyślij e-maila na warsza...@googlegroups.com.
Więcej opcji znajdziesz na https://groups.google.com/d/optout.

[Jakub Nabrdalik]

W dniu 29 października 2015 01:23 użytkownik Przemek Lewandowski <przel...@gmail.com> napisał:

PS. Czym zajmuje sie Architekt Systemu i jakie wiadomości powinna mieć taka osoba jesli chodzi o szukanie pracy ?

Simon Brown napisał niedawno książkę Software Architecture for Developers, która odpowiada ładnie na wszystkie bazowe pytania (kto to jest architekt, jakie ma umiejętności, jakie są problemy na tej pozycji):

https://leanpub.com/software-architecture-for-developers

Ale ostrzegam, jeśli ktoś już zajmuje się architekturą i spodziewa się rzeczy zaawansowanych, to się rozczaruje. Książką przez to że "od zera" odpowiada na podstawowe pytania, jest w dużej części oczywista (nudna) dla ludzi z doświadczeniem.

Dla mnie osobiście, architekt to taki developer, który ma dużo doświadczenia w budowaniu systemów od zera, interesuje się architekturą (wzorce, technologie, etc.) i potrafi poprowadzić zespół/projekt do końca, kodując. Z tej definicji wynika, że w małych projektach często każdy jest architektem :)

Termin Architekt ma różne przedrostki i w różnych firmach oznacza co innego. Spotkałem się z kilkoma archetypami architektów:

System/Software Architect - najczęściej podchodzi pod definicję osobistą powyżej. Doświadczony developer, który nie jeden projekt widział, nie jeden postawił od zera, rajcuje go architektura duża (systemy rozproszone) i mała ( budowa aplikacji i pakiety w środku).

Solution Architect - gdy przyjęto mnie do TouKa na to stanowisko, i zapytałem czemu "Solution" to szef odpowiedział: "Bo twoje rozwiązania nie koniecznie muszą wymagać software'u". I miał rację. Dobry Solution Architect, potrafi to samo co Software Architect, ale dodatkowo startuje w odpowiedzi na RFP, i potrafi zaproponować zmianę procesów biznesowych na lepsze. Do dziś pamiętam, jak TouK jednemu z klientów odpowiedział na RFP: "Możemy wam zrobić ten system, ale nie chcemy, bo to wam nie pomoże. Wy macie problem w procesie biznesowym, i to ten problem trzeba naprawić. Software wam nie jest potrzebny."

Niestety, spotkałem się też w kilku firmach softwareowych z podejściem, że Solution Architect, to architekt procesów, i nie umie programować (nie zna się na technologii). Nie mam nic przeciwko takim ludziom (są bardzo potrzebni), tylko niestety terminologia jest confusing.

Pamiętam do dziś, jak niechcący obraziłem kolegów z firmy consultingowej, których po przedstawieniu się (architekci) zapytałem wprost: "Umiecie programować?". Not the best start ever. Bogu dzięki wytłumaczyliśmy sobie wszystko na piwie :)

Enterprise Architect - albo miałem pecha, albo taki tytuł dostają głównie ludzie którzy nie znają się na technologii, nie potrafią programować, ale i tak się wypowiedzą. Innymi słowy typowi "Ivory Tower Architect". Rekordzistą był koleś z PhD, który dwukrotnie próbował wdrażać swój poroniony pomysł na architekturę i któremu dwukrotnie zespół developerski (bo on sam kodować nie umi) po miesiącu się buntował, widząc że to się kupy nie trzyma i problemy już dawno w firmie rozwiązano inaczej (pierwszy raz) lub też implementacja jego pomysłów skończy się tuż po śmierci termicznej wszechświata (za drugim razem).

Ciekawym wyznacznikiem tej roli, jest narzędzie którym się EA posługuje. Jeśli używają Enerprise Architecta to jest jeszcze spoko. Niektórzy jednak porzucają UML (jest za konkretny) i robią diagramy w... wait for it... power poincie. Nawet email zamiast tekstowo, wysyłają jako jedno-slajdowy power point. Masakra.

Kolejny taki kolo miał zaprezentować zarządowi wizję nowego wspaniałego świata. Poprosił nas o listę komponentów systemu. Wrzucił je w prostokąty w power poincie, i na środku dorysował kwadrat: "Product Factory". Na nasze pytania co to jest, odpowiedział: "Product factory produces the product that will solve our problem". Nawet nie pofatygował się narysować jakiekolwiek strzałki, bo wtedy wyszłaby jego niewiedza. Zarząd oczywiście zadowolony.

Mam dziwne wrażenie, że w wielu EA to byli developerzy, którzy odeszli na "wewnętrzną emeryturę": przestali się uczyć. Przy czym faktycznie są potrzebni ludzie, którzy jedynie orientują się w technologiach na rynku, analizują post-mortem innych firm, organizują zarządzanie wiedzą (knowledge governence) i pomagają wybrać dostawców. Z tej perspektywy Enterprise Achitect, robi architekturę organizacji, a nie software'u. Bliżej do managera niż do programowania. I to ma jakiś sens. Niestety, w wielu firmach tacy ludzie podejmują kluczowe decyzje co do tego jak budować system i jakich bibliotek będziesz używał. I to jest smutne.

Ale weź pod uwagę, że ja mam tylko 13 lat doświadczenia, więc widziałem tylko kilkadziesiąt firm. Jestem pewien że są firmy, gdzie na stanowisku EA pracują dobrzy ludzie. I nawet spotkałem kilku ludzi z tytułem EA, których mógłbym polecić.

Jakiś czas spędziłem rekrutując Chief Architecta dla dużej firmy. To jest dopiero trudna do rekrutacji rola. Pół roku mi zajęło. Byli kandydacie pokroju Software Architecta, ale nie miejący doświadczenia w dużych systemach rozproszonych. Byli kandydacie z doświadczeniem w takich systemach, ale nie z taką ilością ludzi. Generalnie rola opiewała na pół architekta, pół managera architektów, pół lidera, i jeszcze żeby kodował (choć na to czasu w pracy mieć nie będzie). Wyszedłem z założenia, że skoro ja się nie poczuwam do takiej roli (za cieniutki jestem, za mało doświadczenia) to człowiek którego rekrutuję musi być we wszystkich tych obszarach dużo mocniejszy ode mnie.

Było trochę dobrych kandydatów, ale szefostwo wszystkich ujebało, bo byli za miętcy (czytaj: zadawali pytania, zamiast przynieść power pointa w zębach; próbowali zrozumieć problem, zamiast go zasłonić). Znalazłem w końcu dobrego człowieka, spełniającego wszystkie warunki i podobającego się szefostwu w najmniej oczekiwanym miejscu: warszawskim korpo-banku. Niestety dla nas, w międzyczasie szefostwo znalazło sobie kolejnego PowerPoint Architecta w Londynie, który już rysował kolejne Product Factory.

--

Jakub Nabrdalik
http://solidcraft.eu

[Arkadiusz Borek]

Witam, 

@Off topic

@Replication (swoja drogą ciekawe po co jest replikacja).

Mnie uczono, że jak jedne dane szlak trafi to masz kopie.

W replikacji jest jedne problem i często jest on rozwiązywany na poziomie rzeczy które używasz(np baza danych) ponieważ podczas replikacji chcesz mieć duża wydajność podstawowego systemu, czyli replikacja nie może obciążać ci głównego systemu, oraz też nie możesz za bardzo zmarginalizować replikacji, ponieważ dane będą zbyt stare w replice;

Jeżeli weźmiesz pod uwagę, np MongoDB to są systemy w których jest ogromna przewaga, odczytów nad zapisem, możesz sobie tak skonfigurować swój system, że podnosisz priorytet dla operacji replikowania tak by inconsistency danych była jak najmniejsza i masz wiele punków odczytu ale tylko 1 zapisu; co pozwala Ci odciążyć bazę jeżeli chodzi o odczyt, bo czytasz z wielu miejsc;

*inconsistency - sorry,  że nie użyłem słowa niespójność, tylko napisałem po angielsku; 

@architekturalnych systemów informatycznych

Weź sobie jeszcze do serca to co napisał Piotr, a szczególnie ten punkt:

- umiejętność zaprojektowania systemu tak, aby był skalowalny (bo biznes lubi zmieniać zdanie ;) )

bo to biznes jaki realizujesz defacto determinuje Ci jakie rozwiązanie możesz zastosować, i musisz bardzo dobrze rozumieć biznes bo wtedy twoje rozwiązanie będzie lepiej wpasowane, a co za tym idzie będzie mniej baboli z produkcji i mniej roboty :)

ps. Problem nie jest banalny,  stąd i kasa dla ludzi którzy to czują i potrafią zrobić jest odpowiednia :). Bardzo dobrze jest uczyć się tego z materiałów, ale jeżeli chcesz być dobry musisz śledzić bieżące trendy i rozwiązania jakie są na rynku, a co za tym idzie moim zdaniem książki odpadają, zrób sobie rss na kilka storn, na blogi odpowiednich ludzi, pojawiaj się na konferencjach i słuchaj co się dzieje, a będziesz mógł stwierdzić czy warto użyć to w twoim biznesie; I chyba najważniejsze praktyka :)

Pozdrawiam,

Arek;

ps. chyba za dużo buziek :) dałem.

[Michał 'Chlebik' Piotrowski]

A ja się tak podpytam bo w sumie ten aspekt u mnie w RSSach leży - jakieś linki może polecasz specjalnie?

Pzdr

Chlebik