AWS, Google Cloud nebo Microsoft Azure: Jak vybrat platformu

01Nejdřív popište aplikaci, potom vybírejte cloud

Pro běžnou firemní aplikaci nezačínejte žebříčkem poskytovatelů. Připravte jednu stránku požadavků: kdo systém používá, odkud se připojuje, jaké údaje zpracovává, jak vypadá běžný provoz a špička a kdo zasáhne při poruše. Teprve podle toho můžete porovnat AWS, Google Cloud a Microsoft Azure.

Oddělte nezbytné podmínky od přání. Konkrétní databázová funkce, umístění dat nebo napojení na stávající síť může kandidáta vyřadit. Příjemnější konzole nebo dočasný kredit by takové omezení neměly přebít. Pokud stejnou potřebu pokryje hotová služba nebo jednodušší spravovaný hosting, zahrňte jej do rozhodování také.

Výstupem má být provozovatelná sestava služeb pro vaši aplikaci, ne logo na prezentaci. Tento přístup odpovídá i zaměření AWS Well-Architected Framework, který hodnotí rozhodnutí konkrétní architektury. Samotná velikost poskytovatele vám neřekne, zda obnovíte vlastní databázi nebo rozumíte měsíčnímu účtu.

Požadavky na růst a provozní špičky si upřesněte podle průvodce škálovatelností webové aplikace.

02Porovnávejte stejný úkol a stejnou úroveň správy

Virtuální server, spravovaná databáze a platforma pro kontejnery přenášejí na dodavatele různou část práce. Kontejner je balíček aplikace s potřebným prostředím. Rozhodnutí, kdo spravuje servery pod ním, ovlivní rozpočet i požadované dovednosti týmu.

Pro srovnatelný pilot webové aplikace můžete zvažovat Amazon ECS s AWS Fargate, Google Cloud Run a Azure Container Apps. Jde o příklady spravovaného běhu aplikací v kontejnerech, ne zaměnitelné produkty se shodnými limity.

Tabulka je doporučení pro výběr kandidátů podle vaší situace. Neříká, že některý cloud neumí jiné použití. Samotné používání kancelářských aplikací Microsoftu nebo Googlu není důkaz, že tam patří i celý nový systém. Rozhodují skutečné vazby a ověřená úspora práce.

03Region vybírejte pro celou sestavu

Region je geografická oblast, v níž provozujete vybrané prostředky. Ověřte dostupnost všech potřebných služeb a jejich vlastností v daném regionu. Microsoft při výběru regionu upozorňuje na dostupnost služeb, odezvu, náklady a požadavky na umístění dat.

Neporovnávejte jen vzdálenost od kanceláře. Změřte cestu od uživatele přes aplikaci až k databázi a navázanému systému. Když objednávka při každém otevření čeká na účetní server v jiné lokalitě, rychlý aplikační server problém sám neodstraní. Síťové vazby popište společně s návrhem integrací a API.

Požadavek „data v Evropě“ rozepište na hlavní databázi, zálohy, logy a zapojené služby. U každé ověřte možnosti nastavení a příslušné podmínky. Výběr evropského regionu sám o sobě není právní posouzení celého řešení. Do nabídky uveďte konkrétní umístění i postup případného přesunu.

04Spočítejte celý provoz v několika scénářích

Nechte porovnat klidný měsíc, očekávaný provoz a špičku. Ve všech variantách držte stejnou práci aplikace, množství dat, požadovanou dostupnost a dobu uchování. Aktuální odhad sestavte v kalkulátorech AWS, Google Cloud a Azure. Uložte datum, region i předpoklady. Kalkulace je odhad, nikoli cenová garance.

• Běh aplikace: Výkon, paměť, délka běhu a rezervovaná kapacita.
• Data: Databáze, úložiště, operace, zálohy a jejich uchování.
• Přenosy: Komunikace mezi službami a odchozí data podle konkrétního tarifu.
• Provoz: Logy, monitoring, podpora a testovací prostředí.
• Práce lidí: Zavedení, údržba, pohotovost a budoucí změny.

