Cloudová migrace: jak začít, rozhodovat se a získat pomoc

Autor: Dennis Harvey, 1/10/2020, Cadence80Studios.com

Rozhodnutí přesunout výpočetní prostředky vaší společnosti do cloudu může být dost jednoduché, ale taktická rozhodnutí nejsou a chyby jsou nákladné. Některé společnosti hledají řešení od jednoho dodavatele. Někteří sledují cloudové agnostické strategie. Někteří sledují hybridní cloudové přístupy. Tento článek zdůrazňuje Google Cloud Platform (GCP), ačkoli se jeho podstata vztahuje i na ostatní dodavatele cloudů.

Široká škála poskytovatelů služeb spustila trh, aby pomohla s touto bezprecedentní migrací v cloudu, včetně velkých poradenských společností, butikových technologických firem, smluvních zaměstnanců, poskytovatelů IT infrastruktury, poskytovatelů spravovaných služeb a seznam pokračuje.

Cílem tohoto článku je poskytnout shrnutí, které vám pomůže začít s cloudovou migrací, zkrátit křivku učení, vyhnout se nákladným chybám a identifikovat zdroje pomoci.

Rozhodnutí: Vaše společnost čelí těmto rozhodnutím v cloudové migraci ze stálého začátku:

  1. Rozhodněte se pro cloudovou strategii: jeden dodavatel cloudu, cloudový agnostik nebo hybridní cloud.
  2. Jaké aplikace se stěhují do cloudu: stávající podnikové nebo starší aplikace nebo nové aplikace?
  3. Získejte základní základy hned od začátku.
  4. Určete pomoc, kterou potřebujete.

Pojďme vrtat do čtyř tematických oblastí.

Jeden dodavatel cloudu, cloudový agnostic nebo hybridní cloud

Toto téma si pravděpodobně zaslouží svůj vlastní článek, ale zde jsou některé úvodní myšlenky. Mnoho společností se zdráhá vstoupit do scénáře dodavatele cloudu; proto cloudový agnostický přístup zní lépe než jediný dodavatel cloudů na povrchu. Ve skutečnosti je obtížné implementovat cloudovou agnostiku v dostatečném rozsahu, aby byla zajištěna skutečná praktická ochrana proti uzamčení dodavatele, aniž by byla přidána složitost, která pravděpodobně převáží většinu výhod.

Technologie kontejnerů, Docker, Kubernetes a Terraform lze využít k dosažení některých agnostických cílů v cloudu. Všechny kontejnery, Docker a Kubernetes spadají pod deštník nazývaný cloudové nativní aplikace. Kubernetes poskytuje velkou míru cloudové agnostické síly, protože každý dodavatel cloudu má svou vlastní spravovanou službu K8: GKE pro GCP, EKS na AWS a AKS na Azure. Líbí se mi mnoho bodů, které Elliot Forbes uvedl ve svém článku Cloud Agnostic Architecture je mýtus.

Terraform je lídrem v automatizaci poskytování cloudových zdrojů a poskytuje cloudové agnostické super-síly na základě své architektury připojitelných poskytovatelů. To umožňuje Terraformu poskytovat cloudové prostředky na kterékoli z hlavních cloudových platforem pomocí správného poskytovatele. Úlovek je, že každý poskytovatel cloudu má svou vlastní syntaxi ve formě různých zdrojů a tyto zdroje mají své vlastní specifické definice proměnných. Poskytování cloudových zdrojů pomocí Terraformu tedy není zcela cloudové agnostikum, protože samotný Terraform kód se liší pro každého poskytovatele cloudu: GCP, AWS a Azure. Poskytuje však krok správným směrem, protože můžete „portovat“ kód terraformu tak, aby byl v souladu s každým poskytovatelem cloudového terraformu cloud a vytvořil tak cloudové zdroje.

