🥇Prípady použitia servisnej siete

Poznámka. preklad.: Autor tohto článku (Luc Perkins) je advokátom vývojárov v organizácii CNCF, ktorá je domovom takých projektov s otvoreným zdrojovým kódom, ako sú Linkerd, SMI (Service Mesh Interface) a Kuma (mimochodom, tiež vás zaujímalo, prečo je Istio nie je na tomto zozname?). Opäť sa snaží priniesť komunite DevOps lepšie pochopenie trendového humbuku nazývaného „service mesh“, uvádza 16 charakteristických schopností, ktoré takéto riešenia poskytujú.

Dnes servisné pletivo ― jedna z najhorúcejších tém v oblasti softvérového inžinierstva (a právom!). Myslím si, že táto technológia je neuveriteľne sľubná a bol by som rád, keby bola široko prijatá (samozrejme, keď to bude mať zmysel). Pre väčšinu ľudí je však stále obklopený aurou tajomstva. Zároveň aj tí, ktorí dobre známy s ním je často ťažké formulovať jeho výhody a čo presne to je (vrátane vašich skutočných). V tomto článku sa pokúsim napraviť situáciu uvedením rôznych prípady použitia "servisné siete"*.

* Poznámka preklad: tu a ďalej v článku bude presne tento preklad („servisná sieť“) použitý pre stále nový pojem sieťka.

Najprv by som však chcel uviesť niekoľko poznámok:

Nikdy som so servisnými sieťami nepracoval ani som ich nepoužíval mimo projektov začatých na vlastné vzdelávanie. Na druhej strane som to bol ja, kto v roku 2015 napísal kopu dokumentácie pre internú sieť služieb Twitteru (vtedy sa to ešte nenazývalo „service mesh“) a podieľal som sa na vývoji webovej stránky a dokumentácie pre Linkerd, takže to niečo znamená.
Môj zoznam je približný a neúplný. Môžu existovať prípady použitia, ktoré nepoznám, a nové možnosti sa pravdepodobne objavia v priebehu času, ako sa technológia vyvíja a jej popularita rastie.
Zároveň nie každá existujúca implementácia siete služieb podporuje všetky uvedené prípady použitia. Preto by sa moje vyjadrenia ako „servisná sieť môžu...“ mali chápať ako „individuálne a možno všetky populárne implementácie sieťovej siete môžu...“.
Na poradí príkladov nezáleží.

Krátky zoznam:

objavovanie služieb;
šifrovanie;
autentifikácia a autorizácia;
rozdelenie výkonu;
prerušenie obvodu;
automatické škálovanie;
nasadenie kanárikov;
modro-zelené nasadenia;
kontrola zdravia;
znižovanie záťaže;
dopravné zrkadlenie;
izolácia;
obmedzenie počtu žiadostí, opakovanie a časové limity;
telemetria;
audit;
vizualizácia.

1. Objavenie služby

TL;DR: Pripojte sa k iným službám v sieti pomocou jednoduchých názvov.

Služby by sa mali vedieť automaticky „nájsť“ pomocou vhodných názvov – napr. service.api.production, pets/staging alebo cassandra. Cloudové prostredia sú elastické a jeden názov môže skrývať mnoho inštancií služby. Je jasné, že v takejto situácii je fyzicky nemožné zakódovať všetky IP adresy.

Navyše, keď jedna služba nájde inú, mala by byť schopná odosielať žiadosti tejto službe bez obáv, že skončia na vstupe jej nefunkčnej inštancie. Inými slovami, sieť služieb musí monitorovať stav všetkých inštancií služieb a udržiavať zoznam hostiteľov čo najaktuálnejší.

Každá sieť služieb implementuje mechanizmus zisťovania služieb odlišne. V súčasnosti je najbežnejším spôsobom delegovanie na externé procesy, ako je Kubernetes DNS. V minulosti sme na Twitteri používali na tento účel systém pomenovávania Finagle. Okrem toho technológia service mesh umožňuje vznik vlastných pomenovacích mechanizmov (hoci som ešte nevidel žiadnu implementáciu SM s takouto funkcionalitou).

2. Šifrovanie

TL;DR: Zbavte sa nešifrovaného prenosu medzi službami a urobte tento proces automatizovaným a škálovateľným.

