Odpověď bohužel není jednoduchá. Neexistuje žádné univerzální řešení. Než se rozhodnete pro jedno, nebo druhé řešení, měli byste pečlivě zvážit a následně vyhodnotit své interní možnosti, požadavky i požadované výsledky. Níže je uvedeno několik otázek, které vám pomohou se rozhodnout:

1.     Jak zásadní je pro vás zachování úplné kontroly nad daty?

2.     Používáte jednoduché cloudové prostředí, nebo komplexní prostředí kombinující více cloudových poskytovatelů?

3.     Jaký je váš rozpočet?

4.     Máte tým s odbornými znalostmi v oblasti cloudu, který má kapacitu na zajištění migrace a náseldující každodenní správu?

5.     Bude vaše migrace do cloudu pouze přesunem prostředků, nebo budou třeba složité konfigurace a průběžná optimalizace?

6.     Jakou přidanou hodnotu by pro celý proces migrace do cloudu přinesl specializovaný partner?

Nyní, když jsme se nad těmito otázkami zamysleli, podívejme se na výhody a nevýhody obou přístupů. 

Sami vlastním pánem

Interní správa cloudového prostředí nabízí jedinečný pocit kontroly nad cloudem a potenciální snížení počátečních nákladů. Můžete si přesně určit každý aspekt nastavení cloudu a zajistit, aby dokonale odpovídal vašim specifickým potřebám a stávajícím bezpečnostním protokolům. 

Samostatná správa cloudu však s sebou přináší řadu nástrah

Úspěšná migrace do cloudu vyžaduje tým dobře obeznámený s cloudovými řešeními, osvědčenými bezpečnostními postupy a strategiemi průběžné optimalizace. Vybudování a udržování takového týmu a jeho expertízy interně je velkou investicí. Zvažte také, že i když vlastníIT tým máte a přidáte mu odpovědnost za správu cloudového prostředí, povede ke zvýšenému pracovnímu vytížení a zpoždění v jejich hlavní náplni práce. Zůstat v obraze s vyvíjejícím se cloudovým prostředím také vyžaduje neustálé učení a přizpůsobování. Můžete si to teď dovolit?

Síla partnerství

Na druhou stranu, partnerství s poskytovatelem cloudových nebo spravovaných služeb vám umožní těžit z jejich bohatých zkušeností. Tito poskytovatelé disponují odbornými znalostmi, které urychlí proces migrace díky využití jejich zavedených nástrojů a metodik. Zkušenosti partnera umožňují navrhnout cloudové prostředí na míru vašim konkrétním potřebám, což často vede k lepším výsledkům a větší nákladové efektivitě. Kromě toho získáte také přístup k týmu cloudových specialistů, kteří vás provedou komplexitami zabezpečení a dodržováním předpisů a zajistí průběžnou správu celého prostředí.

Další faktory, které je třeba zvážit

Spolupráce s poskytovatelem cloudových nebo spravovaných služeb je lákavou možností, ale přináší s sebou další důsledky. Partnerství obvykle zahrnuje další poplatky za služby, které mohou mít dopad na celkový IT rozpočet organizace. Tyto poplatky je třeba pečlivě zvážit a zohlednit při finančním plánování, aby se zajistil soulad s případnými rozpočtovými omezeními ve vaší firmě.

Partnerství navíc znamená svěřit poskytovateli určitý stupeň kontroly nad vaším cloudovým prostředím. Tento přesun kontroly vyžaduje otevřenou komunikaci a jasně definované dohody o úrovni služeb (SLA), které popisují role, povinnosti a očekávání obou stran, aby byla zajištěna transparentnost a odpovědnost.

Hybridní přístup

Pokud se stále nemůžete rozhodnout a nejraději byste získali výhody interní správy i služeb partnera, můžete zvážit hybridní přístup. Ten využívá interní odborné znalosti pro základní činnosti a zároveň zapojuje partnera pro komplexní aspekty nebo průběžnou správu. Váš interní tým tak může získat cenné znalosti o cloudu a zároveň spolupracovat s partnerem. Můžete se také soustředit na hlavní funkce a zároveň outsourcovat specializované úkoly, které vyžadují hlubší odborné znalosti.

Partnerství s poskytovatelem hostingu může být výhodné, ale neměli byste přehlížet ani vaše interní zdroje. Budování interních odborných znalostí spolu s dobře definovaným partnerstvím s poskytovatelem hostingu vám může zajistit výhodné řešení z pohledu odborných znalostí i financí.

