Jak na hladký odchod z cloudu: Migrace klíčových služeb

„Migrujte do cloudu, zahoďte vlastní hardware, ušetříte.”

Tuto radu slýcháme zleva i zprava posledních sedm let. Bohužel, často se až příliš pozdě ukáže, že migrace do cloudu nebo dokonce cloud native přístup nejenže nedoručí kýženou úsporu, ale naopak přinese nepředvídatelné náklady a vendor lock-in. Ceníky cloudu jsou totiž velmi složité a co na první pohled vypadá jako jasně výhodné mnohdy nemile překvapí. 

Následný pokus o opuštění cloudu pak může vyústit v zásadní dilema – přepsat polovinu aplikace a dvě třetiny firemních procesů, nebo platit stále více a více za cloudové služby?

Co když problémům s migrací z cloudu můžeme předejít?

Nabízí se hraběcí rada: “Tak do cloudu prostě nechoďte.” Ale to je příliš zjednodušený pohled. Například na začátku projektu je spuštění v cloudu velmi rozumná a racionální volba, kterou plošně odmítat by bylo nešťastné. A jsou i další specifické situace a projekty, pro které je cloud native přístup nejlepší volbou. Proto doporučujeme místo kategorických soudů pro či proti, mít při vstupu do cloudu na vědomí, že možná budete chtít jednoho dne odejít. 

S tímto mindsetem se nenecháte zavřít do světa cloudových služeb a když se budete držet ověřených standardních protokolů a postupů, zachováte si flexibilitu. I pokud už v cloudu jste, vyplatí se podívat na váš setup a zamyslet se nad tím, jak se vymanit z případného lock-inu. V dnešním článku se podíváme na několik klíčových služeb, které naši klienti nejčastěji řeší při odchodu z AWS, a jak si jejich převod co nejvíce usnadnit. Rozhodně nejde o vyčerpávající výpis všeho, s čím se můžete potkat. Ze zkušenosti ale mohu říct, že těchto pár služeb dokáže ušetřit velmi mnoho problémů při přechodu.

Elastic Kubernetes Service (EKS)

Kubernetes (K8s) se stal v posledních letech de facto standardem pro provoz kontejnerizovaných aplikací. Jeho jednoduchost, automatické škálování a vysoká dostupnost, velmi snadné rozšíření clusteru o další nody – to všechno jsou výhody, které nám K8s přináší oproti tradiční infrastruktuře. Kubernetes byl vytvořen v roce 2014 pro interní potřeby Googlu, ale velmi rychle opustil jeho datacentra a začal dobývat svět. EKS lze v AWS provozovat buď na vyhrazených EC2 instancích nebo pomocí nástroje Fargate v režimu serverless.  

Jak na migraci EKS z veřejného cloudu?

Obrovskou výhodou EKS je jeho univerzálnost. Díky 100% kompatibilitě s klasickým Kubernetes je odchod na vlastní infrastrukturu víceméně bezproblémový. Stačí vzít existující deploymenty a poslat je na jiný cluster. 

Na co je přesto potřeba dát si trochu pozor, je nastavení ingressu. AWS v EKS používá ingress v podobě svých balancerů, pro vlastní K8s je tedy potřeba ingressy upravit. Ve většině případů se jedná o jednoduché přepsání ingress class z AWS na NGINX.

EC2

Virtuální servery EC2, spolu s S3 a RDS, patří mezi nejstarší a stále velmi oblíbené služby, které AWS nabízí. Tyto servery, běžící na Linuxu nebo Windows a dostupné i na platformě ARM, jsou svou podstatou velmi podobné tradičním serverům, což zjednodušuje jejich migraci z cloudu. Přestože konfigurace operačních systémů a aplikací může být na EC2 srovnatelná s jinými virtualizačními platformami nebo dokonce fyzickými servery, nelze předpokládat, že konfigurace určená pro EC2 bude fungovat bez úprav jinde.

Jak na migraci EC2 z veřejného cloudu?

Migrace EC2 je relativně přímočará díky jejich podobnosti s tradičními servery. Je však důležité upravit cloud-specifické konfigurace, jako jsou load balancery a síťová nastavení, aby odpovídaly novému hostitelskému prostředí. Speciální pozornost by měla být věnována také operačním systémům, zejména pokud používáte Amazon Linux, který může vyžadovat úpravy pro kompatibilitu s běžnějšími distribucemi jako je RHEL, Debian nebo Ubuntu.

