středa 16. dubna 2014

CZ Podcast 97 - Internet věcí

V 97. dílu jsme velmi rádi přijali pozvání do firmy Inmite, kde nás čekala celá řada technologických hraček - Google glasses, Oculus rift, Leap motion, a Air-Bond hardwarového zařízení přímo od InMite - a povídání které zprostředkovali pánové Michal Šrajer a Petr Dvořák. Videa najdete na naší fanouškovské stránce, kde uvítáme i vaše ohlasy.

pondělí 7. dubna 2014

Zdeformovaný programátorský trh aneb chybějící kus pokory

Docela jsem si zvykl, a bylo to zvykání příjemné, že má profese a vůbec celé odvětví je nadstandardně dobře placeno. Když jsem na podzim roku 2001 nastupoval do svého prvního zaměstnání, činila má hrubá mzda dvanáct tisíc korun. To byly na poměry maloměsta, ve kterém jsem tehdy žil, a pochopitelně doby, velmi slušné peníze. Úroveň mých vědomostí s bídou odpovídala úrovni programátorského eléva a jedinou devizou byl můj ničím neutuchající elán. Postupem času vzrůstala moje mzda, a to i násobně, a já měl pocit, že to odpovídá tomu, kolik jsem si toho odkroutil a kolik jsem se toho naučil. Po nějaké době jsem zjistil, že od určité hranice přestávám rozlišovat jestli je výplatní pásce o pár tisíc víc a nebo méně. Zní to možná komicky, ale kdyby mi tehdy přišla polovina výplaty, asi bych to ani nepoznal.


V roce 2010 jsem nastoupil do GoodData a moje tehdejší mzda byla nižší než v předchozím zaměstnání. Dostal jsem sice stock options (velmi zjednodušeně řečeno budoucí podíl na prodeji firmy), ale ty nemají, až do prodeje firmy a nebo její vstupu na burzu, cenu ani papíru na kterém jsou vytištěny. Bral jsem to tak, že je to dobrá příležitost se něco nového naučit. Kdybych to bral z pohledu mzdy, nedával tento krok z krátkodobého hlediska žádný smysl. Z dlouhodobého hlediska to teoreticky mohlo být zajímavější, protože jsem mohl doufat v to, že se naučím něco specifického, co mi dá přidanou hodnotu na trhu práce. Po čtyřech letech v GoodData stále nemám mzdu, která by odpovídala té z předchozího zaměstnání, ale za to vím, že jsem se naučil velkou spoustu věcí a získal vhled do oblastí, o kterých jsem neměl ani ponětí nebo jsem je vnímal jenom povrchně - cloud, škálovatelnost, NoSQL, distribuované systémy, agile a tak bych mohl pokračovat dále. Z mého pohledu jasná konkurenční výhoda na trhu práce.


Od určité doby jsem se začal účastnit pohovorů s případnými kandidáty na pozice k nám do firmy. Skoro vždy mě překvapilo, jaká byla disproporce mezi tím, co si člověk představoval na výplatní pásce, a tím, kolik toho potom věděl. K vysvětlení toho zjevného rozporu si stačilo nechat aktivovat možnost zasílání pracovních nabídek z LinkedIn. Jestliže je mi někdo ochoten zaplatit 4500,- eur za měsíc a práci, která by odpovídala mnou kladeným nárokům na začínajícího vývojáře, pak je něco v nepořádku. To se dá vysvětlit různě. Mohu mít přemrštěné nároky na vývojáře a nebo jsou tady firmy, které reálně přeplácejí a vytváří tyhle deviace.


Můžeme si tu na krásně říkat, že to je zákon trhu - nabídka odpovídá poptávce - ale výsledek na sebe nemusí nechat dlouho čekat. Pokud je méně kvalifikovaná práce placená jako práce, která vyžaduje vyšší kvalifikaci (úroveň vědomostí, dovedností a zkušeností), pak si dříve nebo později někdo spočítá, že za tu samou práci někde na východ od Košic zaplatí mnohonásobně méně. Jsem dalek tvrdit, že na naší práci se třesou hordy indických vývojářů dřepících někde v Bengalore, ale rozhodně bych to nebral na lehkou váhu. Já osobně raději příjmu a dobře zaplatím eléva, který se bude ochoten učit novým věcem. Budu u něj mít jistotu, že nebude zhýčkaný pětihodinovou pracovní dobou a kolbenkářským přístupem. Není jistě bez zajímavosti, že mzda dlouhodobě nefunguje jako hlavní motivační faktor. Mnohem důležitější jsou, co se týká nejen pracovního výkonu a spokojenosti, vnitřní motivátory - baví mě práce, učím se nové věci, dává má práce smysl, vidím za svojí práci nějaký výsledek.


