Hver eneste hybrid cloud management-plattform-pitch starter på samme sted: et diagram med on-premise-serverne dine til venstre, en offentlig sky til høyre, og en pil mellom dem merket migrering. Pilen er produktet. Den er også grunnen til at de fleste av disse prosjektene stopper opp, fordi pilen koster atten måneder og verdien kommer først til slutt. Det mer nyttige spørsmålet er hva du kunne administrert fra ett sted i morgen, uten at noe flyttes eller skrives om.
Hybrid er ikke et arkitekturvalg de fleste team tok med vilje. Det er det man sitter igjen med etter et tiår: et rack med egen maskinvare som fortsatt kjører det ingen enkelt kan flytte, et ERP-system ingen vil røre, arbeidslaster hos en hyperscaler fordi en kunde ba om det, billigere compute et europeisk sted fordi noen regnet på det, og noen servere i et colocation-anlegg som er eldre enn halve dagens team. Ingen designet dette. Alle må drifte det.
Hvorfor hybrid som regel betyr to team
Den praktiske kostnaden ved hybrid er organisatorisk. Sky-ressurser administreres i en nettleser med API-tokens og tagger; den fysiske infrastrukturen administreres med SSH, et konfigurasjonsverktøy og institusjonell hukommelse. To verktøykjeder, to mentale modeller, to sett med runbooks, og som regel to grupper mennesker som omtaler hverandres arbeid som «legacy-siden» eller «den dyre siden». Inventar blir en sammenslåing av eksporter. Tilgangsgjennomgang blir to tilgangsgjennomganger. Hendelser som krysser grensen blir en diskusjon om hvem sitt problem det er.
Standardsvaret fra leverandørene er å få den ene siden til å ligne den andre: installere en privat sky-stack på maskinvaren din, eller løfte alt inn i den offentlige skyen og bli ferdig med det. Begge er legitime strategier, og begge er enorme. De deler også en antakelse verdt å utfordre - at enhet må skje på infrastrukturlaget. Det trenger den ikke. Det meste et team faktisk trenger samlet, ligger én etasje høyere: inventar, tilgang, endringslogg, kostnad, og evnen til å handle.
Hva en hybrid cloud management-plattform ikke må gjøre
En hybrid cloud management-plattform fortjener sin plass gjennom det den nekter å kreve. Den må ikke kreve at du flytter en arbeidslast før den blir nyttig. Den må ikke kreve en agent på hver eneste maskin for å vise deg sky-infrastrukturen din, eller en sky-konto for å vise deg rackene dine. Den må ikke bli en ny avhengighet i den kritiske stien din - hvis den går ned, fortsetter systemene dine å kjøre, og du mister synlighet, ikke tilgjengelighet. Og den må ikke holde infrastrukturen din som gissel i sitt eget format.
Det er derfor vi bygde Sencai import-først. Du kobler til en leverandørkonto med avgrensede credentials, og de eksisterende instansene, nettverkene og lagringen din dukker opp slik de er, ikke som noe du må gjenskape. Ingen som evaluerer en infrastrukturplattform har tom infrastruktur, og et produkt som først viser verdi når du har bygget opp noe på nytt inni det, har i praksis arrangert sin egen demo til å mislykkes. Den første økten bør vise deg infrastrukturen din, inkludert delene du stille hadde glemt.
Start med det som allerede finnes
På sky-siden betyr det elleve leverandører bak ett grensesnitt: Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode og Oracle Cloud. Ikke en laveste-fellesnevner-abstraksjon som skjuler alt det interessante - nettverk, brannmurregler og DNS-oppføringer opprettes og endres hos leverandøren selv, så det du ser er det leverandøren faktisk har, og alt du konfigurerer fortsetter å fungere hvis du slutter å bruke oss i morgen tidlig.
På den fysiske siden bringer en host-agent dine egne servere inn i det samme inventaret: en maskin i ditt eget rack, i et colocation-bur, eller en boks hos en leverandør vi ikke integrerer direkte med. Den ligger side om side med sky-ressursene fremfor i en egen seksjon, fordi hele poenget er at «hva kjører vi» skal ha ett svar. For team hvis begrensninger utelukker en hostet kontrollplan helt, finnes det en on-premise-utgave lisensiert årlig med support.
Den on-premise halvparten er ikke legacy
Det finnes en lat antakelse i dette markedet om at eid maskinvare er en overgangstilstand på vei mot noe bedre. Noen ganger er det det. Ofte er det riktig svar: forutsigbare tunge arbeidslaster der du selv eier avskrivningen, data som regulering eller kontrakt holder innenfor en bestemt bygning, ventetidskrav en region ikke kan innfri, og maskinvare med mange gjenværende brukbare år. Å behandle den infrastrukturen som annenrangs i verktøyene dine akselererer ikke pensjoneringen. Det betyr bare at den overvåkes dårligere.
Én kontrollplan over begge halvdelene endrer små ting som legger seg opp. Forbruk spores på tvers av leverandører med tak, så spørsmålet om hva et miljø koster har ett svar i stedet for fem eksporter. Roller og invitasjoner er per organisasjon, så tilgangsgjennomgang er én gjennomgang. Og hver endring, sky og on-premise likt, havner i det samme append-only, hash-kjedede revisjonssporet, eksportert med hver oppførings hash og forgjengerens, slik at en revisor kan verifisere rekkefølgen uavhengig.
Hva én kontrollplan gir deg
Den ærlige innrammingen er at ingenting av dette gjør hybrid enkelt. To hostingmodeller har fortsatt to feilkarakteristikker, to innkjøpsprosesser og to kostnadsstrukturer, og ingen grensesnitt fjerner det. Det som fjernes er skatten du betaler for grensen: de duplikate inventarene, den andre tilgangsgjennomgangen, hendelsen der ingen kan si hva on-premise-siden gjorde på det tidspunktet. Den skatten betales av det minste teamet ditt, kontinuerlig, og det er derfor hybrid føles verre enn det faktisk er.
Så testen vi ville satt for enhver hybrid cloud management-plattform, vår inkludert, er kort. Kan du se alt du kjører, leid og eid, i én liste, innen en time, uten å migrere noe? Kan du si hvem som endret hva forrige måned, på begge sider av grensen? Kan du svare på hva dette koster uten å åpne fem konsoller? Hvis ja, er hybrid bare infrastruktur igjen. Hvis nei, har du ikke en plattform - du har enda en konsoll.