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

Kolumna

Kako je meni i 35.000 kupaca 96% snižen Foreov UFO postao “najbolje iskustvo kupovine ikad”

Osjećaj kada pronađete, a potom i kupite neki proizvod po 96% nižoj cijeni, nezamjenjiv je, pogotovo ako ste jedni od “rijetkih” koju su ponudu pronašli. Svi vam zavide, napravili ste odličan “deal”, a manje je bitno treba li vam uopće taj proizvod.

Startupi i poslovanje

MVT Solutions iz Pisarovine osigurao 100.000 od 300.000 eura vrijedne runde investicije za brži i jeftiniji razvoj IoT-ja

Ovaj domaći startup u tri je godine, bez ikakve vanjske investicije, razvio IoTaaP, alat koji može uvelike olakšati razvoj IoT proizvoda različitim klijentima. Osim hardvera, njihov poslovni model se skalira kroz softver i cloud, a koliko uspješno su se rješenjem i radom potvrdili do sada, najbolje govori i vijest o prvoj investicijskoj rundi predvođenoj domaćim investitorom.

Startupi i poslovanje

Od agencije do freelancinga: 8 savjeta za život i posao koje sam naučio težim putem

A kako vi ne bi morali, stiže jedna poučna usporedba oblika poslovanja kroz stvarna iskustva.

Što ste propustili

Startupi i poslovanje

Osvojili su “Oscara” za industrijski dizajn, a onda sve snage uložili u kreiranje najboljih madraca

Uz mnoge druge domaće i inozemne nagrade, Filip Havranek i Kristina Lugonja dobitnici su Red Dota, najprestižnije svjetske nagrade za industrijski dizajn, a odnedavno su postali i osnivači startupa. Iako su dosad dizajnirali različite namještaje i proizvode - od stolova, stolica, lampi i prijenosnih SSD-ova - njihov prvi startup proizvod je madrac Nimbus koji se ne prodaje u nijednoj fizičkoj trgovini.

Kultura 2.0

Kako iskoristiti advent za employer branding (a da nije samo domjenak)

Važnost dobrog raspoloženja unutar tvrtke ne možemo zanemariti, pogotovo kad je riječ o kraju godine kada se projekti privode kraju dok se istovremeno pripremmo za nadolazeće. Čini se da je A1 otkrio najbolju formulu kako preživjeti zimu: mjesec dana blagdana u uredima.

Startupi i poslovanje

“Kod nas toga nema”: Samo 16% žena u hrvatskoj IT industriji nije doživjelo spolnu diskriminaciju

“Nejednakost je samo u Vašoj glavi, da manje sjedite pred pudijerom, a više pred knjigom nebi vidjeli nejednakost”.

Tehnologija

Klijenti banaka imaju sve manje vremena: Kako banke razvijaju digitalne proizvode za njih?

Digitalna transformacija mijenja iz temelja različite industrije. Koje vještine su vam potrebne ne bi li u jednoj od njih temelje gradili upravo vi, saznali smo od product ownera i managera Raiffeisen banke.

Kolumna

Kako je meni i 35.000 kupaca 96% snižen Foreov UFO postao “najbolje iskustvo kupovine ikad”

Osjećaj kada pronađete, a potom i kupite neki proizvod po 96% nižoj cijeni, nezamjenjiv je, pogotovo ako ste jedni od “rijetkih” koju su ponudu pronašli. Svi vam zavide, napravili ste odličan “deal”, a manje je bitno treba li vam uopće taj proizvod.

Tehnologija

Hardverski vodič za sve trenutne i buduće influencere, freelancere i gamere

Kraj jedne godine i ulazak u novu možete pamtiti po retrospektivi na prošle uspjehe i neuspjehe te novogodišnjim planovima koji su se izjalovili do sredine siječnja. A možete i po tome kako ste napokon odlučili napraviti prvi korak prema ostvarenju svog influencerskog, gamerskog ili freelancerskog sna. Hardver možda nije najvažnija stvar u toj priči, ali je sigurno bitna stvar za početak.