Blog
Letos jsme měli možnost navštívit další zajímavou vývojářskou konferenci. Tentokrát jsme se vydali do Amsterdamu na konferenci GOTO Amsterdam. Kromě prohlídky města, ochutnávky Heinekenu a dalších volnočasových aktivit jsme zvládli i celý program konference. V tomto článku přinášíme ta nejzajímavější témata, která nás napříč konferencí zaujala.
Autor: Roman Mařák
Current State of Automotive Security
Jedna z prvních keynotes se týkala bezpečnosti moderních automobilů. O crash testech se ale nemluvilo. Chris Valasek vyprávěl o tom, jak spolu se svým kolegou Charliem Millerem za pomoci předplacené karty amerického operátora Sprint našli díru v systému Jeepu Cherokee, která jim umožňovala vzdáleně vypnout brzdy nebo otočit volantem auta. Chyba se týkala 1,4 milionu aut a výrobci trvalo půl roku, než ji plně opravil. Jedním z hlavních výstupů přednášky bylo, že stávající systémy aut využívajících CAN bus (vytvořený v osmdesátých letech), nebyly navrženy jako systémy, které budou přístupné na jakékoliv externí síti.
Code as Risk
Kevlin Henney zde na příkladu uváděl, jak může snížení počtu řádků nejen zpřehlednit kód, ale zabránit vzniku chyb. Functionality is an asset, code is liability. Jako příklad uváděl to, že dnešní automobilky se v reklamách chlubí miliony řádků software v jejich autech. Oproti tomu raketoplán NASA měl jen několik desítek tisíc řádků kvalitního kódu – nebylo tam nic, co by se dalo odebrat. Dále zde pracoval s výsledky několika studií, podle kterých 77% produkčních chyb by se dalo pokrýt unit testy, nebo že v aplikacích je někdy až 93% konfiguračních parametrů neošetřeno oproti nevalidní konfiguraci. Mimo jiné je Kevlin Henney známý jako sběratel chybových hlášek (“blue screenů”) na veřejných místech – doporučuji sledovat jeho Twitter účet (https://twitter.com/KevlinHenney).
Machine Learning
Velké množství přednášek na konferenci bylo zaměřeno na machine learning. Mezi ty zábavnější patřila přednáška autora BachBot (https://bachbot.com/). BachBot je program, který dokáže skládat hudbu podobnou hudbě Bacha a to tak, že ani hudební experti nejsou schopni rozeznat originál od umělé inteligence. Autor (Feynman Liang) hovořil o tom, jak postupně tvořil model pro machine learning, jak počet vrstev a neuronů v nich ovlivňoval výsledek. Mě osobně nejvíce zaujala informace, že generovaná hudba začala znít jako Bach až ve chvíli, kdy do vstupních dat autor zařadil znak konce sloky. Tuto informaci Bach zapisoval do svých not, ale z hlediska hudby žádný význam nemá, alespoň ne pro hráče na hudební nástroj. Pro mě jako naprostého laika v machine learningu byla i zajímavá informace, že jednotlivé neurony měly integrované i “zapomínání” – občas v průběhu učení byly náhodně vypínány a tím se docílilo menší podobnosti se vstupními daty.
Autor: Roman Michalčík
Kotlin – Ready for Production
Přednáška se skládala ze tří oblastí. První část se věnovala historickému pozadí – proč vlastně Kotlin jako jazyk vznikl a jakým směrem by se měl podle JetBrains ubírat. Současná verze Kotlinu běží pod JVM, ale brzy bude možné Kotlin pouštět nativně. V době přednášky byl Kotlin native dostupný jako první release candidate. Neexistuje také žádné omezení v IDE. JetBrains vytvořilo pluginy pro Eclipse, Netbeans a podporován je samozřejmě v IntelliJ a Android Studiu. Druhá část přednášky nebyla pojata jako úvod do jazyka, jak by se dalo očekávat, nýbrž ve stylu, co vše dokážete s Kotlinem. Přednášející neopomněl zmínit možnost transformace Kotlinu do Javy a opačně. Zároveň však upozornil, že tato funkce není vhodná pro použití v produkci. Poslední část přednášky byla věnována výhodám Kotlinu. Bylo zde zmíněno, že Kotlin má vysokou křivku učení nebo že je připraven zůstat na trhu už jen proto, že veškeré nové nástroje a pluginy od JetBrains jsou napsány v tomto jazyce a na těchto nástrojích stojí celý jejich byznys.
Pragmatic Microservices for Organisational Scalability
Hlavní myšlenkou přednášky bylo, jak udělat vývojářům co největší pohodlí, aby se mohli soustředit pouze na vývoj (Organisational Scalability) a jak měřit jejich produktivitu, v případě, že je jim zajištěno maximální pohodlí na projektu. Jistě, dá se to udělat tak, že jim dopřejete dobré jídlo a nakoupíte jim nové MacBooky. Problém nastane, pokud zapojení do projektu trvá příliš dlouho. Ve vývoji neplatí přímá úměra, že čím více vývojářů máme, tím více máme nových commitů. Jak tedy zajistit, aby byl vývojář produktivní a byl schopen již druhý den udělat commit, který bude zařazen do produkce? K tomu aby tohoto jednoduchého cíle docílili, zvolili si cestu v podobě microservice architecture.
Závadou této architektury ale je, že neexistují žádné zkratky. Proto potřebovali několik základních kamenů:
- automatický deploy (kubernetes, docker, jenkins),
- centrální logování (ELK, logz.io),
- centrální monitoring (Datadog),
- centrální autentizaci,
- dynamické routování,
- asynchronní a synchronní komunikaci mezi microservices
Zvolená architektura jim umožnila škálovat práci vývojářů na několik striktně oddělených oblastí. Každou oblast měl na starost jiný tým, aby přechod mezi týmy nebyl nijak technicky a hlavně časově náročný. Každá microservice byla jako samostatný docker image. Nakonec se jim podařilo dosáhnout cíle. Až na minimální výjimky se každý vývojář soustředil na jednu oblast a byl v ní efektivní. Zároveň byla zajištěna rotace mezi týmy, která nijak nesnižovala jejich produktivitu. Každý nový člen týmu nebyl nijak blokován v práci a mohl se rychle zapojit do projektu. Na závěr přednášející vyzdvihl architekturu microservice a uvedl, že měřit produktivitu lidí na základě dat jako jsou story pointy, množství vývojářů v týmu, nebo jejich průměrné hodnoty dodávky za sprint, nelze. Důležité je, aby se každý člen týmu soustředil na jednu feature nebo oblast a nepodceňovat oblast plánování.
It’s Not Continuous Delivery If You Can’t Deploy Right Now
Přednáška od firmy ThoughtWorks, hlavního sponzora konference v Amsterdamu, byla o správném postupu při Continuous Integration (CI) a Continuous Delivery (CD). Ken Mugrage začal na úvod jednoduchou otázkou: “Kdo může nasadit novou verzi aplikace do pěti minut?”. K dokonalému release procesu nestačí využívat jen CI nástroj typu Bamboo nebo Jenkis. Je potřeba nastavit jisté ceremonie a pravidla vývoje. Důležitou součástí je například způsob branchování v gitu a nebo commitovat vše a často. CI nástroj by měl být nastaven tak, že kontroluje pouze přidanou část včetně všech dotčených testů. Pokud má projekt k dispozici postupné testování, nic mu pak nebrání během chvíle přejít do produkce. U testu je pak důležité jejich seřazení tak, aby se dali v co největší míře dělat paralelně. Nastavení specifických pravidel vývoje je potřeba i pro správné CD. Osvědčeným postupem je vytváření spínačů pro každou novou feature, čímž se oddělí vydání od nasazení. Jako vedlejší efekt tohoto postupu je důkladné správné plánování každé nové funkce a čistý kód. Vrcholem CD je minimalizovat výpadek produkční aplikace. Toho se dá docílit například dvěmi identickými instancemi, které po nasazení přepneme. Přidanou hodnotou takto duplikované aplikace je možnost okamžitého návratu zpět na fungující předchozí verzi.
Autor: Lukáš Marek
Cloud Trends
Přednáška byla o přechodu Netflixu na cloud a o aktuálních trendech ve vývoji aplikací do cloudu. Hlavní myšlenka u Netflixu byla, že jakmile začali streamovat filmy, tak se požadavky na jejich systém zvedli 100x. Rozhodli se tedy neinvestovat do noveho hardwaru, ale investovat do vývoje aplikací, které poběží v AWS a které budou dobře škálovatelné. Přecházeli tedy na architekturu microservisy a při nasazování používali load balancery, které na novou architekturu přesouvali uživatele postupně.
Trend přecházet na microservisy byl podle přednášejícího před pěti lety, dnešní a budoucí trend ve vývoji cloudových řešení je přechod na streamy funkcí (AWS lambda). Jedná se o serverless řešení, kdy pro jednu operaci slouží jedna funkce, která je vždy spuštěna, provede nějakou operaci a ukončí se. Tyto funkce jsou většinou za sebou a data si mezi sebou předávají pomocí front. Nejdůležitějším faktorem v takovém vývoji je mít vše automatizované (CI a CD) a monitorované (tzn. i s fail scénářem).
Applied microservices security (docker)
Zde se přednášející zaměřil na bezpečné používání Docker image. Důležité je nepoužívat latest verze ale vždy vybrat konkrétní vydanou verzi a pravidelně aktualizovat a testovat, zda je aplikace s novou verzí funkční. Dále je nutné nastavit uživatele, který spouští aplikace v Docker image, protože defaultně se pracuje s rootem. Při stahování dat kontrolovat, zda jsou data v pořádku (hash, klíč). Pull a push Docker image kontrolovat, zda nebyl poškozen (hash, klíč). Poslední důležitá věc je kontrolovat image na security problémy, protože se stává, že i oficiální image používá programy, u kterých je znám nějaký bezpečnostní problém.
Microservices bol.com
Přednáška od firmy, která provozuje eshop bol.com o provozování aplikace založené na microservices architektuře. Pokud provozujete tuto architekturu, je důležité mít monitoring všech částí systému a mít ošetřené to, že když jedna nefungující část neshodí celou aplikaci. Je nutné počítat se vším, co se může pokazit (např. microservice nejede, bugy v nové verzi, latence). Nejtěžší je vyřešit velké latence a callbacky při chybách.
Při řešení je nutné rozdělit systém na kritické a nekritické části. Bez monitoringu jsme slepí, tzn. je nutné monitorovat kritické části systému a řešit problémy ještě předtím než na ně narazí uživatel.
Na řešení timeoutů je možné využít knihovnu Histrix, které se nastavý malý timeout a v případě vypršení timeoutu se spustí nějaký fail callback, který zajistí izolaci chybových částí systému a popř. zajistí informaci pro klienta u kritických částí systému. Je nutné pracovat i s timeouty klientských aplikací.
Security log
Přednáška o tom, co dělat, když už je váš systém napadený a jak zajistit, aby i v tomhle případě ze systému neunikla žádná data. Prevencí bezpečnostních problémů je dodržování owasp, ale pokud už je systém napaden, tak je nutné to zjistit co nejdřiv. Statistika říká, že útok se vetšinou zjistí až po měsících. Na real-time zjištění je nutné mít monitoring na logy a je nutné logovat všechno, co by mohlo znamenat útoky (např. sql select union atd). Je možné nastavit real-time notifikaci po zjištění nějakého podezřelého dotazu (např. slack). Nástroje logstash, elastix, kibana, elastalert.
Možné řešení – load balancer, který po zjištění útoku přesměruje útočníka na sandbox aplikaci s fake daty a následně je možné útočníka sledovat, jak odhaluje vulnerabilities vašeho systému.
Chceš s námi vyrazit na konference?
Všichni naši vývojáři mají možnost vycestovat na domácí i zahraniční konference a načerpat tak znalosti o novinkách, trendech a tématech, které hýbou světem. Přidej se k nám a vydej se s námi do Amsterdamu, Vídně, Krakova, Kodaně nebo kamkoliv jinam…
Aktuálně hledáme seniorní Java / JEE Developery do kanceláří v Hradci Králové nebo Brně, ale i na home-office. Nebo tě více láká leadership a Scrum ti taky není cizí? Právě hledáme Scrum Mastera & Delivery Managera.
Zajímá tě něco jiného? Mrkni na všechny naše otevřené pozice a dej nám o sobě vědět, bez ohledu na to, zda máš rád front-end nebo back-end, jestli nějakou technologii umíš nebo ne. Pokud budeš ty sám chtít, dostaneš u nás příležitost naučit se, co tě zajímá nebo udělat něco výjimečného.
Poslední komentáře