Chceme provozovat aplikace v různých cloudech a každý měsíc si prozkoumáme, kde je to teď nejlevnější a tam to popřesouváme. Také chceme dělat cloud bursting tak, že aplikace běží například v našem privátním cloudu a když potřebujeme přidat na výkonu, přisypeme si ho tam trochu z public cloudu. Také to chcete takhle? Je to podstatně složitější a například Netflix, špička v moderní aplikační architektuře a využívání cloudu, ještě donedávna byl zcela závislý na Amazon AWS bez přenositelnosti kamkoli jinam. Není podezřelé, že někdo, kdo je takhle daleko, přenositelnost mezi cloudy (ale ano mezi AWS regiony) donedávna neměl vůbec (a dnes má “trošku”)? Je přenositelnost reálná pro enterprise?

Je – ale něco to stojí a má to dost návazností. Dnes se pokusím shrnout pár nejčastějších přístupů a důvodů, proč je možná představa vašeho CIO naivní.

Proč přenositelnost?

Většina lidí nechce vendor lock-in a má představu, že cloud to řeší (přitom cloud – a zejména ten public – je lock-in ještě výraznější, než co známe z minulosti). Je to logické – tam, kde není volba, dochází k nárůstu nákladů. Čím víc jste zamčeni, tím víc platíte – v každém trhu a v každé době. Mít schopnost jednoduše jít jinam je zásadní přínos pro byznys – pro náklady, schopnost inovací (přejdu tam, kde mají něco navíc) a růstu.

Proč je to složitější, než si CIO myslí?

Rozdělme si problém do čtyř kategorií. Je infrastruktura, tedy kombinace compute zdrojů, ukládacích prostorů, síťového propojení, balancingu provozu, firewallingu a jiné síťové bezpečnosti, přenositelná? V tradičním prostředí, kde se tyto věci dělají ručně a jsou popsány jen v dokumentaci, je to v zásadě neopakovatelné a tedy nereálné. Infrastruktura jako služba přináší sadu API, kterou je možné vše automatizovat. Jenže OpenStack, AWS, Azure, Google Compute či Digital Ocean mají toto API vždy jiné. Čím složitější infrastruktura bude, tím obtížnější je konverze mezi těmito API.

Druhou kategorií je aplikační prostředí, tedy image “serverů”, databáze, message služby, chroupání dat a tak podobně. Vezměte si jen image – jak snadné je přesunout image mezi KVM, VMware, AWS a Azure? Hypervisor simuluje hardware a uvnitř VM je kompletní bootovací procedura. Někdy je disk SATA, někdy SCSI, síťové karty jsou různé a tak podobně. Konverze je možná, ale bez obezřetnosti a správného designu může být problematická. Nehledě na to, že některé image, pokud nejsou dobře udělané, mají problém se správně vypořádat se změnami typu změna velikosti disku, přidání NIC a tak dále. Navíc možná budete chtít využít například databázi přímo od cloud providera – ta v Azure samozřejmě není kompatibilní s AWS ani s vaším on-premise Oracle.

A co aplikace samotné? Řada z nich je svázána s infrastrukturou – například očekává nějaké konkrétní IP adresy či DNS jména, což migraci rozhodně nepomáhá. Velká část jich je monolitická a má velmi mnoho návazností na dependencies a jejich verze (a někdy dokonce tyto nejsou explicitně definované, předpokládá se, že je tam operations “nějak dalo”).

Čtvrtou kapitolou jsou data. Jak dostanete data z Azure zpět k sobě? Kolik to stojí peněz a jak dlouho něco takového trvá přes vaše linky? Je to dost rychlé na to, aby to fungovalo jako řešení krizových situací? Nebo chcete proaktivně replikovat data do všech privátních a veřejných cloudů, které jsou u vás “ve hře”? Dává to finanční a technický smysl?

Každá přenositelnost má svou cenu

Všechny naznačené obtíže mají řešení, ale není zadarmo. Na přenositelnosti musíte aktivně pracovat a investovat především čas. Získat znalosti různých prostředí a systémů, automatizovat všechno co jde a přepracovat vaše stávající aplikace, architekturu i infrastrukturu. Potřebujete chroupat data či dělat machine learning? Můžete využít hotovou public platformu (= lock-in) a postupovat rychle, ale dost možná draze. Nebo se to naučte, automatizujte a budujte tak systém sami a mějte prostředky pro rozběhnutí v libovolném privátním či veřejném cloudu. Máte přenositelnost, ale zaplatíte investovaným časem a zdroji. Zkrátka nic není zadarmo – ani přenositelnost. Navíc nic není černé nebo bílé, volte různé strategie pro různé oblasti vašeho byznysu. Pár doporučení se pokusím dát na závěr, teď pojďme do možných řešení detailů.