Další sadou úvah v cloudové agnostické říši jsou: spravované služby a proprietární cloudové dodavatelské služby. Řízené služby buď zjednodušují operace, obvykle podstatně, nebo si dovolují výhody „nevyžadují žádné operace“ nebo „NoOps“ ve srovnání se standardními alternativami. Příklady v GCP zahrnují:

  • CloudSQL místo instancí MySQL nebo Postgresql na instancích GCE (VM)
  • DataProc namísto klastrů a služeb Hadoop

GCP CloudSQL jako příklad poskytuje tyto důležité provozní výhody.

Přísný cloudový agnostický přístup by diktoval vyhýbání se většině spravovaných služeb nabízených každým dodavatelem cloudu. Přesto tyto spravované služby nabízejí mnoho výhod, včetně zjednodušeného použití, automatizovaných funkcí a výrazně efektivnějších operací ve srovnání s ekvivalentními, standardními službami typu roll-your-own. V důsledku toho bude přísné vyhýbání se těmto řízeným službám vyžadovat více provozních zdrojů, složitější a delší dobu uvádění na trh za předpokladu, že váš tým má devops chops.

Proprietární služby mají podobné úvahy jako spravované služby, protože zjevně nejsou cloudové agnostiky. Zvažte služby Pub / Sub v GCP, které poskytují globální služby zasílání zpráv. Pub / Sub je mnohem jednodušší použít pro zasílání zpráv v rámci GCP, než například Kafka jako jedna široce přijímaná alternativa otevřené platformy pro zasílání zpráv. Opět striktní vyhýbání se těmto proprietárním službám bude vyžadovat více provozních zdrojů, složitější a delší dobu uvedení na trh.

Hybridní cloud obecně odkazuje na prostředí, které integruje zdroje on-premise, privátní cloud a veřejné cloudové výpočetní prostředky. Mnoho společností si buď vybere, nebo bude nuceno zvolit hybridní cloudový přístup na základě toho, že mají výpočetní služby, které se nebo se nemohou přesunout do veřejného cloudu. Jedním příkladem jsou bankovní služby, které běží na počítačích sálových počítačů. V ostatních případech mohou být aplikace uchovávány v provozních nebo soukromých cloudech z bezpečnostních důvodů nebo za účelem ochrany duševního vlastnictví.

Pokud vaše společnost buduje produkt / službu, která běží na více cloudových platformách, pak obchodní požadavky zaručí cloudový agnostický přístup. Pokud vaše společnost zvažuje cloudový agnostický přístup jako vágní pojistku, možná budete chtít přehodnotit související složitost a náklady.

Jaké aplikace se stěhují do cloudu: stávající podnikové nebo starší aplikace nebo nové aplikace?

Stávající aplikace a starší aplikace jsou někdy přeneseny do cloudu pomocí přístupu „zdvihni a posunout“, což v podstatě znamená udržovat počítačové zdroje co nejpodobnější s on-premise výpočetními a síťovými prostředky. Tento přístup je často používán ke zjednodušení a tím k urychlení migrace cloudu.

V tomto bodě bylo napsáno mnoho o nevýhodách přístupu „zdvihací a posunovací“ a tato omezení jsem z první ruky zažil ve svých projektech GCP. Nevýhody lze široce klasifikovat jako neúspěch při optimalizaci pro cílovou cloudovou platformu a zahrnují:

  • Nepodařilo se využít pružné, automatické škálování a vysoce dostupné spravované služby, jako jsou skupiny spravovaných instancí a GKE v kontextu GCP.
  • Selhání migrace databázových služeb na výkonnější alternativy, jako je použití CloudSQL namísto roll-your-own MySQL v instancích GCE nebo snad portování na více škálovatelnou platformu SQL, jako je Spanner.
  • Nepodařilo se optimalizovat softwarově definované sítě (SDN v kontextu GCP) sledováním typologií, které nejsou vhodné pro cloud.
  • Nepodařilo se plně využít zcela nové bezpečnostní služby a koncepty poskytované dodavatelem cloudu. Příkladem je, jak jsou v GCP implementována škálovatelná pravidla brány firewall, která se zcela liší od tradičních zařízení hardwarové brány firewall.

