Tygodniowe wyzwanie programistyczne — #3

Zadań ciąg dal­szy — tym razem początku­ją­cy zmierzą się z dia­gramem akty­wnoś­ci. Dla prak­tyków coś nieco innego — słów kil­ka o architek­turze i budowa­niu sys­temów. Gotowa?

Wyzwanie dla początkujących

Przed przys­tąpi­e­niem do zada­nia, zas­tanów się nad rezul­tatem Two­jej wczo­ra­jszej pra­cy: Czego dowiedzi­ałeś się o swoich umiejęt­noś­ci­ach? Czego się nauczyłeś? Co zro­bisz z tą wiedzą?

Dość częstym prob­le­mem początku­ją­cych pro­gramistów jest ‘jak to podzielić’/‘gdzie to zaim­ple­men­tować’. Już śred­niego rozmi­aru aplikac­ja będzie miała kilka­naś­cie mod­ułów, kilka­dziesiąt różnych klas, kil­ka warstw — odnalezie­nie się w tym wszys­tkim to niekoniecznie łatwe zadanie. Cza­sa­mi może pomóc doku­men­tac­ja, cza­sem pomoże nam ktoś z zespołu, ale sama też możesz do tego dojść w prosty sposób!

Jed­nym ze sposobów jest dia­gram akty­wnoś­ci — tech­ni­ka obra­zowa­nia nie tyle samego sys­te­mu czy jego tech­nicznych zaw­iłoś­ci, ile właśnie pro­cesów i danych, które w ramach tych pro­cesów są przetwarzane. Na naszym blogu zna­jdziesz też wpis na ten tem­at :)

Twoim zadaniem będzie stworzyć dia­gram akty­wnoś­ci dla jakiejś czyn­noś­ci, którą codzi­en­nie wykonu­jesz. Może to być np. pro­ces zakupów, przy­go­towa­nia posiłku czy np Two­ja wiec­zor­na ruty­na. W tym wypad­ku ‘dany­mi’ mogą być też przed­mio­ty, których uży­wasz w tym pro­ce­sie, a ‘par­ty­c­ja­mi’  — miejs­ca lub oso­by, które w nim także uczestniczą.

Po stworze­niu dia­gra­mu, zas­tanów się, czy mogłabyś zas­tosować tą tech­nikę do jakiegoś prob­le­mu w pra­cy, który miałaś w ostat­nim cza­sie. Jeśli tak, jak wyglą­dały­by pod­sta­wowe par­ty­c­je i akc­je? Czy potrafisz przed­staw­ić swo­je rozwiązanie za pomocą dia­gra­mu aktywności?

Jeśli chodzi o narzędzia, najprost­szym jest po pros­tu kart­ka i dłu­gopis ;) Możesz też sko­rzys­tać z narzędzi takich jak gliffy.com (bezpłatne kon­to pozwala na stworze­nie do 5 pub­licznych dia­gramów) albo jed­nego z wymienionych na Wikipedii.

Nie zapom­nij podzielić się z nami swoim pomysłem w komen­tarzu pod even­tem na FB!

Nasza odpowiedź

Niby pra­sować każdy umie, jed­nak ja kil­ka razy musi­ałam uzu­peł­ni­ać swój dia­gram aktywności ;)

Wyzwanie dla praktyków

Przed przys­tąpi­e­niem do zada­nia, zas­tanów się nad rezul­tatem wczo­ra­jszej pra­cy: Czego dowiedzi­ałeś się o swoich umiejęt­noś­ci­ach? Czego się nauczyłeś? Co zro­bisz z tą wiedzą?

Architek­tu­ra aplikacji jest zagad­nie­niem sto­sunkowo prostym i bard­zo skom­p­likowanym zarazem. Prostym, ponieważ wiele już zostało w tym tema­cie powiedziane — ist­nieją wzorce (np. Enter­prise Inte­gra­tion Pat­terns), ich imple­men­tac­je (np. Apache Camel), gotowe kloc­ki do budowy rozwiąza­nia (np. Ama­zon AWS, Microsoft Azure), a także wzor­cowe rozwiąza­nia (jak np. AWS Blue­prints). Jed­nocześnie jest to zagad­nie­nie bard­zo skom­p­likowane, ponieważ częs­to wyma­gania są min­i­mal­nie inne niż te ‘wzor­cowe’, opra­cow­anie architek­tu­ry aplikac­ja wyma­ga zna­jo­moś­ci szczegółów jak poszczególne ele­men­ty ze sobą współpracu­ją, jakie są kon­sek­wenc­je pewnych decyzji oraz jak zmi­ana określonych para­metrów wpły­wa na pozostałe.