Je príjemné vedieť, že útočníci nemôžu preniknúť do vašej vnútornej siete. Firewally v tomto robia skvelú prácu. Čo sa však stane, ak sa hacker dostane dovnútra? Bude si môcť s vnútroslužbovou premávkou robiť, čo chce? Dúfajme, že sa tak napokon nestane. Aby ste predišli tomuto scenáru, mali by ste implementovať sieť s nulovou dôverou, v ktorej je všetka prevádzka medzi službami šifrovaná. Väčšina moderných obslužných sietí to dosahuje prostredníctvom vzájomného TLS (vzájomné TLS, mTLS). V niektorých prípadoch funguje mTLS v celých oblakoch a klastroch (myslím, že medziplanetárna komunikácia bude raz usporiadaná podobne).

Samozrejme, pre sieť služieb mTLS voliteľné. Každá služba sa môže postarať o svoje vlastné TLS, ale to znamená, že budete musieť nájsť spôsob, ako generovať certifikáty, distribuovať ich medzi hostiteľov služieb a zahrnúť kód do aplikácie, ktorá tieto certifikáty načíta zo súborov. Áno, nezabudnite si tieto certifikáty v pravidelných intervaloch obnovovať. Servisné siete automatizujú mTLS so systémami ako SPIFFE, ktoré zase automatizujú proces vydávania a rotácie certifikátov.

3. Autentifikácia a autorizácia

TL;DR: Stanovte, kto je žiadateľ, a definujte, čo môže robiť, kým sa žiadosť vôbec dostane k službe.

Služby často chcú vedieť kto vykoná požiadavku (autentifikáciu) a na základe týchto informácií rozhodne že daná entita má povolené (oprávnenie). V tomto prípade sa zámeno „kto“ môže skrývať:

Ostatné služby. Toto sa nazýva "overenie" peer" Napríklad servis web chce získať prístup k službe db. Servisné siete zvyčajne riešia takéto problémy pomocou mTLS: certifikáty v tomto prípade fungujú ako nevyhnutný identifikátor.
Niektorí ľudskí používatelia. Toto sa nazýva "overenie" žiadosť" Napríklad používateľ haxor69 chce si kúpiť novú lampu. Obslužné siete poskytujú rôzne mechanizmy, napr. Webové tokeny JSON.
Mnohí z nás to urobili v kóde aplikácie. Prichádza žiadosť, pozeráme sa cez stôl users, nájdite používateľa a porovnajte heslo, potom skontrolujte stĺpec permissions atď. V prípade siete služieb k tomu dôjde ešte predtým, než sa požiadavka vôbec dostane k službe.

Keď zistíme, od koho žiadosť prišla, musíme určiť, čo môže tento subjekt robiť. Niektoré siete služieb vám umožňujú nastaviť základné politiky (o tom, kto čo môže robiť) ako súbory YAML alebo na príkazovom riadku, zatiaľ čo iné ponúkajú integráciu s rámcami, ako je Otvorte Policy Agent. Konečným cieľom je, aby vaše služby prijali akúkoľvek požiadavku, bezpečne za predpokladu, že pochádza z dôveryhodného zdroja и táto akcia je povolená.

4. Vyvažovanie záťaže

TL;DR: Rozložte zaťaženie medzi inštancie služby podľa špecifického vzoru.

„Služba“ v rámci servisnej časti veľmi často pozostáva z mnohých identických inštancií. Napríklad dnes služba cache pozostáva z 5 kópií a zajtra sa ich počet môže zvýšiť na 11. Žiadosti zaslané na cache, musia byť distribuované v súlade s konkrétnym účelom. Napríklad minimalizujte latenciu alebo maximalizujte pravdepodobnosť prístupu k fungujúcej inštancii. Najčastejšie používaným algoritmom je Round-robin, ale existuje mnoho ďalších – napríklad vážená metóda (vážené) dopyty (môžete vybrať preferované ciele), zvonenie (prsteň) hashovanie (používanie konzistentného hashovania naprieč upstream hostiteľmi) alebo metóda najmenších požiadaviek (preferovaná je inštancia s najmenším počtom požiadaviek).

