Názory k článku Jak se v Seznamu spouští nová služba během 14 dní
-
L.Stříbrný podporovatelMám takový dotaz: Je tu nějaký čtenář, kterému tenhle článek přišel nějak víc přínosný?
Mě přijde, že článek může být rozhodně dobrý pro nové zaměstnance Seznamu, aby se zorientovali v interních procesech. Ale nám, lidem zvenku, popisy "kontaktovali jsme tým A, pak jsme to dohodli s B a nakonec dali vědět C" k ničemu moc nejsou.
A technické aspekty "Nepoužíváme X ale Y protože Z", které by mohly být zajímavé i pro nás zvenku, jsou zase popsány tak obecně, že se z nich moc poučení vzít nedá.
Vidíte to stejně? Nebo je zde někdo, kdo si z článku odnesl nějakou novou, podstatnou informaci?
-
To mas jak Stackshare. Muzes si vsimat, co se kde pouziva a mozna cast pouzit jako inspiraci pro vlastni architekturu.
I mne chybi podrobnejsi popis rozhodnuti. Treba jak se treba resi konzistence pri Couchbase + vice XDCR. Tim myslim: co kdyz klient pristoupi jednou do DC1, podruhe v te same sekunde do DC2? Nevadi, ze to neuvidi? Nebo obsluhuje vzdy jen jedno DC a zbyly vykon lezi ladem?
Dale treba: uvazovali jste nad jinymi NoSQL DB?
Nebo jake alternativy byli uvazovany u GraphQL? To jsou informace, ktere z meho pohledu chybi. -
Ďakujem za podnet, rád tieto veci rozpracujem do samostatného článku, ktorý to popíše viac do hĺbky. V tomto článku som detaily vynechal kvôli rozsahu.
Konzistencia u tohto druhu služby a nášho návrhu dátového modelu predstavuje problém iba v prípade, ak by používateľ rýchlo po sebe viac-krát hlasoval (vyriešené na strane frontendu) alebo poslal hlas a následne okamžite obnovil stránku, pričom by dostal odpoveď z iného datacentra (tu už môže pozorovať nekonzistenciu, ale je to veľmi okrajový prípad). Skrátka - používame všetky datacentrá, a nevadí ak pre každý request klient pristúpi do iného, pretože je krajne nepravdepodobné, že by si používateľ všimol nejakej nekonzistencie z dôvodu oneskorenia na strane replikácie.
Zvažovali sme samozrejme aj iné databázy, okrem iného napr. MongoDB a rôzne možnosti škálovania pre MariaDB a PostgresSQL, ale toto bude vhodnejšie rozobrať v samostatnom článku.
Okrem GraphQL sme zvažovali REST + Swagger. Niektoré služby s Seznamu používajú napr. FastRPC alebo iné možnosti, ale tieto sme zavrhli kvôli našim preferenciám a prioritám u tohto projektu.
-
Všechny AP databáze (z pohledu CAP theoremu) budou pro tento use-case fungovat podobně. Pak je to akorát o preferencích vývojářů a sysopů co jim prostě více vyhovuje.
Na Twitteru taky nikdo neřeší, že když pošle z mobilu tweet tak ho v PC nemusí hnedka vidět. To je prostě cena za eventual consistency.
-
Osobně jsem za takové články rád, i když bych také čekal více detailní vysvětlení výhod/nevýhod zvolených technologií a proč je upřednostnili před jinými.
Na druhou stranu i tak aspoň vidím, jaké technologie a postupy se reálně používají u velkých hráčů na trhu a kam se vývoj technologicky ubírá - což firmy často nerady zveřejňují.
Víc mi vadí "v namespacích Kubernetesu" a další jazykové lahůdky - vím, že pro zrychlení a zjednodušení komunikace v rámci týmu se takový slang běžně používá, ale v článku bych čekal lepší/propracovanější úroveň jazyka, neskloňovaní pojmů, které nejsou počeštěné, a používání českých ekvivalentů tam, kde existují...
-
No ano, ale "iptables chain" je v 1. pádě a nemá zavedený český ekvivalent, čili není důvod mít něco proti. Převést to na "iptables řetězec" je nevhodné používání doslovného překladu. Ovšem formulace "v iptablesovém chainu" je to, co mi vadí...
Zmíněný příklad, se dal česky napsat "Prvním krokem bylo vytvoření servisních účtů v namespace Kubernetes pro vývojové a předprodukční prostřední" a nebylo by co vytknout...
A třeba zkratky SLA a SLO a jiné méně známé pojmy stačí nechat, jak jsou, a jen jim přidat hyperlink na vysvětlení - koneckonců proto "otcové internetu" vymysleli webové stránky, aby se daly málo známé pojmy bez zbytečného okecávání v textu snadno směrovat na detailní vysvětlení.
-
Troufam si tvrdit, ze ne kazdy tady je odbornik na cloudove technologie. Ani ja nejsem a clanek mi proto prisel prinosny. Pravda je, ze to byl jen melky vhled do procesu nasazovani sluzby, ale presto to byl vhled do nasazovani sluzby.
Z pohledu treba zacinajiciho architekta zajimava inspirace. Ne kazdy clanek musi jit az do hloubky bajtu, prece :) Obcas se hodi i ten nadhled. Zase ale souhlasim, ze PR pekne.
Jinak je super, ze se i ve vetsi firme pouzivaji nove technologie a nejen umyvani mrtvol (vyborny vyraz z jednoho vlakna zde na foru). Nedavno jsem mel moznost mluvit s clovekem od front-endu v ING a vyrazy jako Go, WASM nikdy neslysel. Beru tedy tento clanek i jako dukaz, ze ne vsude je to stejne :) -
L.Stříbrný podporovatel
Tak, pokud člověk o dané oblasti netuší (prakticky) nic, tak ano, to že dostane podobný článek pod nos mu ušetří jeden dotaz do Google, uznávám :-)
Jinak nevím, mě ty technologie přijdou poměrně normální. Nic z toho mě nijak neohromilo. Virtuály, dockerizace, Kubernetes, to se používá poměrně běžně i ve velkých firmách už docela dost let.
Co se týče onoho dotyčného, tak úplně nevím, proč by měl znát zrovna Go. WASM nevím, jestli neznal tu zkratku (což klidně nemusí), nebo samotný pojem WebAssembly. To by bylo už trochu víc na pováženou, ale z praktického hlediska je ta technologie zatím stále hodně na začátku, takže zvlášť z pohledu tak konzervativního oboru, jako je bankovnictví. Spíš by bylo zajímavé, zda zná věci jako React, případně Typescript, Redux, GraphQL, ...
-
Mě to přišlo velmi přínosné a zajímavé. Věnuju se dost jiné oblasti vývoje, a mít takhle shrnuté postupy, věci co je potřeba vyřešit, best practices, role jednotlivých teamů, abych si udělal představu, co znamená správně nasadit jednoduchou službu do cloudu, to je pro mě zajímavé. Naopak podrobnější vrtání se v tom, proč se pro každý úkol volilo tohle řešení a ne jiné bych v tomhle článku asi neocenil, článek by se hodně nafoukl, a asi by se v něm trochu rozmlžilo to co je tam teď pěkně vidět.
Pobavilo mě "ubalení webpackem", chybí mi tam už jen "zapálit a vykouřit", je to běžná hantýrka (čekal bych "zabalíme webpackem") nebo interní vtípek?
-
Celý Seznam.cz postupně přechází na model, kde v interním cloudu provozuje každou službu vývojový tým, který za ní stojí...
Hned se mi vybavil článek z heuréky, kde mají taky týmy zodpovědnost jen za svojí "kostičku". A ejhle jak to tehdá dopadlo. Věřím, že máte lépe nastavené krizové scénáře.
https://www.lupa.cz/clanky/jak-robot-spamoval-e-maily-uzivatelu-heureky-a-jak-jsme-to-vyresili/
-
L.Stříbrný podporovatel
Jo, to jsem taky nepochopil. To mají členové všech vývojových týmů běžně přístup k produkčním datům, když to provozují? A když služba spadne v pátek večer, tak do pondělního rána neběží? Nebo snad každý tým drží 24/7 pohotovosti? Nechci podceňovat velikosti týmů pro ty služby, ale nepředpokládám, že jich bude moc, to by byl pěkný opruz, to bych se jim na to mohl vy... Tyhle tendence dělat z programátorů adminy fakt nemám rád. Já taky nechci po adminech, aby mi hledali a opravovali chyby ve zdrojovém kódu programů.
-
Ve vetsi firme je zodpovednost vsech tymu nutnost.
Admini jsou zodpovedni za to, ze bezi HW a SW infrastruktura. S infrastrukturou si rozumeji a vedi, jak ji nahodit.
Neco jineho je to u aplikaci. Kdyz sluzba spadne v patek vecer, tak admini mohou leda tak do soboty vecera cist zdrojaky a pak to mozna opravit. Developeri by meli vedet vice.
Odpovednost za vlastni sluzbu zlepsuje i sluzbu. Neni treba Dev opakovat, ze ten rucni failover na 50 kroku proste nefunguje. Sami se tomu vyhnou.
-
I v našem megacorpu zavedli oncally devu. Dost to pomohlo aby se některá jelita poučila přesně z důvodu které píšeš. Chyběla kultura odpovědnosti. Nebylo výjimkou u některých týmů řešit patching a release v pátek vecer. Typicky to chtěli devove ale odpovědnost za průser byla na těch mámach na matersky co delali aplikační adminy - alias tlacitkovy klikac se znalosti SQL.
Na druhou stranu to bývá i draha sranda neboť někteří berou ctvrt mega měsíčně hrubého.
Ono typicky high level dev většinou práci házel na aplikační support( tohle lidé jsou málokdy schopni něco technicky udělat ve smyslu opravy) nebo na admin. Admin většinou umí opravit leccos ale nerozumi aplikačními stacku ( ne fakt nerozumím 2000 ruznych aplikací naráz). -
L.Stříbrný podporovatel
> Nebylo výjimkou u některých týmů řešit patching a release
> v pátek vecer. Typicky to chtěli devove...To nechápu. Vývojáři udělají verzi zahrnující nějaké featury. Ta se otestuje a je připravená k nasazení. O jejím nasazení rozhoduje product owner / project manager / nějaký jiný manager. Ale rozhodně ne vývojář.
> Neco jineho je to u aplikaci. Kdyz sluzba spadne v patek vecer,
> tak admini mohou leda tak do soboty vecera cist zdrojaky...Ještě existuje taková věc, říká se jí provozní dokumentace. To je to, co mají číst admini. Zdrojáky číst nemají, stejně jako vývojáři nemají dělat adminy, už proto, že je k tomu potřebná jiná sada znalostí i osobních vlastností. Samozřejmě může nastat situace, kdy ani provozní dokumentace nepomůže a pak je potřeba okamžitá akce vývojářů, ale to je něco, co nastává maximálně jednou za hoooodně dlouho (na dobře vedeném projektu).
> Neni treba Dev opakovat, ze ten rucni failover
> na 50 kroku proste nefunguje.To je samozřejmě otázka požadavků na SW / akceptačních kritérií.
Co píšete jen potvrzuje, že snahy o přenášení provozních věcí na vývojáře jsou znakem špatného managementu. (Mluvím o velkých firmách, ne startupech o pěti lidech celkem, tam je situace samozřejmě jiná.)
-
> Věřím, že máte lépe nastavené krizové scénáře.
Našťastie áno. Aspoň si to myslíme :).
> To mají členové všech vývojových týmů běžně přístup k produkčním datům, když to provozují?
Iba tí, ktorí splnia nutné podmienky, okrem iného podpis NDA.
> A když služba spadne v pátek večer, tak do pondělního rána neběží? Nebo snad každý tým drží 24/7 pohotovosti? Nechci podceňovat velikosti týmů pro ty služby, ale nepředpokládám, že jich bude moc, to by byl pěkný opruz, to bych se jim na to mohl vy... Tyhle tendence dělat z programátorů adminy fakt nemám rád. Já taky nechci po adminech, aby mi hledali a opravovali chyby ve zdrojovém kódu programů.
Záleží vždy od povahy problému. Ako už ste dostali v odpovedi od niehoko iného, admini spravujú infraštruktúru, hardware, Kubernetes... cloud ako taký. Admini do zdrojového kódu nezasahujú.
Potom sú tu problémy, ktoré automaticky vyrieši orchestrácia, DDoS ochrana, balancer, či automatické škálovanie.
Vývojári riešia len problémy, ktoré sú spôsobené chybami v kóde. Nikto nie je tlačený do držania pohotovostí 24/7, je to vždy o dobrovoľnosti, a títo vývojári sa vždy striedajú. Vždy sa vzájomne dohodnú komu sa zrovna hodí držať pohotovosť aby to nekonfliktovalo s nikoho osobným životom (tak ako to len ide), a sú za to patrične kompenzovaní. Adminov z nich nerobíme, ako každý iný programátor aj naši vývojári riešia funkcionalitu a opravy chýb, a niektorí dobrovoľne môžu riešiť aj akútne chyby ktoré sa objavia v produkcii mimo pracovnú dobu.
> O jejím nasazení rozhoduje product owner / project manager / nějaký jiný manager. Ale rozhodně ne vývojář.
Samozrejme. Ale keď sa vyskytne akútny problém v produkcii, ktorý musí riešiť vývojár, tak pripraví a nasadí novú verziu, ktorá obsahuje iba opravu toho problému a nič ďalšie.
> Samozřejmě může nastat situace, kdy ani provozní dokumentace nepomůže a pak je potřeba okamžitá akce vývojářů, ale to je něco, co nastává maximálně jednou za hoooodně dlouho (na dobře vedeném projektu).
Áno, je nutné zároveň celý systém správne nastaviť a hlavne sa vyhnúť nezmyselným extrémom ktoré ste spomínali (admini zasahujú do kódu, príp. z vývojárov sú admini). Na tejto službe sme zatiaľ nemali žiaden pohotovostný incident pre vývojárov. Na hlavnej stránke sme naposledy incident mali pred viac než 3 rokmi.
ČLÁNKY DO MAILU