W zde­cy­dowanej więk­szoś­ci aplikacji moż­na sobie poz­wolić na pewne błędy — więk­szość aplikacji, z który­mi pracu­je­my na codzień będzie dzi­ałała tylko na kilku ser­w­er­ach, a ich kilku­min­u­towa awaria nie spowodu­je więk­szych prob­lemów. Zapewne też pra­cow­ałaś z takim pro­jek­tem. Dzisiejsze zadanie pole­ga na przepro­jek­towa­niu sys­te­mu, który pro­jek­towałaś w przyszłoś­ci. Zaczy­na­jąc od wyma­gań niefunkcjon­al­nych oraz głównych założeń, stwórz od nowa ‘ide­al­ną’ architek­turę takiej aplikacji.

Oczy­wiś­cie postaraj się zmieś­cić w godzinie cza­su — mówimy więc tutaj o bard­zo wysokopoziomowym spo­jrze­niu. Postaraj się jed­nak odpowiedzieć na kil­ka pytań:

• co się stanie, kiedy jeden z ser­w­erów przes­tanie dzi­ałać? Co się stanie jeśli cała ser­werow­n­ia przes­tanie działać?
• które cechy były w Twoim sys­temie najważniejsze i dlaczego? jakie kom­pro­misy musi­ałaś w związku z tym podjąć?
• jakie są lim­i­ty Two­jego sys­te­mu? który ele­ment będzie najbardziej ograniczał jego możliwości?

Jeśli potrze­bu­jesz inspiracji albo chci­ałabyś zerknąć, jak zale­ca się budować podob­ne sys­te­my możesz sko­rzys­tać z zasobów AWS (na dole jest sekc­ja ‘AWS ref­er­ence archi­tec­tures’) lub Azure. Możesz też sko­rzys­tać z opisów Enter­prise Inte­gra­tion Pat­terns.

Jeśli możesz — podziel się swoi­mi prze­myśle­ni­a­mi w komen­tarzu pod wydarze­niem na FB :)

Nasza odpowiedź

Pro­jekt, który wybrałem to sys­tem do automaty­cznego mailin­gu — taki odpowied­nik MailChim­pa i GetRe­sponse z cza­sów, kiedy pro­gramy te nie były zbyt pop­u­larne ;) Jeden z ważniejszych czyn­ników w tego rodza­ju aplikac­jach to osob­ne adresy IP dla różnych klien­tów — w sytu­acji kiedy jeden z nich zostanie uznany za spam, nie może to mieć wpły­wu na pozostałych klien­tów. Sys­tem ten był skierowany do przed­siębior­ców prowadzą­cych sprzedaż online — z tego powodu kosz­ty utrzy­ma­nia nie były najis­tot­niejsze (wtedy sprowadza­ło się to do tego, że każdy klient instalował opro­gramowanie u siebie, na włas­nym ser­w­erze VPS). To jed­nak doty­czy wyłącznie częś­ci odpowiedzial­nej za ‚wysyłanie’ maili, jeśli chodzi o samą część związaną z kon­fig­u­racją fakt insta­lacji na ser­w­er­ach klien­tów przys­parzał więcej prob­lemów niż korzyś­ci. Aplikac­ja, którą wtedy zapro­jek­towałem i zaim­ple­men­towałem była mono­li­ty­cz­na, a poszczególne jej instanc­je nie komu­nikowały się ze sobą w żaden sposób.

Podsumowując wymagania:

• sama wysył­ka wiado­moś­ci powin­na odby­wać się w miarę możli­woś­ci z osob­nych adresów IP dla każdego z klien­tów (moż­na powiedzieć, że to taka wari­ac­ja w tema­cie Cell Architecture)
• część kon­fig­u­ra­cyj­na oraz inter­fe­js użytkown­i­ka może być współdzielony pomiędzy klientami
• obciąże­nie sys­te­mu jest skokowe (w momen­cie wysyłek), ruch związany z inter­fe­jsem jest stan­dar­d­owy, z sil­nym tren­dem spad­kowym pod­czas weekendów
• inter­fe­js musi być dostęp­ny pod wielo­ma dom­e­na­mi (z uwa­gi na scor­ing antys­pamowy, lin­ki w treś­ci maili powin­ny kierować do tej samej dome­ny, z której został wysłany mail)

Proponowana architektura:

Dia­gram przy­go­towany został w opar­ciu o pub­licznie dostęp­ne usłu­gi AWS.

Wszyscy klien­ci są obsługi­wani przez wspól­ną flotę ser­w­erów — wspól­na jest też baza danych prze­chowu­ją­ca kon­fig­u­rację. Aplikac­ja jest opar­ta o ser­wisy RESTowe, wystar­czy nam więc warst­wa aplikacji oraz sieć CDN do ser­wowa­nia ruchu staty­cznego. Punkt wejś­ciowy aplikacji to Route53 — usłu­ga DNS, która poz­woli nam odpowied­nio ser­wować zarówno treś­ci staty­czne jak i ser­wisy RESTowe dla wielu domen za pomocą tych samych ser­w­erów. Dane staty­czne obsługi­wane są przez Cloud­For­ma­tion oraz usługę S3, zapy­ta­nia dynam­iczne (poprzez Load Bal­ancer) ser­wowane są za pomocą usłu­gi EC2 — stan­dar­d­owej chmury obliczeniowej.

Poszczególne ser­w­ery mają wspól­ną bazę danych, dla bez­pieczeńst­wa posi­ada­jącą rep­li­ki w różnych stre­fach. W tym wypad­ku baza danych jest rela­cyj­na, co może być ogranicze­niem jeśli chodzi o skalowal­ność aplikacji.

Ser­w­ery aplikacji ‚zle­ca­ją’ wysyłkę wiado­moś­ci email do osob­nej flo­ty — w tym wypad­ku w zależnoś­ci od pref­er­encji klien­ta może to być usłu­ga SES, mogą to być osob­ne ser­w­ery (dla specy­ficznych zas­tosowań i kon­fig­u­racji), a mogą to być także ser­w­ery hos­towane u klien­ta (jes­li jest potrze­ba inte­gracji z wewnętrzny­mi sys­tema­mi jak np. AD — wtedy komu­nikac­ja naw­iązy­wana jest przez VPN).

Potencjalne zmiany / usprawnienia:

• sys­tem nie jest wrażli­wy na czas odpowiedzi, o ile jest on poniżej sekundy; moż­na rozważyć rezy­gnację ze stan­dar­d­owych ser­w­erów EC2 i zastąpić je np. AWS Lamb­da — obliczeni­a­mi na żądanie. Mogło­by to jed­nak negaty­wnie wpłynąć na szy­bkość wdraża­nia zmi­an i nowych funkcji, a ilość inter­akcji z UI jest na tyle mała, że nie gen­erowało by to znaczą­cych oszczędności.
• aby zwięk­szyć możli­woś­ci aplikacji, moż­na zastąpić rela­cyjną bazę danych połącze­niem np. DynamoDB (do prze­chowywa­nia danych) z usługą Elas­tic­Search (pozwala­jącą wyszuki­wać infor­ma­c­je we względ­nie dowol­ny sposób) — z drugiej strony ilość przetwarzanych infor­ma­cji jest względ­nie niewiel­ka, i rela­cyj­na baza danych powin­na być wystar­cza­ją­ca nawet przy licz­bie klien­tów lic­zonych w dziesiątkach tysięcy

Oczy­wiś­cie obec­nie ist­nieje wiele gotowych rozwiązań, które moż­na dopa­sowywać do włas­nych potrzeb — pro­dukt tego rodza­ju raczej nie miał­by zas­tosowa­nia. Mimo wszys­tko było to przy­jemne doświad­cze­nie — częs­to w codzi­en­nej pra­cy nie moż­na sobie poz­wolić na ‚ide­al­ny’ pro­jekt od strony tech­nicznej, bo jest wiele innych czyn­ników, które należy uwzględ­nić. Było to także ciekawe pod tym kątem, że odświeżyłem sobie usłu­gi ofer­owane przez różnych dostaw­ców chmur :)

Cały sys­tem jest też w prosty sposób przenaszal­ny, jeśli klient życzy sobie mieć całkowicie pry­wat­ną instalację.

Pamię­taj, że nowe zada­nia będą się pojaw­iać codzi­en­nie o godzinie 11. Rozwiąza­nia będziemy umieszczać pod zada­ni­a­mi kole­jnego dnia o godzinie 18. Nie zapom­nij podzielić się swoi­mi odpowiedzi­a­mi i prze­myśle­ni­a­mi na wydarze­niu na face­booku, a jak masz ochotę to też w komentarzu ;)!

Lin­ki do wszys­t­kich zadań zna­jdziesz w innym wpisie na naszym blogu. Powodzenia!