Klasické balancéry majú ďalšie funkcie, ako je HTTP caching a DDoS ochrana, ale nie sú veľmi relevantné pre prevádzku z východu na západ (teda pre prevádzku prúdiacu v rámci dátového centra - cca preklad) (typický rozsah service mesh). Samozrejme, nie je potrebné používať sieť služieb na vyrovnávanie záťaže, ale umožňuje vám nastaviť a riadiť politiky vyvažovania pre každú službu z centralizovanej riadiacej vrstvy, čím sa eliminuje potreba spúšťať a konfigurovať samostatné nástroje na vyrovnávanie záťaže v sieťovom zásobníku. .

5. Prerušenie obvodu

TL;DR: Zastavte premávku na problematickú službu a kontrolujte škody v najhorších prípadoch.

Ak sa služba z nejakého dôvodu nedokáže vyrovnať s prevádzkou, sieť služieb poskytuje niekoľko možností na vyriešenie tohto problému (ďalšie budú uvedené v príslušných častiach). Prerušenie obvodu je najzávažnejšou možnosťou odpojenia služby od prevádzky. To však samo o sebe nedáva zmysel - je potrebný záložný plán. Môže byť poskytnutý protitlak (protitlak) na služby, ktoré odosielajú požiadavky (len si na to nezabudnite nakonfigurovať sieť služieb!), alebo napríklad zafarbenie stavovej stránky na červeno a presmerovanie používateľov na inú verziu stránky s „padajúcou veľrybou“ („Twitter je dole“).

Servisné siete umožňujú nielen definovať kedy bude nasledovať vypnutie a že toto bude nasledovať. V tomto prípade môže „kedy“ zahŕňať akúkoľvek kombináciu špecifikovaných parametrov: celkový počet žiadostí za určité obdobie, počet paralelných pripojení, čakajúce požiadavky, aktívne opakovania atď.

Pravdepodobne nechcete zneužívať prerušenie obvodu, ale je fajn vedieť, že máte záložný plán pre prípad núdze.

6. Automatické škálovanie

TL;DR: Zvýšte alebo znížte počet inštancií služby v závislosti od zadaných kritérií.

Servisné siete nie sú plánovače, takže nie vykonať škálovanie seba. Môžu však poskytnúť informácie o tom, ktorí plánovači sa budú rozhodovať. Keďže siete služieb majú prístup k celej prevádzke medzi službami, majú rozsiahle informácie o tom, čo sa deje: ktoré služby majú problémy, ktoré služby sú veľmi málo zaťažené (pridelená kapacita je premrhaná) atď.

Napríklad Kubernetes škáluje služby na základe využitia CPU a pamäte modulov (pozri našu správu "Automatické škálovanie a správa zdrojov v Kubernetes" - približne. preklad.), ale ak sa rozhodnete škálovať na základe akejkoľvek inej metriky (v našom prípade súvisiacej s návštevnosťou), budete potrebovať špeciálnu metriku. Zvládanie Páči sa ti to ukazuje, ako to urobiť pomocou vyslanec, Istio и Prometheus, ale samotný proces je dosť komplikovaný. Chceli by sme, aby to sieť služieb zjednodušila tým, že nám umožní jednoducho nastaviť podmienky ako „zvýšiť počet inštancií služieb auth, ak počet čakajúcich žiadostí presiahne limit do minúty.“

7. Kanárske nasadenie

TL;DR: Testujte nové funkcie alebo verzie služieb na podskupine používateľov.

Povedzme, že vyvíjate produkt SaaS a máte v úmysle uviesť na trh jeho skvelú novú verziu. Vyskúšali ste to v inscenácii a fungovalo to skvele. Ale stále existujú určité obavy z jej správania v reálnych podmienkach. Inými slovami, novú verziu musíte otestovať na skutočných problémoch bez toho, aby ste riskovali dôveru používateľov. Nasadenie Canary je na to skvelé. Umožňujú vám demonštrovať novú funkciu podskupine používateľov. Táto podskupina môže pozostávať z najvernejších používateľov alebo tých, ktorí pracujú s bezplatnou verziou produktu, alebo používateľov, ktorí vyjadrili túžbu byť „pokusnými králikmi“.

Servisné siete to implementujú tak, že vám umožňujú špecifikovať kritériá, ktoré určujú, kto uvidí akú verziu aplikácie, a podľa toho smerovať prevádzku. Pre samotné služby sa však nič nemení. Verzia 1.0 služby sa domnieva, že všetky požiadavky pochádzajú od používateľov, ktorí by ju mali vidieť, a verzia 1.1 je presvedčená, že to isté platí pre používateľov. Medzitým môžete zmeniť percento návštevnosti medzi starou a novou verziou a presmerovať rastúci počet používateľov na novú verziu, ak funguje stabilne a vaše „pokusné králiky“ dajú povolenie.

