Naše zkušenosti s Heroku

Heroku používáme již několik let, ale vždy to bylo hlavně pro potřeby samotného vývoje, tedy DEV serverů. Nyní poprvé jsme začali používat Heroku i pro naše produkční věci, konkrétně na Heroku provozujeme SaaS verzi našeho produktového katalogu WisePorter.

Tento článek obsahuje přehled našich zkušeností, které jsme museli po cestě řešit, a které mohou pomoci i někomu dalšímu při adopci této platformy.

Proč Heroku?

Tento článek není zaměřený na výběr vhodné cloudové platformy pro provozování aplikací, nicméně úvodem bych rád uvedl stručné shrnutí výhod a nevýhod Heroku:

Výhody:

• jednoduchost — to je ta hlavní a vše ostatní převažující výhoda, je to vše strašně jednoduché, připravené k použití, člověk se může soustředit na samotný vývoj (být programátorem) a nebýt až takovým odborníkem na infrastrukturu
• zdarma — Heroku nabízí zdarma několik plánů, které se zdají být ideální volbou pro vývojové potřeby. Samozřejmě tyto plány mají svá určitá omezení, např. aplikační server se po dobu nečinnosti 30 minut vypne nebo počet záznamů v DB je omezený na 10 tisíc apod., ale to vše při vývoji nijak výrazně neomezuje
• ekosystém — Heroku nabízí velice rozsáhlý a pestrý ekosystém technologií a služeb třetích stran (tzn. addons), které je možné využít, integrace je vždy bezproblémová
• podporu CI/CD, integrace a nasazování z Gitu (my používáme Bitbucket) a spolupráci v týmu beru skoro jako samozřejmost
• command-line interface (CLI) — vše je možné spravovat přes příkazovou řádku

Nevýhody:

• omezená flexibilita — je to daň za jednoduchost a připravenost všeho potřebného. Ve většině případů na žádné omezení nenarazíte, ale pokud narazíte, tak se bohužel většinou musíte přizůsobit vy a nebo použít jinou službu.
• drahé — je to drahé, ale pouze pokud se budou porovnávat konkrétní služby od jiných cloudových poskytovatelů jako AWS, Azure nebo porovnávat přímo s variantou, že si pronajmete VPS a veškeré infra si uděláte sami. Tímto pohledem bude Heroku vždy dražší, ale když do toho všeho započtete i čas nutný na implementaci a následný support všech prostředí a serverů, tak už mě to dražší nepřijde (nebo nikoliv o tolik)

Následuje přehled našich drobných nebo větších “záseků” a zkušeností, které jsme posbírali zejména v poslední době během příprav a provozování našich produkčních instancí.

Request timeout 30s

Zpracování HTTP requestu nesmí trvat déle než 30s plus několik dalších drobných omezení týkajících se streamovaní dat, viz https://devcenter.heroku.com/articles/request-timeout. Omezení se vztahuje k HTTP routeru, nikoliv k samotné aplikaci, ta může zpracovávat požadavek naštestí jak dlouho potřebuje. Řešením je převod ze synchronního zpracování na asynchronní.

Další HTTP omezení

Heroku má řadu kontrol a drobných omezení, viz https://devcenter.heroku.com/articles/http-routing#http-validation-and-restrictions. Občas jsme sami narazili, naposledy jsme třeba neměli správně konce řádků u HTTP hlaviček. Oni to ani často nejsou vyloženě omezení, spíše Heroku celkem striktně vyžaduje plnění HTTP specifikace.

Heroku samo přidává několik HTTP hlaviček do vstupních requestů, viz https://devcenter.heroku.com/articles/http-routing#heroku-headers

Vlastní doména

