Kako skaliramo Farmeron uz Lambda arhitekturu i arhitekturu mikroservisa

Kako skaliramo Farmeron pomoću Lambda arhitekture i arhitekture mikroservisa

Pretpostavka za svaku kvalitetnu platformu je dobro osmišljena strategija implementacije odgovarajuće arhitekture. Posebno je to izraženo u složenim domenama. Jednom takvom se bavi i Farmeron.

farmeron_1naslovna

Za one koji ne znaju, Farmeron je enterprise sustav za upravljanje farmama. Prvenstveni su nam fokus velike farme s tisućama životinja. S jedne strane, Farmeron služi kao Data Hub omogućavajući integraciju s različitim hardverskim modulima koji su prisutni na visokotehnološkim farmama. Ovakvi integrirani podaci nadopunjuju one koji su uneseni direktno kroz Farmeronov sustav putem web ili mobilne aplikacije. S druge strane, Farmeron pruža sloj analitike baziran na prikupljenim podacima koji je kao takav jedinstven u svijetu.

Arhitektura mikroservisa

Kako bismo se uspješno nosili s kompleksnosti domene, Farmeronovu platformu baziramo na arhitekturi mikroservisa. Svaki od mikroservisa posjeduje određena svojstva koja nam pomažu u ostvarivanju našeg cilja:

  • Predstavlja samo jednu funkcionalnost u kompleksnoj domeni.
  • Izoliran je od ostalih mikroservisa.
  • Individualno se skalira i razvija.
  • Posjeduje API za konzumaciju.

Upravo ovakva arhitektura omogućava Farmeronu i skaliranje organizacije – umjesto da svi developeri rade na jednom kompleksnom projektu i međusobno si smetaju, male grupe rade na jednom mikroservisu u jednom trenutku. S obzirom na to da broj mikroservisa neprestano raste i broj developera može pratiti ovaj trend bez kreiranja nepotrebnog overheada. 
No, to ne znači da preferiramo one man band tipove pri čemu bi svaki posjedovao vlastiti mikroservis i uspješno izbjegao bilo kakvu interakciju s drugim ljudskim bićima :). Idealni kandidati za posao su timski igrači.

Pored toga, svaki novi developer ne mora odjednom shvatiti cijelu platformu, već samo jedan mali fragment da bi napravio doprinos. Kako smo kao ljudi ograničeni svojim kognitivnim sposobnostima, čak i iskusnim developerima dobro dođe rad na samo jednom mikroservisu u jednom trenutku. Pojednostavljeno rečeno, puno je veća šansa da će developer “smjestiti u glavu” jedan mikroservis u odnosu na ogromnu monolitnu aplikaciju. Time će i broj bugova biti manji.

.
Idealne osobe za ovakav način rada su timski igrači.

Konzumenti mikroservisa kao i sami mikroservisi komuniciraju međusobno HTTP porukama. Ovaj univerzalni “jezik” omogućava da mikroservisi ne moraju biti pisani u jednoj jedinstvenoj tehnologiji niti da pozadinske baze podataka moraju imati takvo ograničenje. Iako prvenstveno baziran na .Net tehnologiji, upravo zbog ove činjenice Farmeron nije dugoročno osuđen na isključivo jedan tehnološki stack.

Ažuriranje samo malog dijela sustava u jednom trenutku – s minimalnim rizikom

Mnogo tvrtki izdaje nove inačice softvera u određenim vremenskim razmacima (često po završetku sprinta – svaka dva do četiri tjedna). U Farmeronu u jednom trenutku izdajemo novu inačicu samo jednog mikroservisa, što developeru omogućava izdavanje i nekoliko inačica dnevno ako za to postoji potreba. S obzirom da je cijeli proces automatiziran, nije čudno da on traje tek nekih desetak sekundi.