Výsledek převeďte také na jednotku práce, která dává smysl: zpracovanou objednávku, aktivní účet nebo dávku dokumentů. Slevové závazky a úvodní kredity ukažte odděleně. Rozhodnutí má vycházet i z ceny po jejich skončení. Sjednoťte měnu a zacházení s daněmi; jinak můžete porovnávat nesrovnatelné součty.

05Spolehlivost a bezpečnost potřebují vlastníka

Nechte firmu určit přijatelnou délku výpadku a přijatelnou ztrátu posledních změn. První požadavek se promítá do cíle doby obnovy, druhý do cíle bodu obnovy. Pro přehled interních dokumentů mohou být jiné než pro příjem objednávek. Podle nich vybírejte redundanci, zálohy a postup obnovy.

Model sdílené odpovědnosti AWS výslovně odděluje úlohy poskytovatele a zákazníka podle použité služby. Spravovaná infrastruktura vás nezbavuje odpovědnosti za vlastní data a oprávnění. Seznam činností přepište na konkrétní lidi: kdo schvaluje přístup, kdo hlídá zálohy a kdo řeší incident.

Google Cloud Well-Architected Framework posuzuje vedle výkonu také bezpečnost, spolehlivost, náklady a provoz. Pro výběr z toho plyne užitečná otázka: dokáže váš tým celou sestavu dlouhodobě spravovat? Levnější infrastruktura s nejasnou odpovědností může znamenat dražší službu jako celek.

06Pilot musí ukázat i poruchu a návrat zpět

Nenasazujte jen úvodní stránku. Vyberte malý reprezentativní tok, například přihlášení, zápis objednávky, přílohu, odeslání do navázaného systému a dohledání chyby. Použijte zkušební údaje odpovídající reálnému objemu a změřte odezvu i spotřebu prostředků.

1. Nasaďte stejnou verzi aplikace opakovatelným postupem.
2. Vyzkoušejte očekávanou špičku a omezení navázaných služeb.
3. Obnovte data ze zálohy a zkontrolujte jejich obsah.
4. Vraťte chybnou verzi aplikace na předchozí funkční stav.
5. Předejte diagnostiku a přístupy druhému člověku.

Záznam pilotu má obsahovat výsledky, nevyřešené potíže a práci potřebnou k nápravě. Rozpočet správy ověřujte s lidmi, kteří ji skutečně převezmou. Pokud je nutná externí údržba a podpora aplikace, patří do porovnání od začátku, včetně rozsahu reakce na incident.

Pokud přesouváte již fungující systém, rozpracujte také přepnutí provozu podle článku o migraci do cloudu bez výpadku.

07Závislosti přijímejte vědomě a výběr zapište

Specifická cloudová služba může ušetřit mnoho vývoje. Za to můžete při změně poskytovatele přepisovat část aplikace. Zapište důvod přijetí této závislosti, dostupný export dat a přibližný rozsah budoucího přesunu. Použití kontejnerů samo nevyřeší přenos identit, databázových funkcí ani provozních pravidel.

Více cloudů zvažujte pro konkrétní důvod a s rozpočtem na jejich správu. Pro malý tým není druhý poskytovatel automatickou zálohou: musí fungovat obnova dat, konfigurace i přepnutí provozu. Často pomůže nejdřív ověřit export a obnovu do čistého prostředí.

Rozhodnutí uzavřete krátkým záznamem: vybraná sestava, důvody, očekávané náklady, vlastník provozu, přijatá omezení a spouštěče nového posouzení. Tím může být výrazná změna objemu dat, vstup na jiný trh nebo služba, kterou původní řešení neumí pokrýt.

08Časté otázky

09Připravte podklady pro skutečné srovnání

Pošlete nám popis aplikace, používané systémy, provozní špičky a požadavek na obnovu. Probereme výběr cloudové platformy a rozsah pilotu, který vám pomůže posoudit techniku, cenu i správu.