Když to tak poslouchám, tak si říkám jestli by nebylo lepší používat monolit a dělat release párkrát do roka, jak se to dělávalo dřív? Nebyla by to první firma, co by se vrátila od microservices k monolitu.
Zvažoval jsem, jestli toto téma zařadit i do přednášky, pro trochu kontextu, měl jsem ale pocit, že by přednáška byla už příliš dlouhá. Možná námět na samostatné téma pro příště 🙂 Každopádně microservices určitě nejsou bezchybné řešení a mají své výhody a nevýhody, což ale myslím obdobně platí i pro monolity. Ve skutečnosti Pipedrive začínal jako monolit (PHP na backendu, Backbone na frontendu) a původní PHP monolit ve značně upgradované a zredukované podobě stále běží (a pravděpodobně ještě dlouho poběží) 🙂 Motivací pro přechod na microservice architekturu bylo několik, ale řekl bych že jednou z hlavních byla developer experience. Když to hodně zjednoduším, dá se říct, že vývojáři už si příliš "sahali pod ruce". Výrazně tomu nahrává i organizační struktura, která je v R&D značně decentralizovaná (což je na jednu stranu super, na druhou stranu to vedlo k několika problémům zmíněným v přednášce) a každý tým ("tribe") spravuje vesměs samostatné domény. Když k tomu připočteme continuous deployment a přes 200 lidí v R&D, tak mít jeden monolit už začalo být neudržitelné. Dá se ale určitě bavit o tom jestli se s microservices nezašlo trochu daleko a není jich zbytečně mnoho 🙂 (Btw. organizační struktura je opět téma na téměř samostatnou přednášku, ale pro zájemce se lze více dočíst zde: medium.com/pipedrive-engineering/pipedrive-agile-framework-a-detailed-view-c0a9717f0c5a ).
Ze života, u nás velmi podobně. Nemůže za to ale GraphQL, na vině je fragmentace kódu a lidí. U nás jsme si tedy ještě výrazně "pomohli" vražednými deadliny (takže téměř žádný tooling) a nízkou odborností (+ jakoukoliv zkušeností s microservices) vedení projektu.
Jestli to dobře chápu, tak jste v BE přešli z graphql na rest a první co zmiňuješ jsou performance problémy? To je hodně divný, protože jedna z největších výhod graphql je právě perf metrika. (Teda za předpokladu, že je BE napsaný správně (dataloadery, cache atd)). Jinak souhlasim, že relay a fragmenty mi přijdou taky složité, ale reálně je člověk nemusí vůbec používat.
Ja v tomto prípade súhlasim s komentom od web_dev_cz, ako náhle ti začnu architektúru riadiť deadliny môžeš mať aj toho najlepšieho architekta na svete...
Enterprise architekty máme, pravdou ale je, že v době, o které mluvím v přednášce, jsme dedikované architekty neměli. R&D v Pipedrive bylo a do velké míry stále je značně decentralizované a pro architektonické otázky tehdy sloužily primárně 2 platformy - diskuze uvnitř týmu (ideální spíše pro "domain-specific" témata) a tzv. guildy (ideální pro rozsáhlejší témata, v tomto případě to byla "arch guilda"). Souhlasím ale, že architektura byla součástí problému, respektive fakt, že po nějakou dobu běžela v podstatě dvě paralelní GraphQL řešení (federated gateway a centralizovaný server). I proto tato retrospektiva, abychom sdíleli naše ponaučení 🙂 Věřím, že v současném setupu už by se něco takového těžko opakovalo.
Když to tak poslouchám, tak si říkám jestli by nebylo lepší používat monolit a dělat release párkrát do roka, jak se to dělávalo dřív? Nebyla by to první firma, co by se vrátila od microservices k monolitu.
Zvažoval jsem, jestli toto téma zařadit i do přednášky, pro trochu kontextu, měl jsem ale pocit, že by přednáška byla už příliš dlouhá. Možná námět na samostatné téma pro příště 🙂
Každopádně microservices určitě nejsou bezchybné řešení a mají své výhody a nevýhody, což ale myslím obdobně platí i pro monolity. Ve skutečnosti Pipedrive začínal jako monolit (PHP na backendu, Backbone na frontendu) a původní PHP monolit ve značně upgradované a zredukované podobě stále běží (a pravděpodobně ještě dlouho poběží) 🙂
Motivací pro přechod na microservice architekturu bylo několik, ale řekl bych že jednou z hlavních byla developer experience. Když to hodně zjednoduším, dá se říct, že vývojáři už si příliš "sahali pod ruce". Výrazně tomu nahrává i organizační struktura, která je v R&D značně decentralizovaná (což je na jednu stranu super, na druhou stranu to vedlo k několika problémům zmíněným v přednášce) a každý tým ("tribe") spravuje vesměs samostatné domény. Když k tomu připočteme continuous deployment a přes 200 lidí v R&D, tak mít jeden monolit už začalo být neudržitelné. Dá se ale určitě bavit o tom jestli se s microservices nezašlo trochu daleko a není jich zbytečně mnoho 🙂
(Btw. organizační struktura je opět téma na téměř samostatnou přednášku, ale pro zájemce se lze více dočíst zde: medium.com/pipedrive-engineering/pipedrive-agile-framework-a-detailed-view-c0a9717f0c5a ).
Ze života, u nás velmi podobně. Nemůže za to ale GraphQL, na vině je fragmentace kódu a lidí. U nás jsme si tedy ještě výrazně "pomohli" vražednými deadliny (takže téměř žádný tooling) a nízkou odborností (+ jakoukoliv zkušeností s microservices) vedení projektu.
to zní jako dream job. Můžeš prozradit alespoň první písmeno jména firmy kde se tohle dělo? :)
@@CyrilUrban-nw8vd taky by mě to zajímalo, a napiš klidně celej název
Jestli to dobře chápu, tak jste v BE přešli z graphql na rest a první co zmiňuješ jsou performance problémy? To je hodně divný, protože jedna z největších výhod graphql je právě perf metrika. (Teda za předpokladu, že je BE napsaný správně (dataloadery, cache atd)). Jinak souhlasim, že relay a fragmenty mi přijdou taky složité, ale reálně je člověk nemusí vůbec používat.
Tyjo, microservices hell.
A nebude spíše problém v architektuře celého toho řešení? Máte tam enterprise a solution architekty? Tohle musí na provozu stát neskutečné peníze.
Ja v tomto prípade súhlasim s komentom od web_dev_cz, ako náhle ti začnu architektúru riadiť deadliny môžeš mať aj toho najlepšieho architekta na svete...
Enterprise architekty máme, pravdou ale je, že v době, o které mluvím v přednášce, jsme dedikované architekty neměli. R&D v Pipedrive bylo a do velké míry stále je značně decentralizované a pro architektonické otázky tehdy sloužily primárně 2 platformy - diskuze uvnitř týmu (ideální spíše pro "domain-specific" témata) a tzv. guildy (ideální pro rozsáhlejší témata, v tomto případě to byla "arch guilda").
Souhlasím ale, že architektura byla součástí problému, respektive fakt, že po nějakou dobu běžela v podstatě dvě paralelní GraphQL řešení (federated gateway a centralizovaný server). I proto tato retrospektiva, abychom sdíleli naše ponaučení 🙂 Věřím, že v současném setupu už by se něco takového těžko opakovalo.