Super odpovědi, je poznat, že o tom něco víte... A teď - nemůžete to popsat jako pro debila? Co je cloud, z čeho to sestává, jaká je logika využití, proč to používat, přoč ne, proč na to vyvíjet, proč ne, ...
Na to se možná ptal tazatel (ale zcela jistě to zajímá mě - nevím o tom víceméně nic, takže dotazy typu "IaaS, PaaS, SaaS?" jsou jaksi mimo mísu).
Tak zaprvé je to marketingový buzzword. Firma, která dneska nemá scrollovací web na celou šířku stránky s bootstrapem, obrovitánskou fotkou šťastných lidí na začátku, nadpisem velikosti nejméně 46px a obláčkem v ikonkách, jako by nebyla
A proto je potřeba se na to dívat přesně, jak říkáš: jako pro debila, bez zbytečných keců
Takže v základu je cloud velké množství serverů, na nakterých jede nějaký virtualizační soft a pod tím virtuální servery. Všechno je to uděláno tak, aby virtuální stroj nebyl vázaný na konkrétní kus hardware a celé to má nějaké skriptovatelné API + webui. Narozdíl od klasického poskytovatele VPSek si můžeš vytvořit kolik virtuálů chceš a podle toho pak platíš (někde od kusu, někde od využitých prostředků).
Takže si prostě někam klikneš nebo zavoláš nějaké API a v řádu desítek sekund až jednotek minut ti běží nový server. Samozřejmě je infrastruktura postavená na nějakém druhu imagů, takže si třeba klikneš "chci nový webserver" a za nějakou tu minutu ho máš. Protože ten pool dostupných prostředků je obrovský, je tam pěkný cvrkot - neustále někdo servery ruší a někdo jiný spouští, takže průměrné využití prostředků by mělo být lepší než když si každá firma bude budovat vlastní servery dimenzované na nejvyšší očekávanou zátěž, které většinu času budou jenom zevlovat.
No a z toho plyne, že aplikace pro cloud se musí psát jinak než pro klasickou infrastrukturu - je potřeba je nějak rozložit na víc virtuálů a umožnit (rádobylineární) škálování - rozjedu dvakrát tolik webserverů -> obsloužím dvakrát tolik požadavků.
Aby to celé šlo nějak rozumně spravovat, je na to potřeba nějaký configuration management - salt, chef, puppet, cfengine... který dělá v principu hlavně to, že na správná místa do konfiguráků vloží aktuální hodnoty cloudu - např. IP adresu databázového stroje (tím, že virtuály pořád nějak zastavuješ a spouštíš se samozřejmě mění minimálně jejich IP adresy, takže prostý image všech strojů ti nestačí).
Marketing říká, že je to celé báječně flexibilní, levné (lepší využití prostředků), spolehlivé (resp. schopné ustát chyby). Skutečnost je spíš taková, že je to flexibilní, takže se komplikuje design aplikace a ne každý umí takovou aplikaci dobře navrhnout (nestačí prostě vzít klasický monolit a prsknout ho do cloudu...), levné to není (stačí zadat do googlu něco jako "ec2 price high") a na úrovni jednotlivých virtuálů nebo obslužného API je to někdy až pekelně nespolehlivé (takže ta fault-tolerance je trochu znouzectnost - bez ní to prostě nejde, cloud tě k ní donutí...).
No a ty jednotlivé zkratky PaaS, IaaS, SaaS apod. potom víceméně označují, na jaké úrovni s tím poolem prostředků pracuješ - buď máš k dispozici "holé" virtuální mašiny a na ně už si všechno instaluješ sám, sám si řešíš jejich orchestraci, správu, záplatování a všechno ostatní (takže je to stejný jako bys měl stejný množství normálních serverů), nebo máš jakoby "nafukovací stroj" - někam nahraješ třeba java aplikaci a cloud ji "sám" provozuje - ideálně i nějak automagicky sám škáluje prostředky. Mezi těmahle dvěma póly je spousta mezistupňů a to jsou víceméně ty jednotlivé zktratky
Nejlíp to celý pochopíš, když si to sám vyzkoušíš - pro vyzkoušení "holých serverů" má třeba Amazon EC2 free tier, kde si můžeš půl roku zadarmo provozovat *tragicky* poddimenzovaný virtuál. Pro vyzkoušení trochy té automagiky můžeš zkusit třeba
https://www.openshift.com/
Zobrazit příspěvky
