6 věcí, které byste měli zvážit, než si vyberete mezi GCP a AWS

A je to tu zas: seznamy deseti charakteristik, výhod nebo vlastností, bla, bla, bla. Ani já nemám tenhle typ článků moc v lásce. Nedávno jsem přešel z jedné společnosti do druhé a musel jsem kvůli tomu přesunout většinu své cloudové práce z AWS (Amazon Web Services) na GCP (Google Cloud Platform). Musím říct, že to byl a stále je vzrušující proces, takže jsem se rozhodl, že upozorním na některé rozdíly mezi těmito platformami, a doufám, že to bude pro někoho užitečné.

Pamatujte, prosím, na to, že tenhle článek píšu v polovině roku 2020 a všechno může být jinak, pokud si ho přečtete někdy v budoucnu. Také bych chtěl upozornit na to, že se jedná o moje vlastní zjištění ve stávající situaci a vaše zkušenost může být úplně jiná, případně budete tu mojí považovat za zcela nevalidní. V takovém případě mě neváhejte opravit. Moc rád se mýlím!

Co chybí GCP… a mně také

Chtěl bych začít věcí, která mi v GCP chybí asi nejvíc: ohromující množství služeb, které nabízí AWS. Vysvětlím proč. Řekněme, že chcete využít službu Elasticsearch v základním rozsahu. Nic fancy, žádné pluginy. Zákazník je ochotný za službu zaplatit, protože ví, že váš čas se dá využít někde jinde a mnohem lépe. A jak to je s GCP? Smůla.

Správně by bylo vaší aplikaci zanalyzovat a použít nějaké jiné GCP služby. Ale pokud byste chtěli použít Elasticsearch, musíte si spustit své vlastní GCE instance a také je spravovat. Pro demonstraci, jak právě s tím teď bojujeme, přikládám odkaz na terraform repozitář, který přesně tohle implementuje. A to je jen jeden z mnoha příkladů.

Vím, že Elasticsearch v AWS není totéž co Elasticsearch, který si spravuje člověk sám. Službě chybí velké množství pluginů a pro malý projekt je celkem nákladná. Hádám, že hlavním důvodem, proč služba neumožňuje širší uživatelské nastavení, je velmi přísné SLA ze strany AWS.

Ale buďme upřímní, kdo by se nevzdal některých pluginů, aby docílil větší celkové stability aplikace? Navíc Elasticsearch není jediná služba, která je v AWS omezená. Spousta funkcí v Amazon Aurora MySQL je vypnutá nebo mapovaná jinými funkcemi, které mohou být volány non-root uživateli. Můžeme se jen dohadovat proč. Mým tipem je opět velmi přísné SLA.

Chybějící služba?

Jako architekt byste to měli být vy, kdo posoudí, zda je chybějící služba pro vaši aplikaci problém. Pokud ano, přejděte na všemocné AWS se všemi nedostatky, nebo se nad aplikací ještě jednou zamyslete. Možná jste udělali nějaká špatná architektonická rozhodnutí a jakmile aplikaci upravíte, měli byste raději zvolit nějakou jinou GCP službu. Abych první problém shrnul – pokud vám v GCP chybí nějaká služba, je možné, že na to jdete ze špatného konce. Pokud vaše aplikace nejde napasovat do GCP služeb, je na čase začít používat AWS.

Druhý problém, který jsem při migraci z jednoho cloudu na druhý odhalil, jsou rozdílné názvy entit, v nichž jsou uloženy vaše resources. V AWS jsou vaše resources přímo v účtu, kdežto v GCP jsou projekty. Podle mě dávají projekty mnohem větší smysl než účty. Ale všechno to záleží na úhlu, z něhož se na svojí infrastrukturu díváte. Pokud přecházíte na AWS bez úprav (lift & shift), vaše servery jsou pravděpodobně mazlíčci vydržovaní společností, která je vlastní. Jasně, dává to smysl. O váš účet je dobře postaráno. Nicméně, jakmile vyvinete aplikaci, která má být stejně rychle zahozena jako nasazena, neměli byste potřebovat samostatný účet s vlastní fakturací; místo toho máte projekt.

Uvažme následující divoký scénář: Máte jeden účet. Ten účet má svou vlastní fakturaci. Není součástí organizace. Váš terraform kód je strašný. Má sklon pojmenovávat resources bez náhodné přípony, takže když chcete něco replikovat, vždycky skončíte s duplikáty resources, které nemohly být vytvořeny. Chytře tedy použijete trik s regiony a dev nasadíte na prostředí ve Frankfurtu, stage do Londýna a produkci do Irska. Paráda. Byli byste překvapeni, jak často se tohle děje. Místo aby lidé vytvořili více účtů (nebo projektů), prostě přepínají mezi regiony. U GCP je v těchto případech terminologie mnohem jasnější. Máte prostě různé projekty a hotovo. Chcete prostředí pro produkci. Není problém. Jen ho nasaďte v jiném projektu a ten napojte na správný billing account.

Různé identity, rozdílné flow

Podívejme se teď na rozdíly mezi základními službami cloudu – AWS IAM vs. GCP IAM. Nejdřív bych chtěl objasnit jednu věc: GCP IAM není IAM a je pro to jednoduchý důvod. GCP IAM neposkytuje identity. Místo toho používá identity ze služby G Suite nebo jiného e-mailového poskytovatele. A je tu ještě něco jiného, na co bych chtěl v případě GCP upozornit. Jsou to tzv. service accounts. Asi jste uhodli, že tyto účty se používají k identifikaci služeb (což mimochodem rozhodně dává smysl).