Přesměrování na vlastní doménu je samozřejmým cílem, pokud chcete něco veřejně provozovat, bohužel má jedno drobné omezení a to přesměrování root domain pro https (nejsem schopen přesměrovat https://mojedomena.cz na variantu https://www.mojedomena.cz). Variantu http://mojedomena.cz jsme dokázali pořešit díky použití nginx pro naší frontendovou reactí aplikaci, ale bohužel pro https to nešlo ze dvou důvodů: DNS A-record musí být statická IP adresa, což Heroku nepodporuje a naopak náš domain provider FORPSI (jako většina jiných) nepodporují CNAME pro tyto potřeby.

DNS A-records can be used to configure zone apex domains (also called bare, naked, or root domains). These records have serious availability implications when used in environments such as on-premise data-centers, cloud infrastructure services, and platforms like Heroku.
For maximum scalability and resiliency applications should avoid using DNS A-records and instead use a DNS provider that supports CNAME functionality at the apex, or use sub-domains exclusively.

My jsme nakonec tuto věc nechali nedořešenou, protože nám tak zásadně nevadí. Možným řešením by bylo si vybrat takového doménového poskytovatele, který podporuje ALIAS/ANAME. Někteří poskytovatelé jsou uvedeny na stránkách Heroku, viz https://devcenter.heroku.com/articles/custom-domains#configuring-dns-for-root-domains

Databáze

Pro ukládání statických dat skoro výhradně používáme Heroku Postgres, tedy další body se týkají této databáze:

• používáme Hobby plány (ve vývoji stačí Hobby Dev, pro produkci nám také většinou stačí Hobby Basic). Nicméně je několik důvodů, proč chtít Standard plán — omezení na 20 connections, žádné DB logy, není dostupná aut. funkce rollback, backupy se ukládají max. 7 dní, neohlášené maintenance výpadky (sice SLA celé služby je přes 99%, ale neohlášený maintenance výpadek nemusí být úplně příjemný, když nevíte kdy bude)
• omezení na 20 připojení není tak “drsné” jak by mohlo na první pohled vypadat, samozřejmě pro aplikaci s větším trafficem to není. Je potřeba si nechat vždy nějaké připojení v záloze pro administraci, např. tvorbu DB záloh. Pokud žádné připojení volné není, tak nemáte ani šanci zjistit jednotlivé procesy resp. připojení z pohledu DB (command pg:ps) a nezbývá nic jiného než použít killall, pokud opravdu nějaký servisní zásah musíte udělat.
• pravidelné automatické zálohy jsou zdarma a dostupné i pro Hobby plány, jen je nutné je aktivovat, viz https://devcenter.heroku.com/articles/heroku-postgres-backups#scheduling-backups
• z používání Dyna resp. aplikačních kontejnerů člověk získá pocit, že upgrade na lepší DB plán je pouze otázka jednoho kliku, bohužel to tak není. Pokud je potřeba provést upgrade DB (vyšší plán nebo i třeba povýšení verze PostgreSQL), tak je nutné nejdříve vytvořit zcela novou databázi v novém plánu a postarat se o přesun dat. Bezvýpadkové to tedy není.
• v případě, že máte více aplikací a tedy potřebu více úložišť, tak je v rámci “šetření” možné využít ten přístup, kdy budete mít jednu databázi a více schémat. Funguje to bez omezení, ale má to několik negativních důsledků, které je dobré si dopředu uvědomit — všechny Heroku operace jsou spojeny s databází bez možnosti výběru schématu. Pokud budete chtít zálohovat nebo přenášet data z produkce na dev, pak vždy celou DB, všechny schémata v něm. A samozřejmě omezení na počet připojení se počítá na celou DB, bez ohledu na to, kolik schémat tam je.

Logy a monitoring

Standardní podpora Heroku pro monitoring a logování nejsou dostatečné pro support produkčních aplikací, proto je nutné počítat v nákladech s využitím služeb třetích stran. My používáme Papertrail pro logování a Librato pro monitoring. Integrace je zcela bez problémů, pouze na jedno kliknutí.

Heroku Teams

Pokud jste firma a je vás tedy více, pak je určitě žádoucí si různé instance sdílet, řídit k nim přístup a mít to vše spárované s firemní kreditkou. Heroku Teams je placená funkce, nicméně do 5 lidí včetně je zdarma. Bohužel hodně omezující je, že v rámci Teams nelze pracovat pouze s Free dynos (plan Dyno Free). Toto je omezující zejména v případech, kdy si vytvoříte Heroku Pipeline s DEV/TEST a PROD instancemi a díky Teams jste tlačeni do toho, aby i DEV instance byla minimálně Hobby, tedy placená, což často není potřeba.

My jsme to zatím vyřešili tak, že jeden z nás je “hlavní”, tedy je vlastníkem (Owner, nestačí být jen Collaborator) všech Heroku instancí a tedy on platí za používání Heroku ve firmě. Potom dle projektů se přidávají další spolupracující (Collaborator) lidé.

Heroku není AWS, Azure ani jiná podobná cloudová platforma. Heroku je nádstavba nad AWS a nabízí “zjednodušený” přístup k tvorbě infrastruktury, k deplyomentu aplikací a jejich provozování. Jednoduchý přístup je ale občas vyvážený omezenou flexibilitou. Prostě něco za něco …