Kdy přestat platit za Keboolu a přesunout datové pipeline do Google Cloudu

Jak to začalo

Původně jsme přes Keboolu stahovali jen reklamní systémy. Tyhle joby běžely pár dnů v týdnu, štědře to pokryl volný limit 60 minut měsíčně a za nástroj jsme neplatili prakticky nic.

Pak jsme chtěli připojit ERP systém Abra, který používáme u nás v Haltimo.com.

Když jsme to v týmu poprvé testovali, podíval jsem se do usage logu a nestačil se divit. Zjistil jsem, že pouhé stažení dat z Abry by trvalo klidně 15 minut denně. A to jsme testovali jen část agendy. Kdybychom tahali kompletně všechno včetně přesunu dat do BigQuery, dostali bychom se na 30 minut denně. Za měsíc to dělá 900 minut a při sazbě $0,14 za minutu výpočtu v PAYG tarifu by nás jen ERP stálo zhruba $126 měsíčně.

Jenže e-shop nežije jen z účetnictví. Když k tomu přidáte například stahování 10 velkých dodavatelských feedů pro 10 různých domén a každý job poběží se vším všudy 6 minut, bavíme se o dalších 60 minutách denně (1 800 minut měsíčně).

Z původně bezplatného nástroje se rázem stala obrovská položka v rozpočtu. Celkem bychom propálili 2 700 minut měsíčně. To byl ten moment, kdy jsme od stahování velkých dat přes Keboolu okamžitě upustili.

Jak vypadá přesun do cloudu technicky

Rozhodl jsem se tyhle těžké joby vyřešit jinak. Jelikož jako datový sklad využíváme BigQuery, volba logicky padla na Google Cloud Platform.

Ve výsledku je ale úplně jedno, jaký cloud k tomu použijete. Zda zvolíte GCP, AWS nebo Azure, nehraje roli. My ukládáme data do BigQuery, proto dává smysl držet výpočet ve stejném ekosystému a jen upravit konec skriptu pro zápis do správného úložiště. Samotná logika stahování a zpracování dat je naprosto univerzální a z velké části přenositelná prakticky kamkoliv.

Není na tom totiž nic magického. V týmu jsme napsali přímočarý Python skript, který tahá data z API Abry a dodavatelů. Zabalili jsme ho do Docker kontejneru a nasadili do služby Cloud Run. O pravidelné spouštění se stará Cloud Scheduler a data padají rovnou do datového skladu.

Kalkulačka: Paretovo pravidlo za čistý výpočet

Rozhodnutí, kde data zpracovat, by mělo být čistě pragmatické. Podívejte se do svého usage logu a sečtěte ty nejtěžší procesy. Jak jsem ukázal výše na našem modelovém příkladu: Abra a feedy pro domény dají dohromady 2 700 minut měsíčně.

Pojďme si spočítat rozdíl čistě za výpočetní čas:

Skrytý háček: Chybějící kapacity a TCO

Abych byl naprosto fér, předchozí kalkulačka účelově srovnává platbu za hotovou službu (Keboola) s platbou za čisté železo (GCP). Chybí v ní to nejdražší: TCO (Total Cost of Ownership) a lidské kapacity.

Běh samotných skriptů v cloudu sice stojí zhruba $10 měsíčně, ale narážíme tu na obrovskou nevýhodu vlastního řešení. Někdo ten kód musí napsat, nasadit a udržovat. Většina e-shopů prostě nemá in-house kapacity na to, aby držela data inženýra jen na údržbu pipeline. Vytvoříte si takzvanou falešnou svobodu. Zbavíte se závislosti na platformě, ale vytvoříte si absolutní závislost na jednom přetíženém programátorovi. Když vám odejde, nebo prostě zrovna nemá kapacitu, máte v cloudu hromadu kódu, kterému nikdo jiný nerozumí.

Musím přiznat, že tento strašák s existencí AI rychle mizí. Umělá inteligence dokáže cizí Python skript rozebrat, pochopit a bleskově upravit, pokud třetí strana například změní endpointy v API. Jenže i když vám AI vygeneruje opravu za pět vteřin, pořád ten proces vyžaduje něčí čas na testování a produkční nasazení.

Pojďme si ten scénář nacenit pomocí hodinové sazby seniorního freelancera: 2 500 Kč na hodinu (zhruba $110).

Samotné naprogramování konektoru zabere zhruba 10 hodin. K tomu ale musíte přičíst dalších 10 hodin na přesun, testování a složité přepojení dat v navazujících reportech. I když to schválně přeháním a počítám s pesimistickou variantou 20 hodin práce, jsme na počáteční investici $2 200.

K tomu přidejme údržbu. Reálně může dobře napsaný skript běžet rok nebo dva naprosto bez zásahu, než se API nějak zásadně změní a vyžádá si přepsání. Když to zprůměrujeme i s běžným monitoringem, spolkne údržba (i za pomoci AI) zhruba 30 minut měsíčně (dalších $55).

Pojďme si to dát vedle sebe pro náš příklad 2 700 minut:

• Keboola: $378 měsíčně
• Vlastní cloudové řešení: $10 (cloud) + $55 (údržba) = $65 měsíčně
• Reálná měsíční úspora: $313

Návratnost počáteční investice ($2 200) je v tomto vysoce přehnaném scénáři rovných 7 měsíců. Už za něco málo přes půl roku vám tedy vlastní kód reálně vydělává peníze. Pokud jste větší firma nebo korporát a točíte dvojnásobek minut, vývoj se vám zaplatí klidně během pár týdnů.

Pokud byste ale takový custom vývoj dělali pro malý job za pár stovek minut měsíčně, kde Keboola stojí dvacet dolarů, paušální náklady na monitoring vás okamžitě pošlou do tvrdého minusu. Návratnost funguje právě a jen u velkých zátěží.

Jak z toho kapacitního problému ven? Pokud nemáte vlastního inženýra, dává smysl sáhnout po partnerovi, který už má tyto konektory na velká ERP či feedy hotové. Tím, že jeden skript běží na desítkách projektů, úvodních 20 hodin vývoje se pohlcuje a vy jako firma rovnou těžíte z desetidolarového provozu v cloudu bez rizika, že vám odejde jediný člověk, co systému rozumí.

Kdy přepsat a kdy nechat běžet

Moje aktuální pravidlo je pragmatické:

• Má to nativní konektor a stahování trvá do 5 minut? Nechte to v Keboole. Údržba a alokace kapacit na vlastní řešení by stály víc než zaplacené kredity.
• Jde o těžký job, který stahuje desítky minut, nebo se násobí přes více domén? Běžte do vlastního cloudu (GCP, AWS). Návratnost je jasně daná, obzvlášť pokud vývoj nesete s partnerem.

Odpověď je v usage logu, ne v pocitu.