Velká PaaS migrace: Co znamená přechod na alternativy pro vaše startup

Pojďme být upřímní: zpráva od Heroku zasáhla komunitu vývojářů jako zvrat, který nikdo nechtěl. Když Salesforce oznámil konec bezplatných dynos a změny v cenovém modelu, bylo slyšet zoufalé povzdechy na každém Discordu i Twitter vláknu. Platforma, na kterou se spoléhalo tolik týmů pro vše od vedlejších projektů po produkční systémy, najednou přestala být útočištěm a začala vypadat jako vztah, ze kterého je třeba vystoupit v klidu a s grácií.

A tak začal hon na nové platformy. Render, Railway, Fly.io a další se najednou ocitly pod drobnohledem. Vývojáři se ptali: „Jste vy ta pravá?"

Sledoval jsem tuto migrační vlnu z první linie a mám na věc svůj názor. Pojďme se podívat, co vás čeká, když opustíte bezpečný přístav Heroku.

Klam předraženého štítku

Tady je nabídka, která se pořád opakuje: „Přejděte k nám a ušetříte 30–40 % na hostingu."

Fajn, ta matematika sedí. Podle toho, jak máte Heroku nastavený, se úspory můžou vyšplhat opravdu vysoko. Pro startup, který pálí peníze za víc dynos, worker procesů a databázových instancí, je sledovat, jak tyto položky padají, docela uspokojivé.

Ale tady je to, co marketing zamlčuje: nejde jen o přesun hostingu. Přesouváte způsob myšlení, workflow a určitou dávku provozní zodpovědnosti, kterou za vás Heroku tiše obstarával.

Pochopení posunu v myšlení

Tady to začíná být zajímavé – a občas frustrující.

Heroku funguje na takzvaném „aplikacemiocentrickém" modelu. Nasadíte aplikaci a ta obsahuje různé typ procesů (web, worker, clock a tak dál), které spolupracují jako jeden ucelený celek. Platforma ví, že tyto procesy k sobě patří. Životní cyklus, konfigurace prostředí i deployment pipeline respektují tento vztah.

Moderní PaaS platformy často volí jinou cestu. Místo aplikací se základní jednotkou stávají jednotlivé služby nebo procesy. To nabízí větší flexibilitu – můžete škálovat, konfigurovat a nasazovat komponenty nezávisle. Ale taky to znamená, že vy se stáváte koordinátorem.

Představte si to jako rozdíl mezi pronajatým zařízeným bytem a stavbou vlastního malého domu. Apartmán (Heroku) má nábytek, energie zařízené, správce budovy, který se stará o údržbu. Malý dům (moderní PaaS) vám dává úplnou kontrolu, ale najednou přemýšlíte o vodoinstalaci, elektřině a kam s tím gaučem.

Jak to vypadá ve skutečnosti

Pojďme se bavit o tom, co se děje, když se začnete stěhovat.

Většina platforem odvedla skvělou práci na „prvním nasazení". Propojíte GitHub repozitář, nakonfigurujete proměnné prostředí, kliknete na deploy a bum – jedete v produkci. Tahle část je opravdu působivá a konkurence se od Heroku poučila.

Ale vaše aplikace není jedna služba. Je jich pět. Nebo deset. Nebo víc. A každou z nich musíte nakonfigurovat, nasadit a udržovat. Každá má svůj vlastní build proces, vlastní pravidla škálování, vlastní health checks.

Najednou nenasazujete jen kód – spravujete konstelaci služeb, které spolu musí fungovat, ale navzájem o sobě vůbec nevědí.

Kde to začíná drhnout

Tady je scénář, který jsem viděl opakovaně: Vytvoříte blueprint.yaml nebo podobný konfigurační soubor definující vaši infrastrukturu jako kód. Skvělé! Všechno je zdokumentované, verzované v gitu a reprodukovatelné.

Pak se podíváte do webového dashboardu a všimnete si nastavení, které nesedí s vaším YAML souborem. Tak ho přepíšete přes UI. Teď co je autoritativní? Soubor v gitu, nebo nastavení v dashboardu, které se právě uložilo?

To není teoretický problém. Tyto nejasnosti vytvářejí zmatek a zmatek v infrastruktuře je nebezpečný. Když se něco rozbije ve dvě ráno, potřebujete přesně vědět, kam se podívat.

Skryté náklady na „vlastnění víc"

Moderní PaaS platformy často propagují, že budete „vlastnit víc" své infrastruktury. Představuje se to jako posílení kompetencí, a v mnoha ohledech to tak je. Víc kontroly, víc přehledu, víc možností přizpůsobení.

Ale vlastnictví má svou cenu. Když má Heroku problém s routing vrstvou, otevřete support ticket. Když má váš Render deployment problém se sítí, ladíte konfigurace load balanceru. Když vaše Fly.io aplikace potřebuje specifické kernel parametry, studujete dokumentaci, která předpokládá hluboké znalosti infrastruktury.

Otázka není, jestli jsou tyto platformy špatné. Nejsou. Otázka je, jestli má váš tým kapacitu, expertízu a chuť nést tuto provozní komplexitu výměnou za úsporu nákladů.

Jak udělat správné rozhodnutí pro vaši situaci

Takže máte migrovat? Odpověď je, frustrujícím způsobem: záleží na tom.

Zůstaňte u jednoduchosti ve stylu Heroku, pokud:

• Jste v rané fázi a jedete rychle
• Váš tým je malý nebo nosíte víc klobouků najednou
• Vaše infrastrukturní požadavky jsou relativně standardní
• Developer experience a rychlost vývoje jsou důležitější než každý ušetřený dolar

Přijměte moderní PaaS komplexitu, pokud:

• Máte vyhrazené DevOps zdroje
• Vaše infrastruktura má unikátní požadavky
• Optimalizace nákladů je kritický parametr pro vaše podnikání
• Váš tým je pohodlný s infrastrukturou jako kódem a debugováním distribuovaných systémů

Závěr

Migrace platformy zřídka bývá tak jednoduchá, jak naznačuje „quick start" guide. Skutečná cena odchodu od Heroku není jen úsilí spojené s migrací – je to trvalý kompromis mezi jednoduchostí a kontrolou, mezi spravovanými službami a vlastní infrastrukturou.

Než skočíte, buďte k sobě upřímní o tom, co všechno obětujete. Levnější hosting je skvělý, ale ne pokud zpomalí váš tým nebo přidá provozní komplexitu, která stojí víc, než ušetříte.

Na konci dne je nejlepší hosting platforma ta, která vám umožní soustředit se na budování produktu místo správy infrastruktury. Někdy je to plně spravovaná platforma s prémiovou cenovkou. Někdy je to flexibilní, nákladově efektivní alternativa, která vyžaduje víc námahy.

Poznejte sami sebe. Poznejte svůj tým. A podle toho se rozhodněte.

Jak probíhá vaše migrace? Napište do komentářů – rádi uslyšíme, jak Velká PaaS Transition probíhá ve vašem případě.