V AWS máte něco podobného, jsou to tzv. roles. Buďte ale opatrní, protože flow se liší. Například v AWS přidělíte roli instanci EC2. Její instance-id identifikuje instanci. Role obsahuje oprávnění, která jsou přijímána (a určována) instancí. V GCP GCE přidělujete instanci service account, který instanci identifikuje a má přidělená oprávnění. Určitě jste zaznamenali zjevné terminologické nesnáze. Service accounts dávají mnohem větší smysl. Problém se zhoršuje vždycky, když cloudy kolidují v nějaké společné službě:

– V AWS můžeme mít K8s cluster, který také obsahuje service accounty.

– V případě GCP je to s K8s o něco jednodušší a service accounty jsou většinou namapované na IAM service accounty.

A to není všechno. Nezapomínejme, že GCP instance mají narozdíl od EC2 instancí, které nemají defaultní role, skoro vždycky default service accounty. Hračka, co? Jak tak píšu tenhle odstavec, jsem si jistý, že moje terminologie je správná jen částečně. Tyhle podobnosti mohou být pro nové uživatele zavádějící.

Pokud potřebujete víc podů, něco je špatně

A nezapomeňme na službu, kolem níž byl v posledních letech největší poprask. AWS K8s se jmenuje EKS, GCP K8s se jmenuje GKE. Upřímně řečeno, Google vyvinul K8s, takže není spravedlivé srovnávat GKE s mladším EKS. Musím také dodat, že situace EKS se zlepšuje každý den. Sám jsem byl smolař, který musel svojí cestu s K8s začít na EKS, který se tehdy zrovna spouštěl.

První problém, s nímž jsem se setkal, byl network overlay. Neexistoval. Nasadili jsme čtyři malé nody, jen abychom projekt otestovali. Abychom viděli, jak EKS pracuje, nasadili jsme asi sto podů. Překvapení! Skoro každý jeden pod byl čekající a nespustitelný. Jistě, náš postup byl hloupý. Nikdo by to tak neměl dělat. Počet vašich nodů a jejich kapacita by měla reflektovat potřeby microslužeb, které na podech běží. Proto by měl také počet IP adres odrážet počet nodů a jejich kapacitu.

Nesmíme také přehlížet fakt, že jeden pod může mít pouze jednu IP adresu a AWS defaultě neumožňuje žádný network overlay. Můžete mít pouze tolik počet IP adres, kolik vám dovolí typ vaší instance. V našem případě to bylo kolem deseti IP adres. Nejhorší případ mohou být limity v horizontálním škálování. Pokud vám dojdou instance, dojdou vám později i IP adresy a vaše škálování se zastaví.

Zkuste to vysvětlit technikovi on-call podpory, který nemůže uprostřed noci naškálovat, protože všechny IP adresy v clusteru zabral jiný namespace. Moje upozornění a rada je, že používání nativního AWS network overlay může být složité. Má své světlé chvilky, ale pro testování a vývoj prostě používejte Calico.

Nezdravý způsob provádění health checků

Další nepěkná vlastnost GCP je způsob, jakým cloud provádí health checky. Vím, že Google nabízí naprosto jedinečné řešení pro Cloud VPC, a – přiznejme si – považujeme ho za samozřejmost. Jen si to představte – VPC pokrývá celý svět, ale proč musí být health checky prováděny pouze z některých subsítí? Netuším. Podle mě by bylo mnohem jednodušší provádět je z load balanceru.

Navíc se subsítě s health checky pro load balancery I4 a I7 liší. To vede k tomu, že každý admin vytvoří jedno firewall pravidlo se všemi health check subsítěmi. To skutečně není ideální. Generuje to spoustu otázek, které také juniorní technici často pokládají. V ideálním světě bych navrhl posílat health checky z load balanceru, ale vím, že jsou velmi unikátní. Trvalo mi několik dní, než jsem vytvořil jednoduchý internal managed load balancer. Ne že bych je nemohl vytvářet v cloudové konzoli, ale vyvinout funkční terraform kód pro kterýkoli GCP load balancer je práce pro kompetentního devopsáka.

Zavádějící jména

Už jsme mluvili o tom, že IAM od AWS a GCP jsou trochu jiné. Co kdybych vám ale řekl, že když chcete navýšit kvóty pro kterýkoli GCP resource, musíte jít do nastavení IAM. Divné, že? V tomhle ohledu je podle mě AWS mnohem jednodušší. Pořád si myslím, že tohle by mělo být záležitostí billingu, ne IAM. Ale to je, hádám, opět otázka úhlu pohledu.

AWS vs. GCP: Souboj hodnot

Místo abych házel špínu na oba cloudy, raději bych chtěl tenhle krátký článek zakončit tím, co byste si z něj měli odnést: Infrastrukturu řídí use case. Právě use case určuje spoustu podmínek, na něž byste měli pamatovat. Napište si je na tabuli, přiřaďte k nim služby, které je splňují, a pak se poučeně rozhodněte, kterou cestou se chcete vydat. 

Samozřejmě že můžete svojí infrastrukturu udělat heterogenní, což je v některých případech zcela správné řešení. Například pro strojové učení byste měli použít našlapané služby od GCP, ale React frontend můžete klidně nechat na AWS S3 bucketu.

Vždy je proto dobré mít na paměti následující otázku: Stojí náklady na takové heterogenní řešení za to? A to nemluvím jen o každodenní lopotě, jako je updatování nodů v K8s. Také byste měli zvážit, jak velké musí být znalosti v ops týmu. Rozhodně ale můžeme říct, že je levnější mít jen jednoho cloudového poskytovatele.