S3

Objektový storage S3, jeden z prvních produktů AWS, má dnes již několik open-source alternativ, jako jsou MinIO a CEPH, které jsou plně kompatibilní s AWS S3 a často nabízejí další funkce. 

Jak na migraci S3 z veřejného cloudu?

Právě tyto open-source varianty lze pro migraci S3 využít. Důležité je přizpůsobit S3 endpointy v aplikacích, aby odkazovaly na novou lokaci. Toto je obvykle jednoduché, pokud vaše aplikace již používá abstraktní vrstvu pro práci se S3.

V infrastrukturách, které pro klienty stavíme ve vshosting, se nejčastěji můžete setkat s implementacemi MinIO nebo S3 na platformě CEPH, protože poskytují vynikající kompatibilitu a rozšiřitelnost.

RDS

Služba relačních databází RDS podporuje nejrozšířenější databázové systémy jako MySQL/MariaDB, PostgreSQL, MSSQL a Oracle. 

Jak na migraci RDS z veřejného cloudu?

Při migraci z RDS nebo z její speciální verze Aurora můžete čelit výzvám při přesunu dat, protože AWS neumožňuje připojení externí databáze v režimu slave pro bezvýpadkové kopírování dat. Jediným řešením je provést export dat z RDS a jejich import do vlastního databázového řešení, což vyžaduje odstávku aplikace a v případě většího množství dat může být časově náročné.

Elastic Container Service (ECS)

Pokud chcete začít používat kontejnerizaci aplikací ale nechcete rovnou skočit do plnohodnotného K8s, patrně sáhnete po ECS. Jednoduché běhové prostředí pro Docker kontejnery využívající stejně jako EKS výkon vyhrazených EC2 serverů nebo serverless pomocí Fargate. Tam ale veškerá podobnost a interoperabilita končí. ECS je proprietární řešení Amazonu a neexistuje pro něj 100% alternativa. 

Jak na migraci ECS z veřejného cloudu?

Protože ECS je výhradní služba Amazonu, migrace vyžaduje větší úpravy. Na klasickém Docker serveru můžete využít existující kontejnery pro ECS, celý způsob deploymentu je ale potřeba od základu přepsat, konfigurace ECS je nepřenositelná. Ze zkušenosti můžeme doporučit, pokud uvažujete o dockerizaci, vynechat krok s ECS a přejít rovnou na EKS. Trochu složitější začátek se vám velmi rychle vrátí nejen v podobě mnohem větší přehlednosti, ale i právě v možnosti snadné migrace z cloudu na vlastní K8s.

Lambda

Lambda je serverless prostředí pro běh kódu. Je to vlastně jeden z prvních a prakticky nejpoužívanější řešení pro spuštění aplikace využívající dávkové zpracování. Na platformě AWS lze v Lambdě pustit různorodé aplikace napsané v PHP, NodeJS nebo třeba v Pythonu. 

Jak na migraci Lambda z veřejného cloudu?

Při přechodu na vlastní řešení je potřeba zvážit, zda vyžadujete udržení konceptu serverless a event driven funkcí nebo zvládnete přejít na plnohodnotnou kontejnerizaci. Pokud je serverless přístup nutný, můžete využít několik projektů, které implementují chování Lambdy do klasického K8s clusteru, např. Knative. Nevýhodou tohoto přechodu je potřeba provozovat celý K8s cluster, na kterém se funkce spouští. Pomocí Knative můžete pouštět funkce napsané v nejrůznějších jazycích jako je PHP, NodeJS, Python nebo Go a není tedy potřeba přepisovat aplikaci jako takovou.

Pár poznámek na konec: Cesta ke kontrole nad vaší cloudovou strategií

Jak vidíte, migrace z cloudu může být přímočará, pokud jsou předem zváženy alternativy k nejpoužívanějším službám. Přesto AWS nabízí i další služby, které nemusí být tak snadno migrovatelné. Důležité je pečlivě zvážit všechny aspekty před nasazením nových technologií v cloudu. Rozhodně existují aplikace, které se vyplatí v cloudu provozovat dlouhodobě (např. AI nebo storage v řádech exabytů), většina projektů si ale vystačí s řešeními, které nezavřou dveře odchodu na levnější a přehlednější alternativu.