Klávesové zkratky na tomto webu - rozšířené Na obsah stránky

DevOps

|

Vlhkým snem všech moderních společností je vyvíjet software rychleji. Nechávají se opít vidinou, že zavedením Agile se rapidně zrychlí a zlevní vývoj software a zázračně dojde ke zvýšení kvality. Tím, že se zvýší množství rituálních meetingů, se vývoj nezrychlí, ani se zásadně nezmění kvalita. Problém totiž není v IT organizacích firem, ale v samotném prostředí firmy.

Firmy vytvářejí nákladová střediska a odpovědnostní sila. Proč? Protože se mnohem snadněji rozděluje moc. Tento manažer je zodpovědný za chod vývoje, tento za operations, tento za sales, jiný za marketing… A to jsou pole jejich moci. Takové pole si opečovávají a řídí, podle svého nejlepšího uvážení. Jsou hodnoceni za výkon (rostoucí KPIs) jím svěřených oddělení a proto se snaží z nich vyždímat co nejvíce. Zvyšuje se efektivita, osekávají se náklady a to vše v rámci sila dané specializace.

Tito manažeři se schází v pravidelných intervalech na schůzkách, kde rozhodují o tom, jaká bude strategie, jaký bude plán činností na další časové období a kolik na to uvolní prostředků. Také si stanoví deadlines, aby se vědělo, kdy to má být hotové.

Zavedením Agile do určité části organizace se často povede zavést element predikovatelnosti. Dokážete totiž měřit kolik práce je tým schopný odbavit za nějakou časovou jednotku. Tým se zlepšuje ve schopnosti odhadovat časovou náročnost zadávaných úkolů tím, že to dělá pravidelně v poměrně krátkých časových rozestupech a že je nucen pracovat v rámci omezeného času. V důsledku je tým nucen se naučit dělit požadavky na menší jednotky, které je schopný v omezeném čase dodat. Tím postupně vzniká kadence dodávané hodnoty. Často mylně považovaná za vyšší rychlost vývoje. Rychlost vývoje se nemění, jen dochází ke zvýšení frekvence dodání, ale zároveň ke snížení objemu dodávané hodnoty.

Snížením objemu dosáhneme i dalšího efektu: Čím jsou změny menší, tím jsou snáze pochopitelnější a snáze se odhalují chyby. Nebo je mnohem menší prostor pro zanesení chyb. To může mít pozitivní vliv na výslednou kvalitu.

Ve výsledku můžeme být lokálně schopni dodávat častěji řešení požadavků a ve větší kvalitě – pokud se splní předpoklad snížení objemu dodávek a nastolení jejich pravidelného rytmu dodávání. Co nám však chybí je big picture. Děláme správnou věc? Budou o ni mít zákazníci zájem? Bude schopná ustát případný velký zájem zákazníků? Jak je řešení v takovém případě schopné škálovat? Jak poznají lidé, co budou systém provozovat, že je vše v pořádku, případně, co se v něm děje a jak na to mají reagovat?

Kanban s kroky přes celou organizaci

DevOps nejde zavést nařízením shora. Největší část DevOps tvoří kultura. Kultura učení se a sdílení. Než se pustíte do zásadních změn, musíte se začít zaměřovat na bolesti a problémy, které máte. Často vidíme jen příznaky problémů. Proto je nutné zavést zpětnovazební systémy, které podpoří Kaizen. Dále je nutné se naučit analyzovat problémy tak, abychom se dostali k jejich podstatě. K tomu by nám měly pomoci agilní retrospektivy a třeba metoda Pěti proč. Jakmile chápeme, kde máme problémy a co s nimi můžeme dělat, můžeme nahajrovat několik DevOps inženýrů a máme problém vyřešený…

Samozřejmě si dělám legraci. DevOps je kultura úzké spolupráce Developers a IT Operations lidí, nikoliv nahrazení dvou specialistů jedním univerzálem. Tím bychom vytvořili další silo, kterých se v DevOps chceme zbavit, protože mají negativní dopad na čtyři klíčové metriky:

  1. Lead Time – čas od vzniku požadavku zákazníka do jeho uspokojení
  2. Deployment Frequency – frekvence nasazení nových verzí do produkce
  3. Mean Time to Restore – průměrná doba potřebná za zotavení z produkčního incidentu
  4. Change Fail Percentage – procento nepovedených nasazení do produkce