8. Modro-zelené nasadenia

TL;DR: Zaveďte skvelú novú funkciu, ale buďte pripravení okamžite vziať všetko späť.

Význam modro-zelené nasadenia je zaviesť novú „modrú“ službu, ktorá ju spustí súbežne so starou, „zelenou“ službou. Ak všetko pôjde hladko a nová služba funguje dobre, starú službu možno postupne deaktivovať. (Bohužiaľ, jedného dňa táto nová „modrá“ služba zopakuje osud tej „zelenej“ a zmizne...) Modro-zelené nasadenia sa líšia od kanárskych v tom, že nová funkcia pokrýva všetci naraz používatelia (nie sú súčasťou); Ide o to, aby bol pripravený „bezpečný prístav“ pre prípad, že by sa niečo pokazilo.

Servisné siete ponúkajú veľmi pohodlný spôsob, ako otestovať „modrú“ službu a v prípade problémov okamžite prejsť na fungujúcu „zelenú“. Nehovoriac o tom, že po ceste poskytujú množstvo informácií (pozri „Telemetria“ nižšie) o práci „modrej“, čo pomáha pochopiť, či je pripravená na plnú prevádzku.

Poznámka. preklad.: Viac o rôznych stratégiách nasadenia v Kubernetes (vrátane spomínanej kanárikovej, modrej/zelenej a ďalších) si môžete prečítať v v tomto článku.

9. Kontrola zdravotného stavu

TL;DR: Sledujte, ktoré inštancie služby sú funkčné, a odpovedajte na tie, ktoré už nie sú funkčné.

Kontrola zdravia (kontrola zdravia) pomáha rozhodnúť, či sú inštancie služieb pripravené prijať a spracovať prevádzku. Napríklad v prípade služieb HTTP môže kontrola stavu vyzerať ako požiadavka GET na koncový bod /health. Odpoveď 200 OK bude znamenať, že inštancia je zdravá, akákoľvek iná - že nie je pripravená na príjem návštevnosti. Servisné siete vám umožňujú určiť spôsob, akým sa bude kontrolovať funkčnosť, ako aj frekvenciu, s akou sa bude táto kontrola vykonávať. Tieto informácie sa potom môžu použiť na iné účely – napríklad na vyrovnávanie záťaže a prerušenie obvodu.

Kontrola stavu teda nie je samostatný prípad použitia, ale zvyčajne sa používa na dosiahnutie iných cieľov. V závislosti od výsledkov kontrol stavu sa môžu vyžadovať aj akcie mimo iných cieľov siete služieb: napríklad aktualizácia stavovej stránky, vytvorenie problému na GitHub alebo vyplnenie lístka JIRA. Servisná sieť ponúka pohodlný mechanizmus na automatizáciu tohto všetkého.

10. Zhadzovanie záťaže

TL;DR: Presmerovanie prevádzky v reakcii na dočasný nárast používania.

Ak je určitá služba preťažená návštevnosťou, môžete časť tejto návštevnosti dočasne presmerovať na iné miesto (t. j. „vypísať“, „preniesť“ (kôlňa) on tam). Napríklad do zálohovacej služby alebo dátového centra alebo do trvalého Pulsar tému. Výsledkom je, že služba bude naďalej spracovávať niektoré požiadavky namiesto toho, aby zlyhala a prestala spracovávať všetko úplne. Uvoľnenie záťaže je vhodnejšie ako prerušenie obvodu, ale stále nie je vhodné ho zneužívať. Pomáha predchádzať kaskádovým zlyhaniam, ktoré spôsobujú pád služieb.

11. Paralelizácia/zrkadlenie dopravy

TL;DR: Pošlite jednu žiadosť na niekoľko miest naraz.

Niekedy je potrebné poslať požiadavku (alebo určitý výber požiadaviek) na viacero služieb naraz. Typickým príkladom je posielanie časti produkčnej prevádzky do stagingovej služby. Hlavný produkčný webový server odošle požiadavku na nadväzujúcu službu products.production a len jemu. A servisná sieť inteligentne skopíruje túto požiadavku a odošle ju products.staging, o čom webový server ani nevie.