Mnozí z vás zažili myšlenku na opravu základních architektonických vad v další fázi projektu a tato fáze se nikdy nestane. Neexistuje žádná náhrada za prvotní design, který by umožňoval správnou architekturu na místě, a to platí i pro cloudové migrace.

Na mých cestách je přístup zdvih a posun vhodný pouze pro jednoduché případy použití aplikací a prostředí a vhodný případ použití narazím pouze jednou ve svých zkušenostech s projektem GCP.

Budování zcela nových aplikací pro cloud je úplně jiný podnik. V mnoha případech budou společnosti používat cloudový nativní přístup pomocí kontejnerů, Docker, Kubernetes a mikro-služeb. V tuto chvíli není pochyb o tom, že jste četli o Kubernetes (aka K8s), nebo jste s ním pracovali sami, protože to je jedna z nejžhavějších technologií v našem počítačovém / devops / cloudovém světě. Neexistuje jen malý důvod znovu nacvičovat známé výhody kontejnerů oproti virtuálním strojům. Každý hlavní dodavatel cloudů má implementaci služeb K8: GKE pro GCP, EKS na AWS a AKS na Azure.

Je důležité si uvědomit, že právě proto, že K8s je horká komodita, existuje mnoho služeb a aplikací, které jsou vhodnější pro jiné služby ve světě GCP, včetně:

  • Výpočetní modul Google (GCE) pro virtuální stroje
  • Aplikační modul Google (GAE) pro platformu spravovaných aplikací
  • Funkce cloudu pro funkce serveru bez událostí
  • Cloud Run ke spuštění aplikací bez kontejnerů

Získejte základy hned na začátku

Základy: Velkým přínosem bude strukturování základních základů v cloudu správně předem. To je volně analogické tomu, jak definovat vaši aplikační architekturu předem ve světě vývoje aplikací.

V říši GCP to znamená správné definování těchto věcí z get-go:

  • Hierarchie zdrojů: organizace, složky, projekty
  • Správa identit a přístupu (IAM): definování skupin identity a účtů služeb
  • Sítě: VPC (virtuální privátní cloud), sdílené VPC, podsítě, pravidla brány firewall a připojení k sítím on-premise
  • Zabezpečení, které se protíná se všemi výše uvedenými, kromě implementace příslušných bezpečnostních služeb, které chrání váš obvod, sítě a aplikace

Tento odkaz na GCP, Doporučené postupy pro organizace podniků, poskytuje dobrý souhrn s některými dalšími podrobnostmi.

Služby: Krátce jsme se dotkli některých úvah týkajících se spravovaných a vlastnických služeb výše. Vaše rozhodnutí týkající se výběru služeb ovlivní: složitost a náklady na migraci v cloudu, devops a budoucí údržbu, škálovatelnost a vysokou dostupnost a budoucí provozní náklady na cloud v trvalé podobě.

Výběr služeb si zaslouží specializovaný komplexní článek, ale nabídnu zde několik poznatků.

Cloud nabízí oproti svému hardwaru ve vašem datovém centru mnoho výhod:

  • Elastické služby, které se automaticky přizpůsobují poptávce
  • Vyšší dostupnost je dosažitelnější
  • Jednotné a centralizované služby pro správu identity a přístupu (IAM)
  • Globální síť zahrnující kontinenty, regiony a zóny
  • Jednotné a komplexní služby pro zabezpečení
  • Centralizované protokolování a monitorování
  • Automatizace (popsána v další části)

Vzpomínám si na touhu po možnostech automatického škálování v mých maloobchodních dnech elektronického obchodování pomocí serverů na premise.

Funkce automatického měřítka v cloudových službách GCP jsou příliš dobré na to, aby byly přehlíženy. Mezi příklady patří:

  • Automatické klastrování klastru v GKE / K8s
  • Automatické škálování ve skupinách spravovaných GCE (v zásadě automatické škálování fondů VM)
  • Bigquery pro analytiku datových skladů je ze své podstaty autoscaling a může škálovat na tisíce jader během několika sekund, aniž by bylo nutné zadat jakékoli informace o klastrech.
  • Dataproc, služba Hadoop and Spark spravovaná společností Google, se automaticky nereguluje, ale během několika minut můžete rozdělit klastry jakékoli velikosti.
  • Spanner je transakční, horizontálně škálovatelná, relační (aka SQL) databáze GCP. Nemá automatické měřítko, ale lze jej snadno upravit přidáním dalších uzlů do instance.

