Phenquestions
Fyzické počítače
Prošli jsme dlouhou cestu od masivních serverů éry dotcomů. V té době byla serverová infrastruktura většinou lokální. Firma provozovala svá řešení na fyzickém serveru. Lidé používali celé samostatné servery pro různé účely (zálohy, poštovní server, webový server atd.). Když určitý server nedokázal držet krok s rostoucími potřebami společnosti, byl nahrazen novějším rychlejším serverem. Škálovali jste tím, že jste získali lepší hardware. Změnili jste svisle.
Hypervisory
Pak přišla éra hypervisorů. Získal na síle s rozmachem VMWare a lidé si uvědomili, že mohou získat jeden regál, který by jim vládl všem. Jeden stojan pro spuštění všech různých případů použití a pro každý z nich vlastní samostatný virtuální stroj. To také vedlo k cloud computingu a podniky přestaly přímo investovat do serverového hardwaru a místo toho se rozhodly „pronajmout“ virtuální servery.
Obrovská a drahá datová centra spravovali poskytovatelé cloudových služeb po celém světě. Podniky to využily tím, že globálně zajišťovaly své služby a využívaly co nejširší škálu datových center. Důvodem bylo hlavně snížení latence, zlepšení zákaznické zkušenosti a cílení na větší trh.
Díky tomu autoři softwaru přemýšleli také o distribuovaných systémech. Psali software, aby běžel ne na jediném obrovském počítači, ale na mnoha průměrných konzistentním a spolehlivým způsobem. Změnili jste horizontálně.
Stále můžete měnit měřítko svisle. Ve skutečnosti se díky virtualizaci usnadnilo zajišťování více zdrojů. Vypnuli jste virtuální počítač, upravili jeho zdroje a zaplatili svému poskytovateli cloudu něco navíc. Kus dortu.
Základní fyzické servery nezmizely. Poskytovatelé cloudu jsou nyní zodpovědní za správu složitosti síťových rozhraní, kompatibility s OS a dalších děsivých patologií.
Kontejnery
Pak přišly kontejnery. Kontejnery byly touto úžasnou lehkou abstrakcí. Virtuální prostředí s operačním systémem, které umožňovalo zabalit a nasadit software jako jednu jednotku. Stejně jako virtuální stroje každý kontejner běžel nevědomý jiných kontejnerů, ale sdílel stejné jádro operačního systému.
To umožnilo lidem nasadit software na servery (fyzický nebo virtuální, na tom nezáleží) na ještě vyšší úrovni abstrakce. Nezáleželo vám na produkčním operačním systému. Pokud podporoval vaši technologii kontejnerizace, spustil by váš software. Také kontejnery se snáze roztočí, což činí služby škálovatelnějšími než kdy dříve.
To dále zvýšilo flexibilitu distribuovaných systémů. S technologiemi, jako je Kubernetes, můžete mít legie kontejnerů provozujících komplexní řadu služeb. Distribuované systémy nabízejí mnoho výhod, vysokou dostupnost, robustnost a schopnost léčit se při selhání uzlu.
Současně, protože jsou tak složité, je také obtížnější je navrhnout, nasadit, udržovat, monitorovat a ladit. To je v rozporu s původním trendem abstrakce složitosti vašeho softwaru a delegování této odpovědnosti na vašeho poskytovatele cloudu. To je místo, kde přichází architektura bez serveru.
Bez serveru nebo jako služba (FaaS)
Myšlenka bez serveru získala trakci hlavně kvůli AWS Lambda, a zde ji budu používat jako model, abych mluvil o bez serveru. Zásady, na kterých je založen FaaS, jsou:
- Platíte za to, co používáte
- Nemusíte se starat o škálování
- Soustředíte se na svůj kód, správu infrastruktury necháte na AWS
Pokud k vašim službám nikdo nepřistupuje, služby nejsou aktivní. To nebyl případ tradičních hostingových řešení, kde platíte za VPS, který je vždy funkční a běží, i když nečinný nečiní nic užitečnějšího než poslouchat nový požadavek.
V architektuře bez serveru vaše služba nefunguje, pokud ji někdo ve skutečnosti nechce používat. Když přijde požadavek, za chodu se vytvoří služba za běhu.
Jak to funguje?
Vaše funkce (například program Python, Go nebo Java) sedí jako soubor na AWS Lambda. S touto funkcí přidružíte určité spouštěcí události, například bránu API nebo nový objekt přicházející do vašeho kbelíku S3. A určité zdroje, jako je databáze nebo jiné úložiště objektů nebo instance EC2.
V reakci na jakoukoli přidruženou spouštěcí událost vytvoří AWS Lambda kontejner s vaší funkcí uvnitř. Funkce se spustí a dá odpověď. Například pokud do vašeho kbelíku S3 přijde nový obrázek, může mít AWS Lambda v sobě kód strojového učení, který by tento obrázek analyzoval a zapisoval jeho výstup do DynamoDB (jedné ze služeb datového úložiště AWS).
Nemusíte platit za celý server, ale pouze za množství paměti, které jste přidělili vaší funkci, počet požadavků, které získáte, a za dobu, po kterou vaše funkce běží.
Kromě toho se nemusíte starat o změnu velikosti kontejnerů v reakci na velké příchozí pracovní vytížení. Pokud dojde k mnoha spouštěcím událostem současně, pak se AWS postará o roztočení nových kontejnerů a plánování pracovních zátěží mezi nimi a všemi ostatními složitostmi.
Není to úplné řešení
Když přišly virtuální stroje, fyzické servery nepřestávaly existovat. Když dorazily kontejnery, stále jsme používali virtuální počítače. FaaS je abstrakce vyšší úrovně a opravdu dobře zapadá do moderního designu RESTful API, bezstavových služeb a lehkých jazyků, jako je Node.js nebo Python.
Stále však běží na fyzickém serveru (například spravovaném AWS), stále poslouchá příchozí požadavky (za to prostě neplatíte přímo) a stále musíte ukládat data vytrvale, a proto má integrace pro S3, EC2 a další služby. Je to nicméně užitečná abstrakce.
