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!

ponuda

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

Vodič za e-Vozačku da ne čekaš (kao mi) u redu u MUP-u

Sustav e-Vozačka, za predaju zahtjeva za novu vozačku dozvolu putem interneta, radi pristojno, ali i pokazuje da korisničko iskustvo i komunikacija mogu i moraju biti bolji. U suprotnom - šalter!

Tehnologija

Apple je pokazao kako više nema ništa za pokazati – čeka li ga Nokijin scenarij?

Sjednite, djeco, da vam ispričam priču o vremenu prije mog vremena. Bijaše to godina 1998., četvrtaste kutije protetičkih boja vrtjele su Windowse 95 ili 98, bilo je to vrijeme disketa, telefonskih slušalica koje se dižu i dial-up interneta koji puca kada se to dogodi.

Internet marketing

Ella Dvornik i Charles Pearce pokreću platformu za europske influencere – Manijak

Porazgovarala sam s Ellom Dvornik i Charlesom Pearceom o njihovom zajedničkom projektu, platformi za influencere i brendove koji s njima žele surađivati - Manijak.

Što ste propustili

Internet marketing

Poznati su dobitnici najvećeg SoMo Borca do sada

Weekend Media Festival jučer je završio dodjelom SoMo nagrada za najbolje digitalne projekte i kampanje.

Nesortirano

Može li igranje igara od nas napraviti bolje kolege, partnere i prijatelje?

Developer, filmaš i umjetnik Onat Hekimoglu na Weekend Media Festivalu govorio je o temi o kojoj ne slušamo često - ozbiljnim igrama.

Mobilno

Zašto zaključavate kućna vrata, ako nećete zaštititi svoje podatke online?

Na ovogodišnjem Weekend Media Festivalu od Alana Delića iz Diverta dobili smo pet savjeta o tome kako se zaštititi online.

Startupi i poslovanje

Poznati timovi koji će se na Idea Knockoutu natjecati za mjesto na CES-u

Sve je spremno za ovogodišnji Idea Knockout, a za put u Vegas borit će se 20 timova.

Startupi i poslovanje

Domaća aplikacija Beyond Seen Screen postala ExRey i stigla na Android uređaje

Nakon rebrandinga, Beyond Seen Screen postaje ExRey, a beta verzija aplikacije koja pretvara pasivno gledanje videa u aktivno dostupna je na Google Playu.

Intervju

Splitski Locastic otvoreno o povratku u esport nakon pauze (i naučenih lekcija)

Locastic je mrtav, živio Locastic? Splitska tvrtka iz drugog pokušaja nastoji postati regionalna sila u igri CS:GO.