Účetnictví, ERP, CRM či jiný informační systém do Azure?
Je tomu více než sedm let, kdy končila éra v České republice velice oblíbeného produktu Microsoft Small Business Server v jeho poslední plné verzi 2011. Microsoft oznámil, že žádná další verze vydána již nebude a budoucnost jednoznačně vidí v cloudu. S myšlenkou Azure si Microsoft pohrával celé desetiletí od roku 2000 a až v únoru 2010 byl oficiálně uveden do komerčního provozu.
Ještě několik měsíců trvalo, než se odladily počáteční bolesti, a v následujícím roce jsme začali testování služeb a připravovali s prvními zákazníky pilotní instalace jejich systémů do Azure a integrace do jejich ostatní IT infrastruktury. Typickým zákazníkem byla společnost, jejíž hardware a software byl na konci životního cyklu, či začínající firma před rozhodnutím o investici do nového on premise řešení. To se ostatně doposud nezměnilo. Končící životní cyklus současného řešení vede dodnes společnosti k myšlence opravdu cloud naplno začít využívat, pokud to bude i cenově smysluplné. Naštěstí za poslední desetiletí významně vymizel jeden z důvodů proti cloudu, a to strach. Ze strany vedení společností především obavy o bezpečnost, ze strany ajťáků občas strach o práci, strach z kroku do neznáma apod. V neposlední řadě se výrazně zlepšila konektivita.
Přeneseme-li se do současné podoby Azure, zjistíme, že je přesně odrazem doby. Žádná verze 2008 následovaná 2011 apod., ale dynamická nabídka, spousty služeb, které se každým dnem vyvíjejí a jejich portfolio se neustále rozšiřuje. Plnou šíři služeb dnes nepokrývá žádná IT společnost jako dodavatel, stejně tak ji plně nevyužívá žádný zákazník, ale každý si najde své. Mezi nejvíce využívané samozřejmě patří App Service, Virtual machines, Backup a úplný ráj představuje Azure pro vývojáře a testery. Ráj trochu pomineme a vrátíme se do reality v kontextu otázky v nadpisu.
Na zjednodušeném příkladu si ukážeme, že není třeba mít z přesunu do cloudu strach, poněvadž řešíme stále stejné prostředky pro běh informačního systému. Typicky máme databázi, vlastní serverovou část informačního systému (IS), pak tlustou či tenkou klientskou aplikaci pro uživatelský přístup, uživatele musíme ověřovat a vše musíme propojit s firemní sítí. Dále zálohovat, udržovat, monitorovat a v neposlední řadě zajistit vzdálený přístup pro uživatele.
Po ověření, že IS je podporován pro běh ve virtuálním prostředí, a tedy má smysl se zaobírat cloudovou myšlenkou, nastává otázka, co to bude stát. Na orientační výpočet můžeme využít např. Azure kalkulačku https://azure.microsoft.com/en-in/pricing/calculator/, která odvádí dobrou práci, ale uživatel musí být znalý základních parametrů a názvosloví. Laik se relevantního výsledku málokdy dobere. Znamená to připravit výčet jednotlivých prostředků, jejich co nepřesnější parametry, kapacity, vytížení… (Sizing). To je ovšem opět stejný krok jako u návrhu on premise řešení.
U nového IS má hlavní slovo jeho dodavatel, který specifikuje nároky a parametry pro optimální běh systému. U migrace současného IS se můžeme dostat o krok vpřed, protože máme možnost systém a jeho využití v konkrétní firmě zmonitorovat a získat tak hodnoty a parametry přímo pro daného zákazníka včetně časového vytížení a užívání, což jsou velice cenné údaje právě pro výběr a optimalizaci návrhu výsledného řešení a samozřejmě s dopadem na optimalizaci ceny.
V následující fázi, ať už počítáme pomocí kalkulačky cenu nebo připravujeme podrobný plán vytvoření cloudového prostředí, nastává proces převodu fyzických prostředků na virtuální v Azure. To je občas náročný úkol, obzvláště pokud požadavky v nějakém směru nejsou úplně standardní, a proto se zde uplatní hodně zkušenosti z předchozích projektů. Typickým příkladem jsou virtuální stroje, kde nyní máme na výběr již přes 160 typů v podání Azure označených v řadách od A až N. Setkáváme se zde s obdobným počtem CPU a paměti, ale chování, výkon a cena se liší. To samé se řeší u úložišť a disků.
Na druhou stranu je zde potřeba zdůraznit jednu z hlavních předností výsledného prostředí v Azure, a tou je škálovatelnost. To znamená, je-li počáteční výkon prostředí nedostatečný, jednoduše lze prostředky a výkon navýšit, často v rámci jednoho restartu. To samozřejmě platí i o budoucím růstu společnosti, kde navýšit výkon a zpřístupnit systém více uživatelům je nepoměrně jednodušší a rychlejší než u on premise řešení. Stále častěji se dokonalé škálovatelnosti využívá pro omezená, často i velmi krátká časová období různých finančních uzávěrek, u e-shopů prodejních akcí apod.
Vraťme se k využití Azure v českém prostředí, se kterým se často setkáváme. Klienti mají či chtějí využívat systémy typu ABRA, Helios, Money S3, Pohoda a další. Rozhodují se mezi nákupem nového hardwaru, softwaru a nasazením lokálně anebo v cloudu.
Historicky např. začínali s SBS Serverem zmíněným v úvodu. Tak získali Windows Server s Active Directory, na poštu Exchange Server a výhodně SQL Server pro informační systém. Poprvé se s cloudem setkali či setkávají při náhradě Exchange Serveru službami Office 365 a často následně řeší v rámci OneDrive a SharePoint práci s dokumenty. Pak nastává potřeba inovovat informační systém. Na to už služby Office 365 nestačí, ale vzhledem k tomu, že využívají ekosystém Microsoft, logická volba ve výběru většinou padne na Microsoft Azure.
Pro zmíněné systémy, hojně v ČR využívané, je scénář velmi podobný. Podle velikosti systému a počtu přistupujících uživatelů volíme množství aplikačních a databázových serverů. Pro uživatelský přístup je většinou využíván tlustý klient, což předurčuje potřebu využití služeb vzdálené plochy, kde v Azure zatím máme volbu mezi platformními službami Citrix anebo možností vytvořit si infrastrukturně RDS/terminálové služby. A to je častá volba. Tyto služby opět podle velikosti a konfigurace můžeme rozdělit do více serverů. To nám implikuje potřebu doménového řadiče s Active Directory, což máme další server. Do tohoto prostředí se uživatelé musí připojit, tzn. potřebujeme VPN, pokud nechceme přímo přes RD Gateway vypublikovat do internetu.
Pojďme scénář ještě rozebrat o trochu podrobněji. Máme on premise infrastrukturu, která obvykle obsahuje doménový řadič s Active Directory, ovšem pro přístup z Azure přes VPN by byla odezva pomalá, a proto vytvoříme repliku přímo v Azure. K tomu nám postačují levnější virtuální stroje (Virtual Machines – VMs) série B. Samozřejmě se nabízí využití platformních služeb v podání Azure Active Directory Domain Services. Bohužel kvůli ceně vlastní AD ve VM většinou vítězí. Podobně jsme na tom u terminálových služeb. Azure RemoteApp byly ukončeny a nahrazeny Citrix službami, které jsou pro malé a střední implementace dražší, a tudíž vítězí vlastní RDS služby ve VMs. V menších prostředích se volí RDS single server instalace, u větších instalací se komponenty oddělují. Pro VMs padá často volba na D série. U aplikačních a databázových serverů saháme většinou také po D či E sérii. U nejmenších prostředí s velkým důrazem na cenu občas tyto servery nahrazuje jeden společný s terminálovými službami. To není ideální, ale opět to dává vzpomenout na SBS servery, kde se vše integrovalo v rámci jednoho až dvou serverů. U větších řešení se naopak setkáváme s více databázovými servery, samostatnými front-end servery apod.
Spoustu čtenářů napadne, proč nevyužít v těchto scénářích platformní databáze. Ať už Microsoft SQL či ostatní nabízené v rámci Azure, které často vycházejí cenově příznivěji, vyžadují nižší správu, náklady atd. Zde bohužel zatím narazíme na historickou zátěž, kde účetnictví a informační systémy často vyžadují funkce a oprávnění, která platformní služby z principu nemohou poskytnout. Zatím se čeká, až tohle vývojáři napraví. Sami už využívají služby Azure pro vývoj a testování, takže je to snad jen otázka času. Za české informační systémy např. Money S4 a S5 platformní Azure SQL databázi umějí využívat.
Zbývá nám infrastrukturu propojit se současnou firemní infrastrukturou a s mobilními uživateli. V prvním případě vytvoříme tzv. Site to Site VPN a v druhém případě Point to Site. To v prostředcích Azure znamená VPN Gateway, Virtual Network a IP adresu. Pro větší řešení, když nám nevyhovují standardní síťové komponenty Azure, si můžeme v Azure marketu vybrat appliance dalších společností Fortinet, Checkpoint, Cisco apod. Naopak v malých prostředích s důrazem na cenu často volíme nativní Azure Basic VPN. U Point to Site můžeme přistupovat také přímo do Azure anebo naopak do centrály společnosti a odsud skrz Site to Site VPN do Azure.
Výše uvedený scénář některé fáze zjednodušuje a zobecňuje, ve větších společnostech bude vyžadována určitě nějaká úroveň SLA, která se musí zohlednit při návrhu apod. Nerozebrali jsme backup, kde nejjednodušší je využít přímo služeb Azure Back-up, stejně tak služby monitoringu, optimalizace apod. Tato témata by vydala na samostatné články.
A nyní zbývá ještě shrnutí. Účetnictví, ERP, CRM či jiný informační systém do Azure? Ano, tyto služby jsou s námi již skoro deset let. Když se správně navrhne jejich využití a konfigurace, nabízejí vysokou bezpečnost, škálovatelnost, možnosti optimalizace výsledné ceny, odpadnou starosti s fyzickými servery, záložními zdroji, klimatizací serveroven, spotřebou energií apod. Čím více se podaří využít platformních služeb, tím se dále zjednoduší správa. Proces implementace a správy není složitý, obzvláště pokud zvolíte zkušeného partnera.
Miroslav Koukola, SUMA