Cartoon – Siloes

Proč jsou tyto metriky pro DevOps klíčové? Protože celkem komplexně měří důležité aspekty byznysové agility. Lead Time je dán vyspělostí celé organizace. Schopností komunikovat a spolupracovat. Optimalizace lead time pomocí automatizace má v ranné části adopce DevOps pramalé dopady, protože většina času (řádově měsíce) je propálena na byznys procesech, nikoliv v IT.

Tohle je věc change managementu a je na adopci DevOps to nejtěžší, protože vyžaduje spolupráci napříč odděleními. Práce nutně musí opustit sila a musí se začít organizovat podle jednotlivých value streamů. Společnost musí pro úspěšnou adopci DevOps přejít na Lean myšlení – změnit způsob jakým vede účetnictví, jakým přiděluje zdroje, jak oceňuje vzniklou hodnotu atd.

V této fázi dokážeme zmapovat neoficiální organizační strukturu a pomoci nalézt agenty změny – klíčové lidi, kteří jsou schopní celý proces transformace pohřbít nebo pomoci s jeho úspěchem. Například náš nástroj Frank a naši koučové vám pomůžou tyto lidi včas identifikovat a pracovat s nimi tak, aby se snížila rizika přechodu na DevOps. Protože většina velkých transformací selhává právě na lidském faktoru a odporu vůči změnám, je potřeba s lidmi pracovat, vše jim vysvětlit a do procesu je zapojit od samotného začátku. Jak už jsem psal, DevOps je kultura spolupráce.

Bezpečnější Traefik

|