Přenositelnost infrastruktury

Jak vzít kompletní infrastrukturu, tedy výpočetní prostředky, ukládání dat, síťová propojení, bezpečnost a balancing provozu a přenést to z jednoho systému do druhého?

Je reálné a účelné sjednotit IaaS vrstvu (OpenStack, AWS, Azure)?

IaaS nabízí API a pokud tato budou u všech stejná, máte vyhráno, že? Pro infrastrukturu možná ano, ale třeba to neřeší hlavní důvod, proč to děláte. Můžete u sebe nasadit OpenStack od libovolného dodavatele a využít veřejné nabídky s touto technologií, třeba Rackspace. Nebo si u sebe rozjedete Eucalyptus a ten má API kompatibilní s Amazonem. Nebo použijete Azure Stack (ten ale bude až v polovině roku 2017 – stávající Azure Pack není 100% kompatibilní s Azure technologií) a Azure. Řeší to ale váš problém? Máte volnost volby? Nejblíže je k tomu asi OpenStack, což je pro mě jasná volba pro privátní cloud, ale ve veřejném prostoru je jeho nabídka slabší. Microsoft je lock-in a Amazon také, možná budete mít zdání přenositelnosti mezi on-premise a public, ale to nestačí (a navíc je to jen zdání, pokud nepodniknete kroky na vyšších vrstvách, viz dále). IaaS je správná abstrakce pro infrastrukturu, ale myslím, že ne přímo pro aplikace. Ani jednotné IaaS API vám neřeší přenositelnost dat a diskových obrazů, ani vám nijak nepomůže s problémem latence.

Infrastrukturní orchestrátory (HPE CSA/OO, Terraform, …)

Existují orchestrační platformy, které vám umožní pracovat s infrastrukturou v různých prostředích. Přesto – žádná vám nedá možnost bez úprav přesunout předpis infrastruktury z jedné strany na druhou. Vždyť už jen infrastrukturní komponenty se jmenují jinak a mají jiný obsah – server m1.medium v OpenStack je jiný, než v AWS nebo Azure (pokud tam vůbec takový je). Image musíte mít také připravené ve všech prostředích, která hodláte používat. Nikdy to není jen jednoduché kliknutí – musíte plánovat a mít připravené šablony pro různá prostředí. V HPE CSA si vytvoříte katalog s možnostmi deploymentu infrastruktury třeba v OpenStack i v AWS, ale musíte to připravit. Terraform je na tom stejně. Tyto nástroje vám rozhodně pomůžou a dokáží to pro vás udělat – ale ne bezpracně. Navíc u jednoduchých konstruktů typu VM, storage a síť je to relativně snadné, ale například nabídka load-balancing služeb OpenStack, Azure a AWS je značně odlišná co do fungování.

Doporučení pro infrastrukturu

Za mne pokud potřebujete přenositelnost infrastruktury, jděte cestou nástrojů typu HPE CSA, Terraform apod. Vyberte si konečný počet systémů (řekl bych tak maximálně dva on-premise a dva cloudové) a pro ně připravte orchestrační šablony. Kdykoli můžete do svého katalogu zařadit nového poskytovatele, pokud vám to bude dávat smysl. Sjednocení API vám dlouhodobě byznysově ani aplikačně nepomůže, ale může to být dobré dočasné rychlé řešení.

Přenositelnost aplikačního prostředí

Infrastruktura samotná je k ničemu v tom smyslu, že v ní aplikace přímo neběží. Ty potřebují prostředí – frameworky, knihovny, databáze, messaging služby. Jak zajistit jejich přenositelnost?

Cloud služby typu DB as a service

Ve veřejném cloudu máte možnost využít nativních služeb typu databáze, messaging nebo chroupání dat. Tyto jsou však dnes zcela nepřenosné. Amazon DynamoDB, ElastiCache, Redshift, Azure DocumentDB, Table Storage jsou specifické pro tato prostředí a dokonce i Azure SQL není 100% kompatibilní s MS SQL (bez změn v kódu se obvykle neobejdete). Tyto prostředky mají všechny výhody managed služby (nemusíte se starat o jejich provisioning či vysokou dostupnost), ale zamykají vás. Buď se s tím smíříte a přenositelnost vzdáte (protože výhody převyšují nevýhody) nebo je použijete, ale svázanost budete řešit na jiné vrstvě, nejčastěji v aplikaci (viz hexagonální architektura).

