AWS, Google Cloud alebo Microsoft Azure: Ako vybrať platformu

01Najskôr opíšte aplikáciu, potom vyberajte cloud

Pri bežnej firemnej aplikácii nezačínajte rebríčkom poskytovateľov. Pripravte jednu stranu požiadaviek: kto systém používa, odkiaľ sa pripája, aké údaje spracúva, ako vyzerá bežná prevádzka a špička a kto zasiahne pri poruche. Až potom viete zmysluplne porovnať AWS, Google Cloud a Microsoft Azure.

Oddeľte nevyhnutné podmienky od želaní. Konkrétna funkcia databázy, umiestnenie údajov alebo napojenie na existujúcu sieť môže kandidáta vyradiť. Príjemnejšia konzola ani dočasný kredit by takéto obmedzenie nemali prevážiť. Ak rovnakú potrebu pokryje hotová služba alebo jednoduchší spravovaný hosting, zahrňte do rozhodovania aj túto možnosť.

Výsledkom má byť zostava služieb, ktorú dokážete prevádzkovať, nie logo v prezentácii. Takto je zameraný aj AWS Well-Architected Framework, ktorý posudzuje rozhodnutia konkrétnej architektúry. Veľkosť poskytovateľa sama nehovorí nič o tom, či obnovíte vlastnú databázu a porozumiete mesačnému účtu.

Požiadavky na rast a prevádzkové špičky si spresnite podľa sprievodcu škálovateľnosťou webovej aplikácie.

02Porovnávajte rovnakú úlohu aj úroveň správy

Virtuálny server, spravovaná databáza a kontajnerová platforma prenášajú na dodávateľa rôznu časť práce. Kontajner je balík aplikácie s potrebným prostredím. To, kto spravuje servery pod ním, ovplyvní rozpočet aj zručnosti, ktoré váš tím potrebuje.

Pre porovnateľný pilot webovej aplikácie môžete zvážiť Amazon ECS s AWS Fargate, Google Cloud Run a Azure Container Apps. Sú to príklady spravovaného behu kontajnerových aplikácií, nie zameniteľné produkty s rovnakými obmedzeniami.

Tabuľka odporúča výber kandidátov podľa vašej situácie. Neznamená, že niektorý cloud nezvláda iné použitie. Samotné kancelárske aplikácie Microsoftu či Googlu ešte neurčujú, kam patrí nový systém. Rozhodujú skutočné väzby a overená úspora práce.

03Región vyberajte pre celú zostavu

Región je geografická oblasť, kde prevádzkujete vybrané prostriedky. Overte si v ňom dostupnosť všetkých potrebných služieb a ich vlastností. Microsoft pri výbere regiónu upozorňuje na dostupnosť služieb, odozvu, náklady a požiadavky na umiestnenie údajov.

Neporovnávajte len vzdialenosť od kancelárie. Zmerajte cestu od používateľa cez aplikáciu k databáze a nadväzujúcemu systému. Ak objednávka pri každom otvorení čaká na účtovný server v inej lokalite, rýchly aplikačný server to sám nevyrieši. Sieťové väzby opíšte spolu s návrhom integrácií a API.

Požiadavku „údaje v Európe“ rozdeľte na hlavnú databázu, zálohy, logy a zapojené služby. Pri každej overte nastavenia a príslušné podmienky. Európsky región sám osebe nie je právnym posúdením celého riešenia. V ponuke má byť konkrétne umiestnenie aj postup prípadného presunu.

04Spočítajte celú prevádzku vo viacerých scenároch

Nechajte porovnať pokojný mesiac, očakávanú prevádzku a špičku. Vo všetkých variantoch zachovajte rovnakú prácu aplikácie, množstvo údajov, dostupnosť a dobu uchovávania. Aktuálny odhad pripravte v kalkulačkách AWS, Google Cloud a Azure. Uložte dátum, región aj predpoklady. Kalkulácia je odhad, nie záruka ceny.

• Beh aplikácie: Výkon, pamäť, čas behu a rezervovaná kapacita.
• Údaje: Databáza, úložisko, operácie, zálohy a ich uchovávanie.
• Prenosy: Komunikácia medzi službami a odchádzajúce dáta podľa konkrétnej tarify.
• Prevádzka: Logy, monitoring, podpora a testovacie prostredie.
• Práca ľudí: Zavedenie, údržba, pohotovosť a budúce zmeny.