Naravno, pod uvjetom da su svi testovi “zeleni” 🙂 – prije nego što se može izdati nova inačica, potrebno je osigurati da je funkcionalnost točno onakva kakva je zadana u specifikacijama projekta. Uloga developera je pisanje testova koji testiraju reprezentira li implementacija ponašanje zadano u specifikacijama projekta. S druge strane, uloga QA tima je pisanje niza automatiziranih testova koji nisu pokriveni od strane developera. kao i takozvano eksplorativno testiranje. Generalno gledajući, cilj je postići transformaciju tekstualnih specifikacija u odgovarajuće automatizirane kako bi se postigao stupanj regresije koji će osigurati da funkcionalnosti ne budu narušene tijekom kontinuiranog razvoja platforme. Pritom je jako bitna komunikacija između developera i članova QA tima.

Arhitektura mikroservisa donosi sa sobom i niz potencijalno negativnih posljedica, posebno onih koje utječu na povećanje operacijske kompleksnosti. Ipak, mi u Farmeronu to ne vidimo kao problem, već kao izazov na koji trebamo odgovoriti odgovarajućim mjerama.

Lambda arhitektura

Što će vam podaci ako ne znate što ćete s njima? :)
Što će vam podaci ako ne znate što ćete s njima? 🙂

Upravo je u samoj srži postojanja Farmerona da ih poveže zajedno, izvuče zaključke i ponudi krajnjem korisniku u obliku koji će mu pružiti važan uvid u svakodnevni rad farme te ga pravovremeno potaknuti na akciju kako bi dodatno optimizirao postojeće procese.

Agregirani podaci preduvjet su naprednoj analitici sa svrhom zaključivanja o trendovima u industriji te o različitim točkama u poljoprivrednom i prehrambenom lancu vrijednosti.

Podatke smještene u bazama mikroservisa, a koji se procesiraju kako bismo iz njih generirali koristan izvještaj, nazivamo “izvorom istine”. Ovi podaci predstavljaju većinom seriju događaja na farmi. Primjer takvih događaja su događaji vezani za:

  • zdravlje životinje,
  • rasplodni ciklus životinje,
  • proizvodnju mlijeka,
  • potrošnju hrane i sl.

Količina podataka je ogromna te raste iz dana u dan. Podatke ne brišemo, već se baziramo na immutability principima – dovoljne su nam samo operacije kreiranja i čitanja u bazi podataka. Ovime nastojimo spriječiti korupciju postojećih podataka, no isto tako omogućavamo analizu nad starim podacima koji se u tradicionalnim sustavima inače prepisuju. 
S druge strane, korisnicima nastojimo pružiti što je moguće bolje korisničko iskustvo kako bi pristupali generiranim izvještajima bez čekanja na učitavanje stranice s podacima. Smatramo kako u današnje vrijeme sa dostupnim resursima ne postoji opravdan argument za sporu aplikaciju.

Izvještaji koji se sami generiraju

Kako bismo to postigli, odlučili smo se na princip proaktivnog generiranja izvještaja. To znači da će se izvještaj generirati unaprijed, čak i prije nego što ga korisnik zaista treba. Prednost takvog pristupa je u tome što je u trenu kada korisnik pristupa izvještaju on već spreman. Samim time je i vrijeme pristupa izvještaju neznatno. I ne samo to, cijeli proces proaktivnog generiranja je automatiziran i odvija se u iteracijama. Drugim riječima, generiranje se događa samo od sebe u zadanim vremenskim intervalima, čak i ako nema promjene nad ulaznim podacima.

Kada postoji bug u sustavu, dovoljno je popraviti izvorni kod i sačekati sljedeću iteraciju kako bi jedan ili više izvještaja bio prepravljen. Farmeronov sustav se “obnavlja” sam od sebe pa je i razina svakodnevnog stresa manja. Za usporedbu – alternativa u tradicionalnim sustavima je ručna prepravka podataka direktno u bazi podataka. 
Kako bi izvještaji bili u realnom vremenu, koristimo tehnologije za streaming događaja. Prilikom ulaska u sustav, događaj se po upisu u bazu podataka šalje u red procesiranja nakon kojeg se prethodno generirani izvještaj inkrementalno ažurira. Ovaj proces najčešće traje manje od jedne sekunde.