Hloupý kdo dává, hloupější kdo nebere. Pokud vám někdo nabídne krásné peníze a je to pro vás motivace, určitě je v pořádku na takovou nabídku kývnout. Je to soukromá věc každého a nezadatelné právo. Každopádně trocha pokory by nám všem prospěla...

neděle 16. března 2014

Svět mikro služeb

Architektura většiny aplikací odpovídá jedné velké kouli bahna, pro kterou se vžilo označení monolitická. Na úrovni aplikace jsou typickými rysy bobtnající závislosti na knihovnách, vzájemné svázané části aplikace vedoucí k nulové odolnosti vůči selhání jednotlivých částí. Na úrovni operačního systému se jedná o jeden velký proces s velkými nároky na zdroje. Monolitické aplikace mají jednu obrovskou výhodu a to je jednoduchost vývoje. Nemusíte řešit, jak bude daný kód spolupracovat se zbytkem systému, prostě ho napíšete a on se stane součástí aplikace. Monolitické aplikace mají ovšem celou řadu nevýhod. Můžete je škálovat pouze jako celek. To vede k neoptimálnímu využití zdrojů. V případě selhání jedné části aplikace, byť absolutně nekrytické pro fungování z pohledu uživatele, dochází lavinovitě k selhání celé aplikace. Klasickým příkladem může být memory leak, který postihne celou aplikaci. Alternativou k monolitickému uspořádání aplikace představuje architektura micro services.


Architektura micro services vychází z toho, že aplikace a její funkcionalita se skládá z velkého množství malých služeb pospojovaných do větších celků. Důležitou charakteristikou tohoto architektonického přístupu je nebo by měla být izolovanost jednotlivých služeb. Adrian Cockcroft (Netflix, eBay, Sun) prosazoval myšlenku, že každá mikro služba může selhat a její konzumenti s tím musí apriori počítat. Byl to právě Adrian Cockcroft a firma Netflix pod jeho vedením, která postavila celý svůj stack právě na této architektuře.


Na velikosti záleží

Velikost mikro služby se těžko kvantifikuje. Četl jsem názory, že by to mělo být maximálně pár stovek řádků kódu, ale to mi nepřijde směrodatné. Mnohem důležitějším aspektem je dodržení takzvané jedné odpovědnosti (single responsibility principle). Každá mikro služba by měla dělat právě a jenom jednu věc - login, checkout, hledání, zobrazení nákupního košíku atd. V případě REST rozhraní mi přijde jako vhodná granularita jeden resource odpovídající mikro službě nebo alespoň funkcionalita z pohledu uživatele. Docela velkým nebezpečím je opačný extrém, tedy že aplikaci příliš fragmentujete vytvořením stovek mikro služeb. Každá mikro služba má svoje nároky, například v Jave musíte počítat s režií pro JVM, a musíte počítat se síťovým overheadem pro každou komunikaci mezi jednotlivými mikro službami. Někde jsem viděl poměrně vtipné přirovnání, že mikro služby představují Enterprise Java Beans pro hipstery.


Skryté náklady

Nejvíce přitažlivé na monolitické architektuře jsou nulové náklady, které máte s přidáváním nových vlastností do aplikace. V případě mikro služeb potřebujete poměrně slušnou infrastrukturu a to pro každou ze služeb. Řekněme, že máme mikro služby, které mají všechny jednotné REST rozhraní (HTTP, JSON). Pro každou z mikro služeb potřebujete kontejner, ve kterém poběží. Potřebujete monitoring, alerting. Každá z mikro služeb by měla být high available. Klienti služeb, další mikro služby, se musí nějakým způsobem dozvědět kde tyto služby běží. Můžete začít tím, že endpointy služeb bude někde v konfiguraci, ale dříve nebo později budete potřebovat nějaký registr služeb a jejich endpointů, protože služby mohou vznikat v nových verzích a nebo kolabovat v průběhu života celé aplikace. To se bavíme jenom o nárocích na běhové prostředí, k tomu je potřeba připočítat automatizaci na úrovni deploymentu (Puppet, Chef).


Kdy začít

Vždycky když merguji pull request, trnu hrůzou z představy, aby nějaká chyba nesprovodila ze světa celý server a já nemusel vstávat ve dvě hodiny ráno a něco řešit. Můžete si zkusit aplikaci rozdělit na kritické a nekritické komponenty z pohledu uživatele, zkusit se zamyslet, jestli byste mohli efektivně škálovat jednotlivé části aplikace, ale nejspolehlivější indikátor je obava, že už vám komplexita aplikace přerůstá přes hlavu. V takovou chvíli je vhodné začít přemýšlet o mikro službách. Velkou výhodou tohoto architektonického přístupu je, že můžete migrovat postupně jednotlivé části aplikace. Nemusí se hned od začátku jednat o velký třesk. Mikro služby nejsou sami o sobě spásou, i zde můžete udělat chybu, ale pokud to uděláte dobře, je velká pravděpodobnost, že chyba složí jenom jednu malou část aplikace.