Výsledok prepočítajte aj na zmysluplnú jednotku práce: spracovanú objednávku, aktívny účet alebo dávku dokumentov. Zľavové záväzky a úvodné kredity ukážte oddelene. Rozhodujte aj podľa ceny po ich skončení. Zjednoťte menu a spôsob započítania daní, aby ste neporovnávali rozdielne základy.

05Spoľahlivosť a bezpečnosť potrebujú vlastníka

Nech firma určí prijateľnú dĺžku výpadku a prijateľnú stratu posledných zmien. Prvá požiadavka sa premietne do cieľa času obnovy, druhá do cieľa bodu obnovy. Pre interné dokumenty môžu platiť iné hodnoty než pre príjem objednávok. Podľa nich vyberajte redundanciu, zálohy a postup obnovenia.

Model zdieľanej zodpovednosti AWS odlišuje úlohy poskytovateľa a zákazníka podľa používanej služby. Spravovaná infraštruktúra vás nezbavuje zodpovednosti za vlastné údaje a oprávnenia. Činnosti prideľte konkrétnym ľuďom: kto schvaľuje prístup, kontroluje zálohy a rieši incident.

Google Cloud Well-Architected Framework posudzuje popri výkone bezpečnosť, spoľahlivosť, náklady a prevádzku. Pri výbere sa preto pýtajte, či váš tím zvládne dlhodobo spravovať celú zostavu. Lacnejšia infraštruktúra s nejasnou zodpovednosťou môže znamenať drahšiu službu ako celok.

06Pilot má ukázať aj poruchu a návrat späť

Nenasadzujte len úvodnú stránku. Vyberte malý reprezentatívny tok, napríklad prihlásenie, zápis objednávky, prílohu, odoslanie do nadväzujúceho systému a dohľadanie chyby. Použite skúšobné údaje zodpovedajúce reálnemu objemu. Merajte odozvu aj spotrebu prostriedkov.

1. Nasaďte rovnakú verziu aplikácie opakovateľným postupom.
2. Vyskúšajte očakávanú špičku aj obmedzenia nadväzujúcich služieb.
3. Obnovte údaje zo zálohy a skontrolujte ich obsah.
4. Vráťte chybnú verziu aplikácie do predchádzajúceho funkčného stavu.
5. Odovzdajte diagnostiku a prístupy druhému človeku.

Záznam pilotu má obsahovať výsledky, nevyriešené problémy a prácu potrebnú na nápravu. Náklady na správu overujte s ľuďmi, ktorí ju prevezmú. Ak potrebujete externú údržbu a podporu aplikácie, patrí do porovnania od začiatku vrátane dohodnutej reakcie pri incidente.

Ak presúvate už fungujúci systém, rozpracujte aj prepnutie prevádzky podľa článku o migrácii do cloudu bez výpadku.

07Závislosti prijímajte vedome a výber zapíšte

Špecifická cloudová služba môže ušetriť veľa vývoja. Pri zmene poskytovateľa však môžete potrebovať prepísať časť aplikácie. Zaznamenajte dôvod prijatia tejto závislosti, dostupný export dát a približný rozsah budúceho presunu. Kontajnery samy nevyriešia prenos identít, databázových funkcií ani prevádzkových pravidiel.

Viac cloudov zvažujte z konkrétneho dôvodu a s rozpočtom na správu. Pre malý tím nie je druhý poskytovateľ automatickou zálohou: musí fungovať obnova údajov, konfigurácia aj prepnutie prevádzky. Často pomôže najskôr overiť export a obnovu do čistého prostredia.

Výber uzavrite krátkym záznamom: zvolená zostava, dôvody, očakávané náklady, vlastník prevádzky, prijaté obmedzenia a podmienky nového posúdenia. Môže to byť výrazná zmena objemu údajov, vstup na ďalší trh alebo potreba, ktorú pôvodné riešenie nepokrýva.

08Časté otázky

09Pripravte podklady na skutočné porovnanie

Pošlite nám opis aplikácie, používané systémy, prevádzkové špičky a požiadavku na obnovu. Preberieme výber cloudovej platformy aj rozsah pilotu, ktorý pomôže posúdiť techniku, cenu a správu.