V našich Docker Swarm clusterech používáme pro řízení provozu reverzní proxy Traefik. Traefik se stará o autodiscovery služeb v clusteru, jejich routování a terminaci TLS (vč. generování certifikátů pomocí Let's Encrypt).

Ve výchozím nastavení je však TLS v režimu široké kompatibility. To znamená, že jsou povoleny starší (a nebezpečnější) verze protokolu a také sady šifer, které už dnešním požadavkům nedostačují. Musíme tedy sáhnout po ruční konfiguraci, abychom dosáhli lepšího výsledku.

TLS v1.2 a silnější šifry

Pro konfiguraci Traefiku používáme CLI argumenty v docker-compose.yml, základní nastavení TLS endpointu vypadá takto:

"--entrypoints=Name:https Address::443 TLS Compress:true"

Pro omezení starších verzí přidáme konfiguraci minimální verze:

TLS.MinVersion:VersionTLS12

A pro silnější šifry podle Mozilla Modern:

TLS.CipherSuites:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Výsledná konfigurace pak vypadá takto:

"--entrypoints=Name:https Address::443 TLS TLS.MinVersion:VersionTLS12 TLS.CipherSuites:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Compress:true"

Poznámka: TLS v1.3 není v Traefik 1.x podporovaná. Připravovaná verze 2.x již podporu pro TLS v1.3 obsahuje.

HTTP Strict Transport Security

Silnější šifry a modernější protokol s lepšími hashovacími funkcemi jsou super, ale ne tak moc, když vám je někdo po cestě odstraní. Je dobré dát světu vědět, že fakt chcete komunikovat po TLS. A k tomu slouží HTTP hlavička Strict-Transport-Security. V Traefiku nejde zapnout globálně, ale musí se nastavit na každém endpointu zvlášť. My to opět, kvůli autodiscovery, děláme pomocí deploy\labels sekce v docker-compose.yml:

traefik.frontend.headers.forceSTSHeader: 'true'
traefik.frontend.headers.STSSeconds: 315360000
traefik.frontend.headers.STSIncludeSubdomains: 'true'
traefik.frontend.headers.STSPreload: 'true'

Více informací o HSTS najdete v přednášce Michala Špačka.

TypeScript a typový sebeklam

|

Tak, jak je to v historii už zvykem, světová scéna opět konverguje k řešení, které je nešťastné. Ať už je to nepochopitelný vzestup Pythonu, kvůli Data Science, na který je objektivně nevhodným jazykem, nebo TypeScript na poli web developmentu. Programátoři podléhají módním trendům více než vědě a inženýrskému přístupu.

Lidí bez patřičných znalostí Computer Science a praktických zkušeností je moře, které neustále zvedá svou hladinu. Většina podléhá efektu stáda a rozhoduje se na základě marketingových masáží výrobců špatných IDE a jazyků a drahých konzultačních služeb. V davu přetrvává přesvědčení, že silné statické typy zlepšují návrh a zaručují funkčnost. Ve skutečnosti návrh neskutečně komplikují a to co dokáží, je eliminovat chyby na úrovni překlepů. Realita je taková, že tyto jazyky a frameworky jsou navržené tak, aby generovaly práci lidem zvaným XY Developer Evangelist a Enterprise XY Consultant, kteří jsou generátory nemalých zisků těchto výrobců.

Nástroje typu TypeScript slibují statickou analýzu a typovou bezpečnost v silně dynamickém světě. Tam, kde je agilita a dynamičnost vaší konkurenční výhodou, si dobrovolně lámete ruce pomocí enterprise návrhových vzorů, zavíráte dveře jednoduchému návrhu, kvůli schopnosti odhalit pár překlepů. TypeScript vám nepomůže se správným/lepším návrhem architektury, který má 100× větší dopad na vaši produktivitu a výslednou efektivitu. Místo toho vám dodává pocit falešného bezpečí. Ano, falešného, protože TypeScript nemá vliv na runtime, kde stále existují coercions a dynamičnost, kde vám (nejen) po drátě přijde úplně něco jinýho, než říkají vaše typy. TypeScript vás dokonce nenechá přeložit naprosto korektní program, který neodpovídá jeho omezené schopnosti popsat skutečné typy.

Lidi raději věří lži než aby žili v nejistotě…

Související studijní materiál

Typové systémy v dynamických jazycích

Efektivní programování s dynamickými jazyky

Generování Twitter Card obrázků

|

Sociální média umožňují (v rámci boje o uživatelovu pozornost) postovat bohaté příspěvky. V případě Twitteru jde o tzv. Twitter Cards, které umožňují nahradit odkaz požadovanými metadaty. Mezi ně patří název, popisek a obrázek. Můžete si dokonce vybrat, jestli chcete čtvercovou ikonu nebo pořádnej 2:1 billboard. No a protože jsem attention hore, rozhodl jsem se pro ten větší formát…

Jenže se mi nechce lozit po fotobankách a hledat nějakou bechderoucí fotečku, která s mými tématy bude asi těžko souviset. Takže jsem musel vymyslet něco jinýho. Docela se mi líbí, jak na feedu vypadaj vložený prezentace ze Speakerdecku. A protože se mi vyloženě líbí, jak vypadaj moje prezentace, tak jsem se rozhodl, že to obšlehnu. Aby se na první pohled dalo poznat, že nejde o prezentaci, ale o blog, rozhodl jsem se pro jinou barvu pozadí. Ale bílá futura zůstává. :)

Tak, nápad by byl, teď už jen jak ho realizovat?

Nejprve jsem si říkal, že bych mohl udělat šablonu ve Figmě a přes jejich API generovat obrázky. Jenže se mi nechce (zatím) učit se jejich API a zavádět vzdálená volání do generátoru, když jsem se jim tak šikovně vyhnul u obsahu. Ok, tak zkusím generovat obrázky pomocí Clojure. To se mi zase nechce low level komponovat bitmapa a navíc, jak dostanu Futuru na integrační server? Přes SVGčko? Sakra…

No, jsem přece web developer. Fonty dostanu přes Typekit Adobe Fonts, stejně jako na webu. Vytvořím tedy kompozici v HTML a obrázky budu típat pomocí Puppeteera! Doplnil jsem do generátoru webu, aby připravil JSON s daty, které budu potřebovat pro generování obrázků. Pak jsem napsal script, kterej otevře stránku a ve smyčce, projde data z JSONu, vloží je do DOMu a udělá screenshot. Není to úplně nejrychlejší řešení, ale 30 s na cca 470 článků není taky úplně nejhorší čas.

Nový život pro rarouš.weblog

|

