Shrnutí cloudových možností v roce 2024
Historické okénko
Samotné základy cloud computingu sahají až do let 1963, kdy tehdejší DARPA (Defense Advanced Research Projects Agency) vyvinula spojení strojů, které byly schopny nést svůj výpočetní výkon sdíleně, po určitou dobu mezi větší množství uživatelů. Daný koncept se stal poměrně populární a aby také ne. Musíme si to uvést do kontextu, jaké byly v tehdejší době pro výzkumníky dostupné hardware zdroje pro práci a pro výpočty.
Myšlenka je to výborná. Místo, abychom každý měli svůj v tehdejší době předražený stroj, dáme to dohromady, každý bude moct po určitou dobu používat výpočetní kapacity jak je potřebuje. Vyjde nás to levněji a budeme mít více výpočetní kapacity abychom byly rychlejší a efektivnější.
Vždyť nemusíme jít v období milénia daleko. I jako mobilní operátor nebo ISP můžete jít cestou, že buď každému klientovi dáte garantovanou linku, anebo tu stejnou linku podělíte pomocí agregace mezi několik uživatelů. Snížíte tím ceny za připojení, nabídnete vyšší rychlosti a navíc, vyjde to každého uživatele levněji. (Pozn: Má to ovšem svá omezení, v časech vysokých průtoků se všichni budou tlačit o ten stejný průtok).
Tedy jak vidíme, samotný koncept “time sharingu” dává smysl.
Jak šel čas, objevili se na trhu giganti. Tito giganti měli trochu jinou potřebu pro svůj vlastní interní vývoj. Potřebovali skokově, párkrát do roka vysoký výpočetní výkon, a po zbytek roku bylo ticho po pěšině a tento výkon připadl v niveč. Napadlo je toto účetní aktivum sdílet s ostatními – a toto to dalo vzniku cloud computingu tak, jak jej známe v dnešní podobě. Tedy původně odpadní produktu nevyužitého potenciálu výpočetních kapacit přinesl novou možnost na trhu pro ostatní firmy.
Co je to cloud
Výše uvedeným okénkem jsme si nepřímo vysvětlili v kontextu k dnešní době, co to cloud je. Jen pro zopakování, je to koncept sdílení výpočetních zdrojů mezi více uživatelů. Dané výpočetní zdroje jsou zpravidla hostované v datacentrech někoho třetího a za poplatek je možno užívat výhody, které třetí strana nabízí spolu s nějakou přidanou hodnotou. Tyto přidané hodnoty jsou následujícího druhu:
- Nějaká grafická nástavba, aby bylo možno rychle naklikat něco, co je potřeba.
- Nějaká programová nástavba (API), aby to stejné, co lze naklikat bylo možno programátorsky “zautomatizovat”.
- Soustava strojů je distribuována napříč celým světem a za poplatek dostupná.
- Výpočetní kapacita je obrovská a za poplatek dostupná po určitou dobu.
Kdy se cloud objektivně hodí
Ve dvou případech:
- Když nemáme finance na vlastní datacentrum a skokově potřebujeme na dočasnou chvíli vysoký výpočetní výkon.
- Když potřebujeme mět nějakou službu distribuovanou po celém světě a nemáme finance na vlastní datacentra.
Dle autora, toto jsou dva opravdové, objektivní důvody, kdy cloudová řešení na trhu dávají smysl. Vše ostatní je zabarvená omáčka.
Neúspěšné příklady na trhu
Pojďme se podívat na pár odkazů, kde lidé pláčou nad tím, jak je cloud computing drahý a na základě toho shazují jeho reálnou tržní hodnotu. Zde je pár odkazů, co autor nalezl:
A pak pojďme se podívat, jak se naopak marketingově se cloud zbožňuje:
Všimněme si, že většinou o nevýhodách cloudu píší média, zatímco o výhodách jednotlivé podnikatelské subjekty. Je to zajímavý trend.
Nyní zpět k hlavnímu proudu článku. V reálu, jsou tři (a možná více) důvodů, proč společnosti a organizace migrují své workloady do cloudu. Zde, se dostáváme na tenký led, protože argumenty “jít do cloudu” vs “nejít do cloudu” se začínají svým charakterem podobat svaté válce a má to velmi podobnou křivku utahaného kotěte, jako je diskuze zdali by ČR měla konečně po 20 letech přijmout euro, nebo ne.
Tyto důvody by autor shrnul následovně:
- Emocionální
- Poloracionální
- Racionální
Emocionální
Emocionální důvody jsou nejčastější důvod, proč firma chce migrovat do cloudu. Je naprosto běžné, že top management je zblblý tímto slovem, začne o tom hledat informace, všude jsou vidět fráze typu:
- Úspory za lidi
- Úspory za zdroje
- Zvýšení efektivity
- Rychlost
- Bezpečnost
bla bla… Na základě toho se rozhodnou začít migrovat to co mají desítky let do cloudu, a pak to dopadne tak, že začnou plakat nad tím, že vše je 10x dražší. Aby ne, ukážeme si to na nějakých modelových příkladech později, kde je problém.
Racionální
Zde je moment, kdy opravdu přijde někdo osvícený, kdo dokáže přijít se strategií adopce do cloudu, nebojí se sáhnout po nějakém odborníkovi, který poradí s návrhem architektury a poté, když je stanoven bojový plán, mohou se vyhrnout rukávy a jít do práce.
Poloracionální
Navazujeme na racionální a jen jej rozšiřujeme. Častým problémem, který dále pokračuje je slovo “agile”. Vy totiž v nějakém čase něco navrhnete, začnete na tom pracovat, pak najednou přijde oznámení z top managementu, že se “změnil směr” a vy musíte být “agile” a celý plán překopat. Takto to uděláte párkrát za svoji kariéru a vznikne vám typický kočkopes, nebo také software typu “Frankensteinovo monstrum”, kterým je trapné se chlubit u piva kamarádům.
Modelové příklady popisující výhody, anebo nevýhody cloudu
Do současné chvíle jsme mluvili jazykem srozumitelným pro lidi netechnického vzdělání. Nyní na chvíli přeskočíme a budeme více mluvit konkrétně a to technickým jazykem. Dané příklady budeme vztahovat pouze k prostředí MS Azure, protože v něm máme nejvíce zkušeností.
Office365 vs exchange
Informace o prostředí a společnosti:
Máme obchodně výrobní společnost. Tato společnost má onprem řešení postavené na Proxmoxu a na něm běží zastaralý MS exchange 2007. Exchange už nemá žádnou podporu. Často v dané lokalitě dochází k výpadku proudu a tím je server nedostupný i přes použití UPS, většinou o víkendech naštěstí. Společnost je typický hanácký kolenovrt a nechce dát peníze na geograficky oddělené zálohování celého serveru. Také nemá peníze na nový Exchange. Zdá se jí to “moc drahé”.
Lokální administrátor je na prášky, protože většinu svojí denní rutiny tráví tím, že hledá nedoručené maily, anebo odstraňuje veřejku z blacklistu anebo řeší, proč něco padá do spamu i když by to nemělo padat do spamu. Tráví tím tak 10% svého dne.
Daná společnost se od roku 2007 až do roku 2024 přeorientovala tak, že její esenciální nástroj pro komunikaci se stala mailová komunikace. často potřebuje sdílet data s okolním světem a zdá se jí, že mailová komunikace je v 21. století celkem pomalá na společnou práci s ostatními dodavateli.
Řešení:
Jednoznačný příklad, kdy dává smysl nasadit Office365 řešení.
odpadne 90% výše popsaných problémů.
Poznámka autora:
Pro nasazení tohoto řešení je také potřeba určitá adopce. Samotné Office365 nasazovat “jen” kvůli mailům, nedává ekonomicky zas tak velký smysl. Je potřeba použít celý toolchain. Tedy OneDrive pro zálohování a bezpečné sdílení dat, Teams pro komunikaci s ostatními nebo uvnitř firmy a Sharepoint jako lokální intranet. Pak je řešení jedno z nejvýhodnějších řešení na trhu vzhledem k tomu, co dokáže ušetřit. Proč je zmíněn Office365? Myslíte, že dané řešení pod kapotou běží na AWS? 🙂
DevBox
Informace o prostředí a společnosti:
Máme společnost, která má několik desítek vývojářů. Vývojáři do firmy přicházejí a zase odcházení. Často rotují. Častým příkladem je onboarding nového vývojáře na dočasnou dobu 2-3 měsíců. Jedna ze zajímavých alternativ je MS DevBox. Dává smysl jej nasadit?
Řešení:
Není jednoznačné.
Poznámka autora:
Záleží na ekosystému. Devbox je v rámci MS vývoje spin-off Azure Virtual Desktopu. Je to náhrada za terminálové služby, náhrada za VDI.
Zde si můžete přečíst článek, který dané řešení opěvuje.
Pokud máme ADDS, GPOs a dobrého dodavatele notebooků, je to předražená služba, která je spíše tlačena marketingově než reálnou poptávkou, ale až čas ukáže, třeba se autor může mýlit.
Migrace aplikace z onprem do Azure
Informace o prostředí a společnosti:
Společnost vyvíjí pro lokální český trh software od roku 1995. Software celkem vyzrál za tu dobu. Rozhodne se provést migraci do Azure. Vždyť je to tak sexy, všichni to dělají, budeme to dělat taky. Vezmou celou soustavu virtuálních strojů, zmigrují to pomocí Azure Migrate z onprem, do Azure.
Řešení:
Nemigruj! Společnost zkapala na tom, že začala plakat, protože najednou to co vlastně nestálo nic, stojí hrozně moc. Odkazujeme se na špatné zkušenosti z cloudem z článků výše.
Poznámka autora:
Typický příklad nepochopení cloud computingu. Pokud máme nějakou legacy aplikaci, a zmigrujeme ji z onprem do bodu Azure, nikdy to nebude dávat ekonomicky smysl. Takto je to špatně. Není využito žádného benefitu.
- Nemá smysl nasadit Azure Front Door nebo CDN
- Nemá smysl dělat Traffic manager
- Není zde žádný benefit z užití ZRS/GRS/, prostě nic.
Všechny DC Azure jsou vzdálenější, než kdyby appka běžela někde lokálně třeba v Praze a měla geograficky oddělenou lokalitu v Brně s geografickou zálohou třeba v US. Toto je typický příklad, kdy migrace do cloudu je naprostý ekonomický provar.
Začalo by to dávát smysl, kdyby bylo užito některého z benefitů cloudu, ale i tak je to diskutabilní. Mnohem ekonomičtější je, aplikace přepsat, ale vyplatí se to?
DevOps vývojáři ve startupu
Informace o prostředí a společnosti:
Máme malý startup, který chce na zelené louce vyrobit aplikaci, která bude zpracovávat velké množství dat, dělat jejich transformace a publikovat reporty. Aplikace bude globálního charakteru, je potřeba aby frontend byl redundantní a aby uživatelé přistupující na appku měli nízkou latenci dle geografické lokality, která jim bude nejblíže. Nemají v týmu žádného opsáka. Nechtějí se starat o virtuální mašiny a plýtvat časem, aby je patchovali. Je potřeba, aby databáze běžela na MSSQL a protože vývojáři s databází příliš neumí, chtějí, aby s tím bylo co nejmíň práce a bylo zajištěno vše pod kapotou (zálohování, vysoká dostupnost).
Vývojáři potřebují nějaký toolchain, ve kterém mohou vyvíjet. Jejich počet bude do 5 lidí maximálně a pak se uvídí, jestli se projekt ukončí, nebo se povede sehnat štědrého investora.
Řešení:
Azure DevOps
Krásný příklad, kdy do 5 userů ze Azure DevOps zadarmo a nabízí naprosto všechno pro práci bez jediného výdaje. Perfektní pro start. Vývojáři doustanou repozitáře, pipelines, azure boards a mohou efektivně a rychle začít pracovat.
WebApps
Daná achitektura se pak nabízí použití WebApps. Není potřeba se starat o žádný stroj, vše pod kapotou manažuje Microsoft. Pro začátek stačí i free verze, než se to nějak odladí, a mohou se přes release pipelines nasazovat nové verze webappky a přehazovat později pomocí deployment slotů.
Databáze
Pokud není jiného zbytí než nasadit MSSQL, tak se přímo nabízí Azure SQL managed instance. Za poplatek dostanou vše co potřebují, nemusí se starat o SQL, mají vždy nejnovější latest verzi, zálohování, HA, vše je v ceně. Ideální na rychlý start
Data analytics
Pro zpracování a analýzu dat se přímo nabízí nástroje typu:
Poznámka autora:
Zde se jedná o běžný example, kdy cloud dává smysl. Za malý peníz, na dočasnou dobu poskytne přesně to, co je potřeba. Bez počátečních vysokých investic za hardware a aniž by bylo potřeba vývojáře trýznit problematikou Ops. Ať se soustředí na vývoj a v krátkém čase zkusí něco vyvinout. Pokud by si vývojáři měli vše obhospodařit sami, jediná cesta je koupit vlastní železo, na něm to vývíjet a pak to přesunou do cloudu, ale dané železo by bylo velmi drahé a za pár měsíců by bylo k ničemu. Dané služby pro zpracování skokového objemu dat jsou požadavek krátkodobý, potřebný jen v určité špičce a poté nepotřebný. Těžce se dané řešení dimenzuje na onpremu. Také – je lepší od začátku nechat vývojáře vyvíjet v cloudu řešení, bude lépe optimalizované od začátku, kdyby se řešení rozběhlo a investora se povedlo sehnat.
Daný příklad je běžné marketinogvé zacílení cloudových služeb pro začínající startupy, kde se střetává velmi často nabídka s poptávkou. Jinými slovy pro Azure takový klient dává smysl, a pro uživatele požití cloud computingu dává také smysl. Je to win-win.
Video rendering
Informace o prostředí a společnosti:
Máme společnost, která má ekosystém nastaven tak, že interní tým pracuje s renderováním videí. Nahrají video přes applikaci, kde se musí nejdříve autentizovat, spustí proces renderování. Daný proces je neuvěřitelně náročný na čas i zdroje, ale trvá jen nějakou chvíli. Skokově potřebují vysoký výpočetní výkon, který nedává ekonomicky smysl, aby si pořizovali na vlastní náklady. Renderování totiž probíhá jednou za měsíc, občas i jednou za dva měsíce.
Řešení:
K onprem aplikaci nasadit Microsoft Entra application proxy, přidat ji jako enterprise application.
A azure si vyrobit
Spojit se a Azure pomocí ExpressRoute, nebo VPN, nebo private endpointu, dle architektury ve firmě a dalších parametrech.
Poznámka autora:
Jedná se o modelový příklad přímo z dokumentace Microsoftu.
Je to totiž typický příklad, kdy cloud zkrátka dává smysl. Potřebujeme skokově vysoký výpočetní výkon, jednou za čas, nedává nám ekonomicky smysl si pořizovat něco vlastního. Cloud je přesně tak jak bylo popsáno v historickém okénku k tomuto zrozen.
Multicloud přístup
Informace o prostředí a společnosti:
Společnost má samostatnou divizi A. Tato divize má za úkol předchystat unifikované prostředí pro práci se zdroji v cloudu. Cílem totiž je, aby vývojářské týmu (kterých jsou stovky), měli sjednocené vývojové prostředí. Doposavaď byl každý vývojářský tým samostatná entita. Top management potřebuje všechny týmy zkonsolidovat, aby každý měl to stejné prostředí pro práci. Je nutné, aby řešení pro práci se zdroji bylo multicloudové. Aby firma nebyla svázána vendor-lockem.
Řešení:
Vyvinou nadřazenou vrstvu abstrakce nad cloudovými službami pomocí nástrojů, které podporují více vendorů, například:
- Ansible
- Terraform
- Packer
Pomocí nějakého multiplatformního programovacího jazyka zajistit dostatečnou flexibilitu těchto nástrojů a jejich možnosti ohýbání.
Zajistit unifikované vstupy pro ovládání všech těchto nástrojů formou deklarace a poté použít některý z možností práce pro lokální vývojové prostředí a provést izolaci jednotlivých části vývoje v kontejneru.
Veškerý vývoj, skripty psát univerzálně, aby je bylo možnost transferovat z různých CI/CD nástrojů
Poznámka autora:
Zde je jen jeden z příkladů, kdy použití multiplatformních nástrojů dokážeme docílit toho, že nutně nemusíme být závislý jen a pouze na jednou cloudovém řešení. Vše se mění, to co je dnes levné, může začít být v budoucnu drahé, je dobré mít možnost odmigrování, jen je k tomu potřebná nějaká vícepráce.
Migrace do cloudu
Informace o prostředí a společnosti:
Společnost působí na lokálním trhu v oblasti e-commerce.
Koncový klienti jsou geograficky ohraničení oblastí České republiky. Jen výjimečně se připojuje někdo ze zahraničí.
Společnost napadlo zmigrovat do cloudu. Je to trendy.
Protože neměli peníze, vyřešili si to amatérsky po svém se soustavou lidí, kteří neumí cloud. Protože narazili na nějaký článek s porovnáním principu cloud agnostic vs cloud-native, rozhodli se jít cestou cloud agnostic řešení.
Provedli migraci. Protože Azure nebo AWS byl drahý, zmigrovali do DigitalOceanu, ale zvažovali i Linode.
Řešení:
Toto je ukázka, jak se to nemá dělat.
Poznámka autora:
Ukázka špatného manažerského rozhodnutí. Stroje pro poskytování služeb jsou nyní mimo ČR, latence se zvýšili, benefit žádný. Protože nepochopili co je to cloud agnostic přístup, zmigrovali 1:1 VMs z onprem do “pseudocloudu”, nepoužívají žádné benefity řešení, přidaná hodnota pro koncové klienty je nulová, výdaje se jim zvýšili násobně.
Shrnutí a závěr
Cloud na svém trhu má místo. Vyvíjel se několik let a jedná se o komplementární doplněk, nebo ještě lépe rozšíření k tomu, co se již nyní aktuálně nachází ve většině firmách. Jeho hlavním cílem není brát IT lidem práci. Jeho hlavním cílem je nabídnout jednu z možností, kterou je možno použít, anebo také není potřeba je využívat. Důležité je používat selský rozum, věci si dopředu spočítat.
Budoucností není mít vše v cloudu, ale budoucností ani není mít vše onprem. Budoucnost je někde mezi, kde se používají benefity daného řešení tam, kde to dává ekonomicky smysl.
Jsou některé ukázky, které dávají ekonomicky smysl a slouží jako inspirace pro ostatní, aby si udělali lepší představu jak lze cloudové služby používat.
A pak jsou ukázky zásadních chyb, které plynou většinou z nepochopení základních principů, nebo amatérismu. Autor doufá, že po přečtení tohoto článku až sem toto množství zásadních chyb bude z trhu mizet, aby nebylo potřeba pak na Lupě nebo root.cz plakat a zbytečně tak mást ostatní čtenáře jedním výsekem pohledu na svět, na který je potřeba se dívat holisticky. Článek vyšel jako výstup ze studia na certifikace Azure Solution Architect Expert
