Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Srovnání provozu aplikací v prostředí cloudu a on-premise Václav Cajthaml
Vedoucí práce: Ing. Pavel Náplava
16. května 2013
Poděkování Na tomto místě bych rád poděkoval panu Ing. Pavlu Náplavovi za jeho pozitivní přístup při vedení mé bakalářské práce a poskytnutí cenných rad. Dále bych chtěl poděkovat panu Zdeňkovi Novotnému ze společnosti Software602 za poskytnuté informace. Na závěr bych chtěl poděkovat rodičům za podporu během celého studia.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 16. května 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Václav Cajthaml. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Cajthaml, Václav. Srovnání provozu aplikací v prostředí cloudu a onpremise. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract This work deals with the comparison of options running applications in the cloud and on-premise mode. For comparison, the environment is first necessary theoretical knowledge of, and therefore first part of the work is detailed description of the environment. The second part is focused on creating a case study for an external client. The content of the study is to analyze real-world applications and comparing possible environment for its operation. . Keywords Cloud computing, on-premise, operating environment, service, internet technology, virtualization, billing methods, IaaS, PaaS, SaaS, private cloud, public cloud, hybrid cloud, Form Filler, Amazon Web Services, Microsoft Azure, Big Blue One
ix
Abstrakt Tato bakalářská práce se zabývá představením a srovnáním prostředí cloudu a on-premise. Pro porovnání provozních prostředí je nejprve nutná teoretická znalost problematiky, a proto obsahem první části je detailní popis prostředí. Druhá část práce je zaměřena na tvorbu případové studie pro externího zadavatele. Obsahem studie je analýza reálné aplikace a porovnání možných prostředí pro její provoz. Klíčová slova Cloud computing, on-premise, provozní prostředí, služba, internetové technologie, virtualizace, způsob účtování, IaaS, PaaS, SaaS, privátní cloud, veřejný cloud, hybridní cloud, Form Filler, Amazon Web Services, Microsoft Azure, Big Blue One
x
Obsah Odkaz na tuto práci . . . . . . . . . . . . . . . . . . . . . . viii Úvod
1
1 Provozní prostředí 1.1 Úvod do provozních prostředí . . . . . . 1.2 Provozní prostředí . . . . . . . . . . . . 1.3 Klient-Server . . . . . . . . . . . . . . . 1.3.1 Tlustý klient . . . . . . . . . . . 1.3.2 Tenký klient . . . . . . . . . . . . 1.4 On-premise . . . . . . . . . . . . . . . . 1.5 Cloud computing . . . . . . . . . . . . . 1.5.1 Definice cloud computing . . . . . 1.5.2 Specifické vlastnosti cloudu . . . 1.5.3 Kategorizace cloudů . . . . . . . 1.6 Modely služeb . . . . . . . . . . . . . . . 1.6.1 SaaS (Software-as-a-Service) . . . 1.6.2 PaaS (Platform-as-a-Service) . . . 1.6.3 IaaS (Infrastructure-as-a-Service) 1.7 Modely nasazení . . . . . . . . . . . . . 1.7.1 Privátní cloud . . . . . . . . . . . 1.7.2 Veřejný cloud . . . . . . . . . . . 1.7.3 Hybridní cloud . . . . . . . . . . 1.7.4 Komunitní cloud . . . . . . . . . 1.8 Závěr kapitoly provozních prostředí . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
3 3 3 5 5 5 6 7 7 8 9 9 10 11 11 11 12 13 13 13 13
2 Technické aspekty aplikací v cloudu 15 2.1 Úvod kapitoly technických aspektů aplikací v cloudu . . . . 15 xi
2.2
2.3
2.4
2.5
Typy aplikací . . . . . . . . . . . . . . . . 2.2.1 Rozhodovací kritéria . . . . . . . . 2.2.2 Shrnutí kriterií pro výběr prostředí Vývoj cloudové aplikace . . . . . . . . . . 2.3.1 Redundantní design . . . . . . . . . 2.3.2 Využití vícejádrové technologie . . 2.3.3 Proměnlivé stavy . . . . . . . . . . 2.3.4 Přenositelnost . . . . . . . . . . . . 2.3.5 Dostupnost dat . . . . . . . . . . . 2.3.6 Databáze . . . . . . . . . . . . . . Nasazení aplikace do prostředí cloudu . . . 2.4.1 Obecný scénář nasazení aplikace na 2.4.2 Obecný scénář nasazení aplikace na Závěr kapitoly technických aspektů cloudu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . prostředí IaaS . prostředí PaaS . . . . . . . . .
. . . . . . . . . . . . . .
15 16 18 18 18 19 19 19 19 20 20 20 22 23
3 Porovnání prostředí cloudu a on-premise 25 3.1 Úvod kapitoly porovnání prostředí cloudu a on-premise . . 25 3.2 Finanční pohled . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 Technický pohled . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Závěr kapitoly porovnání prostředí cloudu a on-premise . . 31 4 Poskytovatelé cloudových služeb 4.1 Úvod kapitoly poskytele cloudových služeb . . . 4.2 Výběr poskytovatelů . . . . . . . . . . . . . . . 4.2.1 Amazon AWS . . . . . . . . . . . . . . . 4.2.2 Microsoft Azure . . . . . . . . . . . . . . 4.2.3 Big Blue One . . . . . . . . . . . . . . . 4.3 Srovnání nabídky . . . . . . . . . . . . . . . . . 4.3.1 Nabídka instancí . . . . . . . . . . . . . 4.3.2 Úložiště . . . . . . . . . . . . . . . . . . 4.3.3 Závěrečné shrnutí nabídky poskytovatelů 4.4 Závěr kapitoly o poskytovatelích cloudu . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
5 Praktická část 5.1 Úvod do praktické části . . . . . . . . . . . . . . . . 5.2 Software602 . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Produkty Software602 . . . . . . . . . . . . . 5.3 Výběr vhodné aplikace . . . . . . . . . . . . . . . . . 5.3.1 Form Filler . . . . . . . . . . . . . . . . . . . 5.3.2 Technické detaily desktopové verze Form Filler 5.3.3 Technické detaily webové verze Form Filler . . xii
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
. . . . . . .
. . . . . . . . . .
33 33 33 33 34 34 34 34 36 37 38
. . . . . . .
39 39 39 40 41 41 41 42
5.4
5.5
5.6
5.3.4 Výhody a nevýhody obou verzí . . . . . . 5.3.5 Obecný scénář nasazení a použití aplikace Z pohledu provozovatele Form Filler . . . . . . . . 5.4.1 Testování aplikace Form Filler . . . . . . . 5.4.2 Výsledky testování . . . . . . . . . . . . . Kalkulace nákladů . . . . . . . . . . . . . . . . . 5.5.1 Cloud - Amazon AWS . . . . . . . . . . . 5.5.2 Cloud - Microsoft Azure . . . . . . . . . . 5.5.3 Cloud - Big Blue One . . . . . . . . . . . 5.5.4 On-premise - IBM . . . . . . . . . . . . . 5.5.5 Shrnutí výsledků . . . . . . . . . . . . . . Závěr praktické části . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
43 44 45 47 48 48 49 50 51 51 52 53
Závěr
55
Literatura
57
A Seznam použitých zkratek
61
B Obsah přiloženého CD
63
xiii
Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6
Přístup k informacích skrze modely cloudu nebo on-premise. Struktura on-premise . . . . . . . . . . . . . . . . . . . . . . Klíčové momenty Cloud computing. . . . . . . . . . . . . . . Rozdělení podle hierarchie služeb . . . . . . . . . . . . . . . Rozdělení modelů podle úrovně zodpovědnosti za správu. . Rozdělení podle rozsahu poskytované služby . . . . . . . . .
. . . . . .
4 6 7 9 10 12
2.1 2.2
Nasazení aplikace na IaaS . . . . . . . . . . . . . . . . . . . . . Zprovoznění aplikace na PaaS . . . . . . . . . . . . . . . . . . .
21 22
3.1
Rozdělení výdaju na IT v on-premise . . . . . . . . . . . . . . .
26
5.1 5.2 5.3 5.4
Logo společnosti Software602 . . . . . . . . . . . . . . Form Filler . . . . . . . . . . . . . . . . . . . . . . . . Scénář použití aplikace Form Filler . . . . . . . . . . . Model použití desktopové a cloudové verze Form Filler
39 42 45 46
xv
. . . .
. . . .
. . . .
. . . . . .
. . . .
. . . .
Seznam tabulek 3.1 3.2
Srovnání cenových parametrů cloudu a on-premise . . . . . . . . Srovnání technických parametrů cloudu a on-premise . . . . . .
29 30
4.1 4.2 4.3 4.4
Nabídka instancí Amazon AWS a Microsoft Azure Cena instancí za hodinu . . . . . . . . . . . . . . Cena úložiště . . . . . . . . . . . . . . . . . . . . Shrnutí nabídky poskytovatelů . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
35 35 36 37
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10
Výhody desktopové a webové verze Form Filler . Nevýhody desktopové a webové verze Form Filler Výsledky měření reálných dat . . . . . . . . . . . Cena za odchozí přenos dat do internetu . . . . . Celkový výpočet nákladů Amazon AWS . . . . . Celkový výpočet nákladů Microsoft Azure . . . . Celkový výpočet nákladů Big Blue One . . . . . . Celkový výpočet nákladů IBM . . . . . . . . . . . Shrnutí výpočtů nákladů všech prostředí . . . . . Srovnání poskytovaného výkonu . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
43 44 48 49 50 51 51 52 53 53
xvii
Úvod Tato bakalářská práce se zabývá srovnáním možností provozu aplikací v cloudu a on-premise režimu. Při srovnání prostředí se soustředím na technické rozdíly, ale také na finanční aspekty plynoucí z provozu aplikací. Tato práce si na základě zadání klade za úkol naplnit 3 cíle. Prvním cílem je seznámení se s detaily prostředí cloudu a on-premise, včetně tvorby jejich podrobnějšího popisu. Předmětem druhého cíle je vzájemné porovnání obou prostředí a identifikování nejdůležitějších rozdílů. Třetím cílem je vytvoření případové studie pro externího zadavatele o možnostech provozu jejich aplikace. Vytyčeným cílům odpovídá členění práce, která je rozdělena na dvě hlavní obsahové části pokrývající samostatně teoretické skutečnosti a praktickou část. Případová studie je vypracována pro externího zadavatele společnost Software602. Pro vytvoření studie je nejprve nutné se seznámit s teoretickými základy problematiky provozu aplikací a identifikovaní nákladových položek s tím spojených. Teoretická část je zaměřena na popis základních poznatků o prostředích pro provoz aplikací. Následně jsem podrobněji popsal specifické vlastnosti každého prostředí. Samotné porovnání obou modelů hodnotím z hlediska technických parametrů ale i z pohledu nákladů na jednotlivá prostředí. Nemalou část nákladových položek představují především poskytovatelé cloudových služeb, a proto se část práce věnuje i analýze poskytovatelů. Praktická část je zaměřena na tvorbu případové studie. Předmětem případové studie je představení vybrané aplikace, následná analýza nabídky provozních prostředí vhodných k nasazení a výběr nejvhodnější možnosti dle kalkulace nákladů. Motivací ke psaní této práce je rozšíření mých znalostí z oboru informačních systémů a přesněji o problematice cloud computingu. Pozitivním 1
Úvod přínosem je rovněž rozšíření přehledu o aktuální situaci poskytovaných služeb formou cloudu a oblasti finanční náročnosti provozu aplikací. Dalším motivačním faktorem je spolupráce a získání nových zkušeností prostřednictvím konzultací se společností Software602.
2
Kapitola
Provozní prostředí 1.1
Úvod do provozních prostředí
V této kapitole se na úvod čtenář seznámí s obecnou definicí provozního prostředí a s klíčovými vlastnostmi, které jsou při výběru prostředí sledovány. Čtenáři je vysvětlen model síťové architektury klient-server a především jsou vysvětleny pojmy tlustý a tenký klient. V další části jsou podrobněji představeny provozní modely cloudu a onpremise. Zároveň se čtenář seznámí se definicemi a vlastnostmi obou modelů a v případě cloudu i s podrobnějším popisem modelu služeb a modelu nasazení.
1.2
Provozní prostředí
Provozní prostředí definujeme jako způsob, jakým je software nasazen do provozu a dále distribuován zákazníkovi. Typy prostředí bývají popsány jako modely nasazení a jsou součástí technické dokumentace i v podobě diagramů. Volba vhodného typu je klíčovým parametrem ovlivňující celý budoucí vývoj aplikace a především její provoz. Výběr prostředí se primárně řídí typem aplikace a jejím předpokládaným způsobem využití. Volbu ovlivňuje i celá řada dalších faktorů, se kterými je třeba počítat: • Náklady na provoz. • Doba potřebná k nasazení. • Dostupnost podnikových zdrojů. • Klíčová skupina uživatelů. 3
1
1. Provozní prostředí • Právní legislativa na ochranu dat. • Bezpečnost dat. Modely poskytování služeb členíme na tři základní typy, jako jsou onpremise, cloud, hosting. Na obrázku 1.1 je možné vidět, jakým způsobem jsou informace delegovány k zákazníkovi. Zákazníkem je zde myšlena společnost nebo i jednotlivec, kterým mají být poskytnuty služby. V případě on-premise modelu se po přijetí dat o zpracování musí postarat výhradně prostředí v režii zákazníka. To s sebou přináší větší zodpovědnost za správu IT a další náklady s tím spojené. Pro model cloudu je z obrázku patrné, že kromě základního výpočetního vybavení, není potřeba dalších zařízení. Avšak je zde majoritní závislost na síti zprostředkovávající přístup ke službám.
Obrázek 1.1: Přístup k informacích skrze modely cloudu nebo on-premise. Zdroj:[[16]]
Modelem, který není na obrázku uveden, je hosting. Hosting můžeme charakterizovat jako kombinaci obou zmiňovaných modelů. Hlavní rozdíl hostingu je patrný v úrovni poskytovaných služeb. Nedisponuje takovou možností škálovatelnosti a možnosti automatizace jako cloud, ale umožňuje provoz aplikace centralizovat. Využitím hostingu lze převézt zodpovědnost za správu hardwaru, softwaru serverů a nákladů spojených s provozem na poskytovatele. 4
1.3. Klient-Server
1.3
Klient-Server
Model síťové architektury, která je rozdělena na klienta a server (označován i jako Host). Klient-server popisuje vztah mezi dvěma aplikacemi, které komunikují skrze počítačovou síť. Klient, který typicky zastupuje uživatelskou stranu, je často aplikace, která využívá služby poskytující serverem. Server je další aplikace, která poskytuje služby. Získaná data server zpracuje a následně zpět odešle klientovi. Typickým příkladem je webový prohlížeč jako zástupce klienta a libovolný webový server zajišťující nalezení a poslání vyžadované internetové stránky. Využití této technologie našlo zastoupení i v obchodních, bankovních a firemních aplikacích. [[25]]
1.3.1
Tlustý klient
Tlustý klient v sobě obsahuje presentační ale i aplikační vrstvu. Datová vrstva je zajištěna serverem, který na základě obdržených dotazů nalezne požadovaná data a zpětně přepošle. Celková správa složená z instalace, nastavení a podpory aplikací ve formě tlustého klienta je časově a tedy i finančně náročnější než ve formě tenkého klienta. Důvodem je nutnost při jakékoliv operaci s aplikací, provést změnu na každém koncovém zařízení zvlášť. Výhodu můžeme sledovat v relativně jednodušším a rychlejším vývoji aplikace. I uživatelské rozhraní je obvykle více modifikovatelné. Aplikace není zcela závislá na síti a využitím vlastního hardwaru je dosaženo i rychlejší odezvy. [[10]]
1.3.2
Tenký klient
Tenký klient obsahuje pouze presentační vrstvu. Aplikační a datová vrstva je zprostředkována serverem. Správa a operace spojené s funkčností jsou v režii serveru a klientovi jsou zasílány pouze výsledky. Nevýhodu lze sledovat v možné pomalejší odezvě aplikace, způsobené serverem ale i rychlostí linky. Na server může v jeden okamžik přijít velké množství dotazů a způsobit přehlcení, které následně zvyšuje dobu zpracování. Závislost na připojení k serveru implikuje nemožnost práce v offline modu. Přirozenou výhodou je fakt, že nasazení, správa a aktualizace jsou prováděny pouze v prostředí serveru. Klient je aktualizován na nejnovější verzi centrálně bez nutnosti zásahu uživatele. To má pozitivní vliv na provozní 5
1. Provozní prostředí náklady i čas potřebný k provedení změn. Nejběžnější formou tenkého klienta je webový prohlížeč, což umožňuje vysokou přenositelnost mezi zařízeními a systémy. Aplikace nezabírá žádné nebo pouze minimální množství diskového prostoru a v zásadně nezatěžuje vlastní hardware zařízení. [[18]]
1.4
On-premise
Model on-premise je nejrozšířenější forma provozování podnikových a nekomerčních aplikací. V literatuře se můžeme setkat také s pojmy interní instalace nebo termínem in-house. Aplikace jsou provozovány prostřednictvím vlastní výpočetní infrastruktury umístěné přímo v podnikových prostorech. Zodpovědnost za zajištění bezpečnosti, přístupnosti a celkové administrace připadá na provozovatele. Součástí správy je i zajištění licencí, případně zakoupení kopií softwaru třetích stran, které jsou potřebné pro provoz vlastních aplikací. Počet licencí se obvykle vztahuje k množství serverů nebo koncových uživatelů.
Obrázek 1.2: Struktura on-premise. Zdroj:[[19]] Na obrázku 1.2 jsou zobrazeny jednotlivé technologické úrovně, ze kterých je složena obecná struktura IT. Rozdíl mezi modely je především v rozsahu správy, za kterou zodpovídá sám zákazník. Správa se zde člení na provoz a obnovu hardwarových komponent a instalaci softwaru včetně zajištění aktualizací. Pro udržení chodu je potřebná i nemalá základna IT správců. [[13]] 6
1.5. Cloud computing
1.5
Cloud computing
Samotná myšlenka cloud computing není žádnou novinkou. První bližší definice počítačové „síťě v oblacích“, se objevuje v šedesátých létech minulého století a vymyslel ji J.C.R. Licklider. Koncem šedesátých let počítačový vědec John McCarthy přišel s revoluční myšlenkou sdílení výpočetní kapacity jako veřejná služba. A právě „služba“ je důležitým klíčem k pochopení smyslu pojmu cloud computing. Klíčové momenty historie Cloud computingu:1.3
Obrázek 1.3: Klíčové momenty Cloud computing. Zdroj:[[12]] V dnešní době je právě na cloud computing nahlíženo jako na nový způsob řešení části problematiky správy veřejného ale i soukromého sektoru IT. Rozvoj dalších technologií jako virtualizace a multi-tentant aplikace, umožnily využívat služeb cloudu i v prostředí soukromého sektoru a mění pohled na řízení podnikové informatiky. O významu tohoto modelu se vyjádřil i prezident a generální ředitel BSA1 Robert Holleyman, který prohlásil: „Cloud computing přinese evropskému hospodářství značný užitek, neboť státní správě, firmám i spotřebitelům umožní využívat efektivněji a levněji špičkový software a IT zdroje.” [[14]]
1.5.1
Definice cloud computing
Název cloud computing je odvozen z anglického slova „cloud“, jenž v překladu znamená „mrak“ nebo „oblak“. Pod pojmem mrak si lze představit něco skrytého, jako princip poskytování služeb. Zákazník předem ví, co získá, je mu však skryt způsob provozu dané služby. Tento mrak technicky představuje výpočetní infrastruktury, datová centra, platformy a síťové technologie potřebné pro funkčnost. Jedna z prvních definic vznikla na půdě univerzity Berkeley v Kalifornii. Zde byl cloud computing popsán a rozdělen na dvě části. V první části jsou 1
Business Software Alliance – organizace sdružující výrobce software v boji proti jeho nelegálnímu užívání.
7
1. Provozní prostředí aplikace, které jsou přístupné jako služba pomocí internetového připojení případně jiné komunikační sítě a které jsou zpoplatněny modelem pay-asyou-go. V druhé části jsou datová centra poskytující hardware a software nutný pro fungování poskytovaných aplikací. Agentura Gantner2 doplňuje a rozšiřuje stávající obecnou definici a navrhuje standardizovanější pohled na problematiku. Cloud computing je popsán jako způsob práce s počítačem, který je založen na poskytování sdílených výpočetních prostředků a přizpůsobitelný možnostem IT. Zákazníkům je zprostředkován jako služba na vyžádání, elasticky, samoobslužně a pomocí internetových technologií. [[9]]
1.5.2
Specifické vlastnosti cloudu
V následujícím seznamu jsou popsány specifické vlastnosti cloud computingu. [[8]] • Service-Based (založena na službě) – Uživatel má možnost si sám, bez nutné asistence poskytovatele samostatně služby aktivovat. Pomocí nabídkového rozhraní uživatel při výběru zohledňuje pouze požadovaný IT výstup a úroveň služby, nikoliv způsob její implementace nebo použité technologie. • Přístup přes síť – Služba je dostupná prostřednictvím internetových technologií s využitím standardních síťových prostředků a protokolů. Poskytovaná služba je nezávislá na povaze komunikačního klienta. • Sdílení výpočetních zdrojů – Spotřebitel nepotřebuje znát umístění zdroje ani způsob realizace služby. Pomocí multi-tentant architektury jsou poskytovány sdílené výpočetní prostředky za účelem zefektivnění využívání dostupných IT zdrojů a snížení nákladů. • Škálovatelnost a přizpůsobitelnost - Spotřebitelům jsou požadované výpočetní prostředky poskytovány na základě nastavení nebo aktuální potřeby v libovolném množství a téměř okamžitém čase. Tyto prostředky je možné přidávat ale i odebírat. • Četnost používání služeb - Účetní model je založený na zpoplatnění množství využíváných služeb, případně upraven do ucelených cenových modelů. Důležitou vlastností je dodržení modelu pay-as-yougo. 1
8
www.gantner.com/
1.6. Modely služeb
1.5.3
Kategorizace cloudů
Cloud computing lze kategorizovat na dva základní modely. První model rozlišuje jak je cloud poskytován a kdo má ke službám přístup. Obecně je v publikacích nazýván jako model nasazení. Druhý model je zaměřen na členění poskytovaných služeb dle technického výstupu. Bývá označován jako model služeb, ale je možné se setkat i s termíny distribuční nebo servisní model. • Model služeb - co je v rozsahu nabízené služby. • Model nasazení - jak je cloud poskytován.
1.6
Modely služeb
Model popisuje, co je v rozsahu nabízené služby. Jednotlivé služby v cloudu se popisují akronomy „XaaS“ neboli as-a-Service. Prvním slovem označujeme oblast, která je danou službou podporována. Podporované oblasti rozdělujeme na tři vrstvy. Na obrázku 1.4 je rozdělení jednotlivých služeb dle typu poskytované služby. Hierarchie modelů je úmyslně zvolená v tomto pořadí, jelikož nejvýše postavený model SaaS zastupuje nejpočetnější kategorii nabízených služeb.
Obrázek 1.4: Rozdělení podle hierarchie služeb. Zdroj: [[20]]
9
1. Provozní prostředí Na obrázku 1.5 je znázorněna obecná struktura složek IT, včetně úrovni zodpovědnosti za jejich správu.
Obrázek 1.5: Rozdělení modelů podle úrovně zodpovědnosti za správu. Zdroj:[[3]]
1.6.1
SaaS (Software-as-a-Service)
V případě modelu software jako služba je pronajímanou komponentou aplikace. Zákazník si pronajímá přístup k používání aplikace bez nutnosti instalace. Z důvodu provozu aplikace na dálku, odpadá zákazníkovi nutnost správy hardwaru, potřebného pro provoz aplikace. Výhodou využití SaaS je též odstranění dalších nákladů spojených s aktualizací, nastavením a denní údržby. Software dodávaný právě formou služby je také okamžitě připraven k používání. Cenová politika přístupu obvykle bývá založena na pevné měsíční taxe nebo zdarma. Vývojové společnosti pružně reagují na aktuální stav technologie cloudu a již aktivně budují své vlastní cloudové portfolio aplikací. Příklad nejpoužívanějších aplikací v cloudu formou SaaS: • email a google docs od společnosti Google, • Microsoft Office 365 posktující velice oblíbené kancelářské programy včetně emailu, 10
1.7. Modely nasazení • Adobe Creative cloud jenž poskytuje profesionální aplikace pro práci s grafikou také formou cloudu.
1.6.2
PaaS (Platform-as-a-Service)
Předmětem pronajímané služby v modelu PaaS je platforma. Zákazník získá kompletní infrastrukturu a zároveň vývojové prostředí. V rámci služby je poskytnuto provozní prostředí a virtuální sada nástrojů pro vývoj, nasazení a následné testování vlastních aplikací. Výsledná aplikace poté může fungovat jako SaaS pro ostatní uživatele. Zákazník tak může zaměřit své zdroje čistě na vývoj a správu svých aplikací namísto plýtvání zdroji na provoz. V PaaS lze jednoduše provozovat nejen jednotlivé aplikace, ale i celé podnikové systémy nebo databáze. Příkladem je Microsoft SQL Azure Database, který poskytuje relační databázi v prostředí cloudu.
1.6.3
IaaS (Infrastructure-as-a-Service)
Nejnižší model služeb v hierarchii cloudu. Zákazníkovi je formou služby zprostředkováván výpočetní výkon. Obecně si zákazník pronajímá výpočetní infrastrukturu, jako jsou servery, zálohovací systémy, firewally. Hlavní výhodou tohoto řešení je, že zákazník se nemusí starat o správu a údržbu hardwaru, nýbrž využívá přímo výkonu. Kapacitu výkonu je možné ihned a plynule měnit a tím i radikálně snižovat náklady v době, kdy není tolik vytížen. Přirozeně lze elasticky okamžitě výkon navýšit v případě náhlých špiček a neomezit koncové uživatele. Za příklady největších poskytovatelů IaaS můžeme považovat Rackspace Cloud nebo Amazon EC2.
1.7
Modely nasazení
Členění na modely nasazení se začalo objevovat společně s otázkou bezpečnosti uložených dat. Zákazníci si dobře uvědomují, že jejich data jsou uložena v cizích datových centrech a že sami nemají nad daty kontrolu. Tato skutečnost a potřeba mít vlastní data v bezpečí, pomohla při dělení cloudových služeb a následné kategorizaci cloudů na modely podle způsobu provozování. Jednotlivé modely se liší přístupností a zaměřením na koncového uživatele. Modely nejčastěji členíme na privátní, veřejný a hybridní viz obrázek 1.6. Existují i další modely, jako například komunitní cloud, který je zaměřený na určitou skupinu uživatelů.
11
1. Provozní prostředí
Obrázek 1.6: Rozdělení podle rozsahu poskytované služby. Zdroj:[[23]]
1.7.1
Privátní cloud
Hlavní myšlenkou privátního cloudu je provoz cloudových služeb výhradně pro vlastní potřebu provozovatele. Provozovatelé neboli společnosti tímto získávají tolik potřebnou kontrolu nad vlastními daty a přesto mohou využívat výhod služeb provozovaných právě pomocí cloudu. Další výhodou a někdy nutnou povinností může být jistota, že data jsou uložena na konkrétním místě, respektive chráněné zákony dané země. Společnosti provozují cloud pomocí vlastní infrastruktury, případně datového centra nebo třetí stranou. Řešení podnikové infrastruktury a sdílení dat pomocí cloudu je především z důvodu ušetření zdrojů IT. Výhodou privátního cloudu je omezení přístupu ke službám pouze pro určené uživatele. Takto vytvořený cloud může zpřístupňovat služby prostřednictvím internetu nebo přes vnitropodnikovou síť. Pro privátní cloud se v dnešní době rozhodují nejen společnosti samotné, ale také hostingové firmy, které privátní cloud na vlastní infrastruktuře nabízejí jako službu s pravidelným měsíčním poplatkem (podobně jako u veřejného cloudu) svým vlastním zákazníkům. 12
1.8. Závěr kapitoly provozních prostředí
1.7.2
Veřejný cloud
Veřejný cloud je volně dostupný, může být využíván kýmkoliv bez zásadních omezení. Může být provozován bezplatně ale i jako komerční služba. Ačkoli se jedná o veřejný cloud, jednotliví uživatelé mají přístup pouze ke svým datům a profilům nastavení aplikací. Společnou částí pro všechny je infrastruktura, na které jsou služby provozovány a aplikace které jsou uživateli používány. Aplikace mohou být členěny na jednotlivé instance, které se rozdělují podle uživatelů, kteří je chtějí využívat. Jistou slabinou řešení přes veřejného poskytovatele se ukázalo například při postupu Amazonu, který ze své cloudové infrastruktury vyhostil data WikiLeaks3 kvůli tomu, že nemají autorská práva k souborům uloženým na serverech Amazonu.
1.7.3
Hybridní cloud
Hybridní cloud kombinuje vlastnosti modelů privátního a veřejného cloudu. Společnosti například provozují vlastní podnikový systém na privátním cloudu a využívají veřejný cloud pro uchování záloh pro případ havárií.
1.7.4
Komunitní cloud
Prostředí komunitního cloudu vzniká spojením výpočetních prostředků poskytovaných určitou skupinou členů. Tato skupina se nazývá komunita, od které je i odvozen název. Členům jsou následně sdružené prostředky zpětně nabízeny formou služby. Infrastruktura je obdobně postavena jako v privátním cloudu, řešena v rámci vlastních podnikových zdrojů nebo externě dodávaná.
1.8
Závěr kapitoly provozních prostředí
V této kapitole se čtenář postupně seznámil s modely provozních prostředí. Čtenáři byla představena obecná struktura IT včetně úrovně zodpovědnosti dle vysvětlovaného prostředí. Ve zbytku kapitoly jsem popisoval definice a vlastnosti obou modelů, včetně kategorizace cloudu na modely služeb a nasazení.
1
Nezisková mediální společnost, která zveřejňuje významné utajované vládní a korporátní dokumenty.
13
Kapitola
Technické aspekty aplikací v cloudu 2.1
Úvod kapitoly technických aspektů aplikací v cloudu
Úvodní podkapitola se zabývá problematikou výběru vhodných typů aplikací pro provoz v cloudu. V další podkapitole se věnuji kritériím, která rozhodují o volbě prostředí pro provoz aplikací. Následující podkapitola je zaměřena na vývoj nových aplikací a především na pravidla, které jsou nutná při vývoji respektovat. Na závěr jsou rozebrány scénáře nasazení aplikace do prostředí cloudu pro modely IaaS a PaaS.
2.2
Typy aplikací
Vzhledem k specifickým vlastnostem cloudu a především rozdílnému účtování za služby v cloudu, se každá aplikace nehodí, aby byla provozována v cloudu. Aplikace citlivé na latenci1 mohou být typickým příkladem. Latence je závislá na kvalitě připojení od místního poskytovatele internetového připojení, které nemusí být dostatečné hned z několika důvodů. Dalším příkladem mohou být aplikace s velkými objemy dat, u kterých je očekáváno odesílání a přijímání velkého objemu dat a s tím spojené i vysoké vytěžování šířky pásma. Speciální kategorií jsou aplikace vyžadující nestandardní hardware, například pro práci s grafikou. 1
Zpoždění, které vznikne než dorazí data z bodu A do bodu B.
15
2
2. Technické aspekty aplikací v cloudu Vhodné aplikace pro provoz v cloudu nelze přesně určit, vždy záleží na vlastnostech dané aplikace. Obecně se dá očekávat, že vhodnými kandidáty jsou výpočetně náročné aplikace nebo takové, ve kterých se vyskytuje rychle se měnící požadavky na výkon hardwaru.[[24]] • Aplikace pro kancelářskou činnost Aplikace pracují s textovými nebo tabulkovými daty. Příkladem může být Microsoft office 365, který v sobě integruje celé portfolio aplikací pro práci s poštou, zpracování textů, tvorbu vizuálních prezentací a tvorbu konferencí. • Komunikační aplikace a sociální sítě Sociální sítě nebo webové konference mohou být vhodným kandidátem na provoz v cloudu z důvodu předpokládaného vysokého počtu připojených uživatelů. Škálovatelnost cloudu umožní sítím dynamicky růst v případě potřeby. • Výpočetně náročné aplikace Typickými adepty jsou výzkumné aplikace provádějící výzkumnou činnost. Takové aplikace mohou generovat extrémní množství požadavků na výpočty. V případě jednorázového nebo málo častého použití je nasazení aplikace do cloudu možností, jak ušetřit vysoké náklady na vybudování stejně výkonné infrastruktury. Problém může vznikat při nahrávání nebo stahování velkého objemu dat z aplikace. S tímto úskalím musíme počítat a sami rozhodnout, zdali je výhodnější investice do vlastního výpočetního výkonu nebo konektivity. • Krizový plán a zálohy - Přesunutím aplikací nebo jejich záloh do cloudu lze v případě výpadků způsobených živelnými pohromami nebo jinými krizovými situacemi obnovit chod kritických aplikací v co nejkratším čase. Díky lepšímu zabezpečení datacenter je vhodné uložení záloh právě do cloudových úložišť. • Testování - Dalším případem je testování provozu aplikací v různéch prostředí. Prostřednictvím cloudu lze rychle a snadno měnit běhové prostředí i včetně operačního systému. Takto variabilní prostředí umožňuje otestovat funkčnost a stabilitu aplikace a uspořit čas i náklady spojené s testováním.
2.2.1
Rozhodovací kritéria
V následujícím seznamu jsou popsána kritéria, která ovlivňují výběr prostředí nejvíce. [[22]] 16
2.2. Typy aplikací • Rychlost nasazení Pokud se rozhodneme, že chceme, aby naše aplikace byla v co nejmenším možném čase implementována a zároveň nasazena, nejvhodnějším řešením je forma PaaS. Důvodem je rozsah dodávané služby a větší množství předpřipravených nástrojů poskytovatelem než v IaaS. V PaaS není nutné se zabývat instalací vývojového prostředí a je připraveno k okamžitému používání. Umožňuje veškerý čas a zdroje zaměřit na samotný vývoj a nasazení aplikace. Na druhou stranu IaaS poskytuje větší přizpůsobitelnost prostředí. • Kontrola a ovládání Pokud budoucí provozovatel disponuje dostatečným provozním IT týmem, může být IaaS lepší volbou. Forma IaaS poskytuje větší možnost kontroly prostředí, které je však podmíněno potřebou dostatečně kvalifikovaného IT týmu. • Vývojové technologie Poskytovatelé PaaS obvykle podporují jen nejvíce populární programovací jazyky. Mezi tyto jazyky patří Ruby, Java, .NET, PHP a Python. Pokud je vyžadována jiná vývojová technologie, může být problém nalézt podporu u předem nabízených prostředí a pak bude výhodnější volba IaaS. • Bezpečnost Bezpečnost v případě IaaS ale i PaaS je většinově v garanci od poskytovatele. Rozdíl je pouze v rozsahu zodpovědnosti. Je nutné si uvědomit, že aplikace a vlastní data jsou uložena v různých datacentrech, které poskytovatel spravuje. Pokud aplikace pracuje s důvěrnými daty klientů nebo obsahují tajné podnikové know-how, bude nejlepší volbou si spravovat vlastní datové úložiště. Parametr bezpečnosti dat a aplikací se obecně označuje jako největší nevýhoda cloudového řešení provozu. Společnosti se jen nerady musí zcela vydávat na milost poskytovatele, který přesto garantuje zabezpečení dat. Zajímavé je sledovat, že ukládat svá data do cloudu je pro ně bezpečnostní problém, přesto nemalé procento těchto společností si nechává vypracovávat například účetnictví u externích společností, ale jako problém to nevidí. • Dostupnost Jak je možné pozorovat na obrázku1.4 v kapitole 1.6, struktura PaaS je postavena na infrastruktuře IaaS. Vysoká dostupnost obou řešení 17
2. Technické aspekty aplikací v cloudu vyžaduje mnohačetnou úroveň správy prostředí a kvalitní systém rozdělování zátěže (load balancing). Dostupnost je ovlivněna i geografickým rozmístěním datacenter, ať už z hlediska živelných podmínek v oblasti výskytu centra nebo politicko-legislativními omezeními. V případě provozu kritických aplikací je lepší volbou IaaS z důvodu možného pronájmu infrastruktury od více poskytovatelů a tím snížit pravděpodobnost výpadku. • Výkon Z hlediska poskytovaného výpočetního výkonu, nelze oba modely příliš rozlišovat. Jelikož PaaS je provozovaný na IaaS, je i nabídka výpočetního výkonu velice podobná.
2.2.2
Shrnutí kriterií pro výběr prostředí
Obecně je PaaS lepší volbou pro aplikace, které se vyvíjejí zcela nové. Naopak IaaS je vhodnější pro složitější aplikace vyžadující vyšší kontrolu řízení nebo mají komplikovanější proces nasazení, typickým příkladem jsou ERP nebo CRM systémy. Moderní přístup nabízí využití výhod obou možností. Pro začínající podniky bude především klíčová rychlost a jednoduchost nasazení aplikací v prostředí PaaS. Jak podniky porostou, bude větší tlak na vlastní kontrolu prostředí, což povede k přesunu na IaaS.
2.3
Vývoj cloudové aplikace
O specifických vlastnostech cloudu jsem psal v kapitole 1.5.2. Aby však aplikace provozované v cloudu byly schopny efektivně využít vysoké škálovatelnosti, dostupnosti a těžit z ekonomických výhod, je nutné již od návrhu respektovat řadu pravidel. [[17]],[[7]]
2.3.1
Redundantní design
Při návrhu architektury aplikace pro cloudové prostředí je klíčová volba takového designu, jenž dokáže rychle obnovit instance, které selhaly z důvodu havárie hardwaru nebo jiných případů. Moderní datová centra poskytovatelů cloudových služeb sama pracující s několika vrstvami redundance při poskytování služeb. A proto aplikace musí přímo podporovat redundantní funkce. 18
2.3. Vývoj cloudové aplikace
2.3.2
Využití vícejádrové technologie
Důležitým atributem aplikace by také měla být schopnost využívat vícejádrové procesory. Především z důvodu podpory škálovatelnosti.
2.3.3
Proměnlivé stavy
Jednou z nejdůležitějších podmínek pro efektivní fungování škálovatelnosti v aplikaci je minimalizace společných měnitelných stavů. V kódu se jedná typicky o proměnné nebo jiné datové struktury, které jsou sdíleny v rámci celé aplikace a v průběhu provozu jsou měněny. Problém vzniká, pokud se více serverů nebo procesů snaží aktualizovat stejné proměnné ve stejný časový okamžik. Výsledkem je vznik deadlocku1 , time-out a selhání transakcí. Řešením je minimalizování počtu nebo nejlépe úplné zrušení těchto krizových stavů v oblasti komunikace se servery, databázemi a s jinými aplikacemi.
2.3.4
Přenositelnost
Tento požadavek je především o volbě požadovaného kompromisu mezi přenositelností aplikace na jiného poskytovatele a snahou o maximální využití nabízených služeb. Pokud vývoj a především provoz aplikace příliš svážeme se specifickými nástroji poskytovatele, mohou v budoucnosti nastat problémy při přechodu k jinému poskytovateli. Tento jev se také nazývá vendor lock.
2.3.5
Dostupnost dat
Další kompromis, který musí vývojář brát na zřetel, je míra dostupnosti dat v lokálním virtuálním prostředí a množství dat načítané z databáze. Důvodů proč tento problém řešit je hned několik. Z výkonnostního hlediska je rychlejší ukládání a následné čtení dat z lokálního úložiště než z databáze. Pokud však má s daty pracovat více nezávislých procesů nebo jiné aplikace, vývojář musí zvolit kompromis mezi mírou dostupnosti dat a výkonu aplikace. Dalším faktorem je bezpečnost lokálně uložených dat ve virtuálním prostředí. Příkladem může být Amazon, který varuje, že data uložena v lokálním virtuálním prostředí nejsou zálohována a v případě selhání nemusí být obnovena. 1
Zablokování procesů nebo vláken způsobené křížovým čekáním na synchronizačních primitivech.
19
2. Technické aspekty aplikací v cloudu
2.3.6
Databáze
Databáze nemusí být přímo součástí aplikace, avšak zvolení nevhodného typu databáze může negativně ovlivnit škálovatelnost aplikace. Pokud je použita jedna centrální databáze, může vznikat kritické místo. Standardní relační databáze umožňují jistou míru škálovatelnosti, avšak ve skutečnosti jsou stejně limitovány na určité množství serverů. Většina poskytovatelů cloudu nabízí vlastní řešení databází, někteří navíc umožňují propojení databáze v cloudu s databází provozovanou on-premise. Na co si však vývojáři při výběru databáze od poskytovatele musí dát pozor, je časté omezení přístupu k nastavení samotné databáze. Omezení se projevují i v nemožnosti použití některých příkazu SQL pro práci se soubory, nepovolené replikaci MySQL databáze v Google AppEngine nebo omezení konfigurace pouze na tabulky a pole databáze.
2.4
Nasazení aplikace do prostředí cloudu
Po úspěšné implementaci naší aplikace nás čeká další krok v podobě jejího nasazení na vybrané prostředí. Avšak nasazení aplikace do prostředí IaaS a PaaS nelze popsat obecně, jelikož k úspěšnému zprovoznění aplikace nevedou stejné kroky. V následujích podkapitolách si představíme možné scénáře nasazení aplikace do obou prostředí. Zcela obecný scénář, který by pokrýval obě prostředí, není možné definovat. Proto jsou popsány scénáře nasazení aplikace pro obě prostředí zvlášť.
2.4.1
Obecný scénář nasazení aplikace na prostředí IaaS
Kroky vedoucí k úspěšnému nasazení aplikace do prostředí IaaS jsou majoritně závislé na specifických vlastnostech dané poskytovatelem. Na obrázku 2.1 je popsána obecná cesta nasazení aplikace na prostředí IaaS. Jednotlivé kroky se mohou lišit, a především vůbec nemusí být vykonány. Například pokud aplikace nevyžaduje pro svůj provoz podporu databáze nebo webového serveru. 1. Spuštění databázového serveru V prvním kroku zvolíme obraz virtuálního stroje (VM - virtual machine) zastupující funkci databázového serveru. Databázový server je možné provozovat vlastní infrastrukturou, případně jiným poskytovatelem. Důvodem může být nedostatečná důvěra v poskytovatele nebo snaha mít celkovou kontrolu nad vlastními daty. 20
2.4. Nasazení aplikace do prostředí cloudu
Obrázek 2.1: Nasazení aplikace na IaaS. Zdroj:[[15]]
2. Spuštění webového serveru Následuje výběr obrazu webového a aplikačního serveru. Některé obrazy mohou vyžadovat ruční instalaci a následnou konfiguraci, vše ale závisí na nabídce poskytovatele. Po zprovoznění serveru, bude další fází instalace serverového systému, který vytvoří prostředí pro nasazení. 3. Nastavení kontrolních prvků a databázových objektů V dalším kroku následuje inicializace bezpečnostních a opravných položek jako jsou log soubory, konfigurační soubory a tvorba tabulek databáze. 4. Nasazení aplikace Po spuštění a nakonfigurování webového serveru zbývá nasadit naši aplikaci. 5. Konfigurace technologie pro vyvažování zátěže Nastavení vyvažování zátěže je nutné pro správné fungování více instančního běhu aplikace. O vyvažování zátěže se nejčastěji stará aplikace (load-balancer). Tato aplikace poté spravuje počet instancí, případně přidělování IP adres instancím naší aplikace. 6. Správa databáze a virtuálních serverů O správu hardwaru nutnou pro funkčnost virtuálních serverů se stará poskytovatel, avšak o aktualizace systému, nástrojů a aplikace se musíme postarat sami. 21
2. Technické aspekty aplikací v cloudu
2.4.2
Obecný scénář nasazení aplikace na prostředí PaaS
Při výběru prostředí PaaS je větší množství zodpovědnosti přesunuto na poskytovatele a od toho se odvíjí i množství nutných nastavení, které musíme provést pro spuštění aplikace. Potřebnou infrastrukturu vybereme na základě charakteru aplikace a předpovídaných požadavků. Dalším nutná část výběru je o volbě operačního systému, případně verze. Na obrázku 2.2 jsou ukázány dva kroky vedoucí k nasazení aplikace na PaaS.
Obrázek 2.2: PaaS nasazení aplikace. Zdroj:[[15]]
1. Nastavení základních technických parametrů V prvním kroku se nastavují technické a výkonnostní parametry webového serveru a databáze. Poskytovatelé nabízejí předpřipravené instance webových serverů, na nás je pouze vybrat nejvhodnější konfiguraci. Parametry, které se nejčastěji ručně nastavují, jsou počet databází, velikost datového a databázového úložistě, velikost CDN 4 , počet transakcí a dalších parametrů. 4
CDN (Content Delivery Network) je síť pro doručování obsahu. Jde o soubor serverů a síťových prvků, které přesměrovávají uživatele na obsah mimo hlavní servery a tak rozkládají zátěž.
22
2.5. Závěr kapitoly technických aspektů cloudu 2. Výběr systému a správa databáze Druhým krokem je výběr požadovaného operačního systému. V nabídce větších poskytovatelů je možné zvolit i několik různých verzí. Před používáním databáze zbývá vytvořit tabulky a naimportovat vlastní data. 3. Nasazení aplikace Podobně jako v IaaS je i zde nutné nasadit aplikaci do připraveného prostředí. O nastavení vyvažování zátěže se zpravidla postará automaticky poskytovatel prostřednictvím předpřipravených nástrojů. Úvodní podkapitola se zabývá problematikou výběru vhodných typů aplikací pro provoz v cloudu. V další podkapitole se věnuji kritériím, která rozhodují o volbě prostředí pro provoz aplikací. Následující podkapitola je zaměřena na vývoj nových aplikací a především na pravidla, které jsou nutná při vývoji respektovat. Na závěr jsou rozebrány scénáře nasazení aplikace do prostředí cloudu pro modely IaaS a PaaS.
2.5
Závěr kapitoly technických aspektů cloudu
V úvodní podkapitole jsem vytipoval a následně popsal 5 typů aplikací, které jsou vhodné k provozování v cloudu. Vhodných aplikací by se zajisté dalo najít více, ale zmíněné považuji za stěžejní. Pro znázornění rozdílu mezi modely PaaS a IaaS jsem použil obrázek s migrační cestou aplikace skrze modely cloudu. Zároveň se čtenář dozvěděl o kriteriích, která mu pomohou při rozhodování nad volbou správného prostředí. V následující podkapitole jsem se zabýval problematikou vývoje aplikací pro cloud a navrhl jsem několik pravidel, jejichž dodržování vede k efektivnímu využívání prostředků. Poslední podkapitola se zaměřuje na scénáře nasazení aplikace do prostředí IaaS a PaaS včetně popisu jednotlivých kroků.
23
Kapitola
Porovnání prostředí cloudu a on-premise 3.1
Úvod kapitoly porovnání prostředí cloudu a on-premise
Srovnání prostředí cloudu a on-premise jsem provedl ve dvou oblastech. Každé prostředí lze charakterizovat podle specifických finančních parametrů, které jsou zajímavé především pro manažerské pozice a podle technických parametrů, které budou zajímat především vývojáře a technické pracovníky starající se o správu. V této kapitole jsou popsány oba pohledy zvlášť.
3.2
Finanční pohled
První oblastí porovnání jsou nákladové položky, které jsou spojeny s nasazením a provozováním aplikací. Především finanční stránka se stala nejdůležitějším faktorem při rozhodování pro přechod do cloudu nebo k inicializaci vývoje aplikace s cloudovou architekturou, o které jsem psal v kapitole 2.3. Z průzkumu 3.1 provedeného společností Microsoft plyne, že v prostředí on-premise je více jak 50% IT výdajů investováno na provoz a obnovu infrastruktury.
25
3
3. Porovnání prostředí cloudu a on-premise
Obrázek 3.1: Rozdělení výdajů na IT v on-premise. Zdroj:[[14]] V grafu jsou zobrazeny položky ovlivňující náklady velice obecně. V položce infrastruktura se skrývá celá řada dalších atributů, které se přímo i nepřímo týkají provozu infrastruktury. V následujícím seznamu je popsána struktura nákladů na model on-premise: • Pořizovací náklady na servery – obvykle největší investiční náklad. Hlavní část nákladové položky se skládá z ceny hardwaru. Součástí ceny mohou být i dodatečné služby, obvykle poskytované renovovanými prodejci, jako je prodloužení záruky, certifikace nebo 24 hodinový servis. • Pořizovací náklady na další síťové prvky – spolu se servery může být potřeba nakoupit ještě další síťová zařízení, jako jsou routery, repeatery, switche nebo huby. • Náklady na zálohování a záložní technologii – nutnou dávku pozornosti si jistě zaslouží technologie provádějící zálohování. Pro funkční zálohování může být potřeba zakoupit specializovaný software nebo hardware jako datové pásky, externí disky případně pole pevných disků. • Náklady na licencování – Spolu s nákupem hardwaru je další základní komponentou serveru software. Do pořizovacích nákladů neza26
3.2. Finanční pohled pomeňme zahrnout licence na operační systém a dodatečné licence na doplňkový software pro provoz serverů. • Náklady na chlazení – chlazení serverů a ostatní infrastruktury je jedna z nejnákladnějších položek. Správný návrh a nasazení chladících systémů je kriticky důležitý pro spolehlivý provoz. • Náklady na elektrickou energii – Typicky provozní náklad, v současnosti dosahuje 15 až 20% celkových nákladů na vlastnictví. Cena elektrické energie je ovlivněna lokalitou i dobou odběru. • Náklady na údržbu HW a SW – Údržba v sobě zahrnuje nákup, výměnu a správu zařízení, ať už z důvodu poškození nebo upgrade. Součástí správy SW je opětovný nákup licencí ale i servisní poplatek, který se nejčastěji vyskytuje u zahraničních dodavatelů SW a opravňuje k získání updatu a upgradu softwaru. • Náklady za prostor – na tuto položku se musíme dívat dvojím pohledem a to jako na náklad a ztrátu. Ztráta je to z důvodu ušlé příležitosti, jelikož by podnik mohl prostor využít pro jiné podnikové účely. Dalším problémem může být sama volba vhodného prostoru pro provoz serverů. Prostor musí splňovat bezpečnostní normy a ideálně by se mělo jednat o bezprašné prostředí. • Náklady za úpravy prostoru – vyčleněný prostor pro vybudování serverovny vyžaduje specializované stavební úpravy jako vybudování zdvojených podlah nebo stropů pro podporu chlazení, vybudování kvalitní napájecí sítě, rozvod počítačové sítě a nákup stojanů pro nasazení serverů. • Náklady na fyzické zabezpečení – součástí bezpečnostních norem je zajištění efektivního hasicího systému. Pro usnadnění správy serverů je vhodná instalace monitorovacího systému. Dostatečnou pozornost bychom měli také věnovat ostraze objektu, ve které se servery nalézají. Zvýšení bezpečnosti lze také zajistit omezením přístupu do prostoru serverů pomocí elektronického zámku s identifikací osob a instalací kamerového systému. • Mzda správců – pro provoz serverů je potřeba i kvalifikovaný personál, starající se o správu. Obvyklá mzda správců a jiného personálu spravující servery se pohybuje v řádech několika desítek tisíc korun. V provozních nákladech pak mzda tvoří velkou položku. 27
3. Porovnání prostředí cloudu a on-premise V následující tabulce 3.1 jsou shrnuty jednotlivé finanční položky, které se týkají cloudu nebo on-premise modelu. Jak je z tabulky patrné, v případě on-premise je mnohem více nákladových položek. To však neznamená, že musí být v konečném součtu nákladnější. Náklady rozlišujeme na kategorie: • Investiční náklady – jsou náklady, které vstupují do dlouhodobého majetku společnosti. Nejvyšších hodnot obvykle dosahují na počátku podnikání. Právě rozdíl počátečních nákladů mezi cloudem a on-premise jsou často brány jako velká výhoda cloudu. Nízké investiční náklady cloudu připravují ideální prostředí pro vznik startupů nebo pro společnosti s žádnou až malou stávající IT infrastrukturou. • Provozní náklady – jsou náklady, které mají závislost s provozní činností a jejich hodnota je vázána na určité období. Hlavními položkami budou především náklady spojené se správou a údržbou prostředí a mezd personálu, vykonávající tyto úkony. Cloud ze své podstaty by měl snížit i provozní náklady, avšak toto snížení není vždy zaručeno, a proto cloud není vhodný úplně pro každého. Množství nákladových položek, ať už investičních nebo provozních, zcela pravdivě nevypovídá o skutečné finanční náročnosti. Při výběru prostředí se především hledí na dva ukazatele: • TCO (Total Cost of Ownership) – neboli celkové náklady na vlastnictví je metoda hodnocení nákladových variant. TCO popisuje celkové náklady složené z pořizovacích a provozních nákladů za určené období. • ROI (Return On Investments) – index označující poměr vydělaných a investovaných pěnez. Výsledkem je výnos z investovaných nákladů v procentuálním poměru. [[5]]
28
3.2. Finanční pohled
Tabulka 3.1: Srovnání cenových parametrů cloudu a on-premise Oblast
Cloud
On-premise
Investiční náklady na
Koncové stanice
Servery
hardware
Síťová infrastruktura
Aktivní síťové prvky
Internetové připojení
Zálohovací server nebo disky
Firewall
Síťová infrastruktura
Síťová infrastruktura
Firewall Koncové stanice
Investiční náklady na
Antivirová ochrana
software a licence
Serverový SW Monitorovací SW Antivirová ochrana
Investiční náklady na
Vyhrazení prostoru
prostor
Úprava prostoru Výbava prostoru Elektrická síť Chladící systém Zabezpečovací systém
Provozní náklady
Poplatky za využité služby
Údržba HW
Údržba SW
Upgrade HW
Prodloužení licencí SW
Údržba SW
Servisní poplatek
Prodloužení licencí SW
Mzda správců
Servisní poplatek
Spotřebovaná energie
Spotřebovaná energie
Internetové připojení
Mzda správců Náklady na zabezpečení
29
3. Porovnání prostředí cloudu a on-premise
3.3
Technický pohled
Pro srovnání cloudu a on-premise jsem vytipoval klíčové technické parametry, na základě kterých je možné jednotlivá prostředí odlišit. Technické oblasti a vlivy daných prostředí jsem shrnul do tabulky 3.2.[[11]] Tabulka 3.2: Srovnání technických parametrů cloudu a on-premise Oblast
Cloud
Infrastruktura
Koncové stanice a internetové připojení.
Ve vlastní režii nebo externí datové centrum.
Přístup k aplikaci
Přes internet nebo síť.
Profil zákazníka
Rychle se rozvíjející společnosti požadující flexibilní růst bez investic do infrastruktury.
Přes internet nebo síť. Pro zavedené společnosti s předpokládaným časovým rámcem pro využívání nad 5 let.
Uživatelské rozhraní
Omezení v rámci webových technologií.
Neomezené prostředí
Spolehlivé připojení k internetu a zobrazovací zařízení.
Tradiční IT komponenty, serverový hardware a software, datové uložiště a infrastruktura zprostředkující síťové připojení.
Hardware pro přístup
Update Obnova
Doba realizace
Update celé aplikace v jeden čas a centrálně. Automatická obnova hardwaru, avšak aplikace musí podporovat obnovení instancí. Kratší doba realizace, úspora v již předpřipravené infrastruktuře.
On-premise
Se spoluprací uživatele, každý klient zvlášť. Obnova po selhání je zcela ve vlastní režii. Delší doba, nutná instalace infrastruktury a vývojového prostředí.
Podpora
Offline nebo online nápověda
Počet uživatelů
V závislosti na pronajaté infrastruktuře, teoreticky neomezený počet.
Offline nápověda, omezená online nápověda V závislosti na vlastní infrastruktuře, teoreticky neomezený počet.
Integrace
Omezená integrace s existujícími systémy.
Snadnější integrace se stávajícími systémy.
Z tabulky je patrné, že k provozu aplikace v cloudu není potřeba složitá infrastruktura. Toto tvrzení platí pouze v případě využití služeb veřejného 30
3.4. Závěr kapitoly porovnání prostředí cloudu a on-premise cloudu. Vybrané profily zákazníků jsou pouze jedny z možných příkladů a zcela nepokrývají všechny možnosti. Nehledě na skutečnost, že zákazníkem může být i jedinec, nikoliv pouze společnost. Velkou výhodou je možnost centrálního update aplikace v cloudu. Centralizace přináší úsporu nákladů a času potřebného k provedení změn. A zároveň se na updatu aplikace nemusí svou spoluprácí podílet uživatel, jako je to v případě on-premise. O obnovu po selhání má v režii zodpovědná instance, kterou je v případě cloudu poskytovatel. Dobou realizace nasazení aplikace v on-premise je delší oproti nasazení v cloudu jen za předpokladu, že infrastruktura pro provoz on-premise se vytváří nová. Pokud infrastruktura existuje, je doba realizace obdobná.
3.4
Závěr kapitoly porovnání prostředí cloudu a on-premise
V kapitole věnované porovnání prostředí cloudu a on-premise jsem se zvlášť věnoval finanční a technické stránce. Obsahem finanční stránky bylo identifikování typů nákladů obou prostředí. Z vybraných nákladu jsem posléze sestavil srovnávací tabulku. Tabulka byla rozdělena na náklady investiční a provozní. Obsahem technické stránky bylo porovnání prostředí na základě technických aspektů. I pro tuto část jsem vytvořil tabulku zahrnující určitou technickou oblast a její popis v závislosti na daném prostředí.
31
Kapitola
Poskytovatelé cloudových služeb 4.1
Úvod kapitoly poskytele cloudových služeb
V této kapitole se zabývám představením 3 vybraných poskytovatelů. V další části provádím porovnání nabízených služeb včetně porovnání cen. V závěru se věnuji porovnání dodatečných služeb.
4.2
Výběr poskytovatelů
V současné době je technologie cloudu neustále na vzestupu. Větší společnosti zaměřené na vývoj softwaru sami nabízí použití jejich aplikací formou cloudových služeb. Přímých poskytovatelů cloudu v jakékoliv formě je nepřeberné množství, a proto jsou vybráni tři velcí zástupci: • Amazon AWS • Microsoft Azure • Big Blue One
4.2.1
Amazon AWS
Společnost Amazon v současnosti patří mezi největší poskytovatele cloudových služeb ať už z hlediska poskytovaných služeb nebo množství zákazníků využívající jejich služby. Současně nabízí největší škálu služeb a podpůrných nástrojů. Celkové zaměření Amazonu je primárně na vývojáře software a další poskytovatele PaaS a SaaS. Amazon měl původně záměr 33
4
4. Poskytovatelé cloudových služeb vybudovat dostatečně výkonné výpočetní centru, které by pokrylo potřeby provozu jejich webu i ve špičce. Avšak množství nevyužitého výkonu dovedl Amazon k myšlence sdílení tohoto výkonu i pro jiné uživatele a dal v roce 2002 vzniknout skupině cloudových produktů Amazon pod zkratkou AWS neboli Amazon Web Services. Pro zajímavost Amazon nyní generuje větší zisky ze segmentu poskytování cloudových služeb, než z prodeje knih a zboží prostřednictvím e-shopu. Pro AWS je především typické poskytování služeb v rozsahu IaaS a PaaS. [[1]]
4.2.2
Microsoft Azure
Microsoft Azure je nejmladším zástupcem z vybraných poskytovatelů. Vývoj platformy Azure započal v roce 2008 a pro zákazníky byla služba zprostředkována v roce 2010. Microsoft ale i Google poskytují primárně vlastní aplikace, a nevyužívají technologii jiných výrobců. Hlavním zaměřením Microsoft Azure je na platformu PaaS, ale s nabídkou virtuálních strojů zasahuje zcela jistě i do segmentu IaaS. Postupně přidává i další služby a rozšiřuje se i do oblasti SaaS. Nativně jsou podporovány jazyky .NET (VB, C#), C++ , PHP, Java, Ruby, Python. [[3]]
4.2.3
Big Blue One
Big Blue One je společný projekt, na kterém se podílí společnosti Cassablanca, VMware, Hewlett-Packard a AMD. Primárním cílem projektu je zaměření na poskytování veřejného cloudu ve formě IaaS. Cloud je postaven na platformě HP CloudSystem Matrix, který je založený na blade serverech rovněž od společnosti HP. Big Blue One nenabízí pouze cloud, ale rovněž má v nabídce službu ONE Solution, které umožňuje sdílení dokumentů napříč platformami. Dále poskytuje služby pro tvorbu záloh a dlouhodobou archivaci. [[2]]
4.3 4.3.1
Srovnání nabídky Nabídka instancí
Je obtížné přesně srovnat nabídku všech poskytovatelů, jelikož Amazon a Microsoft vytváří předpřipravené instance, které mají výkon přesně daný 34
4.3. Srovnání nabídky a Big Blue One naopak umožňuje vlastní konfiguraci. Porovnání nabídky nejlépe uvidíme v tabulce 4.1 Tabulka 4.1: Nabídka instancí Amazon AWS a Microsoft Azure Amazon AWS Micro Instance 613 MB RAM, up to 2 ECUs (for short periodic bursts), EBS storage only Small Instance 1.7 GB RAM, 1 EC2 CU** (1 virtual core with 1 EC2 Compute Unit), 160 GB storage Medium Instance 3.75 GB RAM, 2 EC2 CU** (1 virtual core with 2 EC2 CU each), 410 GB storage Large Instance 7.5 GB RAM, 4 EC2 CU (2 virtual cores with 2 EC2 CU each), 850 GB storage Extra Large Instance 15 GB RAM, 8 EC2 CU (4 virtual cores with 2 EC2 CU each), 1690 GB storage
Microsoft Azure Extra Small Shared core 1.0 GHz, 768 MB RAM 20 GB storage Small 1 Core 1.6 GHz , 1.75 GB RAM, 225 GB storage Medium 2 Cores 1.6 GHz, 3.5 GB RAM 490 GB storage Large 4 Cores 1.6 GHz, 7 GB RAM 1000 GB storage Extra Large 8 Cores 1.6 GHz, 14 GB RAM, 2040 GB storage
Pro přehlednost rovnou uvedu ceny za hodinu pro systémy Windows. Do tabulky přidám vypočtenou cenu u Big Blue One, která odpovídá ekvivalentní konfiguraci Azure 4.2. Tabulka 4.2: Cena instancí za hodinu Amazon AWS Micro Instance Small Instance Medium Instance Large Instance Extra Large Instance
Cena 0,035$ 0,115$ 0,23$ 0,46$ 0,92$
Microsoft Azure Extra Small Small Medium Large Extra Large
Cena 0,02$ 0,12$ 0,24$ 0,48$ 0,96$
Big Blue One 0,07$ 0,17$ 0,32$ 0,41$ 1.11$
Poskytovatel Big Blue One nabízí ve svém cenovém kalkulátoru pouze měny Česká koruna a Euro. Cena v tabulce je ručně přepočtená z korun na dolary1
1
Kurz ke dni 14. 5. 2013 byl 20.21Kč/1$
35
4. Poskytovatelé cloudových služeb Amazon dále nabízí možnost pronájmu dalších dvou typů instancí – rezervované a spot. • Rezervované instance – zákazník si rezervuje určitou instanci a následně platí zvýhodněnou cenu za spotřebovaný výkon. Předplatné neboli rezervace bývá obvykle v rozsahu na 1 a 3 roky. • Spot instance – zákazník má možnost nakoupení zbytkové kapacity formou poptávky, kdy sám zadá vlastní cenu a v případě, že cenová nabídka Amazonu klesne pod hranici zadanou zákazníkem, je mu tato kapacita poskytnuta.
4.3.2
Úložiště
Dalším sledovaným parametr při výběru poskytovatele cloudu je zpoplatnění úložiště: 4.3 Tabulka 4.3: Cena úložiště Amazon AWS První TB / měsíc Dalších 49 TB / měsíc Dalších 450 TB / měsíc Dalších 500 TB / měsíc Dalších 4000 TB / měsíc Dalších 5000 TB / měsíc
Cena 0,140$
Microsoft Azure za každý uložený GB /měsíc
Cena 0.140$
0,125$ 0,11$ 0,095$ 0,08$ 0,055$
Big Blue One nabízí v základní nabídce úložiště dat pouze do velikosti 500GB. Minimální velikost odebrané konfigurace začíná na 20GB a cena rozšíření je 0,01$ / GB.
36
4.3. Srovnání nabídky
4.3.3
Závěrečné shrnutí nabídky poskytovatelů
Na závěr shrnující tabulka4.4 nejdůležitějších podrobností, které potenciálního zákazníka zajímají. Tabulka 4.4: Shrnutí nabídky poskytovatelů: Zdroj:[[1]],[[3]],[[2]]
Způsob platby ovládací rozhraní
Zabezpečovací funkce a služby zdarma
Zabezpečovací funkce a služby placené Autoscaling SLA Load ballancing Monitoring Počet podporovaných systémů Podporované procesory Podporované programovací jazyky Podpora
Služby podpory
Big Blue One pay-as-you-go, platební plán
Amazon AWS pay-as-you-go, platební plán webové rozhraní, API, příkazová řádka, GUI firewall, ochrana osobních údajů, možnost vlastního nastavení oprávnění přístupu, kontrola selhání instance (failover) šifrování dat, perzistence dat, systém kontroly síťových aktivit (IDS), snapshot zálohy ano 99,999% ano (placený) ano
Microsoft Azure pay-as-you-go, platební plán webové rozhraní, API, příkazová řádka
ne 99,9% ano (zdarma) ano
inspekce datových cest (IPS), další IP adresy, víceúrovňové úložiště dat, šifrování dat ne 99,95% ano ano
13
9
7
32 bit, 64 bit
32 bit , 64 bit
32 bit, 64 bit
APL, Java, PHP, Python, Ruby, WinDev placená telefonická podpora, fórum, 24/7, diagnostické nástroje, online průvodce
BASIC, Java, PHP, Python, Visual Basic placená
ochrana osobních údajů, ochrana dat, perzistence dat
úložiště záloh
telefonická podpora, fórum, 24/7, online nápověda
webové rozhraní, příkazová řádka
firewall, geograficky oddělené zálohy dat, kontrola selhání instance (failover)
nespecifikováno placená telefonická podpora, 24/7, online nápověda
37
4. Poskytovatelé cloudových služeb Nabídka poskytovatelů se oblasti způsobu platby příliš neliší, všichni nabízí možnost vytvoření platebních plánů a tím získat i lepší poměr ceny. Velké rozdíly jsou především v doplňkových službách. Amazon AWS nabízí největší škálu zabezpečovacích služeb zdarma, ale i v příplatkovém segmentu. Zároveň jako jediný nabízí službu Auto Scaling, která automaticky přidá nebo odebere Amazon EC2 instance v případě potřeby. I v počtu podporovaných operačních systémů dominuje Amazon. Zajímavostí je deklarování 100% SLA u poskytovatele Big Blue One na přední stránce. Avšak v obchodních podmínkách je uvedena hodnota 99,95%.
4.4
Závěr kapitoly o poskytovatelích cloudu
V kapitole jsem se věnoval analýze nabídek poskytovatelů Amazon AWS, Microsoft Azure a Big Blue One. Zjištěné výsledky byly zapsány do tabulek, ve kterých jsou postupně porovnány nabízené typy instancí 4.1. Ceny instancí za hodinu jsou zaznamenány v samostatné tabulce 4.2. Dalším sledovaným parametrem byla cena uložiště 4.3. V poslední tabulce jsem porovnal ostatní parametry, které se týkají podpory, zabezpečení a dalších oblastí 4.4.
38
Kapitola
Praktická část 5.1
Úvod do praktické části
V praktické části se zabývám výpočtem a porovnáním nákladů na provoz aplikace v cloudu a on-premise. Úvodní část nejdříve seznámím čtenáře se společností Software602 a s její nabídkou aplikací. Na základě konzultací s vedoucím práce bude zvolena aplikace, na které budou prováděny následující aktivity. V další části se věnuji popisu aplikace a určení technických parametrů, které byly sledovány při testování. Na základě výsledků jsem vybral vhodné poskytovatele cloudu a typy instancí, které byly vhodné pro provoz aplikace. Na závěr jsem provedl srovnání jednotlivých prostředí podle výsledků kalkulací nákladů a navrhl jsem doporučené prostředí.
5.2
Software602
Obrázek 5.1: Logo společnosti Software602 Společnost Software602 [[4]] je významným hráčem na českém trhu v oblasti elektronizace dokumentů a jejich dlouhodobé archivace při dodržení 39
5
5. Praktická část přísných českých a evropských legislativních požadavků. Zákazníkům z řad soukromého sektoru ale i státních institucí jsou dodávány řešení postavené na aplikacích formulářového typu a společně s elektronickou archivací (viz kapitola 5.2.1) pomáhají zvyšovat standard pro bezpečnou práci. Software602 působí na českém trhu již od roku 1991 a po dobu své existence si dokázala získat i řadu mezinárodních ocenění. Současně se společnost může pochlubit řadou certifikací podle ISO v oblasti řízení projektů, řízení kvality, poskytování IT služeb a především v oblasti bezpečnosti informací. Konzultanti společnosti se také angažují v rozvoji evropských norem pro archivaci důvěryhodných elektronických dokumentů.
5.2.1
Produkty Software602
Produkty společnosti Software602 se dělí na dvě velké skupiny podle funkčnosti, kterou podporují. První velká skupina produktů je zaměřena na problematiku elektronizace procesů. Druhá skupina se specializuje na dlouhodobou archivaci elektronických dokumentů. Elektronizace procesů - Základním kamenem aplikací pro převod informací z podnikových procesů do elektronické podoby je využití technologie inteligentních formulářů. Krátký popis aplikací je uveden v seznamu: • Form Signer - plugin pro podporu autentizace a autorizace. Současně existuje ve verzi i pro web. • Form Filler - aplikace pro vyplňování elektronických formulářů. • Form Server - server zajišťující centrální správu formulářů, jejich oběh a schvalování. • Form Designer - nástroj pro návrh formulářů. • Spisová služba - systém pro vytváření formulářů a elektronizaci procesů s podporou legislativních požadavků, kterým podléhá spisová služba. • DocFlow server - nástroj pro celkovou správu všech typů dokumentů. Dlouhodobá archivace - Řešení pro podporu dlouhodobého uchování elektronických dokumentů. Tyto aplikace musí splňovat mezinárodní normy ETSI. Seznam aplikací v této kategorii včetně krátkého popisu: • Print2PDF X - nástroj pro centrální zpracování dokumentů ve formátu PDF a PAdES. 40
5.3. Výběr vhodné aplikace • Elektronický archiv - systém pro elektronickou archivaci dokumentů se schvalovacími procesy, řízením dokumentace a unifikovaným rozhraním pro příjem a odesílání dokumentů. • AdES Server - server pro rozšíření funkčnosti informačních systémů o službu dlouhodobé ověřitelnosti dokumentů podle standardu PAdES LTV.
5.3
Výběr vhodné aplikace
Pro řešení praktické části práce byla zvolena z nabídky Software602 aplikace Form Filler. Důvodem výběru této aplikace jsou skutečnosti, že již existují verze provozu formou samostatné aplikace nebo formou zásuvného modulu pro internetové prohlížeče. Právě tyto dvě formy umožňují provoz v prostředí on-premise a cloudu a následnou komparaci, což je klíčové pro výstup z této práce.
5.3.1
Form Filler
Účelem aplikace Form Filler je elektronický sběr informací v offline ale i online režimu ve formátu XML. Form Filler umožňuje vyplnění informací přímo do formuláře a následný sběr dat v elektronické podobě s možností ověření elektronickým podpisem. Výstupní formulář je možné následně tisknout nebo převézt do formátu PDF a odeslat. O organizaci vyplněných formulářů se však nestará Form Filler, ale další produkt od Software602 Form Server. Form Filler existuje ve verzi zdarma, která nabízí pouze omezenou funkčnost. Ze zákaznického hlediska je zajímavější placená verze, která umožňuje kompletní přizpůsobení formulářů. Pro návrh a změnu formulářů je připravena aplikace Form Designer.
5.3.2
Technické detaily desktopové verze Form Filler
Desktopovou aplikaci je možné provozovat v prostředí operačních systémů Windows (podpora od verze XP), dále v systémech Linux(podporovány jsou distribuce Suse Linux Enterprise, OpenSUSE, Red Hat verze 5 a 6, Fedora ve verzích 15 a 16, Ubuntu verze 10.10,10.04,11.04 LTS a 11.10 a dále ještě Debian ve verzi 5 a 6) a Mac OS X (od verze 10.5 a vyšší). Existuje také speciální verze Form Filler Portable, kterou je možné nainstalovat na libovolné přenosné paměťové médium a provozovat na zařízení s operačním systémem Windows. 41
5. Praktická část K provozu aplikace není potřeba nijak zvlášť výkonný hardware. Aplikace si vystačí s počítačem kancelářského typu, který se cenově pohybuje do 10 000Kč. Jediná podmínka je dána na minimální velikost operační paměti, která je stanovena na 512 MB. Nároky kladené na velikost diskové prostoru nejsou také nějak závratné. Instalační soubor v prostředí Windows zabírá 65,5MB, pro prostředí Linux je to ještě méně a to v závislosti na distribuci okolo 35MB. Po instalaci si program zabere na disku 118 MB a tedy nic, s čím by měl mít kancelářský počítač problémy. Komunikace se serverem probíhá buď prostřednictvím internetového připojení nebo podnikové sítě. Na obrázku 5.2 je spuštěná aplikace Form Filler s otevřeným formulářem.
Obrázek 5.2: Form Filler. Zdroj: [Autor]
5.3.3
Technické detaily webové verze Form Filler
Jelikož se jedná o webové aplikace, tak limitní podmínkou pro spuštění je internetový prohlížeč, který zastupuje běhové prostředí. Aplikace funguje na bázi tenkého klienta. Klient stahuje veškerá data od serveru a opětovně posílá zpět ke zpracování. V tomto případě si klient vyžádá formulář a 42
5.3. Výběr vhodné aplikace server pošle příslušný obsah v požadovaném formátu html. Nároky na výkon hardwaru jsou tak přeneseny na server. Většinové nároky na hardware jsou primárně na velikost diskového prostoru a velikost operační paměti, kam si aplikace ukládá svá data ve formě dočasných souborů. Dalším faktorem je zatěžování linky internetového připojení. Kontrola vyplnění povinných polí probíhá na klientské straně pomocí JavaScriptu.
5.3.4
Výhody a nevýhody obou verzí
Vývoj desktopové verze Form Filler pro všechny různé platformy je finančně náročný. Proto vznikla webová verze, která je platformě nezávislá a její vývoj není tolik náročný. Zároveň je i vhodným kandidátem pro převod do formátu provozovatelný v cloudu. Pojďme si přestavit hlavní výhody 5.1 a nevýhody 5.2 obou verzí. Nutno dodat, že některé výhody nebo nevýhody plynou z podstaty tenkého a tlustého klienta. Tabulka 5.1: Výhody desktopové a webové verze Form Filler Webová verze
Desktopový verze
Nižší výkonnostní nároky na klientské zařízení. Možnost pracovat s formuláři kdekoliv, kde je připojení na internet.
Snížení zátěže serveru, jelikož výpočty probíhají na straně klientské stanice.
Vývoj pouze pro jednu platformu.
Plná kontrola nad aplikací a formuláři.
Bez nutnosti instalace a centrální update.
Možnost propojení s dalšími aplikacemi.
Jednoduchý převod aplikace do cloudu.
Okamžitá znaků.
Možnost práce v offline stavu, pokud jsou formuláře stažené na stanici.
kontrola
nepovolených
43
5. Praktická část Tabulka 5.2: Nevýhody desktopové a webové verze Form Filler Webová verze
Desktopový verze
Omezená kontrola nad aplikací
Komplikovaný update a upgrade aplikace.
Závislost na internetovém připojení, nemožnost použití formulářů offline.
Provoz možný pouze v PC, omezená mobilita.
Nejsou podporovány veškeré typy formulářů.
Podpora pouze tří platforem.
Omezená integrace s jinými aplikacemi.
Ruční stahování aktuální podoby formulářů.
Kontrola vkládáni nepovolených znaků, až po přechodu na další krok.
5.3.5
Obecný scénář nasazení a použití aplikace
Pro sepsání scénáře použití aplikace Form Filler spolu s aplikací Form Server, jsem provedl analýzu případových studií společnosti Software602, abych mohl identifikovat pracovní procesy, které jsou s aplikacemi spojené. Vytvoření ukázkového scénáře může pomoci při pochopení způsobu využívání aplikace Form Filler. Aplikace Form Filler většinově není hlavní strategickou aplikací. Hlavním důvodem zavádění bývá snaha nahradit přenos dat papírovou nebo elektronickou tabulkovou formou. Z toho plynou problémy spojené s obtížnou administrací, která zabírá více času zaměstnancům a je více náchylná na zanášení chybných údajů. Kontrola dat probíhá pouze vizuální formou. Obtížné je také vyřešení omezení přístupu jen k určitým datům. Archivace dokumentů a jejich následné vyhledávání je komplikovaný proces vyžadující enormní množství času. Nasazení probíhá v prvotní fázi zavedením systému pro řízení a oběh formulářů (Form Server) na serverovou centrálu společnosti. Obvykle je zde umístěna centrální databáze a je zde zajišťován archiv společně se zálohami. Dalším krokem je nastavení certifikačních autorit pro přístup k daným oblastem v systému a zároveň pro proces schvalování formulářů. Obvyklým požadavkem je integrace s používanými aplikacemi pro správu a řízení vztahů se zákazníky. V posledním kroku zbývá nasazení aplikace elektronických formulářů a převod požadovaných dokumentů do digitálních šablon. Typická struktura je znázorněna na obrázku 5.3. 44
5.4. Z pohledu provozovatele Form Filler
Obrázek 5.3: Scénář použití aplikace Form Filler
Scénář použití aplikace vycházející z analýzy případových studií, je obecně asi takový, že uživatel, kterým může být nejen zaměstnanec ale i zákazník si spustí Form Filler a vyplní všechny požadované údaje do formuláře. Formulář provede automatickou kontrolu buď přímo při vyplňování, nebo při pokusu o další krok. K formuláři je případně přidáno časové razítko a elektronický podpis. Data z formuláře jsou automaticky zaslána na centrálu, kde jsou dále zpracovávána nebo uložena na lokálním úložišti. Po přijetí dat na centrále, příslušná certifikační autorita provede schválení. Každé pracoviště, přes které prochází formulářová data, přidá příslušné certifikáty a tím schválí jejich zpracování. Celý proces probíhá bez nutnosti přepisování dat nebo ručním přeposíláním souborů.
5.4
Z pohledu provozovatele Form Filler
Jak bylo zmíněno, Form Filler nebude pravděpodobně strategickou aplikací. Z toho důvodu se dá předpokládat, že budoucí provozovatel, ať už ze sektoru soukromého nebo státního, bude vlastnit nějakou IT infrastrukturu. Pak je tedy otázka, zdali má vůbec smysl uvažovat o cloudové formě provozu aplikace. Smysl to však mít bude v případech: 45
5. Praktická část • Jedná se o nově rozvíjející společnost, která nemá dostatečný počáteční kapitál pro budování vlastního IT centra. • Společnost již provozuje jinou aplikací v prostředí cloudu a přidání další není problém z důvodu snadné škálovatelnosti. • Společnost, která nechce i kvůli malému množství serverů vyhrazovat a vybavovat prostor pro jejich provoz. • Pro společnosti, kterým končí životnost serverů a zároveň končí podpora od výrobce serverů. • Tam kde bude provoz aplikace vyžadován jen po určitou dobu nebo jen v pravidelných intervalech. Jako budoucí provozovatel se dostávám do fáze, kdy musím vybrat jedno z prostředí pro provoz aplikace. Výběr prostředí omezím na možnosti onpremise a cloud. Na obrázku 5.4 je zachycen rozdílný přístup při používání desktopové a cloudové verze aplikace Form Filler.
Obrázek 5.4: Model použití desktopové a cloudové verze Form Filler. Zdroj:[Autor] 46
5.4. Z pohledu provozovatele Form Filler Nabízí se ještě možnost hostingu, která stojí na pomezí, ten však není předmětem práce, a proto o něm nebudeme uvažovat. Do úvahy musím vzít hned několik faktorů, které musím zvážit a jejichž výsledek může mít vliv na výběr prostředí. Patrně nejdůležitějším faktorem, který obvykle rozhoduje, jsou náklady. K určení nákladů za jednotlivá prostředí, bude prvním krokem určení výkonnostních parametrů aplikace. Technické nároky lze určit na základě testů, kde lze nasimulovat různé scénáře. Výsledky dosažené při testování lze použít jako orientační. Nejreálnější výsledky jsou ovšem pouze přímo z nasazené aplikace. Při testování aplikace jsou sledovány parametry: • zátěž procesoru, • spotřeba paměti RAM, • spotřeba paměti na datovém úložišti, • množství přijatých a odeslaných dat. Dalším faktorem, nad kterým se musím zamyslet, je způsob použití aplikace a také intenzita jejího využívání. Pokud má být aplikace zpřístupněna široké veřejnosti, bude nutné předpokládat, že na aplikaci a provozní prostředí, bude v určitý čas vyvíjena proměnlivá zátěž. O to více je důležité si promyslet, pokud by se například mělo jednat o nahrazení papírových formulářů pro registraci vozidel nebo daňová přiznání, které mohou být klíčové pro fungování veřejných úřadů nebo jiných nenahraditelných institucí.
5.4.1
Testování aplikace Form Filler
Jak jsem uvedl již v úvodu praktické části, minulý rok provedla společnost Software602 na žádost studentů Ondřeje Sedláčka [[21]] a Martina Antonyho [[6]] sérii výkonnostních testů webové aplikace Form Filler. Cílem měření bylo zjištění specifických požadavků, které aplikace vyžaduje pro svůj provoz při různých stupních zátěže. Scénářem využití aplikace je zpřístupnění elektronických formulářů pro hlášení o úrazu (dětí a studentů) prostřednictvím stránek ministerstva školství. O podrobné metodice testování si můžete přečíst v pracích obou studentů. Pro moji práci jsou klíčové výsledky měření, na kterých budu následně provádět porovnání prostředí a vlastní kalkulaci nákladů. Pro správné porozumění výsledkům je dobré zmínit některá kritéria. Měření aplikace proběhlo ve dvou fázích. V první fázi proběhlo generické testování, kde bylo současně spuštěno v jeden čas 100, 250 a 500 formulářů. Pro moje výpočty jsou stěžejní naměřená data získaná v druhé fázi. Tyto 47
5. Praktická část výsledky mají simulovat reálné použití aplikace zakládající se na statistice odeslaných formulářů, které poskytnulo ministerstvo školství. Obě testování probíhala na virtualizovaném serveru, který měl naalokováno 1GB paměti RAM, 1 jádro o frekvenci 3,21 GHz.
5.4.2
Výsledky testování
Ze statistiky poskytnuté ministerstvem školství vyplývá, že formuláře jsou nejvíce využívány ve dvou časových intervalech během dne. Dle výpočtů, které provedl Ondřej Sedláček, se dá očekávat spuštění až 100 formulářů během hodiny. Z toho se odhaduje, že současně v jeden čas může být spuštěno 25 formulářů. Výsledky jsou zaznamenány v tabulce 5.3 Tabulka 5.3: Výsledky měření reálných dat Měřená veličina Omezená kontrola nad aplikací Nejvíce současně otevřených formulářů Nejvyšší zatížení procesoru Průměrné zatížení procesoru Maximální spotřeba paměti RAM Průměrná spotřeba paměti RAM Počet přijatých / odeslaných dat Chyba datového toku Průměrná doba odezvy
5.5
Naměřená hodnota Komplikovaný update a upgrade aplikace. 29 43,75% 2,81% 212 MB 161 MB 22,04 MB / 20,90 MB 106,729 MB 191 ms
Kalkulace nákladů
Když známe výsledky měření, můžeme provézt výpočet nákladů pro jednotlivá prostředí pouze orientačně. Pro kalkulaci nákladů budu uvažovat pouze položky, které se týkají poskytnutých služeb. Jelikož ze scénáře užití aplikace vyplývá, že o vyplňování se postarají sami uživatelé a o zpracování se budou starat úředníci ministerstva školství, dá se tedy předpokládat, že ve vlastnictví ministerstva jsou koncová zařízení a současně je zajištěna dostatečná internetová konektivita a podpora údržby. Proto do nákladů za hardware nebudu ani pro jedno prostředí zahrnovat koncová zařízení a náklady za síťovou infrastrukturu. 48
5.5. Kalkulace nákladů
5.5.1
Cloud - Amazon AWS
Za poskytovatele IaaS, pro kterého budu vypočítávat náklady, jsem zvolil Amazon AWS. Pro výběr vhodné konfigurace musím vycházet z původní konfigurace, která byla použita při testování. Amazon nám nabízí 4 základní instance v kategorii First Generation: • Small Instance - 1.7 GiB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of local instance storage • Medium Instance - 3.75 GiB of memory, 2 EC2 Compute Units (1 virtual core with 2 EC2 Compute Units each), 410 GB of local instance storage • Large Instance 7.5 GiB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of local instance storage • Extra Large Instance - 15 GiB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of local instance storage Při testování bylo použito 1 jádro o frekvenci 3.21 GHz a zátěž se v průměru pohybovala okolo 2,8% a v maximálním zatížení až 43,75%. Spotřeba paměti RAM nepřesáhla hranici 250 MB. Z těchto údajů vyplývá, že za zcela dostačující se nabízí volba Small Instance, která disponuje 1 virtuálním jádrem o výkonu 1 EC2 Compute Unit (1.0 - 1,2Ghz). Cena zveřejněná na webových stránkách Amazonu je už včetně operačního systému. Pro evropský region je cena za Linux instanci 0.065$ za hodinu a pro instanci osazenou systémem Windows je cena 0.091$ za hodinu. Pro následné srovnání byla zvolena instance využívající Windows. Další položkou jsou poplatky za přenos dat. Amazon zpoplatňuje pouze odchozí přenos dat. Zároveň první GB přenesených dat za měsíc je zdarma. Další přenos dat je účtován dle ukázky tarifů (zobrazeny jsou pouze první 3 cenové tarify): Tabulka 5.4: Cena za odchozí přenos dat Měřená veličina první 1 GB / měsíc do 10 TB / měsíc dalších 40 TB / měsíc
Naměřená hodnota zdarma 0.120$ za přenesený GB 0.090$ za přenesený GB
49
5. Praktická část Zároveň využijeme služby CloudWatch, která se stará o monitorování a v sobě skrývá službu Auto Scaling, která umožňuje automatické přidání nebo odebrání instancí na základě sledovaných metrik. Tato služba je celkově zpoplatněna 3,5$ při pokrytí 7 předdefinovanými metrikami na jednu instanci. Druhou možností je platba 0,5$ za vlastnoručně určenou metriku na měsíc. Tabulka 5.5: Celkový výpočet nákladů Amazon AWS Nákladová položka Small Instance Cena odchozích dat Služba CloudWatch Serverový software Součet celkové ceny
5.5.2
Celková cena 0,091$*750h= 68,25$ ((123,633 + 20,90) / 1024 *20 dní - 1 volný GB ) = 2GB( přesně1.822 ale počítáno na celé GB ) GB * 0,12 $ = 0.24$ (3 sledované metriky * 0.5$ * 1 instance = 1,5$ (cena je již započítána v ceně instance. 19.45101 * 69.93 $ = 1361 Kč / měsíc)
Cloud - Microsoft Azure
Z nabízeních typů základních instancí nám nejlépe budou vyhovovat tyto dvě: • Extra small VM (1GHz CPU, 768MB RAM, 20GB Storage) • Small VM (1.6GHz CPU, 1.75GB RAM, 225GB Storage) Při porovnání ceny nám vychází jedna instance Extra small VM na 14,40$ na měsíc v přepočtu 0,0192$ /hod. Oproti tomu jedna instance Small VM vychází 56,60$ což je v přepočtu 0,0754$ / hod. Z porovnání obou variant je jasně patrné, že zvolením například dvou instancí Extra small bychom dosáhli většího společného výkonu a ještě uspoříme 27,8$. Odradit nás může fakt, že v případě instance Extra Small je jádro sdíleno. V tomto případě zvolím rezervovanou instanci Small, která svým výkonem plně pokryje průměrný provoz. Podobně jako Amazon i Microsoft Azure neúčtuje žádný poplatek za příchozí datový tok. Odchozí datový tok je zpoplatněn po přesáhnutí 5 GB, která jsou zdarma. Cena je nastavena na 0,12$ za každý další započatý GB dat pro oblast Severní Ameriky a Evropy. 1
50
aktuální kurz dolaru ke dni 2. 5. 2013
5.5. Kalkulace nákladů Tabulka 5.6: Celkový výpočet nákladů Microsoft Azure Nákladová položka Small VM Cena odchozích dat Součet celkové ceny
5.5.3
Celková cena 0,08$*750h= 60$ do 5 GB za 0$ 19.45101 * 60 = 1167 Kč / měsíc
Cloud - Big Blue One
Do porovnání je zahrnut i jeden ryze český poskytovatel cloudových služeb. Big Blue One je jediný ze zmiňovaných poskytovatelů, který nenabízí již předpřipravené instance, naopak umožňuje pomocí předpřipraveného dynamického prostředí si konfiguraci navolit podle svého. Základní nabízená konfigurace začíná 1 jádrem o frekvenci 2,3 GHz s 1 GB paměti RAM a velikostí diskového prostoru 20 GB. Tato konfigurace začíná na ceně 1090,88 CZK měsíčně což v přepočtu vychází na 35,84 Kč/den. Cena každého dalšího přidaného jádra navyšuje hodnotu denní ceny o 1,59 Kč a v přepočtu za měsíc je nárůst o 48,4 Kč. Velikost paměti RAM a velikost úložného prostoru je v základní verzi dostačující, a proto není potřeba je dále navyšovat. Tabulka 5.7: Celkový výpočet nákladů Big Blue One Nákladová položka Konfigurace o sestavě 1 jádro 2,3GHz, 1GB RAM, 20GB HDD Služba Secure Cloud Součet celkové ceny
5.5.4
Celková cena 1090,88 Kč / měsíc (20,9+20,05+123,699)/1024 * = 3 GB ( přesně 3.21 GB,platba jen za celé GB) * 0.81 = 2,43 Kč / měsíc 1093 Kč / měsíc
On-premise - IBM
IBM nabízí 4 kategorie modelů serverů, dle kategorie použití od serverů vhodných pro malé malé podniky až po kategorii BladeCenter určenou pro ty, kteří požadují robustní, stabilní a výkonnou platformu. V tomto případě se podíváme na nejnižší kategorii modelů IBM System x. IBM System x je nabízen ve variantách Tower a Rack. • Nejlevnější model Tower nabízený na oficiálních stránkách IBM je za cenu 11 600 Kč a disponuje 4 jádrovým procesorem o frekvenci 1
aktuální kurz dolaru ke dni 2. 5. 2013
51
5. Praktická část 3,1Ghz, 4GB paměti RAM a 500GB HDD. Z neoficiálních zdrojů se dají pořídit i levnější varianty IBM serverů v provedení Tower, ale typicky se jedná o starší modely, které zůstaly nevyprodané. • Nejlevnější model Rack nabízený na oficiálních stránkách IBM je za cenu 23 946 Kč. Rack může být osazen 4 jádrovým procesorem s frekvencí až 2,93GHz nebo dvoujádrovým procesorem s frekvencí až 3,06GHz. Osazen je 2GB paměti RAM a 1TB HDD. Na server bude nasazen operační systém Windows Web Server 2012 Standard Edition. Byl zvolen operační systém od společnosti Microsoft, jelikož byl také použit při kalkulaci u ostatních prostředí. Cena roční licence začíná na částce 15000 Kč. Tabulka 5.8: Celkový výpočet nákladů IBM Nákladová položka Hardware Server Síťová infrastruktura včetně firewall textbfSoftware Windows Web Server 2012 Standard Edition Nasazení Provozní náklady Elektrická energie Odpisy Součet celkové investiční ceny Součet provozních nákladů
5.5.5
Celková cena 11 600 Kč 10 000 Kč 15 000Kč 8 hodin * 500 Kč = 4000 Kč 200W * 3,5 / 1000 * 24 * 30Kč = 504 Kč 1/3 ceny hardwaru za rok = 1/3 * 11600 = 3866,66 Kč 40 600 Kč 15000/12 + 504 + 3866,66 / 12 = 2076 Kč / měsíc
Shrnutí výsledků
Jednotlivé výsledky za každé prostředí jsou shrnuty v tabulce 5.9. K získání reálného pohledu je nutné zmínit ještě nějaká fakta. Do výpočtů nebyly zahrnuty náklady za správu a údržbu hardwaru a softwaru. Důvodem jsou těžko odhadnutelné náklady na práci techniků a správců, kteří na ministerstvu pracují.
52
5.6. Závěr praktické části Tabulka 5.9: Shrnutí výpočtů nákladů všech prostředí Prostředí Cloud - Amazon AWS Cloud - Microsoft Azure Cloud - Big Blue One On-premise - IBM
Investiční náklady
Měsíční náklady
0 Kč 0 Kč 0 Kč 40 600 Kč
1361 1167 1093 2076
Roční náklady
Kč Kč Kč Kč
16 14 13 24
332 Kč 004 Kč 116 Kč 912Kč
Na základě výsledků získaných z kalkulací jednotlivých prostředí, lze říci že nejlevnější volbou bude cloud od českého poskytovatele Big Blue One. Zároveň si musíme uvědomit rozdíl výkonů, která poskytují jednotlivá zvolená řešení. Pro rekapitulaci zvýraznění rozdílů jsem shrnul poskytovaný výkon do tabulky 5.10. Tabulka 5.10: Srovnání poskytovaného výkonu Prostředí Cloud - Amazon AWS Cloud - Microsoft Azure Cloud - Big Blue One On-premise - IBM
CPU 1 virtuální jádro 1,01,2 GHz 1 virtuální jádro 1.6GHz 1 virtuální jádro 2,3 GHz 4 fyzická jádra 3,1 GHz
RAM
HDD
1,7 GB
20 GB
1.75 GB
225 GB
1 GB
20 GB
4 GB
500 GB
Z tabulky je patrné, že vyšší cena on-premise modelu je vykoupena daleko výkonnější sestavou, která by byla schopna pokrýt i mnohem vyšší zatížení. Největší výkonnostní rozdíl spatřuji především ve frekvencích jader, kde nejmenší hodnoty paradoxně dosáhl nejdražší poskytovatel. Nutno dodat, že ačkoli Amazon nabízí nejhorší poměr ceny k výkonu v této kategorii, vyvažuje své hodnocení možností široké nabídky dodatečných služeb. Právě v množství podpůrných služeb spatřuji největší výhodu Amazonu.
5.6
Závěr praktické části
Pokud by se jednalo o nasazení pouze aplikace Form Filler, je volba cloudu zajímavou alternativou a dle nákladových výpočtů i levnější variantou. S přihlédnutím na data, jenž byla naměřena a konfiguraci virtuálního serveru, 53
5. Praktická část který byl použit, bych doporučil využití nabídky Amazonu AWS. Z výkonnostního a ekonomického hlediska se sice nejeví jako nejvhodnější varianta. Jelikož však byl testován pouze jeden typ formuláře, dá se očekávat, že v budoucnosti budou přibývat další typy formulářů, které mohou obsahovat více polí a dynamických prvků, jenž ovlivňují výkon nejvíce. Současně s tímto rozšiřováním nabídky se dá předpokládat i větší zájem veřejnosti a navyšování počtu uživatelů, což bude mít za následek větší množství přijatých formulářů. A právě nabídka doplňkových služeb jako je CloudWatch nebo Elastic Load Ballancing umožní plynulý růst a spokojenost uživatelů.
54
Závěr Práce měla za cíle popis a porovnání provozních prostředí a tvorbu případové studie o možnostech provozu aplikace Form Filler. Pro splnění prvního cíle jsem provedl analýzu prostředí cloudu a on-premise. Při popisu jsem se zaměřil na definice a vlastnosti prostředí. Druhý cíl byl splněn při identifikaci finančních a technických parametrů prostředí, na základě kterých jsem vytvořil srovnávací tabulky. Třetí cíl jsem splnil tvorbou případové studie, ve které jsem provedl porovnání a návrh vhodného prostředí pro nasazení aplikace Form Filler. Text práce jsem strukturoval do dvou částí. V teoretické část je čtenář informován o podrobnostech provozních prostředí, dále je popsána problematiku vývoje aplikací pro provoz v cloudu a jsou představeni vybraní poskytovatelé. V praktické části je rozebrán důvod výběru aplikace Form Filler a představení společnosti Software602. Následně je na základě získaných dat z měření provedena analýza nabídky provozních prostředí s kalkulací nákladů a výběr nejvhodnější varianty. Největší přínos této práce spatřuji ve sjednocení informací týkající se vývoje a provozu aplikace v prostředí cloudu. Za osobní přínos považuji seznámení se s oblastí provozu aplikací a především pochopení struktury a nabídky cloudových služeb. Obohacující byla rovněž spolupráce a osobní konzultace se zástupci Software602 a rovněž poznání principu kalkulace nákladů na provoz aplikace. Práci bych mohl dále rozšířit přidáním informací o provozu aplikace v prostředí hostingu, na který se v této práci nedostalo. Právě hosting by se mohl
55
Literatura [1] Amazon Web Services [online]. [cit. 2013-4-26]. Dostupné z: http:// aws.amazon.com/ [2] Big Blue One [online]. [cit. 2013-4-27]. Dostupné z: http:// www.bigblueone.cz/ [3] Microsoft Azure [online]. [cit. 2013-4-27]. Dostupné z: http:// www.windowsazure.com/ [4] Software602 [online]. [cit. 2013-4-27]. Dostupné z: http://www.602.cz/ [5] Adaptic: ROI [online]. 2013, [cit. 2013-4-10]. Dostupné z: http:// www.adaptic.cz/znalosti/slovnicek/roi/ [6] Antony, M.: Aktuální stav cloud technologií. Bakalářská práce, Fakulta informačních technologií ČVUT v Praze, 2012. [7] Bell, P.: Architecting applications for the cloud [online]. červen 2011, [cit. 2013-3-25]. Dostupné z: http://www.ibm.com/developerworks/ cloud/library/cl-cloudappdevelop/ [8] Buchta, M.: Gartner: pět důležitých aspektů cloud computingu[online]. červenec 2009, [cit. 2013-3-8]. Dostupné z: http://m.channelworld.cz/smb/gartner-pet-dulezitychaspektu-cloud-computingu-700 [9] Buchta, M.: Gartner: Investice do soukromého cloud computingu porostou [online]. říjen 2009, [cit. 2013-3-8]. Dostupné z: http://channelworld.cz/smb/gartner-investice-dosoukromeho-cloud-computingu-porostou-1061 57
Literatura [10] Clever-Smart: Vícevrstvá architektura: tenký, tlustý a chytrý klient [online]. květen 2010, [cit. 2013-2-22]. Dostupné z: http://www.cleverandsmart.cz/vicevrstva-architekturatenky-tlusty-a-chytry-klient/ [11] Houška, V.: Jak ušetřit na serverovně či datacentru [online]. leden 2010, [cit. 2013-4-16]. Dostupné z: http://www.completecz.cz/?download= _/z-tisku/1002-ST2-4.pdf [12] Hruška, D.: Cloud computing v praxi [online]. březen 2011, [cit. 2013-3-3]. Dostupné z: http://www.itbiz.cz/cloud-computingv-praxi-maly-pohled-do-historie-aneb-vse-co-jste-o-nemchteli-vedet-ale-bali-jste-se-zeptat [13] Janssen, C.: On-Premises Software [online]. 2010, [cit. 2013-222]. Dostupné z: http://www.techopedia.com/definition/26714/ on-premises-software [14] Jarmila Frejtichová, J. C.: Virtualizace a cloud computing. říjen 2012, [cit. 2013-3-3]. [15] Lau, W.: Comparing IAAS and PAAS [online]. leden 2012, [cit. 2013-4-16]. Dostupné z: https://www.simple-talk.com/cloud/ development/ [16] Onyx: Cloud vs On-premise[online]. 2012, [cit. 2013-2-22]. Dostupné z: http://www.onyx.net/lp/cloud-services.html [17] Pichlík, R.: Nikdo vám nedá, to co já vám slíbím íonline]. březen 2013, [cit. 2013-3-25]. Dostupné z: http://www.dagblog.cz/2013/03/ nikdo-vam-neda-to-co-ja-vam-slibim.html [18] Pietrasová, P.: Možnosti tenkých a tlustých klientů při správě a analýze krajinně-typologických dat [online]. 2008, [cit. 2013-2-22]. Dostupné z: http://petrapie.ic.cz/index.php?str=mapsl&kod=tlusty [19] Save9: Custom Cloud Solutions [online]. duben 2009, [cit. 2013-224]. Dostupné z: http://www.save9.com/cloud-computing/customcloud-solutions/ [20] Schuller, S.: Demystifying The Cloud: Where Do SaaS, PaaS and Other Acronyms Fit In?[online]. prosinec 2008, [cit. 2013-3-8]. Dostupné z: http://www.saasblogs.com/saas/demystifying-thecloud-where-do-saas-paas-and-other-acronyms-fit-in/ 58
Literatura [21] Sedláček, O.: Stav cloud technologií a možnosti jejich využití. Bakalářská práce, Fakulta informačních technologií ČVUT v Praze, 2012. [22] Shriver, R.: Code Management in the Cloud [online]. srpen 2012, [cit. 2013-3-17]. Dostupné z: http://www.virtualizationpractice.com/ code-management-in-the-cloud-17516/ [23] Synergy: Cloud Services[online]. Dostupné z: http://www.synergy.gs/ Solutions/CloudServices [24] Taneja, A.: A guide to moving applications to the cloud[online]. duben 2012, [cit. 2013-3-15]. Dostupné z: http://searchcloudstorage.techtarget.com/tip/A-guide-tomoving-applications-to-the-cloud [25] vlastniSystem: Klient-Server [online]. září 2012, [cit. 2013-2-22]. Dostupné z: http://www.vlastnisystem.cz/supp-idea-cz/basics/ general/client-server-pg.html
59
Příloha
Seznam použitých zkratek IT Information Technology XaaS Anything as a service IaaS Infrastructure as a service PaaS Platform as a service SaaS Software as a service SQL Structured Query Language AWS Amazon Web Services EC2 Elastic Compute Cloud ERP Enterprise resource planning CRM Customer relationship management VM Virtual machine CDN Content delivery network SW Software HW Hardware ROI Return on Investment TCO Total cost of ownership HP Hewlett Packard 61
A
A. Seznam použitých zkratek EBS Elastic Block Store RAM Random-access memory CU Compute unit API Application Programming Interface GUI Graphical user interface XML Extensible markup language IPS Intrusion prevention system IDS Intrusion detection system SLA Service-level agreement ETSI European Telecommunications Standards Institute PAdES PDF Advanced Electronic Signatures LTV Long Term Validation
62
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD src thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce BP_Cajthaml_Vaclav_2013.pdf ....... text práce ve formátu PDF BP_Cajthaml_Vaclav_2013.ps .......... text práce ve formátu PS 63
B