Automatizace standardní služby

Pokud se nechcete zamknout do konkrétní implementace, použijte standardních služeb jako je MS SQL, Redis, MongoDB, MySQL a tak podobně. Získáte tak stejnou službu ať běží kdekoli (= máte potenciál pro přenositelnost… tedy pokud vyřešíte přenositelnost dat, ale o tom později). V takovém případě je ale vhodné všechno automatizovat a to buď univerzálními prostředky (Configuration management viz dále) nebo prostředky poskytovatele (Amazon RDS vám dokáže automaticky připravit třeba standardní MariaDB, MySQL apod., něco podobného můžete udělat s OpenStack Trove).

Konverze image

Existují nástroje na konverzi VM image z jednoho formátu do druhého. Že by fungovaly bezproblémově potvrdit nemůžu, navíc vnitřek image musí být schopen se vypořádat s novou realitou – například roztažením disku, změnou IP adresy a tak podobně. Osobně nejsem zastáncem tohoto přístupu – nemá konzistentní výsledky a nespoléhal bych se na něj.

Immutable servers (např. Packer)

Zajímavou možností je chovat se k VM jako k immutable serverům, tedy VM je zcela zapouzdřená a po startu prostě začne nabízet služby. Nic se nedokonfigurovává, neinstaluje, jde vlastně o appliance. Takto se dá zabalit právě třeba nějaká služba jako je databázový systém. Co chcete jsou obrazy specifické pro konkrétního poskytovatele, jejichž vytváření je ovšem plně automatizované a sjednocené. Můžete použít třeba open source nástroj Packer, který v každém cílovém prostředí spustí základní image s OS (například Ubunut 16.04), automatizovaně do něj nainstaluje databázi v potřebném stavu (skriptem nebo přes configuration management) a pak tento obraz zmrazí a vytvoří z něj immutable server. Pak vám stačí jen spustit tolik kopií, kolik potřebujete. Je to dobré, ale vyžaduje to promyšlenost a plnou míru automatizace – zkrátka zase to něco stojí.

Configuration management (HPE DMA/SA, Ansible, Chef, Puppet, …)

Službu typu databáze můžete instalovat automatizovaným a opakovatelným způsobem s využitím systémů jako je HPE Database and Middleware Automation, Ansible, Chef apod. V cílovém prostředí stačí mít základní OS image a VM “dotáhnout”. Je to ověřené, dobře opakovatelné a je jedno, jaké je cílové infrastrukturní prostředí. Jedinou nevýhodou zde je, že provisioning nějakou dobu trvá (musíte si počkat třeba pár desítek minut, než je služba připravena).

Framework pro služby (Mesos, dnes možná i Kubernetes)

Možná vás napadlo, že by služby typu databáze mohly běžet v kontejnerech, které jsou dobře přenositelné. Je to ovšem docela složité zejména pro tradiční databáze. Kontejnery se historicky nijak netrápily s persistentní storage, což možná pro NoSQL scale-out svět není takový problém, ale pro klasickou DB rozhodně je. V poslední době už je možné použít například Docker Volume drivery pro připojení HPE storage nebo OpenStack prostředků, ale je to docela mladé (a proto možná zatím riskantní). Variantou je nad infrastrukturou použít framework, který se s dlouhoběžící službou umí velmi dobře vypořádat. Takovým rámcem je rozhodně Mesos (a DCOS) a v nové verzi se k témto vlastnostem přihlásil i Kubernetes. Určitě je to zajímavá varianta, ale cílil bych ji tam, kde takové rámce použijete i pro samotné aplikace. Nemyslím, že problém přenositelnosti služeb pro klasické aplikace je vhodné řešit nasazením Mesos – přidá se tím zbytečná složitost. Jdete do cloud native a potřebujete orchestrovat aplikační kontejnery, Hadoop, MySQL a Cassandru? Mesos a DCOS je vynikající volba.

Platform as a Service (Cloud Foundry)

