Altyapınızı başka birinin işletmesine izin vermenin iki yolu var. Birincisinde, bulutu onlardan satın alırsınız: sağlayıcı hesaplarını onlar tutar, faturayı onlar alır, siz ise üzeri kâr eklenmiş bir fatura ve bir destek adresi alırsınız. İkincisinde - genellikle BYOC olarak kısaltılan bring your own cloud - kendi Hetzner, AWS veya OVHcloud hesaplarınızı, kendi sözleşmenizi, kendi faturanızı elinizde tutarsınız ve bir yönetim platformuna, sizin adınıza işletmesi için kapsamlandırılmış credential'lar verirsiniz. İki model bir demoda benzer görünür ve çıkmak istediğiniz gün hiç birbirine benzemez davranır.
Yeniden satış modeli bir dolandırıcılık değil; çoğunlukla tek bir fatura ve şikayet edilecek tek bir yer etrafında gerçek avantajları olan meşru bir iş. Vazgeçtiğiniz şey daha az görünür. Sözleşmesel ilişkiniz sağlayıcıyla değil, satıcıyla; bu yüzden gerçekten uygulayabildiğiniz SLA onlarındır. Taahhütlü kullanım indirimleri, startup kredileri ve müzakere edilmiş fiyatlandırma hepsi onlar üzerinden geçer. Ve resource identity, sunucuların gerçekte yaşadığı hesap, başka birine aittir - bu da ayrılmanın bir iptal değil bir migrasyon olduğu anlamına gelir.
Sözleşmeyi elde tuttuğunuzda ne elde tutarsınız
BYOC altında, sağlayıcı ilişkisi bir avukatın beklediği yerde kalır. Instance'lar sizin hesabınızdadır. Destek ticket'larını açan sizsinizdir. Fatura, finans ekibinizin zaten uzlaştırdığı formatta, zaten durum tespiti yaptığınız bir şirketten, zaten hakkında akıl yürüttüğünüz bir yargı bölgesi altında gelir. Uyum duruşunuz bir servisi kimin yasal olarak işlettiğine bağlıysa - ki Schrems II'den sonra ilginç soru budur, sunucuların fiziksel olarak nerede oturduğu değil - bir control plane benimseyerek o zincire bir halka eklememişsinizdir.
Çıkış testi farkı somutlaştırır. Yönetim platformu bir gecede ortadan kaybolsa ne olur? Yeniden satış altında, sunucularınız kontrol etmediğiniz bir hesaptadır ve cevap avukatları içerir. BYOC altında, sunucular tam olarak oldukları gibi çalışmaya devam eder; bir konsol, bir envanter ve bir miktar otomasyon kaybetmişsinizdir - ki bu varoluşsal değil sinir bozucudur. Bu asimetri herhangi bir özellik listesinden daha değerlidir ve herhangi bir şey imzalamadan önce kontrol edilecek ilk şeydir.
BYOC'ın platformdan talep ettiği şey
Modelin bedeli, platformun artık sahibi olmadığı hesaplar için gerçek üretim credential'larını tutmasıdır. Bu yükümlülük harfiyen ele alınmalıdır. Credential'lar AES-256-GCM ile rest'te şifrelenir, tek bir organizasyona kapsamlandırılır, tenant'lar arasında asla paylaşılmaz ve bir API yanıtında asla döndürülmez - alanlar hem girişte şifreli hem de çıkışta private'dır. Bunların her biri, sıradan bir list endpoint'inden bir credential kaydını serialize etmesi istendiği ilk anda ilginçleşen sıkıcı bir gereksinimdir.
Sonra kimsenin planlamadığı arıza modu var. Bir provisioning job'u, hiçbir credential eklenmeden gelir: bir bug, bir race, bir servisin daha eski bir versiyonundan bir mesaj. Cazip olan davranış, job'un başarılı olması için platformun kendi sağlayıcı token'ına geri düşmektir. Bu davranışı bir kez shipledik ve tam olarak yapacağı şeyi yaptı - platformun kendi hesabında gerçek bir makine oluşturdu, yanlış tarafa faturalandı, müşterinin envanterinde görünmezdi. Varsayılan artık fail-closed'dır. Credential'sız bir job reddedilir ve fallback'i etkinleştirmek açık bir environment flag'i gerektirir.
Çoklu sağlayıcılı BYOC'ın zorlaştığı yer
Bir sağlayıcı bir entegrasyondur; on bir sağlayıcı ise bir taksonomi problemidir. Sencai şu anda Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai'nin Linode'u ve Oracle Cloud'u, artı bir host ajanı aracılığıyla on-premise ve bare-metal sunucuları yönetiyor. Bunların her birinin kendi kimlik doğrulama modeli, kendi kota sistemi, kendi kelime dağarcığı ve bir firewall'un bir makineye mi, bir network'e mi yoksa bir projeye mi ait olduğu konusunda kendi görüşü var. Bunu, yalan söylemeden normalize etmek mühendisliğin büyük kısmı.
Tutmaya çalıştığımız çizgi, control plane'in sağlayıcının bir kopyasını değil sağlayıcının kendisini işletmesidir. Sencai'de bir network, bir firewall kuralı veya bir DNS zone oluşturduğunuzda, çağrı sağlayıcının API'sine gider ve nesne orada var olur - onların konsolunda görünür, onların CLI'ıyla silinebilir, bizi hiç duymamış herhangi biri için gerçektir. Niyeti yalnızca kendi veritabanına kaydeden bir platform, var olmayabilecek şeylerin çok inandırıcı bir envanterini üretir.
Faturalama aynı mantığı takip eder. Fatura sağlayıcıda kaldığı için, platformun işi sizi faturalandırmak değildir. İşi atıf ve kontroldür. Harcama, sizin belirlediğiniz limitlerle birlikte, bağlı her hesap genelinde organizasyon ve proje başına izlenir - böylece "batch pipeline geçen ay ne kadara mal oldu" sorusunun dört formatta dört export yerine tek bir cevabı olur. Bu aynı zamanda BYOC'ın yeniden satıştan gerçekten daha zor kıldığı bölümdür, çünkü okunacak tek bir defter yoktur; rakamların sağlayıcı başına çekilmesi ve uzlaştırılması gerekir.
Bring your own cloud kimin için
BYOC, zaten var olan bir varlığı ve zaten gerçek olan kısıtları olan ekiplere uyar: üç yıl boyunca birikmiş birkaç yüz makine, bir müşterinin tedarik ekibinden bir yargı bölgesi gereksinimi, tasarlanmak yerine kendiliğinden oluşmuş bir sağlayıcı karışımı. Greenfield iseniz, tam olarak tek bir fatura istiyorsanız ve herhangi bir şeyin nerede çalıştığı konusunda hiçbir fikriniz yoksa daha az uyar. Bir satıcı veya tek bir hyperscaler daha basit olacaktır ve daha basit olanı almalısınız. Kimsenin tek bir hesap ve on bir sunucu için bir multi-cloud control plane'ine ihtiyacı yok.
BYOC altında iki şey keskinleşir ve iyi niyetler yerine kasıtlı bir tasarımı hak eder. Birincisi izolasyon: credential'lar bir organizasyona aittir, üyelik davetle gerçekleşir ve roller kimin para harcayabileceğine veya bir firewall'a dokunabileceğine karar verir - çünkü buradaki blast radius bir sandbox değil gerçek bir üretim hesabıdır. İkincisi denetim izi. Platformun sizin adınıza aldığı her eylem, actor, kaynak ve bir correlation ID ile birlikte, export edebileceğiniz bir formda, yalnızca-ekleme olarak kaydedilmelidir. Operasyonları devrediyorsunuz, bu yüzden o operasyonların kaydı, onları kendiniz yapmış olmak yerine elinizde olan şeydir.
Yani, size bring your own cloud satan herkese sormaya değer sorular. Sağlayıcı sözleşmesinde kimin adı var? Devrettiğiniz credential tam olarak ne yapabilir ve onun kapsamını daraltabilir misiniz? Yarın onlara ödeme yapmayı bırakırsanız çalışan altyapıya ne olur? Hesaplarınızın içinde yaptıkları her şeyin log'unu export edip bağımsız olarak kontrol edebilir misiniz? Bu dördüne verilen iyi cevaplar, operasyonlarınızı dışarıya vermeyi altyapınızı dışarıya vermekten ayıran şeydir - ve bunlardan sadece biri bir Salı günü geri alınabilir.