Pokud si stále nejste jisti tím nejlepším přístupem pro vaši firmu, můžete zvážit vyhledání poradenství u cloudových specialistů. Tito odborníci mohou posoudit vaše konkrétní potřeby a doporučit nejvhodnější strategii, ať už jde o interní správu, partnerství s poskytovatelem hostingu, nebo přijetí hybridního řešení. 

Pokud máte zájem o další diskusi o vašich konkrétních podmínkách s odborníkem, neváhejte nás kontaktovat na konzultace@vshosting.cz. 

Nejnovější vývoj v akvizici VMware společností Broadcom

Dokončení akvizice VMware společností Broadcom v hodnotě 69 miliard dolarů přineslo významné změny a nejistoty pro stávající klienty VMware. Přechod na model založený na předplatném a další strategické změny jsou klíčovými událostmi, které by mohly ovlivnit současné zákazníky.

Klíčové problémy a potenciální zvýšení nákladů:

1. Přechod na model předplatného:
   • Broadcom oznámil, že VMware přejde z trvalých licencí na model založený na předplatném. Tato změna znamená, že zákazníci již nebudou moci nakupovat trvalé licence a budou muset přejít na předplatné, nebo časově omezené licence. Tento přechod by mohl časem vést k vyšším nákladům, protože firmy budou muset pravidelně obnovovat svá předplatná namísto jednorázového nákupu.
2. Zjednodušení produktového portfolia VMware:
   • Broadcom plánuje zjednodušit nabídku produktů VMware, což zahrnuje významné změny ve stávajících službách a strukturách podpory. Zatímco tento krok má za cíl zjednodušit portfolio, může také vést k ukončení některých produktů a služeb, na které zákazníci aktuálně spoléhají, což je přinutí přijmout nová řešení, která mohou být dražší nebo méně vhodná pro jejich potřeby.
3. Zvýšené náklady a snížená flexibilita:
   • Jak Broadcom integruje operace VMware, zákazníci mohou čelit vyšším nákladům na podporu a licencování kvůli zaměření společnosti na maximalizaci návratnosti investic. Navíc přechod na model předplatného snižuje flexibilitu, kterou zákazníci měli dříve s trvalými licencemi, což může v budoucnu vést k celkově vyšším nákladům.

Proxmox: vhodná alternativa

Vzhledem k těmto potenciálním problémům a nadcházejícímu zvýšení nákladů by firmy měly zvážit zkoumání alternativ k VMware. Proxmox vyniká jako robustní a nákladově efektivní řešení z několika důvodů:

• Open source a nákladová efektivita: Proxmox je postaven na technologiích s otevřeným zdrojovým kódem, což eliminuje vysoké licenční poplatky a nabízí firmám plnou kontrolu nad jejich infrastrukturou.
• Komplexní funkce: Proxmox nabízí rozsáhlé funkce jako je live migrace, vysoká dostupnost a zabudované zálohování a obnovu, a to bez dodatečných nákladů.
• Podpora komunity a flexibilita: Proxmox těží z aktivní komunity, která neustále vylepšuje platformu, zajišťuje robustní podporu a flexibilitu pro různé potřeby podniků.

Abychom firmám pomohli s hladkým přechodem z VMware na Proxmox, vytvořili jsme exkluzivní whitepaper. Zaregistrujte se nyní a stáhněte si ho. Zajistěte si plynulou migraci na flexibilnější a nákladově efektivnější virtualizační řešení!

Srovnávací tabulka

Shrnutí:

• Nákladová efektivita: Proxmox je obecně nákladově efektivnější, eliminuje vysoké licenční poplatky.
• Flexibilita: Proxmox nabízí větší flexibilitu díky modelu open-source, vyhýbá se závislosti na dodavateli.
• Snadné použití: Proxmox poskytuje uživatelsky přívětivější rozhraní, vhodné pro řadu podniků od SMB po větší podniky.
• Možnosti podpory: Zatímco VMware nabízí rozsáhlou podporu prostřednictvím placených smluv, Proxmox těží ze živé komunity a volitelné placené podpory.

Zvážením těchto faktorů a prozkoumáním Proxmoxu jako alternativy mohou firmy předejít potenciálním úskalím spojeným s nedávnou akvizicí VMware společností Broadcom a zajistit si stabilnější a nákladově efektivnější strategii virtualizace.

Pokud máte jakékoli dotazy nebo potřebujete pomoc s migrací, náš tým expertů je vám připraven pomoci.

„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.