Cloud Foundry je PaaS, kterou můžete rozjet nad různými IaaS a kromě aplikační přenositelnosti (o tom později) nabízí komerční řešení jako je HPE Helion Stackato něco jako Service Broker, který dokáže pro aplikace zajistit provisioning služeb. Klidně k tomu využije Amazon RDS či vlastnosti OpenStack, ale to už vás trápit nemusí. PaaS přidá abstrakci, kdy stačí o službu požádat a máte ji. Ideální pro moderní aplikace.

Doporučení pro aplikační prostředí

Moje doporučení je jednoznačně začít využívat standardizovanou PaaS Cloud Foundry a spolu s ní automatizovaný provisioning služeb v infrastruktuře (Service Broker). To ale vyžaduje nový přístup k aplikacím, takže přestože je to ideální způsob, jak řešit nové aplikace, ne vždy bude dávat smysl předělávat všechny stávající. Pro ty bych šel rozhodně cestou automatizovaného provisioningu a nestyděl se využít zabudovaných variant typu Amazon RDS. Současně bych ale doporučoval držet širokou nabídku cílových prostředí a kombinoval infrastrukturní orchestraci (HPE CSA, Terraform) s automatickým provisioningem služby (HPE DMA, Chef apod.).

Přenositelnost aplikací

Jak ale přenášet aplikace samotné? Pokud například předpokládají, že databáze běží na stejném stroji, tak se všechno dost komplikuje. Jak je odpoutat od infrastruktury a umožnit tak jejich lepší přenositelnost?

Hexagonální architektura

Rozhodně mi přijde dobré oddělit rozhraní s vnějším světem a službami od samotné byznys logiky. Tedy například nechť GUI není prorostlé s aplikací, ale využívá sadu API (což mimo jiné umožní i automatizaci testování bez poměrně komplikovaného testování “klikáním na webu”). Jednotlivé uživatelské přístupy pak použijí “adaptér”, tedy kód, který je mezi API a uživatelským přístupem – adaptér pro webové GUI, adaptér pro nativní mobilní aplikaci nebo adaptér pro B2B/B2C API. Stejně lze v hexagonálním architektuře přistupovat k datům v databázi. Byznys logika by měla být oddělena od způsobu uložení. Ať se o něj postará adaptér – v protypu to třeba bude psát do CSV souboru, později se přejde na nějakou jednoduchou databázi a nakonec to třeba skončí v Oracle. Podstatné je, že byznys logika žije jinde – adaptér řeší jen formu uložení dat. Díky tomu může aplikace třeba podporovat Amazon DynamoDB, Azure DocumentDB a MongoDB současně. Jako vždy – je to práce navíc, ale i když ze začátku zvolíte jen jednu databázi, je dobré s tím v architektuře počítat.

12-factor a mikroslužby

Vývojáři by měli dodržovat 12-factor pravidla (12factor.net), například nesvazovat aplikační služby napevno (třeba čtením ze stejné DB nebo použitím svazujících platforem typ Weblogic či používáním příliš svázaných technologií typu Enterprise Service Bus nebo binárních API jako je RPC či SOAP). Nechť vládne RESTful a standardizované asynchronní messaging technologie (např. RabbitMQ). 12-factor také mluví o service discovery a dalších důležitých vlastnostech cloud native aplikace.

Kontejnerizace (Docker, Kubernetes, Cloud Foundry)

Píšete modernější aplikaci? Kontejnerizujte. Je to způsob jak k aplikaci přibalit všechny její potřebné návaznosti, knihovny a rámce a jednoduše pak takový objekt přesouvat. O “plnění” kontejneru se vám může postarat Dockerfile, ale pokud chcete něco přívětivějšího pro vývojáře, jděte do Cloud Foundry PaaS. Ta obsahuje buildpacky, které vezmou vaše zdrojáky a podle předpisu vytvoří kontejnery a i je provozují a balancují.

Chef Habitat a jiné balíčkovače (třeba Aptitude nebo RPM)

Další klasické řešení je zapouzdřit aplikace s návaznostmi do balíčkovacího řešení v OS, třeba MSI ve Windows, RPM v CentoOS/RHEL apod. Je to ověřené a funkční, byť aktualizace balíčků mají rizika (v takovém případě je bezpečnější infrastrukturu vždy vytvořit znova, tedy použít blue/green deployment strategii). Novinkou v této oblasti je Chef Habitat. Nazvat ho balíčkovačem je asi nespravedlivé a nemoderní, ale chápu to jako konceptuálně příbuzné.

