U našich zákazníků, kteří se věnují vývoji SaaS (software as a service), se dlouhodobě setkáváme s dvěmi hlavními přístupy k hostingu jejich aplikací. Někteří provozují celou svou aplikaci ve sdílené instanci, druzí zase preferují jednu instanci na zákazníka.
Připravili jsme si tedy krátké srovnání obou přístupů tak, jak jej vidíme my.
Předem upozorňujeme, že srovnání není vhodné pro všechny aplikace. Je potřeba brát text jako informativní, protože aplikace našich zákazníků mohou být výrazně odlišné od té Vaší.
Abychom se bavili trochu konkrétněji, tak jsme si připravili ukázkový příklad. Představte si aplikaci na správu požadavků (něco ve stylu redmine). Aplikace ke svému běhu potřebuje nějaký aplikační server (PHP, dotnet, ruby, ...) a databázi.
Nikdo ze zákazníků nesdílí mezi sebou žádné informace a je nežádoucí, aby jednotliví zákazníci viděli citlivé informace ostatních.
Pro ještě větší zjednodušení si představme, že tuto aplikaci prodáváme 50 zákazníkům a jsme v současné době všechny schopni obsloužit z jednoho serveru.
Jedná se o případ, kdy více zákazníků sdíli jednu instalaci aplikace. Všechny zákazníky obsluhuje jeden kód a veškerá izolace zákazníků probíhá na aplikační úrovni. Všichni zákazníci sdílí všechny systémové prostředky s ostatními.
Výhody
Jednoznačnou výhodou tohoto přístupu je levnější provoz. Velké, sdílené instance snadněji pohltí výkyvy v zátěži jednotlivých zákazníků, instance je větší a robustnější. Monitoruje se jen jeden server.
Aplikace má jednoduchý deployment. Databázové migrace se a nasazení změn v kódu je jen na jednom místě.
Nevýhody
V případě technických problémů dojde k výpadku všech zákazníků.
Vývoj aplikace, kde se musí navíc na aplikační úrovni řešit izolace mezi zákazníky, bude už z principu dražší. Vývojáři v tomto případě musí být pozornější a pečlivější, aby nedošlo k nechtěnému zpřístupnění dat jinému zákazníkovi.
Ačkoliv jsme na začátku řekli, že všechny zákazníky zatím obsloužíme z jednoho serveru, tak to v jistém okamžiku může přestat platit a řešení této situace může být náročné. Např. když zákazník vznese požadavek, že chce provozovat aplikaci u nich lokálně ve firmě.
Řešení specifických požadavků a výjimek zákazníků může celý provoz a testování výrazně zkomplikovat. Zde ale velmi záleží na vývojářích, kvalitě kódu a nastavených procesech.
Zálohování a obnova serveru může být komplikovaná. Pokud si jeden ze zákazníků smaže část dat z databáze, tak se musí obnovovat data všech a selektivně vybírat potřebné údaje.
Horší možnost optimalizace serveru. Tento problém se týká hlavně databází, kdy v cache nemusí být data malých instancích, které nejsou tolik používané, a pro data se musí častěji sahat na disk.
Výrazně horší práce na serveru, protože všechny operace ovlivní automaticky všechny uživatele.
Oproti plně sdíleným instancím se liší v tom, že sice běží na jednom serveru, ale izolace uživatelských dat je již na úrovni databáze, kdy každý zákazník má vlastní databázi. Možným rozšířením je možnost dedikovat jednotlivým zákazníkům aplikační procesy.
Srovnání s plně sdílenou instancí.
Výhody
Menší nároky na vývoj, protože odpadá celá vrstva problémů, které souvisí s izolací jednotlivých zákazníků.
Stále relativně malé provozní náklady, protože jednotlivé instance sdílí mnoho částí systému.
Jednodušší obnovat dat, protože jednotliví uživatelé mají vyhrazené databáze.
Nevýhody
Složitější deployment, protože se musí provést databázové migrace na všech instancích.
V tomto případě má každý zákazník svou vlastní instanci aplikace, vlastní server (nebo kontejner).
Výhody
Zákazníci jsou od sebe plně izolovaní.
Každý zákazník má vyhrazené zdroje a velikost instance je vždy uzpůsobena jeho velikosti. Navíc se lépe počítají provozní náklady na jednotlivé zákazníky.
Nevýhody
Zákazník má vždy vyhrazené zdroje, takže nemůže v případě potřeby využívat volné kapacity ostatních.
Dražší provoz, protože zákazníci nesdílí cache a knihovny. Tento problém by měl mít vliv hlavně na nároky na operační paměť a diskový prostor. Na výkon procesoru by to nemělo mít velký vliv.
Složitější konfigurace monitoringu a zálohování (nemusí být vždy pravda - záleží na infrastruktuře).
Vyšší náklady na automatizaci deploymentu.
Deployment aplikace
Deployment aplikace bychom rádi zařadili do výhod. Na jednu stranu je sice složitější, protože by se deployment měl provádět na všechny instance. Je tedy potřeba investovat do automatizace deploymentu a vytváření jednotlivých instancí. Avšak, zároveň se tím automaticky získá i velké množství výhod.
Například u vývoje je u našich zákazníků běžné, že si pro otestování úprav vytvoří instanci, naimportují data zákazníka, otestují změny a instanci následně smažou. Vývojáři v klidu mohou pracovat s produkčními daty zákazníka a přitom se nemusí bát, že dojde k nějakému problému. Celý proces je pak velmi spolehlivý, protože vytváření a mazání instancí je již součástí infrastruktury.
Poslední dobou jsme rádi, když zákazníci volí dedikované instance svých aplikací. Systémové zdroje jsou dnes relativně levné a nám se pak takové aplikace lépe provozují, protože jednotlivé problémy jsou vždy izolované na jednotlivé instance a se zákazníky se dají lépe plánovat potřebné úkony.
Je ale nutné znovu upozornit, že takovýto přístup není aplikovatelný u všech instancí a jeho použití musí dávat smysl.