Vlákno názorů k článku Jak se v Seznamu spouští nová služba během 14 dní od L. - Mám takový dotaz: Je tu nějaký čtenář, kterému...

Má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.

Proč ne nějakou Cassandru nebo ScyllaDB? To by mohlo fungovat i lépe ne?

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.

Obe tieto varianty sme zvažovali (napr. Cassandru používame na inej službe), ale po konzultácii s adminmi sme dospeli k záveru, že CouchBase bude vhodnejšia voľba.

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ší/propraco­vanější úroveň jazyka, neskloňovaní pojmů, které nejsou počeštěné, a používání českých ekvivalentů tam, kde existují...

Když jsem před dávnou dobou psal článek, tak mi korektor "iptables chain" přepsal na "iptables řetězec". To byla teprve chuťovka to pak číst.

Mně osobně tento slang, který se běžně používá při komunikaci mezi vývojáři, vyhovuje i v článcích. Nemusím si to pak překládat do pojmů, kterým rozumím.

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í.

"v iptablovám chainu", nikoliv "v iptablesovém chainu" prosím :)

Ano, není to správně, ale lidi to tak říkají.

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 :)

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, ...

Apropo nove technologie. Technologicki hipsteri uz neuznavaju Kubernetes (to je uz pre nich mainstream - mrtvola :-D).
Uz vyznavaju opsless: nakodia si infrastrukturu (infrastructure as a code) + kod a pushnu ho cez CI/CD do produkcie, kde si to uz orchestration osefuje.