Deployment přes Configuration management (Chef, Puppet, Ansible, …)

Configuration management nástroje můžete kromě deploymentu aplikačního prostředí použít k instalaci aplikací samotných. Nevýhodou je, že binárky musíte do VM nějak transportovat. Zdá se mi, že řešení obvykle nemají dostatečně pohodlně a bezpečně vyřešené repozitáře pro takové případy, nicméně je to koncept, který funguje spolehlivě.

Service discovery vás odpoutá od infrastruktury (Etcd, Consul, Cloud Foundry)

Aplikace se musí dozvědět o službách, které potřebuje – třeba o API z jiné části aplikačního celku nebo přístupu do databáze. V žádném případě by toto nemělo být součástí kódu a není ani příliš výhodné to dávat do konfiguračních souborů. Lepší je informace zprostředkovat aplikaci při startu přes environmentální proměnné (s tím vám dobře pomůže Cloud Foundry, Docker i Kubernetes). Škálovatelnější variantou je použít dedikované distribuované service discovery, tedy jakýsi globálně přístupný distribuovaný seznam služeb (kde je jaká služba, na jaké IP adrese, jaké verze API, jestli žije apod.) a to obvykle včetně distribuovaného key-value store (tam si můžete uložit různá nastavení). Pokud je vaše aplikace distribuovaný systém (microservices), tak toho rozhodně využije i jinak – například pro implementaci split-brain ochrany, volby mastera, záměčků či garantovaného frontování (v praxi platí – nepokoušejte se nahradit robustní mechanismy distribuovaného konsenzu Paxos či Raft v systémech jako Etcd či Consul nějakým vaším pokusem typu hearthbeat s timeouty…to není pro distribuovaný systém konceptuálně v pořádku a vede k těžko odhalitelným fatálním potížím).

Platform as a Service (Cloud Foundry)

Cloud Foundry dokáže nasazovat a provozovat vaše aplikace cloud native způsobem. Není vhodné pro tradiční architekturu, ale pro moderní cloud native přístup je naprosto ideální. Odstíní vás od nepříjemných detailů na úrovni jednotlivých kontejnerů a nemusíte řešit jak vytvořit image kontejnerů, jak balancovat a směrovat provoz, jak připojovat služby k aplikaci atd. Vezmete zdrojový kód aplikace, řeknete krleš a platforma se postará o zbytek – o build, deployment i provoz. Celou PaaS můžete nainstalovat nad různé IaaS – identické prostředí vám pak běží v OpenStack, vSphere či Amazon. Navíc Cloud Foundry Foundation dává výrobcům certifikaci přenositelnosti – máte tak možnost přesouvat mezi Cloud Foundry PaaS od různých dodavatelů. Podívejte se na HPE Helion Stackato, které můžete rozjet na různými on-premise i cloud prostředími.

Doporučení pro aplikace

Snažil bych se na aplikační vrstvě co nejvíc oprostit od přímého svázaní s infrastrukturou. Využívat přístupu “adaptérů” v hexagonální architektuře, směřovat k dodržování 12-factor a zvážit service discovery. To vám umožní získat lepší přenositelnost a přitom ještě není nutné razantně změnit architekturu (například přechodem na mikroslužby). Tradiční aplikace bych pak nasazoval přes Configuration management případně využil balíčkování. Budoucnost je ovšem v kontejnerizaci a modernější aplikace bych táhnul tímto směrem. Ušetřil bych si hodně práce a zkoumání tím, že bych šel do Cloud Foundry – je to nejrychlejší cesta k modernímu řešení, která je pro vývojáře i velmi pohodlná a návodná.

Přenositelnost dat

Data mají jeden problém – jsou objemná. Jak na jejich přenositelnost?

Pozor na praktickou jednosměrnost public cloudu

Když se data ukládají, jde o postupný dlouhotrvající proces a pokud jde o veřejný cloud, tak za takto přenesená data obvykle neplatíte. Když ale potřebujete stávající data z cloudu vzít a dostat někam jinam, je to horší. Potřebujete najednou celý jejich (typicky dost značný) objem a je to směr, za který ve veřejném cloudu obvykle platíte za přenos. Linky nemají nekonečnou propustnost a náklady jsou značné. Mějte promyšlenou “exit strategii”, než začnete veřejný cloud “plnit”.

Mikroslužby a mikrodata