Sve navedeno predstavlja principe Lambda arhitekture. Kako bismo joj “udahnuli život”, koristimo Apache Spark tehnologiju.

Apache Spark je generalni distribuirani sustav za računanje nad klasterom. Za Farmeron je jako bitan jer pruža mogućnost horizontalnog skaliranja (dodavanja novih čvorova) kako količina podataka bude rasla. Također, Apache Spark pruža mogućnost strojnog učenja i rada na velikim skupovima podataka koristeći sučelje analitičarima omiljenog R-a. Naime, R donosi bogate open source statističke i vjerojatnosne pakete uz moćnu vizualizaciju dobivenih rezultata. Ova funkcionalnost omogućit će Farmeronu daljnji napredak analitičkog tima na Data Science polju.

Želiš i sam vidjeti i sudjelovati u daljnjem napretku Farmerona? Pridruži se timu kao Backend Developer!

Komentari

  1. dkatavic

    dkatavic

    26. 10. 2016. u 12:29 am Odgovori

    Koristim Lambda funkcije dosta često u svom poslu, pa sam se nadao malo detaljnijem opisu workflowa, točnije kako testirate Lambde, koji framework koristite, kakav vam je sami dev workflow kod lambde i.t.d.

    Možda ovo spada van interesa čitatelja netokracije, pa bi i link na neki blog post bio koristan.

    • nitkobitan

      nitkobitan

      26. 10. 2016. u 10:42 am Odgovori

      dkatavic, ovo nema veze sa anon funkcijama tzv lambde koje su koncept iz FP-a. Ovo je vezano za mikroservise kao arhitekturu umjesto jedne velike monolitne aplikacije.

      Lambde nisu nista drugo nego… matematicke funkcije ukoliko je purism FP-a zadovoljen. Ljepota FP-a je to sto nemoras testirat takve stvari, vec su ti well defined i moguce je naci gresku vrlo jednostavno. Samim time sto imas dobro definirane domene, primjerice

      add :: Int -> Int -> Int
      add = \x y -> x + y

      ti se nemoze dogodit slucaj gdje se iz ove funkcije vraca monad ili monoid, recimo. U slucaju da zelis poslat lambdu u neku higher order funkciju, odmah mozes znati da je lambda ta koja je kriva ako se problem dogodi posto uvijek mozes testirati higher order funkciju. Ne vidim potrebe za ovim sto si spomenuo.

      Primjer spomenutoga:

      foldl :: (b -> a -> b) -> b -> [a] -> b
      jasno prima funkciju koja uzima argument tipa b i a, currya te vraca argument tipa b, argument tipa b, nekakvu listu tipa a te nam vraca rezultat tipa b.

      Iz samih tipova mozemo zakljuciti da foldl prodje po listi tipa a i primjeni funkciju koju smo poslali unutra, te vrati 1 rezultat, te je sada moguce napraviti ovakvu konstrukciju:

      foldl (\x y -> concat [“(“,x,”+”,y,”)”]) “0” (map show [1..13]) koja ce imati output:
      “(((((((((((((0+1)+2)+3)+4)+5)+6)+7)+8)+9)+10)+11)+12)+13)”

      Iz ovoga je jasno ukoliko rezultat nije ocekivan da je funkcija koju smo poslali unutra pogresna, u ovom slucaju anonimna funkcija tzv lambda.

    • Ivan Lozić

      Ivan Lozić

      26. 10. 2016. u 10:59 am Odgovori

      “Lambda” se u ovom slučaju odnosi isključivo na arhitekturu (iako se samo ime se koristi i za lambda izraze). Ukratko, Lambda arhitektura reprezentira se pomoću dva sloja putem kojih se podaci procesiraju i pohranjuju u obliku izvještaja. To su Batch i Stream slojevi. Batch sloj učitava sve podatke (a sam proces može trajati nekoliko munita, sati pa čak i dana), dok Stream sloj radi na razini jednog po jednog događaja u stvarnom vremenu. Preporučio bih jednu odličnu prezentaciju na ovu temu od samog kreatora imena ove arhitekture (Nathan Marz): https://www.youtube.com/watch?v=ucHjyb6jv08

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Tehnologija