Kdysi dávno (už to bude 15let) jsem vytvořil blogovadlo postavený nad ASP.NET a s tím jsem začal i blogovat. Původně se blog (po vzoru Mraveniště a Sovy v síti) jmenoval Liščí nora. Což moc dlouho nevydrželo a za nějakou dobu se ustálil název rarouš.weblog.

Blogovadlo fungovalo celkem dlouho, ale časem jsem ztratil přístup k serveru, na kterém běželo a postupně stránky začínaly uhnívat. Po tom, co se mi podařilo získat dumpy databáze a kompletního obsahu ze serveru, jsem vytvořil svůj první Clojure program, který vzal XML dump z MSSQL a vygeneroval z něj EDN s články. Následoval můj první Clojure web, který z toho EDN on demand generoval stránky. Výhoda byla, že jsem byl schopný zachovat původní URL – vč. fallbacků do historie. Hostoval jsme to na Heroku a pak jsem to přesunul do Docker Cloudu.

Problém ale byl s psaním nových článků. Publikování nového článku spočívalo v ruční editaci XML dumpu, kam jsem musel vložit článek v Texy formátu a zároveň i HTML verzi, kterou jsem získal na http://texy.info/try. To všechno jsem musel XML encodovat. Zkrátka s tím bylo sraní a přestalo mě to bavit. Tak jsem skoro přestal psát. Občas jsem něco vypustil přímo z Quipu, kde píšu většinu všeho.

Během loňského jara jsem začal psát nový generátor, který vzal původní dump a vygeneroval z něj soubory pro každý článek zvlášť i s jejich metadaty. Výstupem je Texy soubor s hlavičkou, ve které je EDN. Protože nesnáším YAML. A protože jsem měl 450+ článků napsaných v Texy.

V létě jsem přestal používat Facebook, zavřel LinkedIn a vracím se ke starým návykům, používat Feedly a Pocket. Vypnout informační šum a naladit se na kvalitu ručního výběru.

Fast forward do konce loňského roku, kdy jsem začal psát generátor webu. První problém byl, jak přetavit Texy do HTML? Původní myšlenka byla, že vytvořím AWS lambdu, kde poběží Texy a bude mi vracet HTML na základě mých požadavků. No, není to moc schůdná cesta, protože není úplně jednoduché dostat do lambdy PHP extenze. Druhá myšlenka byla, místo lambdy využít Fargate a mít to v kontejneru.

Vzdálená volání jsou ale drahá. Nejen na čas, ale v případě Fargate i na peníze. Takže jsem skončil u volání Texy scriptu přes shell. Navíc volat Texy pro každý článek zvlášť neslo taky slušný overhead. Nakonec jsem to vyřešil jedním batch-callem, kterej zprocesuje všechny články najednou. Rázem jsem se dostal z desítek minut na desítky sekund. Nakonec jsem musel připravit Docker image pro běh v CircleCI, který podporuje jak Clojure Tools Deps, tak PHP.

A už to lítá.

Nový backend

Základem je Pulumi program, který připraví infrastrukturu. Zatím tam je jen S3 bucket a patřičná Policy, ale až dodělají podporu Cloudflare, bude se správa CDN a DNS provádět tudy. Druhá část, jak už jsme naznačil, je Circle CI, které spustí script generátoru a v dalším kroku provede Gulpové transformace nad assety. V posledním kroku se udělá sync do S3 a je to venku.

Screenshot: Delivery pipeline

Upravený frontend

Moc věcí se nezměnilo, hlavně jsem obměnil typografii. Na další věci se dostane postupně. Co se změnilo zásadně, je struktura adres a stránek blogu. Přešel jsem na hierarchický model rok/měsíc/den/slug. Když si odmažete jednotlivé segmenty najdete tam indexy pro vybrané časové období. Taky jsme přešel z nesmyslných kategorií na štítky. Ačkoliv jsem se dříve snažil štítkovat, tak v tom moc žádný systém nebyl. Proto jsem značnou část článků prošel a přeštítkoval. Vznikly tak nové rubriky, tématicky doufám vytříbenější, které najdete dole v patičce. Ta se asi brzo taky dočká značné aktualizace. :)

Spousta věcí je spíchnutá narychlo, vím o spoustě drobných vad, ale psaní a čtení nejsou na překážku.

Oprašte své RSS čtečky, je čas se vrátit ke kořenům!