Jednou z výhodou architektury mikroslužeb je, že každá funkční část aplikace je do značné míry autonomní a to včetně své volby ukládání dat. To na jednu stranu může vyvolat menší přehlednost (každá mikroslužba může mít data v jiném DB systému apod.), ale na straně druhé to snižuje objem každé z nich. To vám dává podstatně víc volnosti. Místo naše data = kolosální Oracle databáze, kde je celá firma, se dostanete do “tohle jsou data jedné mikroslužby v rámci aplikace”. A to je jednodušší na řešení migrace.

Objekty a NoSQL – celoplanetární replikace

Objektová storage a NoSQL databáze jsou typicky scale-out a dovolují vám tak data pružně replikovat mezi různými lokalitami či cloudy. Pokud víte, že data potřebujete na dvou místech současně, je to dobrý způsob. Počítejte ale s tím, že aplikace se musí vypořádat s vlastnostmi eventuální konzistence (BASE), což je pro vývojáře někdy neznámá situace (většinou mají zkušenosti s ACID). Replikace do několika cloudů má také finanční dopady (platby za přenos i použitý prostor), tak to nepřehánějme, ať to dává byznysově smysl.

Tradiční datová vrstva

V tradičním SQL systému není díky jeho ACID vlastnostem vhodné ho příliš roztahovat (latence mají brutální dopad na výkon) a migraci bych tak raději řešil formou exportu a importu dat. Realistické to je zejména v situaci mikroslužeb, kdy objem celé databáze nemusí tak veliký, aby to mělo dopady na praktickou použitelnost takového postupu. V každém případě bych doporučoval postup automatizovat, třeba s HPE DMA+OO nebo použít moderních vývojových prostředků i na práci s SQL daty (dbdeploy.com). Nenapadá mě jak jinak a lépe řešit produkční data (pokud vás ano, napište prosím do komentářů). Jiná věc jsou data pro testování a vývoj. Tam lze použít malých testovacích dat (vytvořte si a verzujte skript pro vytvoření a naplnění DB testovacími daty), existují systémy pro anonymizaci a naplnění dat a v neposlední řadě lze nasadit třeba HPE Service Virtualization, která bude pro účely testování databázový přístup simulovat.

Bloková replikace

Pro dva on-premise cloudy se dá docela dobře použít i infrastrukturní řešení ve formě replikace na poli. Za největší výhodu tady vidím odladěnost, robustnost a jednoduchost něčeho takového. Na druhou stranu přenositelnost tím dobře vyřešena není, pokud mluvíme i o public cloudu. Existují nástroje jak třeba replikovat Amazon ven z public cloudu, ale je to hodně kostrbaté a neefektivní. Další možností je nízkoúrovňové řešení překrýt nějakou abstakcí, třeba clusterovaným souborovým systémem. Pokud klasická aplikace ve skutečnosti nepotřebuje bloky, ale klasický souborový systém, je možné pak něco takového nasadit nad libovolné blokové řešení (v zásadě místo databáze nebo modernější objektové storage použijete souborové řešení). Teoreticky je tu i možnost nasadit softwarově definovanou storage nad jinou blokovou storage, ale nejsem si jist výsledku něčeho takového. Existují dokonce i přístupy, které jako backend mají objektovou storage a objekt ven simulují jako disk. Tam bych se zas bál výkonnostních dopadů. Pokud tedy jdete do on-premise, replikace na úrovni storage pole může být výborná. Pokud preferujete maximální přenositelnost, je lepší to vyřešit o pár úrovní výš.

Doporučení pro data

Je to složité, protože na rozdíl od aplikací jsou data objemnější a jejich přenos náročnější. Doporučoval bych rozdělit ukládání na menší nezávislé kousky a v maximální míře všechno automatizoval. Tam, kde to bude pro aplikaci vhodné, bych šel do eventuálně konzistentních systémů typu NoSQL nebo object store, které vykazují větší míru volnosti.

Kudy do toho?

V první řadě bych doporučoval smířit se s tím, že není jednoduché řešení, které na kliknutí migruje tradiční aplikace mezi cloudy. Přenositelnost není zdarma a dá práci. Klíčem je správně vážit přínosy z přenositelnosti s náklady vzhledem k požadavkům byznysu a dobře si situaci rozmyslet. Nešel bych do jednoho řešení pro celé IT, orientoval bych se podle konkrétních aplikací. Největším artiklem výrobců nechť vám jsou konzultace a jejich zkušenosti, tahle problematika není o prodeji jednoho zázračného part numberu.