Každá prezentace hybrid cloud management platform začíná stejně: diagram, kde vlevo stojí vaše on-premise servery, vpravo veřejný cloud a mezi nimi šipka s nápisem migrace. Ta šipka je celý produkt. A je taky důvod, proč většina takových projektů uvázne, protože šipka stojí osmnáct měsíců a hodnota přichází až na jejich konci. Užitečnější otázka zní, co byste dokázali řídit z jednoho místa zítra, aniž byste cokoli přesunuli nebo přepsali.

Hybrid není architektonická volba, kterou by většina týmů udělala záměrně. Je to to, co vám zbude po deseti letech: rack vlastního hardwaru, na kterém pořád běží věc, kterou nejde snadno přesunout, ERP, na které nikdo nechce sáhnout, workloady u hyperscalera, protože si to vyžádal zákazník, levnější compute někde v Evropě, protože si to někdo spočítal, a pár serverů v housingu, které jsou starší než polovina současného týmu. Tohle nikdo nenavrhl. Provozovat to musí všichni.

Proč hybrid obvykle znamená dva týmy

Reálná cena hybridu je organizační. Cloudové zdroje se spravují v prohlížeči přes API tokeny a tagy; fyzické prostředí přes SSH, konfigurační nástroj a paměť pamětníků. Dva toolchainy, dva mentální modely, dvě sady runbooků a obvykle dvě skupiny lidí, které tu druhou popisují slovy ta legacy strana nebo ta drahá strana. Z inventury se stává slučování exportů. Z revize přístupů dvě revize. A incident, který jde přes hranici, se mění v hádku, čí je to problém.

Standardní dodavatelská odpověď zní udělat z jedné strany druhou: nainstalovat na váš hardware private cloud stack, nebo všechno zvednout do veřejného cloudu a mít pokoj. Obojí je legitimní strategie a obojí je obrovské. Sdílí taky předpoklad, který stojí za zpochybnění - že sjednocení musí proběhnout na vrstvě infrastruktury. Nemusí. Většina toho, co tým reálně potřebuje mít sjednocené, leží o patro výš: inventura, přístupy, záznamy o změnách, náklady a schopnost jednat.

Co hybrid cloud management platform dělat nesmí

Hybrid cloud management platform si své místo zaslouží tím, co odmítá vyžadovat. Nesmí vyžadovat, abyste nejdřív přesunuli workload, než začne být užitečná. Nesmí vyžadovat agenta na každém stroji, aby vám ukázala cloudové prostředí, ani cloudový účet, aby vám ukázala vaše racky. Nesmí se stát novou závislostí v kritické cestě - když spadne, vaše systémy běží dál a přijdete o přehled, ne o dostupnost. A nesmí vám držet infrastrukturu jako rukojmí ve vlastním formátu.

Proto jsme Sencai postavili tak, že začíná importem. Připojíte účet u providera se scoped credentials a vaše existující instance, sítě a úložiště se objeví tak, jak jsou, ne jako něco, co musíte znovu vytvořit. Nikdo, kdo hodnotí infrastrukturní platformu, nemá prázdnou infrastrukturu, a produkt, který ukáže hodnotu až potom, co v něm něco znovu postavíte, si vlastní demo zařídil tak, aby propadlo. První session má ukázat vaše prostředí, včetně částí, na které jste tiše zapomněli.

Začněte tím, co už existuje

Na cloudové straně to znamená jedenáct providerů za jedním rozhraním: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode od Akamai a Oracle Cloud. Ne abstrakci nejmenšího společného jmenovatele, která schová všechno zajímavé - sítě, pravidla firewallů a DNS záznamy se zakládají a mění přímo u providera, takže vidíte to, co provider skutečně má, a cokoli nakonfigurujete funguje dál, i kdybyste nás zítra ráno přestali používat.

Na fyzické straně přivádí vaše vlastní servery do stejné inventury hostový agent: stroj ve vlastním racku, v housingové kleci nebo krabice u providera, kterého přímo neintegrujeme. Stojí vedle cloudových zdrojů, ne v oddělené sekci, protože celý smysl je v tom, aby otázka „co provozujeme“ měla jednu odpověď. Pro týmy, jejichž omezení hostovaný control plane vylučují úplně, existuje on-premise edice licencovaná ročně včetně podpory.

Vlastní hardware není legacy, je to volba

V tomhle trhu se lenivě předpokládá, že vlastní hardware je přechodný stav na cestě někam lepší. Někdy je. Často je to ale správná odpověď: předvídatelné těžké workloady, kde si odpisy vlastníte sami, data, která regulace nebo smlouva drží v konkrétní budově, latenční požadavky, které region nesplní, a hardware, který má před sebou roky užitečného života. Když s takovým prostředím zacházíte v nástrojích jako s druhou kategorií, jeho vyřazení tím neurychlíte. Jen ho budete hůř monitorovat.

Jeden control plane nad oběma polovinami mění drobnosti, které se sčítají. Výdaje se sledují napříč providery včetně stropů, takže otázka, kolik stojí dané prostředí, má jednu odpověď místo pěti exportů. Role a pozvánky jsou per organizace, takže revize přístupů je jedna revize. A každá změna, v cloudu i on-premise, přistane ve stejném append-only audit trailu zřetězeném hashem, exportovaném s hashem každého záznamu i jeho předchůdce, aby si auditor mohl posloupnost ověřit nezávisle.

Co vám jeden control plane přinese

Upřímné zarámování je, že nic z tohohle hybrid nezjednoduší. Dva modely hostingu mají pořád dvě charakteristiky selhání, dva nákupní procesy a dvě nákladové struktury a žádné rozhraní to neodstraní. Co to odstraní, je daň, kterou platíte za tu hranici: zdvojené inventury, druhá revize přístupů, incident, u kterého nikdo neumí říct, co v tu chvíli dělala on-premise strana. Tuhle daň platí váš nejmenší tým, průběžně, a je to důvod, proč hybrid působí hůř, než jaký doopravdy je.

Test, který bychom pro jakoukoli hybrid cloud management platform, včetně té naší, postavili, je krátký. Uvidíte všechno, co provozujete, pronajaté i vlastní, v jednom seznamu do hodiny a bez jakékoli migrace? Zjistíte, kdo co změnil minulý měsíc, na obou stranách té hranice? Dostanete odpověď na to, kolik to stojí, aniž byste otevřeli pět konzolí? Pokud ano, je hybrid zase jenom infrastruktura. Pokud ne, nemáte platformu, ale další konzoli.