SCNET · Kurumsal BT · Ankara, Türkiye

Sanal Çekirdek

Bulut bir yer değil, bir işletim biçimidir.

Bulut mimarisi, sanal makineyi başka bir yerde çalıştırmak değildir. Sanal Çekirdek ağ, kimlik, veri yerleşimi, maliyet görünürlüğü ve işletim modelini tek tasarımda ele alır.

Mimarisi kurulmadan taşınan yükler bulutta daha pahalı ve daha kırılgan çalışır. Kazanç, taşımanın kendisinden değil işletim biçiminin değişmesinden gelir.

Hedef mimari ve yerleşim kararı

Her iş yükü için hedef ortam ayrı belirlenir: bir kısmı yeniden barındırılır, bir kısmı yeniden düzenlenir, bir kısmı yerinde kalır. Karar, uygulamanın durum tutma biçimine, veri sınıfına ve entegrasyon yoğunluğuna bakılarak verilir.

  • Durum tutan bileşenler ayrı ele alınır
  • Yerinde kalacak yükler de kararla belirlenir
  • Aynı uygulamanın katmanları farklı ortamlarda olabilir
  • Karar gerekçesi mimari kayıt defterine yazılır

Ağ, kimlik ve sınırlar

Hibrit mimaride bağlantı ve kimlik, uygulamalardan önce kurulur. Adresleme planı, özel bağlantı, DNS çözümlemesi ve merkezî kimlik kaynağı olmadan taşınan her yük, sonradan sökülmesi zor bir geçici çözümle ayakta durur.

  • Adresleme planı çakışmaları taşımadan önce çözülür
  • Kimlik tek kaynaktan, yetki en az ayrıcalıkla
  • Ortamlar arası trafik açıkça izinlendirilir
  • Yönetim düzlemine erişim ayrı kanaldan

Maliyet görünürlüğü ve FinOps

Bulut maliyeti bir faturayla değil, bir yönetim disipliniyle kontrol edilir. Etiketleme standardı, maliyet sahipliği ve bütçe uyarıları ilk günden kurulur; aksi hâlde harcamanın nereden geldiği ay sonunda aranır.

  • Etiketleme standardı kaynak oluşturmadan önce zorunlu
  • Her harcamanın bir sahibi olur
  • Rezervasyon ve taahhüt kararları ölçümle verilir
  • Kullanılmayan kaynak otomatik işaretlenir

İşletim modeli ve otomasyon

Altyapı elle kurulursa elle bozulur. Kaynaklar kodla tanımlanır, değişiklikler gözden geçirmeden geçer, ortamlar aynı tanımdan üretilir. Bu, hız kadar geri dönebilirlik de sağlar.

  • Kaynak tanımları sürüm kontrolünde tutulur
  • Ortamlar arası fark tanımdan değil, parametreden gelir
  • Değişiklik gözden geçirme kaydı bırakır
  • Geri dönüş, önceki tanımı uygulamakla yapılır

Nasıl çalışırız

  1. İş yükü envanterini ve durum tutma biçimini çıkarın
  2. Hedef ortamı iş yükü bazında kararlaştırın
  3. Ağ, kimlik ve maliyet temelini kurun
  4. Taşımayı dalgalar hâlinde yürütün
  5. İşletim modelini ve otomasyonu devreye alın

Başarı nasıl ölçülür

  • Her iş yükünün hedef ortamı ve gerekçesi yazılı
  • Etiketsiz kaynak oranı sıfıra yaklaşıyor
  • İşaretlenen atıl kaynaklar aynı dönemde kapatılıyor
  • Ortamlar aynı tanımdan üretilebiliyor

Sık sorulan sorular

Her şeyi buluta taşımalı mıyız?

Hayır. Bazı yükler yerinde kalmalıdır; karar iş yükü bazında ve ölçütle verilir. «Hepsi bulut» kararı, «hiçbiri bulut» kadar gerekçesiz olabilir.

Çoklu bulut karmaşıklık getirmez mi?

Getirir. Bu yüzden çoklu bulut bir hedef değil, bir gereksinimin sonucu olmalıdır: düzenleme, tedarikçi riski veya belirli bir servis ihtiyacı. Gerekçe yoksa tek sağlayıcı daha ucuz ve daha sağlamdır.

Maliyet gerçekten düşer mi?

Mimari değişmeden taşınırsa çoğu zaman düşmez. Kazanç; ölçeklenme, kapatılabilirlik ve işletim yükünün azalmasından gelir. Beklenen etkiyi baştan sayıyla koyarız.

Bulut kararını iş yükü bazında vermek isterseniz envanterinizi paylaşın; hedef mimariyi birlikte çıkaralım.

Hedef mimari çalışması isteyin