Ďalší súvisiaci prípad použitia siete služieb, ktorý možno implementovať popri paralelizácii prevádzky, je regresné testovanie. Zahŕňa odosielanie rovnakých požiadaviek na rôzne verzie služby a kontrolu, či sa všetky verzie správajú rovnako. Ešte som sa nestretol s implementáciou servisnej siete s integrovaným systémom regresného testovania ako Diffy, ale samotná myšlienka vyzerá sľubne.

12. Izolácia

TL;DR: Rozdeľte sieť služieb na mini-siete.

Taktiež známy ako segmentáciaIzolácia je umenie rozdeliť sieť služieb na logicky odlišné segmenty, ktoré o sebe nič nevedia. Izolácia je trochu ako vytváranie virtuálnych privátnych sietí. Základný rozdiel je v tom, že stále môžete využívať všetky výhody siete služieb (napríklad vyhľadávanie služieb), ale s pridanou bezpečnosťou. Napríklad, ak je útočník schopný preniknúť do služby v jednej podsieti, nebude schopný vidieť, aké služby sú spustené v iných podsietiach, ani zachytiť ich prevádzku.

Okrem toho môžu byť výhody aj organizačné. Možno budete chcieť podsieťovať svoje služby na základe štruktúry vašej spoločnosti a odbremeniť vývojárov od kognitívnej záťaže, keď musia mať na pamäti celú sieť služieb.

13. Požiadavka na obmedzenie rýchlosti, opakovanie a časové limity

TL;DR: Už nemusíte do svojej kódovej základne začleňovať náročné úlohy správy požiadaviek.

Všetky tieto veci by sa dali považovať za samostatné prípady použitia, ale rozhodol som sa ich skombinovať kvôli jednej spoločnej vlastnosti: preberajú úlohy správy životného cyklu požiadaviek, ktoré zvyčajne riešia knižnice aplikácií. Ak vyvíjate webový server v Ruby on Rails (neintegrovaný so sieťou služieb), ktorý odosiela požiadavky na backendové služby prostredníctvom gRPC, aplikácia sa bude musieť rozhodnúť, čo robiť, ak N žiadostí zlyhá. Budete tiež musieť zistiť, koľko návštevnosti budú tieto služby schopné spracovať a pevne zakódovať tieto parametre pomocou špeciálnej knižnice. Aplikácia sa navyše bude musieť rozhodnúť, kedy je čas vzdať sa a nechať požiadavku vyprchať (na základe časového limitu). A ak chcete zmeniť ktorýkoľvek z vyššie uvedených parametrov, webový server bude musieť byť zastavený, prekonfigurovaný a znova spustený.

Presunutie týchto úloh do siete služieb nielenže znamená, že vývojári služieb o nich nebudú musieť premýšľať, ale tiež to, že sa na ne dá pozerať globálnejšie. Ak sa použije zložitý reťazec služieb, povedzme A -> B -> C -> D -> E, treba brať do úvahy celý životný cyklus požiadavky. Ak je úlohou predĺžiť časové limity v službe C, je logické to urobiť naraz a nie po častiach: aktualizáciou servisného kódu a čakaním, kým nebude akceptovaná požiadavka na stiahnutie a systém CI nasadí aktualizovanú službu.

14. Telemetria

TL;DR: Zhromažďujte všetky potrebné (a nie celkom) informácie zo služieb.

Telemetria je všeobecný pojem, ktorý zahŕňa metriky, distribuované sledovanie a protokoly. Servisné siete ponúkajú mechanizmy na zber a spracovanie všetkých troch typov údajov. Tu sú veci trochu rozmazané, pretože počet možných možností je príliš veľký. Na zhromažďovanie metrík existuje Prometheus a ďalšie nástroje, ktoré možno použiť na zber protokolov plynule, Loki, vektor et al. (napríklad ClickHouse s naším zrubový dom pre K8 - cca. preklad.), pre distribuované sledovanie existuje Morský vták a tak ďalej. Každá sieť služieb môže podporovať niektoré nástroje a iné nie. Bude zaujímavé sledovať, či projekt dokáže Otvorte telemetriu poskytnúť určitú konvergenciu.

