Vzdělávání
Přednášky, záznamy a technické postřehy z dílny NTIT Group — sdílíme, co jsme se naučili v praxi.
Doporučená přednáška
Digitalizace firem
Krátká přednáška o ERPNext a zapojení umělé inteligence do digitalizace firem.
Technické postřehy & case studies
8 článků
Serverless není drahý. Špatná architektura je drahá.
Na internetu koluje článek o tom, jak startup přešel z AWS Lambda na EC2 a ušetřil $140 000 ročně. Zní to dramaticky. Ale když si sednete a přepočítáte čísla podle veřejného ceníku AWS, zjistíte, že ta matematika vůbec nesedí. Tady je rozbor toho, co se doopravdy stalo – a proč serverless za to nemůže.
MCP server v AWS: Jak jsme Claudovi dali klíče od skladu
Dát umělé inteligenci přístup k vašim systémům zní jako sci-fi, ale dnes je to realita. Říká se tomu MCP – Model Context Protocol. Tady je příběh o tom, jak jsme vyrostli z lokálního proof of conceptu na plnohodnotný cloud server s OAuth přihlášením, dynamickými oprávněními a Lambdami, a proč to pro klienty mění pravidla hry.
Jeden příkaz a pět minut: Proč stavíme infrastrukturu jako kód (IAC)
Jak se to v tom cloudu vlastně všechno reálně objeví? Můžete buď strávit odpoledne zběsilým klikáním v konzoli a doufat, že jste v padesátým kroku nic nepokazili, nebo to prostě napíšete jako kód. Tady je o tom, proč už na infrastrukturu nesahám myší (pokud se tomu dá vyhnout, což je 95% případů) a jak díky tomu nasadíme kompletní systém pro nového klienta lusknutím prstu. A proč je to pro byznys vlastně ta nejlepší pojistka proti blbosti.
Generace Z u klávesnic: Proč si vybrali dřinu místo AI zkratek?
36 hodin kódování, studenti ZŠ a SŠ a překvapivé zjištění našeho CTO. V době AI se mladí vývojáři rozhodli jít tou nejtěžší cestou. Proč je "ruční práce" v IT na začátku kariéry nenahraditelná a co si z Campfire Hackathonu odnášíme my v NTIT?
DynamoDB: Tajná zbraň serverless designu
Kdysi jsem si myslel, že jediná cesta je vlastní server a relační databáze. Dnes ale drtivou většinu našich systémů stavíme na DynamoDB – serverless key/value bestii od AWS. Proč jsme se rozhodli jít proti proudu tradičních řešení, jako je SQL nebo MongoDB? Tento článek není jen technickým srovnáním, ale pohledem pod kapotu toho, jak nám tato technologie umožňuje škálovat projekty do nebes a zároveň šetřit klientům peníze.
AI v praxi: co se ve firmě dá reálně zautomatizovat
Obecná umělá inteligence o vaší firmě nic neví. Ukážeme, jak ji technologií RAG naučíme pracovat s vašimi daty, které procesy se vyplatí zautomatizovat jako první a co už zvládnou autonomní agenti napojení přímo na vaše systémy.
Aplikace na míru
Váháte, zda pro svůj projekt potřebujete mobilní aplikaci, nebo by stačila webová? Vysvětlíme vám klíčové rozdíly i to, proč musíme architekturu stavět škálovatelně, aby systém ustál nápor uživatelů a rostl společně s vámi.
Digitalizace firmy: kdy Excel přestane stačit a co postavit místo něj
Excel je skvělý start, ale pro řízení rostoucí firmy se brzy stane brzdou. Nemusí ho hned nahradit velké ERP – často stačí jeden systém postavený přesně na váš proces. Podle čeho se rozhodnout a jestli ho provozovat v cloudu, nebo u sebe na serveru?
Serverless není drahý. Špatná architektura je drahá.
Intro
Nedávno jsem na Mediumu četl článek, že: Náš serverless účet za Lambda dosáhl $12 000. Přešli jsme zpátky na EC2 za $400. Klasický virální formát – velký čísla, dramatický obrat, jasný záporák (AWS Lambda). Přesně ten typ obsahu, který se šíří rychleji než technická pravda.
A protože jsme firma, která na serverless staví vždycky, když může – od DynamoDB přes Lambda funkce až po MCP servery – tak mě to samozřejmě zajímalo. Sedl jsem si k tomu, otevřel veřejný ceník AWS a začal počítat.
A bylo to... zajímavé.
Čísla, která nesedí
Autor článku tvrdí, že měl 2 miliony API requestů měsíčně a účet $12 247. Pojďme si to rozebrat po položkách, protože tady to začíná být podezřelé.
Poplatek za invokace Lambdy: $200
AWS Lambda účtuje $0,20 za milion requestů. Dva miliony requestů tedy stojí... $0,40. Ne $200. Aby invokace stály $200, musela by Lambda zpracovat přibližně miliardu požadavků. Ne dva miliony. Miliardu. To je o tři řády víc, než autor uvádí.
Poplatek za compute (duration): $3 200
Při 1 GB paměti stojí sekunda výpočtu $0,0000166667. Za $3 200 to vychází na cca 192 milionů sekund compute time. Rozpočítáno na 2 miliony requestů to znamená, že každý request běžel průměrně 96 sekund. Autor přitom tvrdí, že průměrná exekuce trvala 120 ms. A API Gateway má hard timeout 29 sekund – takže 96sekundové requesty by ani nebyly možné.
API Gateway: $2 100
REST API Gateway stojí $3,50 za milion requestů. Dva miliony = $7. Aby autor dosáhl $2 100, musel by buď mít stovky milionů requestů (což netvrdí), nebo protlačit přes API Gateway přes 23 TB dat (což by byl extrémně neobvyklý traffic pro SaaS s 2M requesty měsíčně – a navíc to odporuje jeho vlastnímu číslu $340 za data transfer).
Jsou v zásadě dvě vysvětlení: buď jsou čísla vymyšlená pro efekt, nebo (a to je zajímavější a pravděpodobnější varianta) měl autor v kódu kritický bug – třeba rekurzivní retry loop, kde se Lambda volala sama do nekonečna. Serverless totiž nešetří vaše peníze, když váš kód dělá miliardkrát něco, co dělat nemá. Serverless perfektně škáluje i vaše chyby.
Co se asi stalo doopravdy
Když odhlédneme od matematických nesrovnalostí, článek popisuje řadu architektonických rozhodnutí, které by bolely v jakémkoliv prostředí – ale v serverless prostředí za ně platíte okamžitě a viditelně. To je vlastně jedna z výhod serverless: špatnou architekturu nepokryje tichý idle server.
DynamoDB dotaz trvající 8 sekund
Autor zmiňuje, že jeden z endpointů měl DynamoDB dotaz, který trval 8 sekund, a to způsobilo kaskádový výpadek. Tady musím říct – kdo pracoval s DynamoDB ví, že 8 sekund je absolutní anomálie. DynamoDB je navržené na single-digit milisekundové odezvy. Vždycky. Bez ohledu na objem dat.
Osm sekund znamená téměř jistě Scan – tedy procházení celé tabulky řádek po řádku místo cíleného dotazu přes index. O tom, proč je správný návrh klíčů v DynamoDB tak důležitý, jsem psal podrobněji. Se správně nastaveným Partition Key a Sort Key by ten dotaz vrátil výsledek za 10 ms a žádný concurrency problém by nenastal.
Lambda ve VPC s NAT Gateway
Autor platil $187 měsíčně za NAT Gateway, aby jeho Lambda funkce mohly přistupovat k internetu. Ale – a to je klíčové – používal DynamoDB, což je služba s veřejným endpointem. Lambda mimo VPC má přístup k DynamoDB automaticky, bez jakékoliv další konfigurace. Ten NAT Gateway tam být vůbec nemusel. A navíc, VPC přidává do cold startů stovky milisekund navíc. Takže autor zbytečně platil $187/měsíc za pomalejší a dražší setup.
(Pokud by přece jen potřeboval přistupovat k nějakému privátnímu zdroji ve VPC, řešením je VPC Endpoint pro DynamoDB, který je zdarma a nepotřebuje NAT.)
2sekundové cold starty
Autor naměřil cold starty 2 120 ms – z toho 800 ms inicializace a 1 200 ms načítání závislostí. Pro jednoduchou autentizační funkci v Node.js je to hodně. Naznačuje to, že deployment package byl přeplácnutý – pravděpodobně tam byl celý Express framework, plný AWS SDK v2 (který je masivní), a kdo ví co dalšího.
Moderní přístup: esbuild/bundler, modulární AWS SDK v3, single-purpose funkce. Výsledek? Cold start kolem 200 ms. A s Provisioned Concurrency nebo SnapStart (pro Javu) se dá cold start eliminovat úplně, ale to je většinou overkill. Nicméně pokud máme klienta, kterého cold start opravdu bolí, toto je standardní řešení.
Kolik by to mělo stát doopravdy?
Takže co kdyby autor použil standardní best practices? Pojďme si to spočítat realisticky pro 2 miliony requestů měsíčně:
HTTP API (ne REST API – je levnější a pro většinu use cases lepší): $2,00. Lambda invokace: $0,40. Lambda compute (100 ms průměr, 512 MB ARM64): cca $1,30. DynamoDB on-demand s indexovanými dotazy: cca $2,50. Data transfer (realistický JSON payload): pod $10. NAT Gateway: $0 (nepotřebujete ho).
Celkem: někde kolem $16 měsíčně.
V reálné produkci bych počítal s overhead – monitoring, logy, občasný spike, nějaký ten S3 bucket navíc. Řekněme realisticky $30–80 měsíčně. Pořád dramaticky méně než autorových $315 za EC2 setup.
Samozřejmě, $315 za EC2 není špatná cena. Ale argument, že EC2 je levnější než serverless, tady prostě neplatí. Je levnější než špatně postavený serverless.
Kdy dává EC2 smysl?
Nechci tu hrát na strunu "serverless vždy vyhrává" – to by bylo stejně neférové jako ten původní článek. Jsou legitimní situace, kde VM nebo kontejnery dávají smysl:
Dlouhodobé, CPU-intenzivní workloady (video encoding, ML inference) – tam Lambda prostě nemá co nabídnout. WebSocket servery nebo jiné stavové aplikace, kde potřebujete trvalé spojení. Situace, kde tým nemá zkušenosti se serverless patterny a migrace by stála víc, než kolik ušetří. Legacy aplikace, kde přepis na serverless není ekonomicky ospravedlnitelný.
Ale pro typické API sloužící JSON responses s databázovými dotazy? Tam je serverless nejen levnější, ale i jednodušší na provoz – jak jsem psal v článku o IaC, nasazení celého stacku je otázka jednoho příkazu.
Závěr
Jako kdybych řekl, že "Jezdit autem je pomalé, to je nesmysl." a měl celou dobu zataženou ručku ;)
Serverless vyžaduje trochu jiný způsob přemýšlení o kódu – lehké funkce, správně navržené databázové dotazy, žádné zbytečné síťové vrstvy. Ale když to uděláte dobře, dostanete systém, který škáluje automaticky, neplatíte za idle a nasadíte ho lusknutím prstu, jednomu klientovi nebo deseti.
A když to uděláte špatně? AWSko vám to vysvětlí pak na faktuře :)