Zdroje a užitečné odkazy

sobota 15. března 2014

CZ Podcast 96 - QA panel v Avastu

Do 96. dílu jsme si pozvali, tedy co my, ale Roumen pozval a zorganizoval, QA diskuzní panel ve společnosti QA. Společně s ním dorazil Pavel Chytil, Lukáš Hasík a Jaromír Cvrček. Celou dobu jsme se si povídali o tom, jak klucí zajišťují kvalitu antivirového řešení Avastu, jak využívají Virtual Box pro testování nových verzí a vůbec o infrastruktuře, kterou používají. Vaše ohlasy, komentáře a otázky uvítáme na naší oficiální Facebook stránce.

čtvrtek 27. února 2014

Go není další Jenkins a je to dobře

ThoughtWorks oznámili uvolnění platformy Go jako open source. Go realizuje myšlenky, které ThoughtWorks dlouhodobě razí tj. Continuous Integration a především Continuous Delivery. Samotné Go je zajímavé z několika úhlů pohledu. Přestože existuje celá řada CI serverů, s uceleným konceptem realizace Continuous Delivery zatím nikdo nepřišel až do představení Go - kolega to trefně nazval post Jenkinsovou érou. Go je postavený podle myšlenek a zkušeností, které popsali pánové Jez Humble a David Farley v knize Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

One size fits all vs. Lego

Jenkins se stal v mnoha firmách páteří Continuous Integration infrastruktury neboť nabízí velmi dobrou rozšiřitelnost. Existuje celá řada rozšíření, pomocí kterých můžete nad Jenkinsem vystavět prakticky jakýkoliv proces v oblasti testování a nasazení. Jenkins a jeho rozšíření představují Lego skládačku, ze které si postavíte cokoliv. Když vám náhodou nějaká funkcionalita chybí, můžete si jí naprogramovat. Díky Lego konceptu dostanete kostičky, které si musíte sestavit dohromady, aby dávaly dohromady požadovanou funkcionalitu. Bohužel neexistují v uvozovkách Lego stavebnice, které by obsahovaly jenom otestovanou sadu realizující konkrétní use case například Continuous Delivery. Lego koncept umožňuje teoreticky postavit cokoliv, ale prakticky, a to jsme si v GoodData vyzkoušeli mnohokrát, to je velmi nákladné a velmi křehké.

Náklady na skládání kostiček nesete nejenom na úrovni vývoje a testování výsledného řešení, ale i jeho udržování. Při vývoji si musíte nejdříve najít pluginy, pomocí kterých by šel váš scénář realizovat, zjistit jestli by spolu nějak mohly spolupracovat a potom je umě pospojovat dohromady. Prakticky jakýkoliv upgrade Jenkinse a nebo jednoho z jeho rozšíření může vést k tomu, že se celé řešení rozsype jako domeček z karet. Nezanedbatelnou roli hraje doménová znalost problému např. Continuous Delivery. Pokud nevíte co máte postavit, těžko to postavíte.

Doménová znalost Continuous Delivery a realizace jeho základních konceptů přímo v jádru systému je podle mého obrovskou výhodou Go oproti Jenkinsu. Go nabízí rozšiřitelnost, díky které můžete systém přizpůsobit vašim potřebám. Go mi dává smysl v tom, že se nesnaží profilovat jako další Continuous Integration server, ale jako realizace Continuous Delivery infrastraktury. Go nebude zcela určitě Jenkins killer, stále tu budou společnosti, které budou využívat jeho Lego vlastností v oblasti testovací infrastruktury a Continuous Integration.

Kdybych měl dnes znovu začít na vývoji platformy, kterou se v GoodData snažíme realizovat Continuous Integration/Delivery viz Evoluce Continuos Integration infrastruktury v GoodData, určitě bych jí začal stavět právě nad Go. Ušetřilo by nám to spoustu programování a práce s ohýbáním a laděním Jenkinse (pipeliny, propagování artefaktů, vizualizace a mohl bych pokračovat dál). S Go nemám žádné zkušenosti a možná se tahle implementace dlouhodobě neprosadí, ale koncept je krok správným směrem. Mimochodem dejte mi vědět pokud by vás práce s Go zajímala.