V tomto prípade je výhodou technológie servisnej siete, že kontajnery postranných vozíkov môžu v zásade zbierať všetky vyššie uvedené údaje zo svojich služieb. Inými slovami, máte k dispozícii jediný telemetrický zberný systém a servisná sieť dokáže spracovať všetky tieto informácie rôznymi spôsobmi. Napríklad:

tail logs z určitej služby v CLI;
monitorovať objem požiadaviek z dashboardu servisnej siete;
zbierajte distribuované stopy a posielajte ich do systému ako Jaeger.

Pozor, subjektívny úsudok: Všeobecne povedané, telemetria je oblasť, v ktorej je nežiaduce silné rušenie zo siete služieb. Zhromažďovanie základných informácií a priebežné sledovanie niektorých zlatých metrík, ako je úspešnosť žiadostí a latencia, je v poriadku, ale dúfajme, že neuvidíme, že sa objavia Frankensteinove zásobníky, ktoré by sa pokúsili nahradiť špecializované systémy, z ktorých niektoré sa už osvedčili a dobre preštudovali. .

15. Audit

TL;DR: Tí, ktorí zabudnú na lekcie histórie, sú odsúdení na to, aby si ich zopakovali.

Auditovanie je umenie pozorovania dôležitých udalostí v systéme. V prípade siete služieb by to mohlo znamenať sledovanie toho, kto odoslal požiadavky na konkrétne koncové body pre konkrétne služby, alebo koľkokrát sa za posledný mesiac vyskytla nejaká udalosť súvisiaca so zabezpečením.

Je zrejmé, že auditovanie veľmi úzko súvisí s telemetriou. Rozdiel je v tom, že telemetria sa zvyčajne spája s vecami ako produktivita a technická integrita, zatiaľ čo audit sa môže týkať právnych a iných záležitostí, ktoré presahujú čisto technickú sféru (napríklad súlad s GDPR – všeobecným nariadením EÚ o ochrane údajov).

16. Vizualizácia

TL;DR: Nech žije React.js – nevyčerpateľný zdroj efektných rozhraní.

Možno existuje aj lepší výraz, ale ja ho nepoznám. Mám na mysli jednoducho grafické znázornenie siete služieb alebo niektorých jej komponentov. Tieto vizualizácie môžu zahŕňať indikátory, ako sú priemerné latencie, informácie o konfigurácii postranného vozíka, výsledky kontroly stavu a upozornenia.

Práca v prostredí orientovanom na služby zahŕňa oveľa vyššiu kognitívnu záťaž v porovnaní s Jeho Veličenstvom Monolitom. Preto by sa mal kognitívny tlak za každú cenu znížiť. Jednoduché grafické rozhranie pre servisnú sieť s možnosťou kliknutia na tlačidlo a získanie požadovaného výsledku môže byť rozhodujúce pre rast popularity tejto technológie.

Neboli zahrnuté v zozname

Pôvodne som mal v úmysle zahrnúť do zoznamu niekoľko ďalších prípadov použitia, ale potom som sa rozhodol nie. Tu sú spolu s dôvodmi môjho rozhodnutia:

Multi-dátové centrum. Podľa môjho názoru to nie je ani tak prípad použitia, ako skôr úzka a špecifická oblasť aplikácie servisných sietí alebo nejaká sada funkcií, ako je vyhľadávanie služieb.
Vstup a výstup. Toto je príbuzná oblasť, ale obmedzil som sa (možno umelo) na prípad použitia „doprava z východu na západ“. Vstup a výstup si zaslúži samostatný článok.

Záver

To je zatiaľ všetko! Tento zoznam je opäť veľmi svojvoľný a s najväčšou pravdepodobnosťou neúplný. Ak si myslíte, že som niečo vynechal alebo mám niečo zle, kontaktujte ma na Twitteri (@luckerkins). Prosíme o rešpektovanie pravidiel slušnosti.

PS od prekladateľa

Titulná ilustrácia k článku je založená na obrázku z článku “Čo je to Service Mesh (a kedy ho použiť)?“ (Gregory MacKinnon). Ukazuje, ako sa niektoré funkcie z aplikácií (v zelenej farbe) presunuli do servisnej siete, ktorá medzi nimi zabezpečuje vzájomné prepojenia (modrá).

Prečítajte si aj na našom blogu:

Zdroj: hab.com