Automatizace: Cloud je o nahrazení hardwaru softwarem: softwarově definované prostředky, síťově definované sítě (SDN) a software definovaný v podstatě všechno. Ve světě on-premise hardware máte hardware. V novém cloudovém světě máte zdrojový kód, nebo byste alespoň měli, jak zdůrazním brzy.

V GCP a dalších dodavatelích cloudu jsou všechny zdroje vytvářeny, uvedeny a jinak spravovány voláním zabezpečených rozhraní REST API. Tato API však mohou být vyvolána různými mechanismy, nástroji a programy, včetně:

  • Konzola GCP: console.cloud.google.com
  • Gcloud SDK
  • Nástroje pro poskytování zdrojů, jako je Terraform nebo Google Cloud Deployment Manager
  • Domácí programy a shellové skripty, které volají cloudová REST API

Každý z výše uvedených lze využít pro různé případy použití. Když je vše řečeno a hotovo, měli byste mít úplnou sadu zdrojového kódu pomocí nástroje v některém jazyce, který poskytuje tyto klíčové funkce:

  1. Dokumentujte své cloudové zdroje v kódu
  2. Znovu vytvořte svá cloudová prostředí (vývoj, inscenace, QA, produkce) podle libosti
  3. Postupně spravujte / zlepšujte / rozšiřujte své cloudové zdroje v průběhu času
  4. Podpora vysoké dostupnosti a obnovy po katastrofě

Důležitost výše uvedeného nelze přehlížet. Ve výrobě jsem narazil na několik hlavních komerčních prostředí, kde byly cloudové prostředky vytvořeny pomocí konzoly bez jakéhokoli kódu nebo automatizace. Cloud poskytuje možnosti automatizace, které obecně pro hardware na místě neexistují, proto je od začátku používejte. To je chyba, kterou nesmíte opakovat, a snadno se jí vyhnete správným přístupem a pomocí partnera.

Určete pomoc, kterou potřebujete

Nápověda: Udělali jste některá důležitá rozhodnutí uvedená výše a je čas identifikovat pomoc, kterou potřebujete, aby se vaše cloudová migrace stala realitou.

Prodejci a technologičtí partneři nabízejí celou řadu služeb, včetně strategického poradenství, technologického poradenství, implementace (s variantami designu, sestavení, nasazení a revize metodik) a školení. V případě GCP zahrnují uvedené partnerské specializace: vývoj aplikací, cloudovou migraci, analýzu dat, infrastrukturu, IoT, lokalizační služby, strojové učení, marketingovou analýzu, zabezpečení, transformaci práce a školení (analýza dat, infrastruktura, zabezpečení ).

Jaký druh pomoci potřebujete: strategické nebo architektonické rady nebo pomoc při taktické implementaci?

V mnoha případech můžete vyškolit lidi, které máte u svého technického personálu, aby dosáhli požadovaných cloudových dovedností k provedení taktické implementace. Online vzdělávací zdroje, které jsou nyní k dispozici, jsou úžasné, protože linuxacademy, coursera a udemy poskytují online kurzy k získání požadovaných znalostí a dosažení různých úrovní certifikací dodavatelů cloudů. Jsem částečným linuxacadémií, které jsem použil k získání několika svých certifikátů GCP.

V mnoha případech budete chtít najmout správného partnera, který od začátku vyjasní strategické a architektonické rozhodnutí, abyste se vyhnuli nákladným chybám.

Dennis Harvey je zakladatelem konzultační praxe GCP pro jednoho člověka, https://cadence80studios.com/, která staví na klikaté kariéře v oblasti vývoje softwaru, podnikového zpracování dat, rozsáhlého elektronického obchodování a pojmenování.