Cloud i hardware, který už vlastníte, jedna řídicí vrstva
Většina infrastrukturních platforem bere on-premise jako speciální případ přišroubovaný k produktu postavenému primárně na cloudu - samostatný agent, samostatná obrazovka, horší zážitek. Sencai to postavila obráceně: fleet agent se chová identicky na cloudové instanci i na serveru stojícím ve vašem vlastním racku, a zapojení se nikdy neptá, jestli má stroj cloudový účet, protože spousta reálné infrastruktury ho nemá. Ať provozujete vlastní hardware vedle cloudové kapacity, úplně místo ní, nebo někde mezi tím, platí stejná řídicí vrstva, stejná auditní stopa a stejné runbooky všude.
Stejný agent na každém linuxovém boxu
Nainstalujte fleet agenta na linuxový server - cloudovou instanci nebo fyzický stroj ve vlastním racku - a chová se úplně stejně bez ohledu na to, kde ten server skutečně sídlí. Průběžný monitoring, správa patchů, inventura softwaru a automatizace runbooků, to všechno běží přes identického agenta, s identickou bránou schválení dřív, než se cokoliv spustí. Napište postup pro reakci na incident jednou, jako runbook, a spusťte ho dnes proti VM na Scaleway a příští týden proti colocated bare-metal boxu, aniž byste se dotkli samotného postupu - agent nemění chování podle toho, na čem zrovna sedí. Samostatný, účelově postavený agent řeší Kubernetes: nainstalujte ho in-cluster a hlásí inventuru a umožní spravovat ten cluster ze stejného dashboardu jako všechno ostatní, cloudové nebo on-premise. Ani jeden agent se neptá, který provider - nebo jestli vůbec nějaký provider je - dřív, než začne hlásit. Dostanete jeden download, jeden instalační proces, jedno místo, kam se dívat, ať už to nasazujete napříč flotilou cloudových instancí, nebo hrstkou serverů pod stolem.
Bez nutnosti cloud účtu na začátek
Zapojení serveru nevyžaduje jeho propojení s účtem u cloud providera, protože spousta on-premise hardwaru žádný nemá. Rackový server, colocated box, starý pracovní stroj povolaný do služby jako build stroj - každý se zapojí přímo, samostatně, bez jediného cloudového přihlašovacího údaje kdekoliv v procesu. Cloudem propojené instance a samostatný hardware pak stojí ve stejném pohledu na flotilu: filtrovatelné, otagovatelné, spravované přes identickou sadu obrazovek a runbooků. To je záměrné návrhové rozhodnutí, ne přehlédnutí - platforma nepředpokládá, že každý spravovaný server vede zpátky k cloudovému účtu, protože spousta reálné infrastruktury nikdy vést nebude. Pokud je vaše prostředí dnes celé on-premise, bez jediného připojeného cloudového účtu, fleet agent, auditní log, patchování i automatizace runbooků fungují úplně stejně, jako by fungovaly pro tým provozující čistě cloud u hyperscaleru. Hybridní provoz není speciální režim přišroubovaný navrch - je to výchozí předpoklad, kolem kterého byla platforma postavena.
Cloudové účty se připojují - nic se nemigruje
Pro cloudovou stranu hybridního prostředí se Sencai připojuje k účtům, které už máte, napříč jedenácti providery - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode a Oracle Cloud. Při připojení se nic nemigruje. Účet, smlouva i faktura zůstávají přesně tam, kde už u providera jsou; Sencai drží šifrovaný přihlašovací údaj a nic víc, a tenhle přístup můžete u providera kdykoliv odvolat, okamžitě, bez kontaktování kohokoliv tady. Ve chvíli, kdy se účet připojí, jeho instance, sítě, úložné svazky a DNS zóny se automaticky objeví v inventuře - žádný migrační krok, žádné vynucené přebírání, žádné čekání na servisní okno. Odtud je to zdroj po zdroji: vy rozhodujete, co se dostane pod aktivní správu a co zatím zůstane jako záznam v inventuře jen pro čtení. Podívejte se na stránky integrací - počínaje Hetznerem - na to, co dnes každý připojený provider podporuje.
Nebo nechte cloudovou smlouvu na Sencai
Pokud nechcete držet samostatnou smlouvu s každým providerem, kterého se dotýkáte, může Sencai provisionovat a fakturovat cloudovou kapacitu pod svými vlastními účty vaším jménem. To je jedna smlouva a jedna faktura místo mnoha, s vlastní cenou providera přeposlanou dál plus 2% marží, uvedenou jako vlastní položka na výpisu - nikdy neviditelně zahrnutou do většího čísla. Oba modely nejsou rozcestí, které si vyberete jednou a s tím žijete. Jedna organizace může provozovat BYOC účty pro infrastrukturu, kterou už má, a přidat kapacitu spravovanou Sencai pro cokoliv dalšího, nebo začít spravovaně a existující BYOC účty přidat později - oba stojí ve stejné inventuře, pod stejnými politikami, bez rozdělení prostředí mezi dva nástroje nebo dvě auditní stopy. Kombinujte to s on-premise hardwarem zapojeným přímo, a jedna organizace může legitimně pokrývat vlastní racky, BYOC účet AWS založený před lety a kapacitu, kterou Sencai dnes provisionuje a fakturuje, aniž by si kdokoliv musel pamatovat, co je co, když otevře dashboard.
Jedna inventura, jedna politika, ať hardware stojí kdekoliv
Cloudové instance, on-premise servery i Kubernetes clustery přistanou ve stejné inventuře, pod stejným řízením přístupu na základě rolí, stejným jednotným přihlášením - Microsoft Entra ID nebo Google Workspace, se SCIM provisioningem pro oba - a stejným workflow just-in-time elevace pro kohokoliv, kdo potřebuje dočasný zvýšený přístup se schválením. Neexistuje samostatná konzole pro prostředí datacentra a žádné druhé přihlášení pro tým spravující fyzický hardware. Bezpečnostní prověrka nebo interní audit přístupu nepotřebuje jinou odpověď pro servery v colocation zařízení než pro instance v cloudovém regionu - je to stejná flotila, stejné role, stejná stopa schválení, zeptáno a zodpovězeno jednou. Viz bezpečnost a compliance pro to, jak tenhle model přístupu obstojí při prověrce. Pro tým provozující hybridní model konkrétně proto, že některé workloady nesmí opustit konkrétní budovu, na tomhle konzistenci záleží stejně jako na samotném pokrytí: politika se tiše neuvolní na okraji sítě, kam cloudová konzole nevidí.
Auditní stopa, která se nezastaví na hranici cloudu
Každá akce napříč flotilou - cloudová nebo on-premise - se zapíše do stejného pouze přidávaného, hash-řetězeného auditního logu. Kdo minulé úterý patchoval rackový server, kdo ve dvě ráno spustil runbook proti bare-metal boxu, kdo se dotkl pravidla firewallu na cloudové instanci: je to dotaz do jednoho logu, ne rekonstrukční projekt poskládaný z hypervizoru, ticketového systému a něčí paměti. Sencai nemá certifikaci ISO 27001 ani SOC 2 a otevřeně to říká, místo aby to naznačovala jinak. Bezpečnostnímu hodnotiteli místo toho předá evidenci, za kterou tyhle certifikace obvykle stojí jako náhrada: exportovatelnou auditní stopu, záznamy o zpracování, zveřejněný registr subdodavatelů, prohlášení o rezidenci dat a zveřejněnou smlouvu o zpracování osobních údajů. Pro tým, který drží určité workloady on-premise konkrétně kvůli rezidenci dat, je tahle evidence - v kombinaci s provozem podle práva EU, od společnosti se sídlem v Praze - často blíž tomu, co se prověrka skutečně snaží zjistit, než certifikát pokrývající infrastrukturu, kde citlivý workload stejně nesídlí.
Přineste hardware, který už máte
Zapojte server přímo nebo připojte cloudový účet - oba přistanou ve stejné inventuře ve chvíli připojení, bez migrace a bez vynuceného přebírání. Bezplatný tarif pokrývá 1 uživatele, 1 organizaci a 5 spravovaných zdrojů bez nutnosti karty, a placené tarify organizace začínají na 299 EUR/měsíc (viz [ceník](/pricing/)) s 14denní plně funkční zkušební verzí, která taky nepotřebuje kartu.