Probao sam robotsku kosilicu – mnogo je više od “Roombe za travnjake”

Imati robota koji vam kosi travu je super ideja, ali koliko je realizacija zapravo jednostavna i uspješna?

Kultura 2.0

Prva prepreka za elektroničko glasanje je digitalna nepismenost

Kako je situacija s pandemijom koronavirusa digitalizirala i digitalno transformirala dobar dio i privatnog i javnog sektora, aktualiziralo se i pitanje o elektroničkom glasanju. O temi spremnosti na taj oblik glasanja, i s tehnološke i društvene strane, razgovarala sam s osobom koja je razvila jedan takav sustav, Ivanom Hendijom iz FairVotesa.

Startupi i poslovanje

Nemojte se ugledati na ‘lifestyle’, ‘hustle’ i Instagram poduzetnike koji ne kuže biznis (osim onih koji kuže)

Toksična pozitivnost i poslovna naivnost mogu biti katastrofalna kombinacija u doba ekonomske krize. Je li vrijeme da unfollowate sve lifestyle poduzetnike i motivirajuće Instagram profile?

Što ste propustili

Tehnologija

Tenisice, ruž, naočale… Kad ih već ne možemo isprobati u trgovini, zašto ne bismo virtualno?

Unatoč razvoju online prodaje, fizičke trgovine zadržale su svoju glavnu prednost - mogućnost da kupac sam isproba željene proizvode. No, nakon što su se trgovine diljem svijeta zatvorile zbog pandemije, porasla je popularnost virtualnog isprobavanja proizvoda koje pokušava donekle nadomjestiti korisničko iskustvo na kakvo smo navikli u tradicionalnim trgovinama.

Intervju

Nakon investicije od više od 50.000 eura, najveća regionalna CS:GO zajednica, CSadria, postala Esport Adria

Ovaj novi brend okupit će gamere i fanove ne samo esport igara, već i mobilnih i drugih igara koje igra mnogo veći broj ljudi.

Startupi i poslovanje

Email marketing u doba “korone”: 3 greške i 3 trika za bolju učinkovitost

Pomno pripremate i šaljete newslettere, ali učinka nema? Uz Brunu Zagorščaka iz agencije Neuralab, nedavno certificiranog Mailchimp partnera, prolazimo osnovne pogreške i taktike email marketinga.

Tehnologija

S Omoguru widgetom ne čitaju lakše samo disleksičari, već svi mi koji u ekrane buljimo svakodnevno

Za osobe koje imaju poteškoće u čitanju Omoguru je dar s neba, a odnedavno im je njihov alat još dostupniji. Radi se o widgetu koji gotovo svaku stranicu može učiniti čitljivijom.

Startupi i poslovanje

Nemojte se ugledati na ‘lifestyle’, ‘hustle’ i Instagram poduzetnike koji ne kuže biznis (osim onih koji kuže)

Toksična pozitivnost i poslovna naivnost mogu biti katastrofalna kombinacija u doba ekonomske krize. Je li vrijeme da unfollowate sve lifestyle poduzetnike i motivirajuće Instagram profile?

Startupi i poslovanje

Kakva je budućnost hibridnog rada u Hrvatskoj i regiji?

U Netokraciji već desetljeće radimo 'hibridno', malo od doma, malo iz ureda, ali kako će izgledati tržište rada u kojem i velike tvrtke i startupi rade tako - gdje to nije ni opcija, nego osnova posla?