Google Cloud Hizmetleri ile Kurumsal Altyapı Entegrasyonu

Bir şirketin Google Cloud kullanmaya başlaması, birkaç sanal makine oluşturup uygulamaları internete açmaktan çok daha fazlasıdır. Sağlıklı bir kurumsal geçişte kimlik yönetimi, ağ bağlantıları, veri akışı, güvenlik politikaları, uygulama entegrasyonu, izleme, maliyet kontrolü ve felaket kurtarma aynı mimarinin parçaları olarak ele alınır. Özellikle şirket içi veri merkezi kullanılmaya devam ediyorsa, Google Cloud kurumsal altyapıya nasıl entegre edilir sorusunun cevabı tek bir servis seçmekten değil, bütün sistemlerin birlikte nasıl çalışacağını tasarlamaktan geçer. Yaklaşık on yıllık altyapı ve bulut projelerinde gördüğüm en önemli konu şudur: En başarılı projeler önce temel mimariyi kurar, ardından workload taşımaya başlar. Bu rehberde Google Cloud Hizmetleri ile Kurumsal Altyapı Entegrasyonu sürecini kimlikten ağa, Kubernetes'ten veritabanına, güvenlikten monitoring mimarisine kadar uçtan uca ele alacağız.

Google Cloud ile Kurumsal Altyapı Entegrasyonu Nedir?

Kurumsal entegrasyon, mevcut BT altyapısının Google Cloud kaynaklarıyla güvenli, yönetilebilir ve sürdürülebilir biçimde birlikte çalışmasını sağlar. Burada amaç tüm sistemleri bir gecede buluta taşımak değildir. Şirket içindeki uygulamalar, veri tabanları, kullanıcı hesapları ve ağ servisleri belirli bir geçiş planı kapsamında Google Cloud servisleriyle bir araya getirilir. Böylece işletme mevcut yatırımlarını korurken ihtiyaç duyduğu alanlarda bulut servislerinden yararlanabilir. Doğru yaklaşım, teknik ekiplerin farklı platformları tek bir operasyon modeli içerisinde yönetebilmesine yardımcı olur.

Kurumsal Altyapı Entegrasyonu Kavramı

Kurumsal altyapı entegrasyonunu iki veri merkezini birbirine bağlamak şeklinde düşünmek eksik olur. Entegrasyon ağı, kullanıcı kimliklerini, uygulamaları, veri akışlarını, logları, güvenlik politikalarını ve operasyon süreçlerini kapsar. Örneğin şirket içindeki bir ERP uygulaması Google Cloud üzerinde çalışan bir API servisine erişebilir, aynı zamanda kullanıcılar merkezi kimlik sistemi üzerinden yetkilendirilebilir. Loglar ortak bir merkezi projede toplanabilir ve güvenlik ekipleri olayları aynı ekran üzerinden inceleyebilir. Bu yaklaşım, birbirinden kopuk servisler yerine yönetilebilir bir kurumsal platform oluşturur.

Cloud Adoption ile Cloud Migration Arasındaki Fark

Cloud migration mevcut bir workload'un fiziksel sunucudan veya başka bir ortamdan buluta taşınmasını ifade eder. Cloud adoption ise daha geniştir ve şirketin geliştirme, operasyon, güvenlik, finans ve yönetişim süreçlerini bulut modeline uyarlamasını kapsar. Bir uygulamayı Compute Engine üzerine taşımak migration örneğidir. Buna karşılık projelerin Terraform ile oluşturulması, merkezi IAM politikalarının uygulanması ve maliyetlerin ekip bazında takip edilmesi adoption sürecinin parçalarıdır. Kurumsal projelerde yalnızca migration düşünülürse teknik borç yeni ortama taşınmış olur.

Hybrid Cloud Nedir?

Hybrid cloud modelinde şirket içi altyapı ile Google Cloud birlikte çalışır. Bazı uygulamalar veri merkezinde kalırken yeni servisler bulut tarafında çalışabilir. İki ortam arasında Cloud VPN veya daha yüksek kapasite gereksinimlerinde Cloud Interconnect gibi bağlantılar kurulabilir. DNS, routing ve kimlik yapısının iki tarafta tutarlı olması kullanıcı deneyimi açısından önemlidir. Şirket içi sistemler Google Cloud ile nasıl entegre edilir sorusunda en sık karşılaşılan model bu hibrit yapıdır.

Multi-Cloud Nedir?

Multi-cloud yaklaşımı bir kurumun birden fazla bulut platformunu aynı BT stratejisi içerisinde kullanmasını ifade eder. Bunun nedeni belirli servis ihtiyaçları, bölgesel gereksinimler, satın alma kararları veya mevcut yatırımlar olabilir. Böyle bir yapıda kimlik, network, observability ve maliyet yönetiminin merkezi standartlara bağlanması gerekir. Aksi durumda ekipler her ortam için farklı operasyon süreçleri yürütmek zorunda kalır. Multi-cloud tercih ediliyorsa teknik standartların platformdan bağımsız tanımlanması uzun vadede önemli avantaj sağlar.

Kurumsal Entegrasyonun Temel Katmanları

Kurumsal entegrasyonu yedi temel katmanda ele almak pratik bir yöntemdir. Identity kullanıcıların ve servislerin kim olduğunu belirlerken network hangi kaynakların birbirine ulaşabileceğini kontrol eder. Compute uygulamaların çalıştığı ortamı, data ise kurumsal verinin depolanmasını ve hareketini kapsar. Application katmanı API, event ve entegrasyon akışlarını düzenlerken security bütün katmanlara uygulanır. Operations katmanı da monitoring, logging, incident management, maliyet ve kapasite yönetimini bir araya getirir.

Identity

Identity tasarımı insan kullanıcıları, servis hesaplarını ve workload kimliklerini birbirinden ayırmalıdır. Yetkilendirme mümkün olduğunca grup ve rol bazlı yapılmalıdır. Kalıcı yönetici izinleri yerine görev süresince verilen erişimler tercih edilebilir. Uzun ömürlü anahtarların kullanımını azaltmak güvenlik riskini ciddi biçimde düşürür. Kimlik yapısı kurulmadan workload taşımaya başlamak ileride geniş çaplı yetki düzenlemelerine neden olabilir.

Network

Network katmanı VPC, subnet, routing, firewall, DNS, NAT ve hibrit bağlantıları kapsar. IP aralıklarının şirket içi ağlarla çakışmaması daha proje başlamadan kontrol edilmelidir. Production, test ve geliştirme ortamları arasında ağ sınırları belirlenmelidir. Kritik bağlantılarda yedeklilik tek cihaz veya tek tünel bağımlılığını azaltır. Network tasarımı uygulamaların sonraki yıllarda nasıl büyüyebileceği düşünülerek yapılmalıdır.

Compute

Compute seçimi her workload için aynı olmamalıdır. Eski bir sanal makine Compute Engine üzerinde çalıştırılabilirken stateless bir API Cloud Run üzerinde daha rahat yönetilebilir. Container tabanlı karmaşık uygulamalar için GKE değerlendirilebilir. Yönetilen servisler operasyon yükünü azaltırken sanal makineler daha fazla kontrol sağlar. Bu nedenle platform seçimi uygulamanın teknik gereksinimine göre yapılmalıdır.

Data

Veri katmanında yalnızca hangi veritabanının kullanılacağına karar verilmez. Veri sınıflandırması, şifreleme, yedekleme, erişim kontrolü, retention ve bölge seçimi birlikte düşünülür. Online transaction sistemleri ile analitik sistemlerin ihtiyaçları farklıdır. Veri göçü sırasında tutarlılık ve geri dönüş planı ayrıca test edilmelidir. Hassas verilerin buluta taşınması öncesinde kurumun hukuki ve operasyonel gereksinimleri değerlendirilmelidir.

Application

Application katmanı şirket içi uygulamalar ile bulut servisleri arasındaki iletişimi düzenler. Doğrudan veritabanı bağlantıları yerine mümkün olduğunda API veya event tabanlı modeller tercih edilebilir. Böylece sistemler birbirine daha az bağımlı hale gelir. Pub/Sub, Workflows ve Application Integration farklı entegrasyon senaryolarında kullanılabilir. Tasarım sırasında hata yönetimi, retry ve idempotency gibi operasyonel ayrıntılar unutulmamalıdır.

Security

Güvenlik ayrı bir proje fazı olmamalıdır. IAM, Organization Policy, firewall kuralları, loglama ve veri koruma ilk günden uygulanmalıdır. Production sistemlerinin gereksiz public IP kullanması önlenebilir. Hassas kaynaklara erişim mümkün olduğunca private bağlantılar üzerinden sağlanabilir. Güvenlik politikalarının Infrastructure as Code süreçlerine eklenmesi manuel hataların azaltılmasına yardımcı olur.

Operations

Operations katmanı sistemin production ortamında nasıl yaşayacağını belirler. Monitoring yalnızca CPU kullanımını izlemek değildir. Uygulama hataları, latency, bağlantı durumu, maliyet, backup başarısı ve güvenlik olayları da izlenmelidir. Ekiplerin hangi alarmı kimin yöneteceği konusunda açık sorumlulukları olması gerekir. Sağlıklı operasyon modeli olmayan güçlü bir teknik mimari kısa sürede yönetilmesi zor bir yapıya dönüşebilir.

Kurumlar Neden Google Cloud Kullanıyor?

Kurumların Google Cloud tercihleri genellikle tek bir özelliğe dayanmaz. Ölçeklenebilir altyapı, yönetilen veri servisleri, Kubernetes desteği, global bağlantı modeli ve güvenlik servisleri birlikte değerlendirildiğinde kurumsal platform oluşturmak için kapsamlı seçenekler sunar. Bununla birlikte her servisi kullanmak doğru mimari anlamına gelmez. Ben projelerde servis seçimini mümkün olduğunca iş gereksinimine bağlamayı tercih ediyorum. Çünkü kullanılmayan veya gereğinden büyük tasarlanan her servis zamanla maliyet ve operasyon yükü oluşturur.

Ölçeklenebilirlik

Google Cloud kaynakları talebe göre büyütülebilir veya küçültülebilir. Bu özellik özellikle değişken trafik alan uygulamalarda kapasite planlamasını kolaylaştırır. Autoscaling doğru kullanıldığında gereksiz kaynak tüketimini azaltabilir. Ancak her sistem yatay ölçeklemeye uygun değildir. Uygulama mimarisi ölçekleme modeline uygun hale getirilmeden yalnızca altyapı kapasitesini artırmak beklenen verimi sağlamayabilir.

Yönetilen Servisler

Yönetilen servisler işletim sistemi, patch, yüksek erişilebilirlik veya kapasite yönetiminin bir bölümünü servis sağlayıcıya bırakır. Bu sayede ekipler daha fazla uygulama ve iş ihtiyacına odaklanabilir. Cloud SQL, GKE ve Cloud Run gibi servisler farklı düzeylerde yönetilen çalışma modelleri sunar. Bunun karşılığında servis sınırlarının ve fiyatlandırmanın iyi anlaşılması gerekir. Yönetilen servis seçimi teknik fayda kadar operasyonel beceri setiyle de değerlendirilmelidir.

Global Network

Google Cloud network yapısı farklı bölgelerdeki sistemlerin merkezi tasarım ilkeleriyle bağlanmasına imkân verir. Global VPC yaklaşımı birçok kurumsal network senaryosunu daha sade hale getirebilir. Buna rağmen subnet ve IP planlaması bölgesel ihtiyaçlara göre yapılmalıdır. Kritik sistemlerde bağlantı yedekliliği ve trafik yolları önceden test edilmelidir. Network mimarisi yalnızca bugünkü lokasyonlara göre değil gelecekteki büyümeye göre planlanmalıdır.

Veri Analitiği

Kurumsal verinin farklı kaynaklardan bir araya getirilmesi karar süreçlerini hızlandırabilir. BigQuery gibi analitik servisler büyük veri kümeleri üzerinde sorgulama yapılmasını sağlar. Şirket içi kaynaklardan gelen veriler batch veya streaming yöntemleriyle aktarılabilir. Bununla birlikte veri kalitesi, sahiplik ve erişim kontrolü teknik platformdan bağımsız olarak çözülmesi gereken konulardır. İyi analitik mimarisi güçlü sorgu motorundan önce güvenilir veri akışı gerektirir.

Yapay Zeka ve Vertex AI

Vertex AI, model geliştirme ve kurumsal yapay zeka kullanım senaryoları için yönetilen araçlar sağlar. Kurumsal projelerde asıl konu modeli çalıştırmaktan çok modelin hangi veriye, hangi kimlikle ve hangi sınırlar içinde erişeceğini belirlemektir. RAG tabanlı çözümlerde kaynak verinin doğruluğu ve erişim kontrolü özellikle önemlidir. Model endpoint'lerinin private network üzerinden sunulması bazı projelerde gerekli olabilir. AI sistemlerini mevcut IAM ve audit modelinin dışında bırakmamak gerekir.

Kubernetes ve GKE

GKE, container tabanlı uygulamaların kurumsal ölçekte yönetilmesi için güçlü bir seçenek sunar. Ancak Kubernetes kullanmak her uygulama için zorunlu değildir. Çok sayıda mikroservis, farklı deployment süreçleri ve platform ekipleri bulunan yapılarda avantajı artar. Daha küçük servislerde Cloud Run operasyon açısından daha basit olabilir. Container mimarisini öğrenmek isteyenler için https://www.diyarbakiryazilim.com.tr/posts/docker-ile-izole-edilmis-gelistirme-ve-dagitim-ortamlari adresindeki içerik de temel kavramları anlamaya yardımcı olabilir.

Hybrid ve Multi-Cloud

Kurumların tamamı bütün workload'larını aynı platforma taşımaz. Bazı sistemler veri merkezinde kalırken yeni uygulamalar Google Cloud üzerinde çalışabilir. Bu nedenle hibrit bağlantı, merkezi kimlik ve ortak observability tasarımı önem kazanır. Multi-cloud ortamlarında Terraform ve OpenTelemetry gibi ortak standartlar operasyon modelini sadeleştirebilir. Hedef her platformu aynı hale getirmek değil, ekiplerin ortak kurallarla çalışmasını sağlamaktır.

Güvenlik ve Governance

Kurumsal Google Cloud ortamında governance Resource Hierarchy, IAM ve Organization Policy ile başlar. Proje oluşturma, region seçimi, external IP kullanımı ve servis hesapları merkezi standartlarla sınırlandırılabilir. Güvenlik ekiplerinin her kaynağı manuel incelemesi ölçeklenebilir bir yöntem değildir. Bu nedenle kontrol mekanizmalarının mümkün olduğunca otomasyona taşınması gerekir. Governance geliştirici ekipleri yavaşlatmak yerine güvenli bir self-service modeli oluşturmalıdır.

Kurumsal Google Cloud Entegrasyonuna Nereden Başlanmalı?

Kurumsal projelerde ilk adım servis seçmek değil mevcut durumu anlamaktır. Uygulamalar, sunucular, veritabanları, kullanıcılar, network bağlantıları ve bağımlılıklar envantere alınmalıdır. Ardından iş hedefleri ile teknik hedefler aynı plana bağlanmalıdır. Birçok projede en büyük gecikmenin teknoloji seçiminden değil, bilinmeyen bağımlılıklardan kaynaklandığını gördüm. Bu nedenle discovery aşamasına ayrılan zaman çoğu zaman migration sırasında kazanılır.

Business Case Oluşturmak

Business case neden buluta geçildiğini açık biçimde tanımlamalıdır. Hedef yalnızca donanım maliyetini azaltmaksa sonuç beklendiği kadar güçlü olmayabilir. Daha hızlı ürün geliştirme, felaket kurtarma, kapasite esnekliği ve operasyon otomasyonu da hesaba katılmalıdır. Başarı kriterleri ölçülebilir biçimde yazılmalıdır. Teknik ekip ile yönetim aynı hedefler üzerinde anlaşmadan kapsamın sürekli değişmesi sık rastlanan bir sorundur.

Teknik Hedefleri Belirlemek

Teknik hedefler somut olmalıdır. Örneğin production sistemlerinde public IP kullanımını azaltmak, RTO değerini belirli seviyeye getirmek veya deployment süresini kısaltmak ölçülebilir hedeflerdir. Her hedef için sorumlu ekip ve ölçüm yöntemi tanımlanmalıdır. Bu yaklaşım mimari kararların kişisel tercihlere göre verilmesini önler. Teknik hedeflerin business case ile doğrudan ilişkili olması gerekir.

Mevcut Altyapıyı Envanterlemek

Envanter yalnızca sunucu listesinden oluşmamalıdır. İşletim sistemi, CPU, RAM, disk, network trafiği, veri tabanı türü ve uygulama sahibinin de kaydedilmesi gerekir. Kullanılmayan veya sahipliği belli olmayan sistemler ayrıca işaretlenmelidir. Bu kayıtlar migration sıralamasını belirlerken büyük kolaylık sağlar. Envanteri güncel tutmak daha sonraki maliyet ve güvenlik analizlerini de destekler.

Bağımlılıkları Haritalamak

Bir uygulama tek başına çalışmıyorsa onu tek başına taşımak risklidir. DNS kayıtları, veri tabanları, dosya sistemleri, dış API'ler ve mesaj kuyrukları bağımlılık haritasına eklenmelidir. Network akışları gerçek trafik verileriyle doğrulanmalıdır. Uygulama sahiplerinin verdiği bilgi her zaman bütün bağlantıları göstermeyebilir. Migration wave tasarımı büyük ölçüde bu bağımlılık haritasına dayanmalıdır.

Güvenlik Gereksinimlerini Belirlemek

Güvenlik gereksinimleri tasarımın sonunda eklenmemelidir. Hangi verinin hassas olduğu, kimlerin production erişimine ihtiyaç duyduğu ve hangi logların tutulacağı baştan belirlenmelidir. Service account kullanım modeli ve anahtar politikası ayrıca tanımlanmalıdır. Kurumun güvenlik ekibi landing zone çalışmalarına ilk günden katılmalıdır. Sonradan eklenen kontroller çoğu zaman uygulama mimarisinin yeniden düzenlenmesine yol açar.

Veri Yerleşimi Gereksinimleri

Verinin hangi bölgelerde tutulabileceği teknik ve hukuki gereksinimlere göre değerlendirilmelidir. Her veri aynı sınıfa ait değildir. Kişisel veriler, finansal veriler ve anonim telemetri farklı kurallara tabi olabilir. Region seçimi yapılırken yalnızca latency değil yedekleme ve felaket kurtarma planı da hesaba katılmalıdır. Veri yerleşimi konusu platform kurulduktan sonra değil daha mimari tasarım aşamasında ele alınmalıdır.

Bütçe ve TCO

Toplam sahip olma maliyeti yalnızca sanal makine fiyatından oluşmaz. Network egress, log saklama, backup, lisans, operasyon ve insan kaynağı da hesaba katılmalıdır. Rightsizing yapılmadan hesaplanan tahminler yanıltıcı olabilir. Migration sonrası otomatik ölçekleme ve committed kullanım modelleri ayrıca değerlendirilebilir. FinOps yaklaşımının ilk günden projeye dahil edilmesi sürpriz faturaların önüne geçer.

Hedef Mimari Oluşturmak

Hedef mimari mevcut sistemin birebir bulut kopyası olmamalıdır. Bazı workload'lar sanal makine olarak taşınabilirken bazıları yönetilen servislere dönüştürülebilir. Identity, network, logging ve security ortak platform servisleri olarak ele alınmalıdır. Hedef mimari migration wave'lerinin ulaşacağı yönü göstermelidir. Uygulama ekipleri bu mimarinin nasıl kullanılacağını net biçimde anlayabilmelidir.

Google Cloud Migration Center ile Mevcut Altyapıyı Analiz Etmek

Migration Center mevcut altyapıyı keşfetme, değerlendirme ve taşınacak workload'lar hakkında karar verme sürecine yardımcı olabilir. Kurumsal migration projelerinde önce ölçüm yapmak benim en çok önem verdiğim adımlardan biridir. Çünkü yalnızca sunucu adlarına bakarak doğru instance boyutu veya doğru hedef servis seçilemez. Kullanım verileri, bağımlılıklar ve teknik uygunluk birlikte değerlendirilmelidir. Böylece migration kararları tahmine değil gerçek verilere dayanır.

Migration Center Nedir?

Migration Center mevcut altyapının keşfedilmesini ve cloud migration açısından değerlendirilmesini destekleyen merkezi bir yaklaşım sağlar. Fiziksel ve sanal sunucular hakkında veri toplanabilir. Kullanım profilleri üzerinden sizing çalışmaları yapılabilir. Workload'ların hedef servislerle uyumu değerlendirilebilir. Bu bilgiler migration roadmap hazırlanırken teknik kararların daha sağlam verilmesini sağlar.

Infrastructure Discovery

Infrastructure discovery ortamda gerçekte hangi sistemlerin bulunduğunu ortaya çıkarmayı amaçlar. Uzun yıllardır çalışan veri merkezlerinde dokümantasyon ile gerçek durum arasında fark bulunması oldukça normaldir. Aktif sunucuların, bağlantıların ve kullanım oranlarının ölçülmesi bu farkı azaltır. Keşif sırasında sahipliği belli olmayan sistemler ayrıca incelenmelidir. Böylece taşınması gerekmeyen kaynaklar migration kapsamından çıkarılabilir.

Sunucu Envanteri

Sunucu envanterinde CPU ve RAM dışında işletim sistemi, disk yapısı ve network bilgileri de tutulmalıdır. Uygulama sahipliği ayrıca kaydedilmelidir. Sunucunun production, test veya geliştirme amacı taşıdığı açıkça belirtilmelidir. Kritik sistemlerin bakım pencereleri ve bağımlılıkları eklenmelidir. Bu detaylar migration wave planlamasında doğrudan kullanılır.

VM Envanteri

VM envanteri sanal makinelerin kapasite ve kullanım profilini gösterir. Ayrılmış kapasite ile gerçek tüketim arasındaki fark rightsizing için önemlidir. Yıllar önce büyük boyutlandırılan ama bugün düşük kaynak kullanan makineler sık görülür. Bunları aynı boyutta taşımak gereksiz maliyet oluşturabilir. Gerçek kullanım verisine dayalı sizing daha doğru başlangıç noktası sağlar.

Database Discovery

Veritabanı keşfi migration projelerinin kritik parçalarından biridir. Sürüm, boyut, transaction yoğunluğu, replication modeli ve desteklenen uzantılar kaydedilmelidir. Uygulamaların hangi veri tabanlarına bağlandığı netleştirilmelidir. Yönetilen servise geçiş planlanıyorsa uyumluluk ayrıca test edilmelidir. Veri tabanını yalnızca dosya boyutuna bakarak taşımak ciddi risk oluşturabilir.

Application Dependency Mapping

Dependency mapping uygulamalar arasındaki gerçek ilişkileri görünür hale getirir. Bir web uygulamasının veri tabanı, LDAP, dosya paylaşımı veya harici API bağlantıları olabilir. Bu bağlantılar aynı wave içinde ele alınmadığında migration sonrası beklenmeyen kesintiler yaşanabilir. Network trafik kayıtları haritalamanın doğruluğunu artırır. İşletme sahiplerinin bilgisi ile teknik ölçümlerin birlikte kullanılması daha sağlıklı sonuç verir.

Technical Fit Assessment

Technical fit assessment bir workload'un hangi Google Cloud servisinde daha uygun çalışabileceğini anlamaya yardımcı olur. Her sanal makinenin Compute Engine'e taşınması gerekmez. Bazı uygulamalar container platformlarına veya yönetilen veri servislerine uygun olabilir. Ancak modernizasyonun geliştirme maliyeti de hesaba katılmalıdır. En iyi hedef, teknik fayda ile geçiş riskinin dengelendiği seçenektir.

Rightsizing

Rightsizing gerçek kaynak kullanımına göre uygun kapasiteyi belirleme sürecidir. On-premises ortamlarda kapasite genellikle gelecekteki büyüme düşünülerek büyük tutulur. Bulut ortamında kapasite daha esnek biçimde artırılabildiği için aynı yaklaşım gerekli olmayabilir. CPU, RAM ve disk I/O verileri birlikte incelenmelidir. Küçük başlamak ve ölçerek büyümek bazı workload'larda daha ekonomik olabilir.

TCO Hesaplama

TCO hesabı yalnızca compute fiyatlarını karşılaştırmamalıdır. Network, storage, backup, monitoring, lisans ve operasyon maliyetleri de eklenmelidir. Şirket içi altyapıda elektrik, soğutma, donanım yenileme ve bakım giderleri unutulmamalıdır. Bulut tarafında egress ve log saklama maliyetleri özellikle takip edilmelidir. Gerçekçi TCO çalışması teknik mimari ile finans ekiplerinin ortak çalışmasını gerektirir.

Hedef Google Cloud Servisini Belirleme

Hedef servis workload özelliklerine göre belirlenmelidir. Eski ve değişmesi zor uygulamalar Compute Engine üzerinde başlayabilir. Container uyumlu servisler GKE veya Cloud Run seçenekleriyle değerlendirilebilir. Transaction odaklı veri tabanları ile analitik sistemler aynı platform gereksinimine sahip değildir. Hedef seçiminde operasyon kapasitesi de en az teknik uyumluluk kadar önemlidir.

Workload'lar Nasıl Sınıflandırılmalı?

Workload sınıflandırması migration sıralamasını ve hedef platform seçimini kolaylaştırır. İş kritiklik seviyesi, teknik risk, veri hassasiyeti, latency ve bağımlılık sayısı birlikte değerlendirilmelidir. Tek bir puan yerine birkaç eksende değerlendirme yapılması daha sağlıklıdır. Örneğin teknik olarak kolay görünen bir uygulama finansal süreçlerin merkezindeyse ilk wave için uygun olmayabilir. Buna karşılık düşük riskli ve bağımsız bir test uygulaması pilot migration için iyi aday olabilir.

Business Criticality

Business criticality uygulamanın kesilmesi durumunda işletmenin ne kadar etkileneceğini gösterir. Gelir üreten veya kritik operasyonları yöneten sistemler daha yüksek seviyede sınıflandırılır. Bu sistemlerin migration planında daha fazla test ve rollback adımı bulunmalıdır. Düşük kritik workload'lar pilot çalışma için kullanılabilir. Kritikliği yalnızca teknik ekip değil iş birimleriyle birlikte değerlendirmek gerekir.

Teknik Karmaşıklık

Teknik yapı uygulamanın taşınma zorluğunu etkiler. Eski işletim sistemleri, özel network protokolleri ve düşük dokümantasyon migration riskini artırabilir. Çok sayıda servis bağımlılığı da planlamayı zorlaştırır. Buna karşılık stateless ve iyi dokümante edilmiş uygulamalar daha hızlı taşınabilir. Teknik değerlendirme sonucunda bazı workload'ların önce modernize edilmesi gerekebilir.

Data Sensitivity

Data sensitivity verinin güvenlik ve erişim gereksinimini belirler. Kişisel ve finansal veri barındıran sistemler daha sıkı kontroller gerektirir. Encryption, IAM ve audit politikaları veri sınıfına göre uygulanmalıdır. Hassas veri taşıyan workload'ların migration testleri anonim veya maskelenmiş örneklerle yapılabilir. Veri sınıflandırması bilinmeden sağlıklı erişim modeli tasarlanamaz.

Availability Requirement

Availability requirement uygulamanın kabul edilebilir kesinti süresini ifade eder. Yüksek erişilebilir sistemler multi-zone veya daha geniş yedeklilik modelleri gerektirebilir. Bakım penceresi olmayan servislerin cutover planı daha ayrıntılı hazırlanmalıdır. Kullanıcı etkisi ve iş kaybı birlikte değerlendirilmelidir. Availability hedefi teknik maliyet üzerinde doğrudan etkilidir.

Latency Requirement

Latency özellikle hibrit mimarilerde kritik hale gelir. Uygulama Google Cloud'a taşınıp veri tabanı şirket içinde kaldığında her istek WAN üzerinden geçebilir. Bu durum uygulama performansını beklenenden fazla düşürebilir. Application dependency mapping ile trafik yoğunluğu önceden ölçülmelidir. Çok düşük latency isteyen bileşenleri aynı migration wave içinde taşımak genellikle daha güvenlidir.

Dependency Complexity

Bağımlılık sayısı arttıkça migration planının koordinasyon ihtiyacı da artar. Tek bir API'nin bile farklı ekipler tarafından yönetilen birçok sisteme bağlı olduğu görülebilir. Bu ilişkiler dokümante edilmezse cutover sırasında bağlantı sorunları yaşanabilir. Dependency seviyesine göre workload grupları oluşturmak planlamayı kolaylaştırır. Daha bağımsız sistemlerin ilk wave'lerde kullanılması ekiplerin deneyim kazanmasını sağlar.

Migration Readiness

Migration readiness teknik ve organizasyonel hazırlığı birlikte ifade eder. Uygulamanın dokümantasyonu, test süreci, sahibi ve rollback planı hazır olmalıdır. Eksik bilgi bulunan sistemleri production migration'a almak gereksiz risk yaratır. Hazırlık puanı belirlemek wave sıralamasını kolaylaştırabilir. Readiness zaman içerisinde iyileştirilebilen bir ölçüttür.

Modernization Potential

Bazı workload'lar taşınmadan önce veya taşındıktan sonra modernizasyon için iyi adaydır. Monolith uygulamalar parçalara ayrılabilir veya container ortamına alınabilir. Ancak her sistem için refactor yapmak ekonomik değildir. Uygulamanın kalan ömrü ve iş değeri dikkate alınmalıdır. Modernizasyon fırsatı ile migration hızını dengede tutmak önemlidir.

Cloud Migration Stratejisi Nasıl Seçilir?

Migration stratejisi workload bazında seçilmelidir. Bir kurumdaki yüzlerce uygulamanın tamamını aynı yöntemle taşımaya çalışmak hem süreyi hem riski artırır. Bazı sistemler hızlı biçimde rehost edilebilirken bazıları yeniden tasarlanmalıdır. Bazı uygulamaların ise emekli edilmesi daha doğru olabilir. Strateji seçerken teknik uygunluk, iş değeri, maliyet ve modernizasyon hedefleri birlikte değerlendirilmelidir.

Rehost

Rehost mevcut uygulamayı büyük değişiklik yapmadan yeni ortama taşır. Bu yöntem hızlı migration ihtiyacında kullanılabilir. Eski sanal makineler için uygun bir başlangıç olabilir. Ancak mevcut teknik borç da yeni ortama taşınır. Rehost sonrasında modernizasyon yol haritası hazırlanması faydalıdır.

Replatform

Replatform uygulamanın tamamını yeniden yazmadan bazı altyapı bileşenlerini değiştirmeyi ifade eder. Örneğin yönetilen veri tabanına geçiş bu modele örnek olabilir. Operasyon yükü azalabilir ve yüksek erişilebilirlik daha kolay yönetilebilir. Buna karşılık uyumluluk testleri gereklidir. Uygulama kodunda sınırlı değişiklik yapmak kabul edilebiliyorsa dengeli bir seçenek olabilir.

Refactor

Refactor uygulamanın mimarisinde daha önemli değişiklikler yapılmasını içerir. Monolith yapılar mikroservislere veya event tabanlı modellere dönüştürülebilir. Bu yaklaşım daha uzun proje süresi gerektirir. Buna karşılık ölçeklenebilirlik ve deployment bağımsızlığı artabilir. İş değeri düşük uygulamalarda geniş refactor yatırımı yapmak her zaman mantıklı değildir.

Re-Architect

Re-Architect yaklaşımında uygulamanın çalışma modeli yeniden ele alınır. Servis sınırları, veri akışı ve deployment modeli değişebilir. Bu karar genellikle mevcut mimari iş hedeflerini artık karşılamadığında verilir. Proje kapsamı klasik migration'dan daha geniştir. Sağlam domain analizi yapılmadan başlanan yeniden tasarım süreçleri beklenenden fazla uzayabilir.

Repurchase / Replace

Bazı uygulamaları taşımak yerine hazır bir hizmetle değiştirmek daha ekonomik olabilir. Özellikle eski ve yoğun bakım isteyen sistemlerde bu seçenek değerlendirilmelidir. Veri aktarımı ve kullanıcı geçişi yine planlanmalıdır. İş süreçleri yeni çözüme uyarlanabilir. Karar yalnızca lisans fiyatına göre verilmemelidir.

Retain

Her workload hemen buluta taşınmak zorunda değildir. Teknik bağımlılık, lisans veya veri gereksinimi nedeniyle bazı sistemler mevcut ortamda kalabilir. Bu durumda hybrid cloud tasarımı önem kazanır. Retain kararı plansız erteleme anlamına gelmemelidir. Sistemin neden kaldığı ve ne zaman yeniden değerlendirileceği kayıt altına alınmalıdır.

Retire

Kullanılmayan sistemleri taşımamak en ekonomik migration stratejilerinden biridir. Eski ortamlarda sahipliği belirsiz çok sayıda servis bulunabilir. Gerçek kullanım analiz edilerek gereksiz sistemler kapatılabilir. Böylece migration kapsamı ve maliyet azalır. Retire kararı verilmeden önce iş birimleriyle doğrulama yapılmalıdır.

Hangi Workload İçin Hangi Yaklaşım?

Kritik ama eski sistemlerde önce rehost, ardından kontrollü modernizasyon mantıklı olabilir. Yeni geliştirilen servislerde container veya serverless platformlara geçiş daha kolaydır. Kullanım ömrü dolmuş uygulamalar retire edilmeye adaydır. Yönetilen servis uyumluluğu yüksek veri tabanlarında replatform düşünülebilir. Tek bir stratejiyi bütün portföye uygulamak yerine workload bazlı karar vermek daha sağlıklı sonuç verir.

Migration Wave Nedir?

Migration wave, workload'ların kontrollü gruplar halinde taşınmasını sağlar. Amaç bütün sistemi tek bir gecede değiştirmek değildir. İlk wave genellikle daha düşük riskli ve bağımlılığı az uygulamalardan oluşur. Ekip burada network, IAM, monitoring ve cutover süreçlerini gerçek ortamda test eder. Öğrenilen dersler sonraki wave'lerin daha hızlı ve güvenli ilerlemesini sağlar.

Workload'ları Wave'lere Bölmek

Wave oluştururken uygulamaların teknik bağımlılıkları ve iş kritiklik seviyesi birlikte değerlendirilmelidir. Birbirine sıkı bağlı servisleri ayrı tarihlerde taşımak latency ve erişim sorunları oluşturabilir. Düşük riskli workload'lar başlangıç için tercih edilebilir. Her wave için net kapsam belirlenmelidir. Kapsam sürekli değişirse cutover yönetimi zorlaşır.

Dependency Bazlı Gruplama

Bağımlılık bazlı gruplama birlikte çalışan sistemleri aynı migration planına alır. Uygulama, veri tabanı ve entegrasyon servisleri tek grup olarak değerlendirilebilir. Bu yöntem hibrit geçiş süresini azaltabilir. Network trafiği dependency haritasıyla doğrulanmalıdır. İş ekiplerinin süreç akışları da teknik bağımlılıklarla birlikte incelenmelidir.

Düşük Riskli İlk Wave

İlk wave kurumsal migration sürecinin öğrenme alanıdır. Çok kritik olmayan ama gerçek kullanıcı trafiği bulunan bir uygulama iyi aday olabilir. Burada cutover, rollback ve monitoring süreçleri test edilir. Operasyon ekibi gerçek production deneyimi kazanır. İlk wave'de edinilen bilgiler sonraki planlara aktarılmalıdır.

Dev ve Test Ortamlarından Başlamak

Dev ve test ortamları platform süreçlerini doğrulamak için uygundur. IAM, network ve CI/CD entegrasyonu production öncesinde denenebilir. Ancak test ortamının production mimarisinden tamamen farklı olması öğrenme değerini azaltır. Temel platform standartlarının benzer tutulması faydalıdır. Production verisi test ortamına kontrolsüz biçimde kopyalanmamalıdır.

Production Migration Wave

Production wave için değişiklik takvimi, rollback kriterleri ve sorumlular önceden belirlenmelidir. Network ve DNS testleri cutover öncesinde tamamlanmalıdır. Veri senkronizasyonunun ne zaman durdurulacağı açıkça planlanmalıdır. Monitoring ekranları geçişten önce hazır olmalıdır. Go veya no-go kararı ölçülebilir kriterlere dayanmalıdır.

Wave Success Criteria

Başarı yalnızca uygulamanın açılmasıyla ölçülmemelidir. Latency, error rate, kullanıcı deneyimi ve veri tutarlılığı kontrol edilmelidir. Backup ve monitoring süreçlerinin çalışması ayrıca doğrulanmalıdır. Maliyet tahmini gerçek tüketimle karşılaştırılabilir. Başarı kriterleri migration başlamadan önce yazılmalıdır.

Lessons Learned

Her wave sonrasında kısa bir değerlendirme yapılması büyük fayda sağlar. Beklenmeyen network kuralları, eksik DNS kayıtları veya IAM sorunları belgelenmelidir. Hangi adımların gereksiz olduğu da not edilmelidir. Bu bilgiler runbook'lara eklenebilir. Sürekli öğrenme migration hızını sonraki aşamalarda belirgin biçimde artırır.

Sonraki Wave'i İyileştirmek

Bir önceki wave'deki sorunlar yalnızca raporlanmamalı, sonraki süreçte düzeltilmelidir. Tekrarlanan manuel adımlar otomasyona taşınabilir. Eksik monitoring kontrolleri standart template'e eklenebilir. IAM veya network talepleri için self-service süreçler oluşturulabilir. Böylece her wave öncekinin kopyası değil geliştirilmiş sürümü olur.

Google Cloud Landing Zone Nedir?

Landing zone, workload'lar gelmeden önce hazırlanmış kurumsal Google Cloud temelidir. Resource hierarchy, network, IAM, security, logging, billing ve automation kuralları bu yapının içerisinde bulunur. Ben landing zone olmadan production workload taşınmasını en sık karşılaşılan mimari hatalardan biri olarak görüyorum. Çünkü sonradan standart oluşturmak, çalışan onlarca projeyi yeniden düzenlemeyi gerektirebilir. Sağlam landing zone geliştirici ekiplerin güvenli ve tekrar edilebilir biçimde yeni proje oluşturmasına yardımcı olur.

Landing Zone ile VPC Arasındaki Fark

VPC yalnızca network katmanıdır. Landing zone ise VPC'nin yanında kimlik, organizasyon yapısı, loglama ve güvenlik gibi birçok bileşeni kapsar. Bir VPC oluşturmak kurumsal platform kurmak anlamına gelmez. Production ortamında billing ve Organization Policy gibi kontroller de gereklidir. Landing zone bütün bu parçaları ortak standartta bir araya getirir.

Cloud Foundation Kavramı

Cloud foundation, bulut ortamının üzerinde workload çalıştırılabilecek temel yapısını ifade eder. Identity, hierarchy, connectivity ve governance ana bileşenlerdir. Foundation ne kadar standart olursa ekiplerin yeni ortam oluşturması o kadar kolaylaşır. Manuel kurulumlar yerine IaC tercih edilmesi tekrar edilebilirlik sağlar. Platform büyüdükçe foundation yönetiminin önemi daha fazla hissedilir.

Landing Zone Neden Workload'lardan Önce Kurulmalıdır?

Workload önce taşınırsa her ekip kendi network ve IAM modelini kurabilir. Birkaç ay içinde farklı güvenlik seviyelerine sahip projeler ortaya çıkar. Merkezi logging veya maliyet etiketleri sonradan eklenmek zorunda kalır. Bu değişiklikler production sistemlerinde risk oluşturabilir. Landing zone önce kurulduğunda workload ekipleri hazır standartları kullanarak daha hızlı ilerler.

Landing Zone'un Temel Bileşenleri

Sağlıklı landing zone identity, resource hierarchy, networking, security, logging, billing ve automation bileşenlerini birlikte ele alır. Bu parçaların her biri diğerini etkiler. Örneğin network projesinin kim tarafından yönetileceği IAM modeline bağlıdır. Merkezi logging için resource hierarchy ve sink tasarımı gerekir. Landing zone tek seferlik kurulum değil sürekli geliştirilen kurumsal platform olmalıdır.

Identity

Identity temelinde kullanıcı ve workload kimliklerinin ayrı yönetilmesi gerekir. Grup bazlı IAM tercih edilmelidir. Yetkiler minimum ihtiyaç seviyesinde verilmelidir. Production erişimi sınırlandırılmalıdır. Federation imkanları kalıcı credential kullanımını azaltabilir.

Resource Hierarchy

Resource hierarchy Organization, Folder ve Project yapısını düzenler. Politika mirası bu hiyerarşi üzerinden uygulanabilir. Production ve non-production ortamlarını ayırmak yönetimi kolaylaştırır. Organizasyon şemasını birebir kopyalamak yerine teknik sınırlar düşünülmelidir. Hiyerarşi değişikliklerinin ileride operasyon etkisi olacağı unutulmamalıdır.

Networking

Networking katmanında VPC, subnet, routing ve hibrit bağlantılar tasarlanır. IP adres planı merkezi biçimde yönetilmelidir. Shared VPC ekipler arasında network sorumluluğunu ayırmaya yardımcı olabilir. Firewall ve DNS standartları baştan belirlenmelidir. Kritik bağlantılar yedekli kurulmalıdır.

Security

Security Organization Policy, IAM ve network kontrollerini kapsar. Public erişim yalnızca gerçekten gerekli sistemlerde açılmalıdır. Service account key kullanımının sınırlandırılması iyi bir başlangıçtır. Hassas loglar merkezi sisteme gönderilmelidir. Güvenlik kontrollerinin otomasyon süreçlerine eklenmesi gerekir.

Logging

Logging dağıtık projelerde merkezi görünürlük sağlar. Organization seviyesinde log sink tasarlanabilir. Audit kayıtlarının merkezi projeye aktarılması incident incelemelerini kolaylaştırır. Retention ihtiyaca göre belirlenmelidir. Gereksiz logların uzun süre tutulması maliyeti artırabilir.

Billing

Billing organizasyonun maliyet görünürlüğünü sağlar. Project ve label bazlı maliyet dağılımı oluşturulabilir. Budget ve alert mekanizmaları erken uyarı verir. Billing export analitik raporlamada kullanılabilir. Maliyet yönetimi migration tamamlandıktan sonra başlatılmamalıdır.

Automation

Automation platform standartlarını tekrar edilebilir hale getirir. Terraform gibi IaC araçları project ve network oluşturmayı standartlaştırabilir. Pull request süreci değişikliklerin incelenmesini sağlar. Manuel console değişiklikleri mümkün olduğunca azaltılmalıdır. Otomasyon aynı zamanda audit kabiliyetini de güçlendirir.

Google Cloud Organization Yapısı

Organization yapısı Google Cloud kaynaklarının yönetim sınırlarını belirler. Folder ve Project katmanları üzerinden erişim, politika ve maliyet yönetimi uygulanabilir. Kurumsal ortamlarda bu yapı ilk günden planlanmalıdır. Çok sayıda proje oluşturulduktan sonra hierarchy değiştirmek operasyon yükü yaratabilir. Yapının şirketin organizasyon şemasından çok teknik ve yönetişim gereksinimlerini yansıtması daha faydalıdır.

Organization

Organization kurumsal kaynak hiyerarşisinin en üst seviyesidir. Merkezi politikaların uygulanabileceği ana sınırı sağlar. IAM ve Organization Policy alt kaynaklara miras bırakılabilir. Güvenlik ekipleri bu seviyede temel guardrail'ler oluşturabilir. Organization yapısına geniş erişim yalnızca sınırlı yöneticilerde bulunmalıdır.

Folder

Folder projeleri mantıksal gruplar altında toplar. Production, development veya belirli iş alanları için kullanılabilir. Politika mirası yönetimi kolaylaştırır. Çok derin folder yapısı operasyonu zorlaştırabilir. Tasarım mümkün olduğunca sade tutulmalıdır.

Project

Project kaynakların temel yönetim sınırlarından biridir. IAM, quota, billing ve API kullanımı project seviyesinde takip edilebilir. Uygulamaların birbirinden ayrılması blast radius'ı azaltabilir. Production ile development genellikle farklı projelerde tutulmalıdır. Project oluşturma sürecinin otomasyona bağlanması standardizasyon sağlar.

Resource

Resource sanal makine, bucket, veri tabanı veya diğer servis nesnelerini ifade eder. Kaynaklar project içerisinde oluşturulur. IAM politikaları bazı kaynak seviyelerinde ayrıca uygulanabilir. Çok fazla kaynak bazlı özel yetki yönetimi karmaşık hale gelebilir. Mümkün olduğunda grup ve proje seviyesinde tutarlı rol modeli tercih edilmelidir.

Policy Inheritance

Policy inheritance üst seviyede tanımlanan kuralların alt kaynaklara aktarılmasını sağlar. Bu yöntem merkezi governance için güçlüdür. Örneğin belirli konumlarda kaynak oluşturmayı sınırlandıran politikalar üst seviyede uygulanabilir. İstisnalar kontrollü süreçle yönetilmelidir. Politika mirasının etkisi production öncesinde test edilmelidir.

IAM Inheritance

IAM inheritance üst kaynaklarda verilen rollerin alt kaynaklara ulaşmasını sağlar. Çok geniş Organization seviyesinde rol vermek gereksiz erişime yol açabilir. Kullanıcı erişimleri mümkün olduğunca grup üzerinden yönetilmelidir. Production erişimleri daha dar tutulmalıdır. IAM değişiklikleri audit loglarla takip edilmelidir.

Billing Boundary

Billing Account birden fazla projeyi ortak faturalandırma yapısına bağlayabilir. Cost center bilgileri project veya label seviyesinde takip edilebilir. Bu yapı FinOps raporlarının temelini oluşturur. Ortak servis maliyetlerinin nasıl dağıtılacağı önceden belirlenmelidir. Finans ekiplerinin resource hierarchy tasarımına erken katılması yararlıdır.

Quota Boundary

Bazı quota değerleri project veya servis seviyesinde uygulanır. Büyük migration projelerinde quota gereksinimleri önceden kontrol edilmelidir. Aksi halde production cutover sırasında kaynak oluşturma sınırına takılmak mümkündür. Kritik servislerin kapasite planı migration öncesinde yapılmalıdır. Quota monitoring operasyon sürecinin bir parçası olmalıdır.

Kurumsal Resource Hierarchy Nasıl Tasarlanır?

Resource hierarchy şirketin teknik yönetim modelini yansıtmalıdır. Environment, ürün, iş birimi veya regülasyon ihtiyaçlarına göre farklı modeller kullanılabilir. Tek bir doğru şablon yoktur. Önemli olan policy inheritance ve IAM yönetimini anlaşılır tutmaktır. İleride yeni ekip veya yeni region eklendiğinde yapının tamamen değiştirilmesine ihtiyaç duyulmaması iyi tasarım işaretidir.

Environment-Based Hierarchy

Environment-based model production, test ve development ortamlarını üst seviyede ayırır. Güvenlik politikalarının ortama göre farklılaşması kolaylaşır. Production için daha sınırlı erişim uygulanabilir. Billing raporları ortam bazında ayrıştırılabilir. Çok sayıda ürün bulunan şirketlerde ek folder katmanlarına ihtiyaç duyulabilir.

Business Unit-Based Hierarchy

Business unit tabanlı yapı kaynakları iş birimlerine göre gruplar. Maliyet sahipliğini belirlemek kolaylaşabilir. Ancak ortak güvenlik standartlarını korumak gerekir. Aynı uygulamanın farklı ortamlardaki projeleri farklı folder'lara dağılabilir. Model seçilirken operasyon ekiplerinin çalışma biçimi dikkate alınmalıdır.

Product-Based Hierarchy

Product tabanlı yaklaşım ürün ekiplerinin kaynaklarını ortak sınır altında tutar. Platform engineering modelinde bu yapı doğal olabilir. Ürün maliyeti daha kolay takip edilebilir. Production ve development alt folder'larla ayrılabilir. Ortak servisler ayrı platform alanında tutulmalıdır.

Region-Based Hierarchy

Region tabanlı hierarchy veri yerleşimi gereksinimleri bulunan kurumlarda değerlendirilebilir. Bölgesel güvenlik veya operasyon ekipleri farklı politikalar uygulayabilir. Ancak Google Cloud servislerinin bazıları global davranış gösterebilir. Bu nedenle yalnızca isimlendirme üzerinden bölgesel sınır varsayılmamalıdır. Resource location politikaları ayrıca uygulanmalıdır.

Regulated Workload Hierarchy

Regülasyona tabi workload'lar ayrı folder veya project sınırlarında tutulabilir. Daha sıkı IAM ve Organization Policy uygulanabilir. Merkezi loglama bu alan için farklı retention süresine sahip olabilir. Network erişimi daha dar tasarlanabilir. Bu yapı audit sırasında ilgili kaynakların ayrıştırılmasını kolaylaştırır.

Hybrid Yaklaşım

Çoğu büyük kurum tek bir model yerine hybrid hierarchy kullanır. Üst seviyede environment, alt seviyede product veya business unit ayrımı yapılabilir. Tasarımın çok fazla katmana dönüşmemesine dikkat edilmelidir. Policy inheritance herkes tarafından anlaşılır olmalıdır. Basit ve tutarlı yapı uzun vadede daha kolay yönetilir.

Organizasyon Şemasını Birebir Kopyalamamanın Nedeni

Şirket organizasyonları zaman içinde sık değişebilir. Teknik resource hierarchy her organizasyon değişikliğinde yeniden taşınırsa operasyon yükü artar. Bu nedenle hierarchy daha kalıcı teknik ve güvenlik sınırlarına dayanmalıdır. İnsan kaynakları yapısı ile platform yapısı aynı şey değildir. Ekip sahipliği IAM grupları ve cost center etiketleriyle ayrıca yönetilebilir.

Dev, Test ve Production Nasıl Ayrılmalı?

Environment ayrımı kurumsal Google Cloud güvenliğinin temel parçalarından biridir. Production ile development ortamlarını aynı project içerisinde tutmak istemeden yapılan bir değişikliğin kritik sisteme ulaşma riskini artırır. Ayrı project, IAM, budget ve gerektiğinde network sınırları kullanmak daha güvenlidir. Bu ayrım aynı zamanda maliyet görünürlüğünü iyileştirir. Ekipler farklı ortamların erişim seviyelerini daha açık biçimde yönetebilir.

Ayrı Project Kullanımı

Farklı environment'lar için ayrı project kullanmak güçlü izolasyon sağlar. API, quota ve IAM yönetimi ayrılabilir. Production kaynaklarına erişim daha sıkı tutulabilir. Test maliyetleri kolayca raporlanabilir. Project Factory kullanılarak standart proje oluşturma süreci otomatik hale getirilebilir.

Ayrı Folder Kullanımı

Ayrı folder kullanımı environment bazlı politikaları merkezi biçimde uygulamayı sağlar. Production folder'ına daha sıkı Organization Policy tanımlanabilir. Development ekiplerine daha geniş deneme alanı verilebilir. Folder seviyesinde IAM kullanımında geniş rollerden kaçınılmalıdır. Politika mirasının etkisi düzenli olarak gözden geçirilmelidir.

Ayrı Shared VPC

Environment başına Shared VPC kullanmak network izolasyonunu güçlendirebilir. Production trafiği development kaynaklarından ayrılır. Firewall ve routing politikaları farklı uygulanabilir. Network ekibi merkezi kontrolü korur. Bununla birlikte çok fazla VPC oluşturmak yönetim yükünü artırabileceği için ihtiyaç bazlı karar verilmelidir.

Farklı IAM Politikaları

Development erişimi ile production erişimi aynı seviyede olmamalıdır. Production yönetimi daha sınırlı gruplara verilebilir. Deployment kimliği ile runtime kimliği ayrılmalıdır. Geçici admin erişimi gerektiğinde süre sınırlı yetki modelleri tercih edilebilir. IAM değişiklikleri merkezi olarak audit edilmelidir.

Farklı Organization Policy

Production ortamında external IP veya public bucket gibi riskli yapılandırmalar daha sıkı sınırlandırılabilir. Development tarafında kontrollü esneklik sağlanabilir. Politika istisnalarının onay süreci olmalıdır. İstisnalar süresiz bırakılmamalıdır. Policy as Code yaklaşımı değişikliklerin tekrar edilebilir olmasını sağlar.

Farklı Budget

Her environment için ayrı budget tanımlamak maliyet görünürlüğünü artırır. Development ortamlarının beklenmedik büyümesi erken fark edilebilir. Production bütçesi business kapasitesine göre planlanabilir. Alert eşikleri ilgili ekiplere yönlendirilmelidir. Budget tek başına harcamayı engellemez, bu nedenle süreçlerle desteklenmelidir.

Production Blast Radius'ı Azaltmak

Blast radius bir hatanın ne kadar geniş alanı etkileyebileceğini ifade eder. Project ve network ayrımı bu etkiyi sınırlandırabilir. IAM rollerinin dar tutulması yanlış işlemlerin kapsamını azaltır. CI/CD ortamlarının production'a yalnızca ihtiyaç duyduğu izinlerle erişmesi gerekir. Tasarımın amacı tek bir hatanın bütün kurumsal platformu etkilemesini önlemektir.

Project Factory Nedir?

Project Factory, yeni Google Cloud projelerini ortak standartlarla otomatik oluşturan yaklaşımı ifade eder. Büyük kurumlarda her ekibin console üzerinden kendi projesini oluşturması zamanla farklı network, logging ve IAM modellerine yol açar. Factory yaklaşımı bu farklılığı azaltır. Yeni proje talebi belirli bir template üzerinden oluşturulabilir. Böylece ekipler hızlı ilerlerken platform ekibi temel güvenlik kurallarını korur.

Manuel Project Oluşturmanın Sorunları

Manuel proje oluşturmak küçük ortamlarda kolay görünür. Proje sayısı arttıkça isimlendirme, IAM ve billing standartları bozulmaya başlar. Merkezi log sink unutulabilir. Network yanlış projeye bağlanabilir. Automation bu tekrar eden hataları azaltır.

Self-Service Project Provisioning

Self-service modelinde uygulama ekibi kontrollü form veya repository süreci üzerinden proje talep eder. Platform gerekli kontrolleri otomatik uygular. Manuel ticket sayısı azalır. Güvenlik standartları korunur. Bu yaklaşım controlled autonomy için iyi bir temel oluşturur.

Project Template

Project template standart başlangıç ayarlarını tanımlar. İsimlendirme, billing ve gerekli API'ler template içerisinde belirlenebilir. Ortak servis entegrasyonları eklenebilir. Template version kontrolünde tutulabilir. Platform geliştikçe template de güncellenebilir.

Default Labels

Default labels maliyet ve sahiplik takibini kolaylaştırır. Environment, cost center ve owner bilgileri standardize edilebilir. Billing export raporları bu etiketlerden yararlanabilir. Eksik label bulunan kaynaklar policy kontrolleriyle tespit edilebilir. Etiket standardı proje başlamadan belirlenmelidir.

Default IAM

Default IAM her yeni projeye minimum gerekli erişim modelini uygular. Geniş basic roller yerine tanımlı roller kullanılmalıdır. Ekip erişimleri grup üzerinden verilebilir. Production projelerinde varsayılan yetki daha dar tutulabilir. IAM değişiklikleri repository üzerinden izlenebilir.

Default Network

Kurumsal ortamlarda varsayılan otomatik network yapısını kullanmak yerine merkezi tasarım tercih edilebilir. Shared VPC bağlantısı project creation sürecine eklenebilir. Subnet ve firewall politikaları network ekibi tarafından yönetilebilir. Uygulama ekipleri yalnızca gerekli servis alanlarını kullanır. Bu model network standardizasyonunu güçlendirir.

Default Logging

Yeni projelerin merkezi logging sistemine otomatik bağlanması önemli avantaj sağlar. Audit logların unutulması engellenir. Retention ve export politikaları ortak biçimde uygulanabilir. Güvenlik ekipleri yeni projeleri ayrıca keşfetmek zorunda kalmaz. Logging platform foundation'ın standart bileşeni haline gelir.

Default Security Policies

Security policy'ler proje oluşturulduğu anda uygulanmalıdır. Public erişim ve service account key kullanımı gibi konular kontrol altına alınabilir. İstisna gerekiyorsa kayıtlı onay süreci işletilmelidir. Policy kontrollerinin CI/CD sürecine eklenmesi faydalıdır. Böylece güvenlik kontrolü production sonrasına kalmaz.

Cost Center Etiketleri

Cost center bilgisi finansal sahipliği belirlemek için kullanılabilir. Her projenin hangi iş birimine ait olduğu raporlanabilir. Ortak servis maliyetleri ayrıca dağıtılabilir. Eksik maliyet sahipliği shadow IT sorununu büyütebilir. Project Factory bu bilgiyi zorunlu alan haline getirebilir.

Terraform ile Google Cloud Landing Zone

Terraform kurumsal altyapıyı kod olarak tanımlamak için sık kullanılan araçlardan biridir. Google Cloud landing zone oluştururken folder, project, network, IAM ve policy gibi kaynakların kod üzerinden yönetilmesini sağlar. Böylece aynı kurallar farklı environment'larda tekrar uygulanabilir. Değişiklikler pull request üzerinden incelenebilir ve audit geçmişi korunabilir. Kurumsal Google Cloud altyapı kurulum ve entegrasyon hizmeti tasarlanırken IaC kullanmak operasyon kalitesini belirgin biçimde artırır.

Infrastructure as Code Nedir?

Infrastructure as Code altyapı yapılandırmalarının kod dosyalarında tanımlanmasıdır. Manuel console adımları yerine version kontrollü değişiklikler yapılır. Aynı ortam tekrar üretilebilir. Review süreçleri teknik kaliteyi yükseltir. Kod ile gerçek ortam arasındaki fark düzenli plan kontrolleriyle izlenebilir.

Terraform Google Provider

Terraform Google Provider Google Cloud kaynaklarının kod üzerinden yönetilmesine yardımcı olur. Project, network ve IAM gibi birçok kaynak tanımlanabilir. Provider sürümleri kontrollü biçimde güncellenmelidir. Büyük ortamlarda modüler yapı kullanmak kod tekrarını azaltır. Değişikliklerin test ortamında doğrulanması production riskini düşürür.

Cloud Foundation Toolkit

Cloud Foundation Toolkit kurumsal foundation yapılarını oluştururken yararlanılabilecek örnekler ve modüler yaklaşımlar sunar. Hazır modüller başlangıç süresini kısaltabilir. Bununla birlikte kurum gereksinimlerine göre uyarlama yapılmalıdır. Her örneği doğrudan production'a uygulamak doğru değildir. Güvenlik, network ve billing standartları kurum tarafından ayrıca doğrulanmalıdır.

Bootstrap

Bootstrap aşaması Terraform'un kendisinin çalışacağı temel yapıyı hazırlar. State yönetimi ve deployment kimlikleri burada önemlidir. CI/CD için kalıcı service account anahtarları kullanmaktan kaçınılabilir. Yetkiler yalnızca gerekli kaynaklarla sınırlandırılmalıdır. Bootstrap ortamı güçlü audit kontrollerine sahip olmalıdır.

Organization

Organization seviyesindeki kaynakları Terraform ile yönetmek merkezi yönetişim sağlar. Folder ve policy yapıları kodlanabilir. Organization seviyesinde yapılan hataların etkisi geniş olabileceği için review süreci zorunlu tutulmalıdır. Değişiklikler önce plan çıktısında incelenmelidir. Production apply işlemi kontrollü onay gerektirebilir.

Environments

Development, test ve production yapılarını modüller üzerinden oluşturmak tutarlılık sağlar. Farklı environment değerleri variables ile yönetilebilir. Temel güvenlik standartları ortak kalabilir. Production için daha sıkı policy uygulanabilir. Kod tekrarını azaltırken environment farklarını açık biçimde göstermek önemlidir.

Networks

VPC, subnet, firewall ve routing kaynaklarının IaC ile yönetilmesi güçlü audit imkânı sağlar. IP planı merkezi modüllerde tutulabilir. Manuel firewall değişiklikleri azaltılabilir. Network değişiklikleri uygulamadan önce plan çıktısı üzerinden incelenebilir. Kritik routing değişiklikleri ayrıca connectivity testleriyle doğrulanmalıdır.

Projects

Project Factory Terraform modülleriyle oluşturulabilir. Billing, label, API ve Shared VPC bağlantıları otomatik hale getirilebilir. Uygulama ekipleri aynı template üzerinden yeni proje talep eder. Platform ekibi standartları merkezi olarak geliştirir. Project creation süresi manuel ticket süreçlerine göre önemli ölçüde kısalabilir.

CI/CD ile Terraform Apply

Terraform apply işlemini CI/CD hattına taşımak kontrollü değişiklik süreci sağlar. Pull request aşamasında terraform plan çalıştırılabilir. Security ve policy kontrolleri otomatik eklenebilir. Production apply için onay adımı tanımlanabilir. Deployment kimliğinde uzun ömürlü anahtar yerine federation kullanmak güvenliği güçlendirir.

Landing Zone'u GitOps ile Yönetmek

GitOps yaklaşımında infrastructure değişikliklerinin kaynağı Git repository olur. Console üzerinden yapılan geçici değişiklikler yerine repository'de tanımlanan durum esas alınır. Pull request incelemesi güvenlik ve platform ekiplerinin değişikliği uygulamadan önce görmesini sağlar. Bu yöntem audit sürecini de sadeleştirir. Özellikle çok ekipli ortamlarda GitOps, Google Cloud platformunun değişiklik yönetimini daha şeffaf hale getirir.

Git Repository

Repository altyapı kodunun merkezi kaynağıdır. Branch korumaları yetkisiz doğrudan değişiklikleri azaltır. Modüller ve environment dosyaları düzenli yapı içerisinde tutulmalıdır. Secret bilgiler repository'ye yazılmamalıdır. Commit geçmişi değişikliklerin kim tarafından yapıldığını gösterir.

Pull Request

Pull request altyapı değişikliğinin teknik olarak incelenmesini sağlar. Network, IAM ve security ekipleri gerekli değişiklikleri görebilir. Otomatik testler PR aşamasında çalıştırılabilir. Büyük değişiklikler küçük ve anlaşılır parçalara bölünmelidir. Review tamamlanmadan production apply yapılmamalıdır.

Terraform Plan

Terraform plan uygulanacak değişikliklerin ön izlemesini verir. Silinecek veya değiştirilecek kritik kaynaklar burada fark edilebilir. Plan çıktısının CI/CD loglarında saklanması audit açısından faydalıdır. Beklenmeyen değişiklik görülürse apply durdurulmalıdır. Production için plan ile apply arasında kod değişmediği doğrulanmalıdır.

Security Review

Security review IAM ve network etkilerini inceler. Public erişim açan veya geniş rol veren değişiklikler özellikle kontrol edilmelidir. Otomatik static analiz araçları manuel review'u destekleyebilir. Her değişikliğin güvenlik ekibi tarafından elle incelenmesi ölçeklenebilir değildir. Risk bazlı review modeli daha sağlıklıdır.

Policy Validation

Policy validation altyapı kodunun kurumsal kurallara uygunluğunu kontrol eder. Örneğin yasaklanan region veya external IP kullanımı CI aşamasında tespit edilebilir. Böylece hatalı kaynak daha oluşturulmadan engellenir. Policy kodları da version kontrolünde tutulmalıdır. İstisnalar kayıtlı ve süreli olmalıdır.

Approval

Approval özellikle production değişikliklerinde önemlidir. Her değişiklik için çok sayıda manuel onay süreci oluşturmak ekipleri yavaşlatabilir. Risk seviyesi yüksek işlemler için onay zorunlu tutulabilir. Düşük riskli standart değişiklikler otomatik ilerleyebilir. Controlled autonomy iyi platform tasarımının hedeflerinden biridir.

Apply

Apply yalnızca doğrulanmış plan üzerinden çalıştırılmalıdır. Deployment kimliği ihtiyaç duyduğu minimum role sahip olmalıdır. İnsan kullanıcıların yerel bilgisayardan production apply yapması sınırlandırılabilir. CI/CD logları merkezi sisteme gönderilebilir. Başarısız apply işlemleri için recovery prosedürü bulunmalıdır.

Audit Trail

Git commit, pull request, CI logları ve Cloud Audit Logs birlikte güçlü audit trail oluşturur. Bir kaynağın neden değiştiği geçmiş kayıtlarla bulunabilir. Incident incelemesi hızlanır. Manuel değişiklikler bu zinciri kırabilir. Bu nedenle console işlemleri özel durumlarla sınırlandırılmalıdır.

Rollback

Infrastructure rollback uygulama rollback kadar basit olmayabilir. Bazı kaynak değişiklikleri geri döndürülemez veri etkisi oluşturabilir. Bu nedenle değişiklik öncesi plan dikkatle incelenmelidir. Geri alma kod üzerinden yapılmalıdır. Kritik network ve database değişikliklerinde ayrı recovery adımları hazırlanmalıdır.

Configuration Drift Nasıl Önlenir?

Configuration drift, gerçek bulut ortamının IaC üzerinde tanımlanan durumdan farklılaşmasıdır. Genellikle acil durumlarda yapılan manuel console değişiklikleriyle başlar. Küçük farklar zaman içerisinde büyür ve kodun güvenilirliğini azaltır. Düzenli Terraform plan çalıştırmak drift tespitinde yardımcı olur. Acil değişiklik yapıldıysa aynı değişikliğin sonradan IaC koduna geri aktarılması gerekir.

Drift Nedir?

Drift kod ile çalışan altyapı arasındaki farktır. Örneğin Terraform'da kapalı görünen bir firewall kuralı console üzerinden açılmış olabilir. Bu durum security review süreçlerini etkisiz hale getirir. Düzenli detection önemlidir. Drift bulunduğunda kaynağın mı yoksa kodun mu doğru olduğu belirlenmelidir.

Console Üzerinden Manuel Değişiklik Riski

Console değişiklikleri hızlı olsa da version kontrolünü atlar. Değişikliğin nedeni aylar sonra bilinmeyebilir. Benzer ortamlara aynı değişiklik uygulanmaz. Rollback zorlaşır. Manuel işlem yalnızca kontrollü break-glass süreçlerinde kullanılmalıdır.

Terraform Plan

Periyodik terraform plan kod ile gerçek ortam arasındaki farkları gösterebilir. Sonuçlar otomatik raporlanabilir. Kritik farklar platform ekibine alert olarak gönderilebilir. Plan otomatik çalışsa bile apply kararı kontrollü verilmelidir. Böylece yanlış otomatik düzeltme riskinden kaçınılır.

Drift Detection

Drift detection düzenli veya event tabanlı yapılabilir. IAM ve firewall gibi güvenlik açısından kritik kaynaklar önceliklendirilebilir. Tespit edilen farkların sahibi belirlenmelidir. Tekrarlayan drift süreç problemi olduğuna işaret eder. Platform ekibi neden kullanıcıların console değişikliğine ihtiyaç duyduğunu araştırmalıdır.

Reconciliation

Reconciliation gerçek ortam ile tanımlı durumun yeniden eşitlenmesidir. Bazı durumlarda IaC kodu doğru kabul edilip ortam eski haline getirilir. Bazı acil değişikliklerde ise kod güncellenir. Karar değişikliğin iş gerekçesine dayanmalıdır. Otomatik reconciliation kritik sistemlerde dikkatle kullanılmalıdır.

Break-Glass Değişiklikleri

Break-glass erişimi acil durumlar için ayrılmış kontrollü yöntemdir. Normal çalışma sırasında kullanılmamalıdır. Erişim süreli ve audit edilebilir olmalıdır. İşlem sonrasında yapılan değişiklikler gözden geçirilmelidir. Gerekli değişiklik IaC repository'sine aktarılmalıdır.

Manuel Değişikliği IaC'ye Geri Aktarmak

Acil durumda yapılan manuel değişikliğin kalıcı hale gelmesi gerekiyorsa kod güncellenmelidir. Aksi halde sonraki Terraform apply işlemi değişikliği geri alabilir. Pull request içerisinde olay referansı eklenebilir. Security review yeniden yapılmalıdır. Böylece repository tekrar gerçek ortamın kaynağı haline gelir.

Kurumsal Kimlik Entegrasyonu Nasıl Yapılır?

Kurumsal kimlik entegrasyonu çalışanların ve workload'ların Google Cloud kaynaklarına kontrollü biçimde erişmesini sağlar. Google Cloud hybrid cloud VPN Interconnect ve IAM entegrasyonu nasıl yapılır sorusunda network kadar kimlik katmanı da kritik öneme sahiptir. Kullanıcılar mümkün olduğunca merkezi identity provider üzerinden doğrulanmalıdır. Service account key yerine kısa ömürlü credential ve federation modelleri tercih edilmelidir. Kimlik tasarımı iyi yapılırsa kullanıcı yaşam döngüsü ve yetki yönetimi büyük ölçüde sadeleşir.

Google Cloud IAM

IAM hangi principal'ın hangi kaynağa hangi role ile erişebileceğini belirler. Predefined role'lar çoğu senaryo için yeterlidir. Basic role'lar genellikle gereğinden geniş izinler içerdiği için kurumsal ortamda sınırlı kullanılmalıdır. Grup bazlı erişim yönetimi kullanıcı bazlı izinlerden daha sürdürülebilirdir. IAM düzenli olarak gözden geçirilmelidir.

Cloud Identity

Cloud Identity kullanıcı ve grup yönetiminde merkezi directory yaklaşımı sağlar. Kurumsal hesapların yaşam döngüsü tek noktadan yönetilebilir. Kullanıcı ayrıldığında erişimi merkezi olarak kaldırılabilir. Grup üyelikleri IAM politikalarına bağlanabilir. Directory tasarımı şirketin mevcut identity süreçleriyle birlikte planlanmalıdır.

OIDC

OIDC modern federation senaryolarında sık kullanılan protokollerden biridir. Workload ve kullanıcı kimliklerinin harici identity provider üzerinden doğrulanmasını sağlayabilir. Short-lived credential kullanımına yardımcı olur. Attribute mapping ile yetkilendirme kararları zenginleştirilebilir. Federation tasarımında token claim'leri dikkatle sınırlandırılmalıdır.

SAML

SAML özellikle kurumsal SSO entegrasyonlarında yaygın kullanılan standartlardan biridir. Kullanıcıların mevcut kimlik sistemi üzerinden Google Cloud erişimi sağlamasına yardımcı olabilir. Authentication merkezi kalır. Kullanıcı yaşam döngüsü süreçleri mevcut directory ile uyumlu yürütülebilir. SAML entegrasyonu yapılırken grup ve rol eşlemesi ayrıca planlanmalıdır.

Workforce Identity Federation Nedir?

Workforce Identity Federation, çalışanların ve harici kullanıcıların mevcut identity provider üzerinden Google Cloud kaynaklarına erişmesini sağlar. Her kullanıcıyı ayrı bir Google directory kaydıyla senkronize etmek gerekmeyen senaryolarda yararlı olabilir. Authentication mevcut kurum sisteminde gerçekleşir. Attribute mapping ve conditions üzerinden erişim kontrolleri uygulanabilir. Özellikle partner ve geçici kullanıcı modellerinde merkezi federation yaklaşımı operasyon yükünü azaltabilir.

Çalışan Kimlikleri

Çalışanlar mevcut kurumsal hesapları üzerinden Google Cloud'a erişebilir. Böylece ayrı parola yönetimi ihtiyacı azalır. Erişim gruplar veya attribute'lar üzerinden sınırlandırılabilir. Çalışan ayrıldığında kurum identity provider'ındaki hesabın kapatılması erişimi etkiler. Bu yaklaşım merkezi kullanıcı yaşam döngüsünü güçlendirir.

Partner Kimlikleri

Partner kullanıcıları kurum çalışanlarından ayrı erişim modeline sahip olmalıdır. Yalnızca gerekli proje veya kaynaklara erişim verilmelidir. Süreli erişim politikaları uygulanabilir. Attribute conditions belirli partner gruplarını sınırlandırabilir. Partner erişimleri düzenli olarak gözden geçirilmelidir.

Contractor Kimlikleri

Geçici çalışan hesapları uzun süreli kalıcı erişim riski taşır. Federation sayesinde kimlik kendi sağlayıcısında yönetilebilir. Erişim proje süresiyle sınırlandırılabilir. Production rollerinin verilmesi daha sıkı onaya bağlanabilir. Kontrat sona erdiğinde erişimin de otomatik olarak sona ermesi hedeflenmelidir.

Harici IdP Kullanımı

Harici identity provider mevcut kullanıcı doğrulama süreçlerinin korunmasını sağlar. Kullanıcı parolaları Google Cloud tarafında ayrıca yönetilmek zorunda kalmaz. Attribute mapping doğru tasarlanmalıdır. Issuer ve audience kontrolleri güvenlik açısından önemlidir. Federation konfigürasyonu değişiklik yönetimine dahil edilmelidir.

Identity Synchronization Olmadan Federation

Federation kullanıcı kaydını sürekli kopyalamadan erişim sağlayabilir. Bu model directory senkronizasyon ihtiyacını azaltır. Yetkilendirme token attribute'larına dayanabilir. Kullanıcının kimliği kaynak sistemde kalır. Buna rağmen erişim politikalarının merkezi audit edilmesi gerekir.

Attribute Mapping

Attribute mapping dış identity bilgisini Google Cloud tarafındaki erişim modeline dönüştürür. Grup, kullanıcı veya başka claim değerleri kullanılabilir. Çok geniş eşlemeler istenmeyen erişime yol açabilir. Mapping test ortamında doğrulanmalıdır. Değişiklikler version kontrollü süreçle yapılmalıdır.

Attribute Conditions

Attribute conditions yalnızca belirli özellikleri taşıyan kimliklerin erişmesini sağlar. Örneğin belirli grup veya organizasyon niteliği kontrol edilebilir. Bu yöntem federation güvenliğini güçlendirir. Conditions mümkün olduğunca açık ve okunabilir tutulmalıdır. Yanlış koşullar bütün kullanıcıların erişimini kesebileceği için test önemlidir.

SSO

SSO kullanıcıların mevcut kurumsal oturumuyla erişim sağlamasına yardımcı olur. Ayrı parola kullanımını azaltır. Kullanıcı deneyimini iyileştirir. Authentication politikaları merkezi kalır. MFA gibi kontroller identity provider üzerinde uygulanabilir.

Workforce Pool

Workforce pool harici kullanıcı kimliklerini mantıksal havuzda toplar. Farklı provider'lar aynı yapı içerisinde yönetilebilir. IAM politikaları pool principal'larına bağlanabilir. Pool tasarımı kullanıcı grupları ve erişim sınırlarına göre yapılmalıdır. Production ve harici kullanıcı erişimleri özellikle dar tutulmalıdır.

Cloud Identity mi Workforce Identity Federation mı?

İki model farklı ihtiyaçlara cevap verir. Directory senkronizasyonu, kullanıcı yaşam döngüsü ve mevcut çalışma araçları tercih üzerinde etkilidir. Yalnızca Google Cloud kaynaklarına erişmesi gereken harici kullanıcılar federation modelinden yararlanabilir. Kurumun merkezi kullanıcı dizini ve grup yapısı varsa directory tabanlı model daha uygun olabilir. Bazı büyük yapılarda iki yaklaşım birlikte kullanılır.

Directory Synchronization Gereksinimi

Kullanıcıların Google tarafında directory kaydına ihtiyaç duyduğu durumlarda synchronization değerlendirilebilir. Grup üyelikleri merkezi sisteme aktarılabilir. Yaşam döngüsü otomasyonu önemlidir. Eski kullanıcıların erişiminin otomatik kaldırılması gerekir. Sync sürecinin hata monitoring'i ayrıca kurulmalıdır.

Google Workspace Kullanımı

Google tabanlı çalışma ortamı kullanan kurumlarda directory yapısı cloud erişimiyle daha doğal bütünleşebilir. Kullanıcı ve grup yönetimi ortak süreçlerden yararlanır. Bununla birlikte production IAM yine minimum yetki prensibine göre tasarlanmalıdır. Her kullanıcıya geniş rol verilmemelidir. Workspace kullanımı otomatik olarak doğru IAM modeli anlamına gelmez.

Yalnızca Google Cloud Kaynaklarına Erişim

Harici kullanıcının yalnızca Google Cloud kaynaklarına erişmesi gerekiyorsa federation pratik olabilir. Ayrı hesap yaşam döngüsü yönetmek gerekmeyebilir. Erişim attribute üzerinden sınırlandırılabilir. Kullanıcı kendi identity provider'ında doğrulanır. Bu model özellikle geçici işbirliklerinde yararlıdır.

Partner ve Vendor Kullanıcıları

Partner kullanıcıları için ayrı bir erişim sınırı oluşturulmalıdır. Production admin rollerinden kaçınılmalıdır. Proje veya kaynak düzeyinde minimum erişim verilebilir. Erişim süresi sınırlandırılabilir. Periyodik access review uygulanması önemlidir.

Data Residency Gereksinimi

Kimlik verisinin nerede tutulduğu bazı kurumlar için önemli olabilir. Directory ve federation modellerinin veri akışı buna göre değerlendirilmelidir. Hukuki ekiplerin gereksinimleri teknik tasarıma dahil edilmelidir. Gerekli olmayan kullanıcı verilerinin kopyalanmasından kaçınılabilir. Data minimization ilkesi identity sistemleri için de geçerlidir.

Hibrit Identity Modeli

Büyük kurumlarda çalışanlar directory tabanlı, partnerler federation tabanlı yönetilebilir. Böylece her kullanıcı tipi için uygun yaşam döngüsü uygulanır. Ortak IAM standartları korunmalıdır. Loglar merkezi audit sistemine gönderilebilir. Hibrit model daha esnek olsa da dokümantasyonun açık olması gerekir.

Workload Identity Federation Nedir?

Workload Identity Federation, uygulamaların ve otomasyon sistemlerinin uzun ömürlü service account key saklamadan Google Cloud'a erişmesini sağlar. Kimlik doğrulama harici platformdan gelen kısa ömürlü token üzerinden yapılabilir. Bu yaklaşım credential sızıntısı riskini azaltır. CI/CD sistemleri ve on-premises workload'lar için özellikle değerlidir. Kurumsal güvenlik modelinde insan kimlikleri ile workload kimliklerinin ayrı değerlendirilmesini sağlar.

İnsan ve Workload Identity Arasındaki Fark

İnsan kullanıcıların erişim modeli ile uygulamaların erişim modeli aynı olmamalıdır. İnsanlar SSO ve MFA üzerinden doğrulanabilir. Workload'lar makine kimliği kullanmalıdır. Runtime servislerin kişisel kullanıcı credential'ı kullanması ciddi operasyon sorunu yaratır. Her workload ayrı sorumluluk sınırına sahip olmalıdır.

Service Account Key Problemi

Service account key dosyaları uzun süre geçerli olabildiği için sızıntı riski taşır. Repository veya build loglarına yanlışlıkla eklenebilir. Kimin kullandığını takip etmek zorlaşabilir. Rotation süreçleri ek operasyon yükü oluşturur. Federation mümkün olduğunda statik anahtara olan ihtiyacı azaltır.

Short-Lived Credentials

Kısa ömürlü credential çalınsa bile kullanım süresini sınırlar. Otomatik olarak yenilenebilir. Manuel key rotation ihtiyacını azaltır. Erişim mevcut identity provider ile ilişkilendirilebilir. Production otomasyonlarında bu model daha güvenli bir varsayılan oluşturur.

Security Token Service

Security Token Service harici credential'ların Google Cloud erişim token'larına dönüştürülmesini destekler. Federation modelinin önemli parçasıdır. Token exchange belirli provider ve attribute kurallarına göre yapılır. Yetkilendirme yine IAM üzerinden kontrol edilir. Provider yapılandırması yanlışsa gereğinden geniş erişim oluşabileceği için test edilmelidir.

OIDC

OIDC birçok modern CI/CD ve workload platformunda federation için kullanılabilir. Workload kendi platformundan imzalı kimlik token'ı alır. Google Cloud bu token'ı doğrular. Statik key saklama ihtiyacı azalır. Audience ve subject kontrolleri güvenli tasarım için önemlidir.

On-Premises Workload Federation

Şirket içindeki uygulamalar da uygun harici kimlik altyapısı üzerinden federation kullanabilir. Böylece veri merkezinde service account JSON anahtarı saklamak gerekmeyebilir. Workload kimliği erişeceği kaynaklarla sınırlandırılabilir. Network bağlantısı ile identity birbirinden bağımsız güvenlik katmanları olarak ele alınmalıdır. Bu yaklaşım hybrid cloud güvenliğini güçlendirir.

Service Account Key Kullanmadan Google Cloud'a Erişim

Kurumsal güvenlikte hedeflerden biri uzun ömürlü service account key kullanımını mümkün olduğunca azaltmaktır. Workload Identity Federation bu hedefe ulaşmak için kullanılabilir. Harici workload doğrulanır ve kısa süreli Google credential elde eder. Böylece JSON key dosyasının source code, CI secret veya sunucu üzerinde saklanmasına ihtiyaç azalır. Least privilege ile birleştirildiğinde oldukça güçlü bir erişim modeli oluşur.

Long-Lived Key Riskleri

Uzun ömürlü anahtarın sızması uzun süre yetkisiz erişime yol açabilir. Anahtarın nerelerde kopyalandığını bilmek zor olabilir. Rotation unutulabilir. Kullanılmayan key'ler yıllarca aktif kalabilir. Kurumsal policy ile yeni key oluşturma sınırlandırılabilir.

Workload Identity Pool

Workload identity pool harici workload kimliklerini mantıksal grupta toplar. Farklı provider'lar bu pool içerisinde tanımlanabilir. IAM politikaları federated principal'lara bağlanabilir. Her workload için açık erişim sınırları oluşturulmalıdır. Pool isimlendirmesi operasyon ekiplerinin sistemi anlamasını kolaylaştırmalıdır.

Workload Identity Provider

Provider harici token kaynağının nasıl doğrulanacağını tanımlar. Issuer ve audience bilgileri güvenlik için kritiktir. Provider yalnızca beklenen token'ları kabul etmelidir. Attribute mapping erişim modelini etkiler. Değişiklikler test ve review sürecinden geçirilmelidir.

Attribute Mapping

Mapping harici token claim'lerini Google Cloud principal özelliklerine dönüştürür. Repository, branch veya workload adı gibi bilgiler kullanılabilir. Aşırı genel mapping geniş erişime neden olabilir. Production deployment yalnızca belirli branch veya environment ile sınırlandırılabilir. Mapping kuralları güvenlik testlerine dahil edilmelidir.

Direct Resource Access

Bazı senaryolarda federated principal doğrudan kaynak üzerinde IAM yetkisi alabilir. Böylece service account impersonation gerekmeyebilir. Model daha sade hale gelir. Ancak resource desteği ve operasyon gereksinimi değerlendirilmelidir. IAM politikaları merkezi standarda uygun tutulmalıdır.

Service Account Impersonation

Federated principal sınırlı bir service account'u impersonate ederek kaynaklara erişebilir. Bu model mevcut IAM yapılarıyla uyumlu olabilir. Service account'a yalnızca gerekli roller verilmelidir. Impersonation yetkisi de dar tutulmalıdır. Audit loglar kimliğin kaynağını izlemek için kullanılabilir.

Least Privilege

Federation kullanmak tek başına yeterli güvenlik sağlamaz. Workload yalnızca ihtiyaç duyduğu kaynaklara erişmelidir. Geniş project rollerinden kaçınılmalıdır. Kullanılmayan permission'lar düzenli review ile kaldırılabilir. Least privilege hem insan hem workload kimlikleri için temel ilkedir.

Google Cloud IAM Nasıl Tasarlanmalı?

IAM tasarımı kurumsal platformun güvenliğini doğrudan belirler. Kullanıcı bazlı dağınık yetkiler yerine grup ve rol bazlı model tercih edilmelidir. Basic rollerden mümkün olduğunca kaçınılmalı, predefined veya gerektiğinde custom roller kullanılmalıdır. Production ortamında admin erişimleri sınırlı ve denetlenebilir olmalıdır. IAM düzenli olarak gözden geçirilmeli ve artık kullanılmayan erişimler kaldırılmalıdır.

Principal

Principal erişim isteyen kullanıcı, grup veya workload kimliğidir. İnsan ve workload principal'ları ayrılmalıdır. Grup kullanımının operasyonel avantajı büyüktür. Bireysel kullanıcıya doğrudan rol vermek zamanla yönetimi zorlaştırır. Principal sahipliği kayıt altında tutulmalıdır.

Role

Role belirli permission'ların paketlenmiş halidir. Predefined roller çoğu ihtiyaç için yeterli olabilir. Çok geniş roller güvenlik riskini artırır. Custom role yalnızca gerçekten gerekli olduğunda oluşturulmalıdır. Roller periyodik olarak incelenmelidir.

Permission

Permission belirli bir işlemin yapılmasına izin verir. IAM tasarımının en küçük yetki birimidir. Kullanıcıların ihtiyaç duyduğu işlemler analiz edilmelidir. Gereksiz permission erişim kapsamını genişletir. Role seçiminde gerçek iş görevleri esas alınmalıdır.

Policy

IAM policy principal ve role ilişkisini kaynak üzerinde tanımlar. Organization, Folder, Project veya bazı resource seviyelerinde uygulanabilir. Çok dağınık policy yapısı troubleshooting süresini artırır. Mümkün olduğunca standart seviyeler tercih edilmelidir. Policy değişiklikleri audit edilmelidir.

Predefined Roles

Predefined roles servis ihtiyaçlarına göre hazırlanmış rol setleridir. Basic rollerden genellikle daha dar erişim sağlar. Kurumsal ortamda ilk tercih olabilir. Yine de her predefined rolün içerdiği permission'lar kontrol edilmelidir. Gereğinden genişse custom role değerlendirilebilir.

Custom Roles

Custom role özel iş ihtiyacına göre permission seti tanımlamayı sağlar. Çok sayıda custom role oluşturmak bakım yükü yaratır. Önce predefined rol seçenekleri değerlendirilmelidir. Custom roller versiyon değişiklikleriyle izlenmelidir. Sahibi belli olmayan roller zaman içinde risk oluşturabilir.

Basic Roles'dan Kaçınmak

Basic roller genellikle geniş erişim içerir. Kurumsal production ortamında bu erişimler ihtiyaçtan fazlasını sağlayabilir. Daha dar predefined roller tercih edilmelidir. Eski projelerde basic role kullanımını azaltmak için aşamalı çalışma yapılabilir. Role değişikliği öncesinde gerçek permission kullanımı incelenmelidir.

Group-Based Access

Group-based erişim kullanıcı yaşam döngüsünü sadeleştirir. Yeni çalışan ilgili gruba eklenir ve gerekli erişimi alır. Ayrıldığında grup üyeliği kaldırılır. IAM policy'de yüzlerce bireysel kullanıcı bulunmaz. Grupların sahipleri ve amaçları dokümante edilmelidir.

Least Privilege

Least privilege kullanıcının görevini yapması için gereken minimum yetkiyi almasını hedefler. Başlangıçta geniş rol verip sonra daraltmak çoğu zaman unutulur. Bu nedenle ilk erişim mümkün olduğunca sınırlı verilmelidir. Gereksinim arttıkça kontrollü biçimde genişletilebilir. Access review süreçleri kullanılmayan izinleri tespit eder.

Deployment ve Runtime Identity Neden Ayrılmalıdır?

Deployment sistemi ile çalışan uygulama aynı kimliği kullanmamalıdır. Deployment platformunun yeni sürüm yükleme ve altyapı değiştirme yetkileri olabilir. Runtime uygulamanın ise yalnızca veri tabanı veya mesaj servisine erişmesi gerekebilir. Aynı kimlik kullanılırsa uygulama ele geçirildiğinde deployment yetkileri de saldırganın eline geçebilir. Ayrı identity modeli blast radius'ı küçültür ve audit kayıtlarını daha anlaşılır hale getirir.

CI/CD Service Identity

CI/CD identity yalnızca deployment için gerekli rolleri almalıdır. Infrastructure provisioning ayrı identity ile yapılabilir. Production deployment erişimi belirli repository veya branch ile sınırlandırılabilir. Federation statik key ihtiyacını azaltır. CI/CD işlemleri merkezi loglanmalıdır.

Runtime Service Identity

Runtime identity uygulamanın çalışırken kullandığı kimliktir. Veri tabanı ve storage erişimleri bu kimlik üzerinden verilir. Deployment yetkisi bulunmamalıdır. Her servis için ayrı identity kullanmak hata alanını küçültür. Uygulama kapatıldığında identity erişimi de kaldırılmalıdır.

Data Access

Runtime uygulama yalnızca ihtiyaç duyduğu veri kaynaklarına erişmelidir. Bir servisin bütün project verilerine erişmesi gerekmeyebilir. Dataset veya resource bazlı sınırlar kullanılabilir. Audit loglar veri erişimini izlemeye yardımcı olur. Hassas verilere yönelik roller ayrıca gözden geçirilmelidir.

Infrastructure Provisioning

Infrastructure provisioning geniş resource oluşturma izinleri gerektirebilir. Bu yetkiler runtime uygulamaya verilmemelidir. Terraform pipeline ayrı service identity kullanabilir. Apply işlemleri review sürecine bağlanabilir. Provisioning logları merkezi audit sistemine gönderilmelidir.

Blast Radius

Blast radius identity ayrımıyla azaltılabilir. Bir uygulama ele geçirilse bile yalnızca kendi kaynaklarına erişebilmelidir. Ortak geniş service account kullanımı bu sınırı ortadan kaldırır. Project ve IAM izolasyonu birlikte uygulanmalıdır. Güvenlik mimarisi bir credential'ın ihlal edildiği senaryoyu da hesaba katmalıdır.

Credential Isolation

Her servis ayrı credential modeli kullandığında erişim daha net izlenir. Ortak anahtarların paylaşılması önlenir. Federation kullanılıyorsa credential kısa ömürlü olabilir. Secret rotation yükü azalır. Identity sahipliği uygulama envanterine eklenmelidir.

Privileged Access Nasıl Yönetilmeli?

Kalıcı admin erişimi kurumsal güvenlikte önemli risklerden biridir. Günlük işi geliştirme olan bir kullanıcının sürekli Organization seviyesinde geniş yetkiye sahip olması gerekmez. Just-in-Time ve time-bound access modelleri ihtiyaç duyulduğu anda geçici yetki sağlar. Kritik işlemler için approval süreci uygulanabilir. Break-glass hesaplar ise yalnızca normal erişim sistemlerinin kullanılamadığı acil durumlar için tutulmalıdır.

Permanent Admin Access Riski

Kalıcı admin rolü hesabın ele geçirilmesi durumunda geniş etki oluşturur. Kullanıcı aylar boyunca bu yetkiye ihtiyaç duymayabilir. Yetkinin aktif kalması gereksiz risk yaratır. Düzenli access review yapılmalıdır. Mümkünse ayrı privileged access süreci kullanılmalıdır.

Just-in-Time Access

Just-in-Time access ihtiyaç anında kısa süreli yetki sağlar. Kullanıcı görevini tamamladıktan sonra rol sona erer. Bu yaklaşım kalıcı admin erişimini azaltır. Onay ve gerekçe kaydı audit sürecini güçlendirir. Acil durum senaryoları ayrıca tasarlanmalıdır.

Privileged Access Manager

Privileged Access Manager süreli ayrıcalıklı erişim süreçleri oluşturmak için kullanılabilir. Erişim talebi belirli rol ve kaynakla sınırlandırılabilir. Onay mekanizması eklenebilir. Süre dolduğunda yetki otomatik sona erebilir. Bu model production yönetiminde faydalıdır.

Approval

Approval kritik rollere erişimin ikinci göz tarafından kontrol edilmesini sağlar. Talep gerekçesi kayıt altına alınabilir. Her işlem için çok ağır süreç kurmak operasyonu yavaşlatabilir. Risk bazlı onay modeli kullanılmalıdır. Acil güvenlik olaylarında hızlı ama audit edilebilir yol bulunmalıdır.

Time-Bound Access

Time-bound access yetkiyi belirli süreyle sınırlar. Uzun süredir unutulmuş admin rollerini azaltır. Bakım çalışması için birkaç saatlik erişim yeterli olabilir. Süre sonunda otomatik kaldırma operasyon yükünü azaltır. Yenileme gerektiğinde yeni talep oluşturulmalıdır.

Break-Glass Account

Break-glass hesap yalnızca acil durum için saklanmalıdır. Günlük operasyonlarda kullanılmamalıdır. Güçlü kimlik doğrulama ve alarm mekanizması bulunmalıdır. Her kullanım güvenlik olayına benzer şekilde incelenmelidir. Hesabın çalıştığı periyodik olarak test edilmelidir.

Admin İşlemlerini Audit Etmek

Admin işlemleri Cloud Audit Logs üzerinden merkezi olarak izlenmelidir. Kritik policy ve IAM değişiklikleri için alert oluşturulabilir. Kim, ne zaman, hangi kaynağı değiştirdi sorularına hızlı cevap verilebilmelidir. Audit retention kurum gereksinimine göre belirlenmelidir. Loglara erişim de ayrıca sınırlandırılmalıdır.

Organization Policy ile Governance

Organization Policy kurumsal Google Cloud ortamında merkezi guardrail oluşturmak için kullanılır. Amaç ekiplerin her işlemini manuel onaya bağlamak değil, riskli yapılandırmaların otomatik olarak sınırlandırılmasıdır. External IP, resource location, public paylaşım ve service account key gibi konularda politika uygulanabilir. Policy inheritance sayesinde kurallar alt kaynaklara aktarılabilir. İstisnaların ise kayıtlı, süreli ve sorumlu kişisi belli bir süreç üzerinden yönetilmesi gerekir.

Organization Policy Nedir?

Organization Policy kaynak konfigürasyonları üzerinde merkezi kısıtlar uygulamaya yardımcı olur. Hiyerarşinin üst seviyesinde tanımlanabilir. Alt project'ler politikayı miras alabilir. Güvenlik standartlarının bütün organizasyona yayılmasını sağlar. Yeni policy production öncesinde test edilmelidir.

Resource Location Restriction

Resource location restriction belirli kaynakların izin verilen bölgelerde oluşturulmasını sağlayabilir. Veri yerleşimi gereksinimi bulunan kurumlarda yararlıdır. Servislerin location davranışı ayrıca anlaşılmalıdır. Her kaynağın region kavramı aynı değildir. Politika iş ve hukuk ekiplerinin gereksinimleriyle uyumlu olmalıdır.

External IP Restriction

External IP kullanımı gereksiz internet erişim yüzeyi oluşturabilir. Production VM'lerinde private IP ve kontrollü egress tercih edilebilir. Gereken istisnalar ayrıca onaylanmalıdır. Cloud NAT dış bağlantı ihtiyacında kullanılabilir. Public erişim gereken servislerde katmanlı güvenlik uygulanmalıdır.

Service Account Key Restriction

Service account key oluşturmayı sınırlandırmak credential riskini azaltır. Workload Identity Federation gibi alternatifler değerlendirilmelidir. Zorunlu legacy kullanım varsa istisna kaydı tutulmalıdır. Key rotation ve kullanım monitoring'i uygulanmalıdır. Uzun ömürlü anahtar varsayılan çözüm olmamalıdır.

Public Storage Restriction

Storage kaynaklarının yanlışlıkla public hale gelmesi hassas veri sızıntısına yol açabilir. Merkezi policy public erişimi sınırlandırabilir. Public içerik gerekiyorsa ayrı ve kontrollü proje kullanılabilir. Veri sınıflandırması storage tasarımına bağlanmalıdır. Public ayar değişiklikleri için alert oluşturulabilir.

Domain Restricted Sharing

Domain restricted sharing kaynakların yetkisiz dış kimliklerle paylaşılmasını sınırlamaya yardımcı olabilir. Kurumsal veri sınırlarını güçlendirir. Partner erişimi gerektiğinde kontrollü istisna süreci tasarlanmalıdır. Identity federation seçenekleri değerlendirilebilir. Politika değişikliği mevcut entegrasyonları etkilemeden önce test edilmelidir.

Policy Inheritance

Inheritance merkezi policy'nin alt folder ve project'lere uygulanmasını sağlar. Bu model yüzlerce project'in tek tek yönetilmesini önler. Ancak üst seviyedeki yanlış policy çok geniş etki oluşturabilir. Değişiklikler test edilmelidir. Dry-run veya kontrollü rollout yaklaşımı tercih edilebilir.

Exception Süreci

Her kuralın gerçek hayatta istisnası olabilir. Önemli olan istisnanın kontrolsüz kalmamasıdır. Talep gerekçesi, sahibi ve sona erme tarihi tutulmalıdır. Süresi dolan istisna otomatik gözden geçirilmelidir. Kalıcı istisnalar politika tasarımının yeniden değerlendirilmesi gerektiğini gösterebilir.

Policy as Code Nasıl Uygulanır?

Policy as Code kurumsal güvenlik standartlarını kod haline getirerek CI/CD süreçlerine bağlar. Böylece yanlış altyapı yapılandırmaları production'a ulaşmadan tespit edilebilir. Terraform değişiklikleri pull request sırasında kontrol edilebilir. Preventive kontroller hatalı kaynağı engellerken detective kontroller mevcut ortamda kural dışı durumları bulur. İstisna yönetimi de aynı repository ve review süreçleri içerisinde yürütülebilir.

IaC Validation

IaC validation kodun kurumsal standartlara uygunluğunu kontrol eder. Public IP, region veya IAM gibi kurallar otomatik incelenebilir. Hatalar pull request aşamasında geliştiriciye gösterilir. Production deployment'a kadar beklemek gerekmez. Kurallar açık dokümantasyonla desteklenmelidir.

Preventive Controls

Preventive control riskli yapılandırmanın oluşmasını engeller. Organization Policy buna örnek olabilir. CI pipeline içindeki policy check de benzer görev görür. Çok katı kontroller gerekli geliştirme süreçlerini engelleyebilir. Bu nedenle kontrollü istisna mekanizması bulunmalıdır.

Detective Controls

Detective control mevcut ortamda kural dışı kaynakları tespit eder. Configuration drift ve eski projeler için önemlidir. Bulgular merkezi dashboard üzerinde takip edilebilir. Yalnızca alert üretmek yeterli değildir. Remediation sahibi ve süresi belirlenmelidir.

Pull Request Security Checks

Security check altyapı değişikliğini uygulanmadan önce inceler. Geniş IAM rolü veya açık firewall gibi riskler işaretlenebilir. Otomatik kontrol manuel review süresini azaltır. Kritik değişiklikler ayrıca insan onayına yönlendirilebilir. Sonuçların geliştiriciye anlaşılır mesaj vermesi gerekir.

Policy Exceptions

İstisna politikayı tamamen devre dışı bırakmak anlamına gelmemelidir. Belirli kaynak, süre ve gerekçeyle sınırlandırılmalıdır. Repository üzerinden yönetilebilir. Güvenlik sahibi tarafından onaylanabilir. İstisna sona erdiğinde standart policy yeniden uygulanmalıdır.

Exception Expiration

Süresiz istisnalar zamanla kalıcı güvenlik açığına dönüşebilir. Her exception için expiration tarihi belirlenmelidir. Süre yaklaşınca sorumlu ekibe bildirim gönderilebilir. Devam etmesi gerekiyorsa yeniden değerlendirme yapılmalıdır. Böylece eski gerekçeler otomatik olarak yıllarca yaşamaz.

Audit

Policy değişiklikleri ve istisnalar audit edilebilir olmalıdır. Git geçmişi teknik değişikliği gösterir. Cloud Audit Logs gerçek ortamdaki uygulamayı izler. Onay kayıtları iş gerekçesini açıklar. Bu üç kaynak birlikte güçlü governance kanıtı oluşturur.

Kurumsal Google Cloud Network Mimarisi

Network, şirket içi sistemler Google Cloud ile nasıl entegre edilir sorusunun merkezindedir. Kurumsal mimaride VPC, subnet, routing, DNS, firewall ve NAT birlikte tasarlanmalıdır. On-premises bağlantılarının IP planı Google Cloud adresleriyle çakışmamalıdır. Production trafiğinde tek bağlantı noktasına bağımlılık bırakılmamalıdır. Network ekibi ile uygulama ekiplerinin sorumluluklarını ayırmak Shared VPC gibi modellerle mümkün olabilir.

VPC Nedir?

VPC Google Cloud kaynaklarının özel network alanını oluşturur. Subnet ve routing yapıları bu ağ içerisinde tanımlanır. Firewall politikaları erişimi kontrol eder. Kurumsal ortamda VPC isimlendirme ve IP planı standardize edilmelidir. Her uygulama için ayrı VPC oluşturmak her zaman gerekli değildir.

Global VPC

Google Cloud VPC yapısı global kapsamda çalışabilir. Farklı region'lardaki subnet'ler aynı VPC altında bulunabilir. Bu özellik merkezi network tasarımını kolaylaştırabilir. Buna rağmen veri ve uygulama yerleşimi bölgesel olarak planlanmalıdır. Routing etkileri değişiklik öncesinde test edilmelidir.

Subnet

Subnet belirli region için IP aralığı tanımlar. CIDR boyutu gelecekteki büyümeyi dikkate almalıdır. Çok küçük subnet daha sonra kapasite sorunu oluşturabilir. Çok büyük aralık ise diğer network'lerle çakışma riskini artırır. Merkezi IP address management süreci faydalıdır.

Region

Region workload'un fiziksel çalışma bölgesini etkiler. Latency, veri yerleşimi ve disaster recovery kararlarıyla ilişkilidir. Kullanıcıya yakın region tercih etmek her zaman tek kriter değildir. Kurumsal bağlantı noktaları ve veri kaynakları da değerlendirilmelidir. Bölgesel arıza senaryosu ayrıca planlanmalıdır.

Routing

Routing trafiğin hangi yoldan gideceğini belirler. Hybrid cloud ortamlarında Cloud Router ve BGP dinamik rota paylaşımına yardımcı olabilir. Yanlış rota geniş çaplı erişim sorunları oluşturabilir. Route değişiklikleri kontrollü yapılmalıdır. Monitoring üzerinden beklenmeyen trafik yolları takip edilebilir.

Firewall

Firewall kuralları minimum gerekli trafiğe izin vermelidir. Geniş kaynak ve hedef aralıkları risklidir. Uygulama portları sahipleriyle birlikte doğrulanmalıdır. Legacy sistemlerde bilinmeyen port kullanımları dependency discovery sırasında ortaya çıkarılabilir. Kural değişiklikleri merkezi audit edilmelidir.

DNS

DNS hybrid cloud entegrasyonunda çoğu zaman gözden kaçan kritik servistir. Şirket içi domain'ler ile Google Cloud private zone'ları birlikte çalışmalıdır. Forwarding ve split-horizon senaryoları tasarlanabilir. DNS kesintisi network bağlantısı çalışsa bile uygulamaları erişilemez hale getirebilir. Production öncesi DNS testleri zorunlu olmalıdır.

NAT

Cloud NAT private VM'lerin public IP almadan internet yönüne çıkmasına yardımcı olur. Production compute kaynaklarında bu model güvenlik açısından avantajlıdır. Port kapasitesi trafik hacmine göre planlanmalıdır. NAT logları troubleshooting için kullanılabilir. Egress trafiği maliyet açısından da izlenmelidir.

Shared VPC Nedir?

Shared VPC network yönetimini merkezi ekipte tutarken uygulama kaynaklarının farklı service project'lerde çalışmasına imkân verir. Büyük kurumlarda network ekibi ile application ekiplerinin görevlerini ayırmak için etkili bir modeldir. Host project ortak VPC kaynaklarını barındırır. Service project'ler bu network kaynaklarını kullanır. Bu yapı standardizasyon sağlarken doğru IAM tasarımı yapılmazsa operasyon süreçleri yavaşlayabilir.

Host Project

Host project Shared VPC network kaynaklarını barındırır. Subnet ve firewall yönetimi merkezi tutulabilir. Erişim yalnızca network ekibine verilebilir. Host project içerisinde uygulama workload'u çalıştırmamak yönetimi sadeleştirebilir. Değişiklikler IaC üzerinden yapılmalıdır.

Service Project

Service project uygulama kaynaklarını barındırır. Uygulama ekibi kendi compute kaynaklarını yönetebilir. Network temel yapısı host project'ten gelir. Böylece görev ayrımı sağlanır. Billing yine project bazında takip edilebilir.

Merkezi Network Yönetimi

Merkezi network yönetimi IP planı ve firewall standardını korur. Her uygulama ekibinin farklı network yaklaşımı geliştirmesi önlenir. Ortak hybrid bağlantılar daha kolay paylaşılır. Bununla birlikte network ekibinin darboğaz oluşturmaması gerekir. Self-service subnet veya firewall talepleri otomasyonla desteklenebilir.

Network Team ve Application Team Ayrımı

Network ekibi bağlantı, routing ve güvenlik sınırlarını yönetebilir. Application ekibi workload ve deployment süreçlerinden sorumlu olur. IAM bu görev ayrımını desteklemelidir. Ortak değişikliklerde RACI açık olmalıdır. Böylece sorun yaşandığında sorumluluk belirsizliği azalır.

Environment Başına Shared VPC

Production ve development için ayrı Shared VPC kullanmak izolasyonu güçlendirebilir. Firewall politikaları farklı uygulanabilir. Production erişimi daha dar tutulabilir. IP planı yine merkezi koordinasyon gerektirir. Ortam sayısı arttıkça yönetim otomasyona bağlanmalıdır.

Shared VPC Avantajları

Shared VPC merkezi yönetim ve uygulama izolasyonunu bir araya getirir. Network standartları korunur. Service project sayısı yüksek ortamlarda tekrar eden network kurulumları azalır. Hybrid bağlantılar ortak kullanılabilir. Platform engineering yaklaşımıyla iyi uyum sağlar.

Shared VPC Dezavantajları

Merkezi model yanlış süreç tasarımında network ekibini darboğaza dönüştürebilir. IAM rolleri ilk başta anlaşılması zor olabilir. Çok fazla host project operasyon yükünü artırır. Resource ownership açık tanımlanmalıdır. Automation eksikse proje onboarding süreçleri yavaşlayabilir.

Hub-and-Spoke Network Mimarisi

Hub-and-spoke modeli farklı network alanlarının merkezi hub üzerinden bağlanmasını sağlar. Ortak inspection, routing veya hybrid connectivity servisleri hub katmanında konumlandırılabilir. Spoke network'ler uygulama veya environment bazında ayrılabilir. Model büyük ve çok segmentli organizasyonlarda yararlı olabilir. Ancak her trafiği zorunlu olarak merkezi noktadan geçirmek latency ve maliyet üzerinde etkili olabileceği için trafik akışı dikkatle planlanmalıdır.

Hub VPC

Hub VPC merkezi connectivity ve network servislerini barındırabilir. Hybrid bağlantılar burada sonlandırılabilir. Inspection servisleri merkezi konumlandırılabilir. Hub erişimleri network ekibiyle sınırlandırılmalıdır. Tek hata noktasına dönüşmemesi için yüksek erişilebilirlik planlanmalıdır.

Spoke VPC

Spoke VPC uygulama veya environment alanlarını ayırır. Merkezi hub ile kontrollü bağlantı kurar. Bu model network segmentasyonunu güçlendirebilir. Spoke sayısı büyüdükçe otomasyon ihtiyacı artar. IP planı bütün spoke'ları kapsamalıdır.

Merkezi Firewall

Merkezi firewall ortak güvenlik politikalarının uygulanmasını kolaylaştırabilir. Trafik inspection için hub üzerinden yönlendirilebilir. Ancak trafik yolları gereksiz uzamamalıdır. Performance testleri yapılmalıdır. Kritik firewall değişikliklerinde rollback planı bulunmalıdır.

Inspection

Inspection belirli trafiklerin güvenlik kontrolünden geçirilmesini sağlar. Hangi trafiklerin inspection gerektirdiği risk bazlı belirlenmelidir. Bütün doğu-batı trafiğini aynı noktadan geçirmek kapasite ihtiyacını büyütebilir. Loglar merkezi SIEM sistemine aktarılabilir. Inspection altyapısı yedekli tasarlanmalıdır.

Routing

Hub-and-spoke modelinin başarısı routing tasarımına bağlıdır. Spoke'lar arasında hangi trafiğin izinli olduğu açıkça tanımlanmalıdır. Hybrid rotalar yanlış yayılırsa trafik beklenmeyen noktaya gidebilir. Route değişiklikleri otomatik testlerle doğrulanabilir. Network diagramlarının güncel tutulması önemlidir.

Shared VPC vs Hub-and-Spoke

Shared VPC ortak network kaynaklarını service project'lerle paylaşır. Hub-and-spoke ise bağımsız network alanlarını merkezi bağlantı noktasında birleştirir. İki model birbirinin doğrudan alternatifi olmak zorunda değildir. Büyük yapılarda birlikte kullanılabilir. Seçim izolasyon, ekip yapısı ve routing gereksinimine göre yapılmalıdır.

Hangi Model Ne Zaman Kullanılmalı?

Daha merkezi ve ortak network isteyen yapılarda Shared VPC uygun olabilir. Güçlü segmentasyon veya ayrı network domain'leri gereken yapılarda hub-and-spoke değerlendirilebilir. Regülasyon gerektiren workload'lar ayrı spoke üzerinde tutulabilir. Tasarımın operasyon ekibinin yönetebileceği seviyede kalması önemlidir. Gereğinden fazla segmentasyon troubleshooting süresini artırabilir.

IP Adres Planlaması

IP planlaması hybrid ve multi-cloud projelerin en erken yapılması gereken çalışmalarından biridir. On-premises CIDR aralıklarının Google Cloud ile çakışması network entegrasyonunu ciddi biçimde zorlaştırabilir. GKE gibi platformlar secondary IP ranges ihtiyacı oluşturabilir. Gelecekte eklenecek region ve environment'lar için alan bırakılmalıdır. IP Address Management süreci merkezi tutulduğunda ekiplerin aynı CIDR aralığını tekrar kullanma riski azalır.

RFC1918

Özel IP adres alanları kurumsal internal network'lerde yaygın kullanılır. Hangi aralıkların nerede kullanıldığı merkezi envanterde tutulmalıdır. Yeni subnet oluşturulmadan önce çakışma kontrolü yapılmalıdır. Satın alınan şirketlerin network'leri de hesaba katılmalıdır. Hybrid connectivity sırasında overlapping CIDR ciddi problem oluşturabilir.

CIDR

CIDR subnet boyutunu ve adres alanını belirler. Çok dar aralık büyüme sorununa yol açabilir. Çok geniş blok ise gelecekteki network'ler için alan bırakmayabilir. Kullanım senaryosu ve büyüme beklentisi birlikte değerlendirilmelidir. Adres planı dokümante edilmelidir.

Subnet Sizing

Subnet sizing workload sayısı ve ölçekleme beklentisine göre yapılmalıdır. GKE node ve pod ağları ek IP tüketebilir. Autoscaling senaryoları hesaba katılmalıdır. Subnet genişletme imkanları tasarım sırasında değerlendirilmelidir. Rastgele büyük aralıklar ayırmak iyi planlama değildir.

IP Address Management

IPAM merkezi IP kullanım görünürlüğü sağlar. On-premises, Google Cloud ve diğer network alanları aynı envanterde tutulabilir. Yeni proje talebinde otomatik CIDR tahsisi yapılabilir. Çakışma riski azalır. IP sahipliği ve kullanım amacı kayıt altında olmalıdır.

On-Prem CIDR'larla Çakışma

On-premises ve Google Cloud aynı CIDR aralığını kullanırsa routing belirsiz hale gelir. NAT geçici çözüm olabilir ancak mimariyi zorlaştırır. Bu nedenle cloud subnet oluşturulmadan önce mevcut adres planı incelenmelidir. Çakışma bulunursa yeniden numaralandırma maliyeti değerlendirilmelidir. Uzun vadede benzersiz adres alanı daha sağlıklı çözümdür.

GKE Secondary IP Ranges

GKE VPC-native yapıda pod ve service adresleri için secondary ranges kullanabilir. Bu aralıklar baştan planlanmalıdır. Cluster büyümesi IP tüketimini artırır. Çok sayıda cluster varsa merkezi kapasite hesabı yapılmalıdır. IP yetersizliği production ölçeklemesini engelleyebilir.

Gelecekteki Büyümeyi Planlamak

IP planı yalnızca mevcut sunucu sayısına göre yapılmamalıdır. Yeni region, yeni ekip ve satın alma senaryoları hesaba katılmalıdır. Rezerve adres blokları belirlenebilir. Plan yılda en az bir kez gözden geçirilebilir. Böylece platform büyüdükçe yeniden numaralandırma ihtiyacı azalır.

Hybrid Cloud Network Bağlantısı Nasıl Kurulur?

Hybrid cloud bağlantısı şirket içi veri merkezi ile Google Cloud VPC arasında güvenilir trafik yolu oluşturur. Başlangıç veya düşük trafik senaryolarında Cloud VPN kullanılabilir. Daha yüksek bant genişliği ve daha öngörülebilir performans ihtiyacında Cloud Interconnect değerlendirilebilir. Cloud Router ve BGP dinamik rota paylaşımını kolaylaştırır. Mission-critical sistemlerde bağlantıların farklı cihaz ve fiziksel yollar üzerinden yedeklenmesi tek noktaya bağımlılığı azaltır.

On-Premises Data Center

Şirket içi veri merkezinin network envanteri çıkarılmalıdır. Router, firewall ve CIDR bilgileri doğrulanmalıdır. Cloud tarafına hangi network'lerin ilan edileceği belirlenmelidir. Güvenlik ekipleri izinli portları listelemelidir. Bağlantı kapasitesi gerçek trafik ölçümüne göre seçilmelidir.

Google Cloud VPC

Cloud tarafındaki VPC şirket içi adreslerle çakışmamalıdır. Subnet ve routing tasarımı hybrid bağlantıyı desteklemelidir. Private kaynaklara erişim gereksinimleri tanımlanmalıdır. DNS entegrasyonu ayrıca yapılmalıdır. Connection monitoring ile bağlantı sağlığı izlenebilir.

Cloud VPN

Cloud VPN IPsec tabanlı bağlantı sağlar. HA VPN yüksek erişilebilir hybrid bağlantılar için tercih edilebilir. Kurulum süresi genellikle fiziksel bağlantı seçeneklerine göre daha kısadır. Internet üzerinden çalıştığı için latency değişken olabilir. Kritik sistemlerde yedek yol olarak da kullanılabilir.

Cloud Interconnect

Cloud Interconnect yüksek bant genişliği gerektiren kurumsal bağlantılarda değerlendirilebilir. Dedicated ve partner modelleri farklı bağlantı ihtiyaçlarına cevap verir. Fiziksel ve operasyonel hazırlık VPN'e göre daha uzun sürebilir. Redundant bağlantı tasarımı önemlidir. Kritik sistemlerde farklı fiziksel yollar tercih edilmelidir.

Cloud Router

Cloud Router BGP üzerinden dinamik rota alışverişini destekler. Hybrid ağ değişikliklerinin manuel route güncellemesi olmadan yayılmasını kolaylaştırır. Route advertisement politikaları dikkatle yönetilmelidir. Yanlış ilan geniş network etkisi oluşturabilir. Router metric ve session durumu monitoring'e eklenmelidir.

BGP

BGP on-premises ve cloud network'leri arasında dinamik routing sağlar. Prefix filtreleri gereksiz route yayılımını önleyebilir. Session kesintileri için alert oluşturulmalıdır. Failover davranışı test edilmelidir. Network ekibinin BGP politikalarını dokümante etmesi önemlidir.

Redundant Connectivity

Redundancy yalnızca iki tünel açmak anlamına gelmemelidir. Aynı router, aynı ISP veya aynı fiziksel yol ortak hata noktası olabilir. Kritik sistemlerde bağlantılar mümkün olduğunca bağımsız tasarlanmalıdır. Failover düzenli olarak test edilmelidir. Kullanılmayan yedek bağlantının çalıştığı varsayılmamalıdır.

Cloud VPN Ne Zaman Kullanılmalı?

Cloud VPN düşük ve orta trafik, hızlı kurulum ve yedek bağlantı senaryolarında etkili bir seçenektir. Şirket içi ağ ile Google Cloud arasında IPsec tüneli kurulur. HA VPN yüksek erişilebilirlik ihtiyacında kullanılabilir. Ancak internet tabanlı bağlantının latency ve throughput özellikleri workload gereksinimiyle karşılaştırılmalıdır. Yüksek hacimli veya sürekli düşük latency gerektiren sistemlerde Interconnect daha uygun olabilir.

HA VPN

HA VPN yüksek erişilebilir bağlantı tasarımını destekler. Birden fazla tunnel ile yedeklilik sağlanabilir. On-premises tarafının da yedekli olması gerekir. Tek router kullanılırsa gerçek uçtan uca yedeklilik oluşmaz. Failover testleri düzenli yapılmalıdır.

IPsec

IPsec network trafiğini şifrelemek için kullanılır. VPN bağlantısı internet üzerinden güvenli tunnel oluşturur. Şifreleme parametreleri iki taraf arasında uyumlu olmalıdır. Anahtar yönetimi operasyon sürecine dahil edilmelidir. Tünel durumları monitoring ile izlenmelidir.

Düşük ve Orta Trafik

Düşük ve orta trafik hacimlerinde VPN ekonomik ve hızlı başlangıç seçeneği olabilir. Pilot hybrid cloud projelerinde sık kullanılır. Trafik büyüdükçe throughput ölçülmelidir. Uygulama latency değerleri ayrıca izlenmelidir. Gerektiğinde Interconnect'e geçiş yol haritası hazırlanabilir.

Hızlı Deployment

VPN fiziksel devre kurulumuna ihtiyaç duymadığı için hızlı devreye alınabilir. Migration öncesi bağlantı testi için uygundur. Network ekipleri IPsec ve routing ayarlarını hazırlamalıdır. DNS entegrasyonu paralel yürütülmelidir. Hızlı kurulum güvenlik testlerinin atlanması anlamına gelmemelidir.

Yedek Bağlantı

Interconnect kullanan yapılarda VPN yedek yol olarak değerlendirilebilir. Ana bağlantı kesildiğinde kritik trafik VPN üzerinden devam edebilir. Yedek yol kapasitesi gerçek ihtiyaçla uyumlu olmalıdır. Route priority doğru ayarlanmalıdır. Failover yalnızca tasarım dokümanında kalmamalı, test edilmelidir.

Cloud VPN'in Sınırları

VPN internet tabanlı olduğu için network koşullarından etkilenebilir. Throughput ve latency kritik workload'lar için sınırlayıcı olabilir. Çok yüksek veri transferlerinde maliyet ve performans ayrıca değerlendirilmelidir. Mission-critical sistemlerde yalnızca tek VPN bağlantısına güvenilmemelidir. Kapasite ölçümü gerçek trafik üzerinde yapılmalıdır.

Cloud Interconnect Ne Zaman Kullanılmalı?

Cloud Interconnect yüksek bant genişliği, düşük ve daha öngörülebilir latency isteyen kurumsal sistemlerde değerlendirilebilir. Büyük veri transferleri ve sürekli hybrid uygulama trafiği buna örnektir. Dedicated veya Partner Interconnect modeli kurumun fiziksel erişim imkanına göre seçilebilir. Kritik yapılarda bağlantı redundancy ile kurulmalıdır. Interconnect tasarımı network kapasitesi kadar disaster recovery gereksinimini de dikkate almalıdır.

Dedicated Interconnect

Dedicated Interconnect doğrudan yüksek kapasiteli fiziksel bağlantı gereksinimleri için kullanılabilir. Kurulum lokasyon ve operasyon hazırlığı gerektirir. Yüksek trafik hacminde avantaj sağlar. Redundant bağlantı tasarımı ayrıca yapılmalıdır. Fiziksel devrelerin aynı hata alanında bulunmaması önemlidir.

Partner Interconnect

Partner modeli doğrudan bağlantı noktasına erişimi olmayan kurumlar için alternatif olabilir. Servis sağlayıcı üzerinden bağlantı sunulur. Kapasite seçenekleri ihtiyaca göre değerlendirilebilir. SLA ve routing modeli dikkatle incelenmelidir. Yedeklilik partner ve lokasyon seviyesinde planlanmalıdır.

Yüksek Bandwidth

Büyük veri kümelerinin sürekli taşındığı ortamlarda bandwidth önemli kriterdir. Backup, replikasyon veya analitik veri akışları yüksek trafik oluşturabilir. Gerçek kullanım ölçülmeden kapasite seçilmemelidir. Peak trafik de hesaba katılmalıdır. Gelecekteki büyüme için yeterli headroom bırakılabilir.

Düşük Latency

Hybrid uygulamalarda her request veri merkezine dönüyorsa latency kullanıcı deneyimini etkileyebilir. Interconnect daha öngörülebilir bağlantı sağlayabilir. Yine de uygulama mimarisi uzak veri bağımlılıklarını azaltmalıdır. Network hızını artırmak kötü servis sınırlarını çözmez. Latency SLO'ları migration öncesinde tanımlanmalıdır.

Predictable Performance

Kurumsal workload'larda yalnızca ortalama performans değil değişkenlik de önemlidir. Interconnect daha kontrollü network yolu sağlayabilir. Trafik trendleri monitoring üzerinden izlenmelidir. Capacity alert'leri oluşturulabilir. Performance requirement iş gereksinimiyle ilişkilendirilmelidir.

Mission-Critical Workloads

Kritik sistemlerde network kesintisinin iş etkisi yüksek olabilir. Bu nedenle bağlantı tek devreye bağlı olmamalıdır. Redundant Interconnect ve gerektiğinde VPN backup değerlendirilebilir. Failover süresi RTO hedefleriyle uyumlu olmalıdır. Uçtan uca DR testi yapılmalıdır.

Redundant Interconnect Tasarımı

Redundant tasarım farklı fiziksel bağlantı ve cihazları kapsamalıdır. Aynı network cihazındaki iki port gerçek bağımsızlık sağlamaz. On-premises router yapısı da yedekli olmalıdır. BGP failover davranışı test edilmelidir. Monitoring her bağlantıyı ayrı izlemelidir.

Cloud VPN vs Cloud Interconnect

Cloud VPN ve Cloud Interconnect seçimi maliyet, bant genişliği, latency, deployment süresi ve availability hedeflerine göre yapılmalıdır. VPN daha hızlı başlangıç sağlayabilir. Interconnect yüksek trafik ve daha öngörülebilir performans isteyen sistemlerde avantajlıdır. Birçok kurum bu iki modeli birlikte kullanır ve VPN'i backup bağlantı olarak tutar. Tek doğru seçenek yoktur, workload ihtiyacı belirleyicidir.

Maliyet

VPN başlangıç maliyeti açısından daha erişilebilir olabilir. Interconnect fiziksel bağlantı ve kapasite maliyetleri içerir. Ancak yüksek trafik hacminde toplam maliyet farklılaşabilir. Network egress fiyatları ayrıca değerlendirilmelidir. TCO yalnızca aylık port ücretine göre hesaplanmamalıdır.

Bandwidth

Bandwidth gereksinimi seçimde temel kriterdir. Yüksek ve sürekli trafik Interconnect lehine olabilir. Daha düşük trafik VPN ile karşılanabilir. Peak kullanım ayrıca ölçülmelidir. Kapasite planlaması gelecekteki büyümeyi hesaba katmalıdır.

Latency

Internet üzerinden VPN latency değişkenliği gösterebilir. Interconnect daha öngörülebilir bağlantı sağlayabilir. Ancak uygulamanın data locality tasarımı da latency üzerinde büyük etkiye sahiptir. Kritik API çağrıları mümkün olduğunca aynı ortamda tutulmalıdır. Ölçüm gerçek kullanıcı trafiğiyle yapılmalıdır.

Deployment Süresi

VPN genellikle daha kısa sürede devreye alınabilir. Interconnect fiziksel süreçler nedeniyle daha uzun hazırlık gerektirebilir. Migration takvimi bu süreyi hesaba katmalıdır. İlk wave VPN ile başlayıp daha sonra Interconnect'e geçiş planlanabilir. Geçiş sırasında routing ve DNS yeniden test edilmelidir.

Availability

Her iki çözüm de yedekli tasarlanabilir. Gerçek availability uçtan uca mimariye bağlıdır. On-premises router tekse cloud tarafındaki yedeklilik yeterli olmaz. Farklı hata alanları düşünülmelidir. Failover hedefleri düzenli testlerle doğrulanmalıdır.

Security

VPN trafiği IPsec ile şifreler. Interconnect için veri koruma gereksinimi mimariye göre ayrıca değerlendirilmelidir. Network bağlantısı tek başına güven modeli olmamalıdır. IAM ve application-level authentication kullanılmalıdır. Zero Trust yaklaşımı network lokasyonuna sınırsız güven verilmesini engeller.

Hangi Senaryoda Hangisi?

Pilot, düşük trafik ve hızlı kurulum için VPN iyi başlangıç olabilir. Büyük veri transferi ve kritik hybrid workload'larda Interconnect değerlendirilebilir. Yüksek availability için iki yöntem birlikte kullanılabilir. Teknik seçimden önce trafik ölçülmelidir. Uygulama ekibinin latency ve throughput gereksinimi yazılı hale getirilmelidir.

Network Connectivity Center Nedir?

Network Connectivity Center farklı network bağlantılarını merkezi hub yaklaşımıyla yönetmeye yardımcı olabilir. VPN, Interconnect ve VPC bağlantıları ortak topoloji içinde değerlendirilebilir. Büyük hybrid cloud ortamlarında merkezi görünürlük operasyon ekiplerinin işini kolaylaştırır. Spoke modeli farklı bağlantı türlerini ortak yapıya bağlar. Platform büyüdükçe network topolojisinin kod ve diagram olarak güncel tutulması önemlidir.

Hub

Hub merkezi connectivity yapısını temsil eder. Farklı spoke bağlantıları hub altında organize edilebilir. Network topolojisi daha anlaşılır hale gelir. Merkezi policy ve routing planı oluşturulabilir. Hub tasarımında yüksek erişilebilirlik dikkate alınmalıdır.

Spokes

Spoke farklı network bağlantılarını hub'a bağlayan bileşenlerdir. VPN, VPC veya Interconnect bağlantıları farklı spoke türleri olarak ele alınabilir. İsimlendirme standardı operasyonu kolaylaştırır. Spoke sahipliği dokümante edilmelidir. Trafik yolları düzenli kontrol edilmelidir.

VPN Spokes

VPN bağlantıları merkezi connectivity yapısına dahil edilebilir. Şube veya veri merkezi bağlantıları organize edilebilir. Routing davranışı test edilmelidir. VPN kapasitesi monitoring'e eklenmelidir. Yedek bağlantılar ayrı hata alanında tutulmalıdır.

Interconnect Spokes

Interconnect bağlantılarının merkezi topolojiye eklenmesi büyük ağlarda yönetimi kolaylaştırır. Trafik yolları daha görünür hale gelir. Kapasite ve durum monitoring'i yapılmalıdır. Redundant bağlantılar doğru şekilde modellenmelidir. Failover süreçleri dokümante edilmelidir.

VPC Spokes

VPC network'leri merkezi hub yapısına bağlanabilir. Bu model çok sayıda izole network alanında yararlı olabilir. IP çakışmaları önceden kontrol edilmelidir. Routing gereksinimleri açıkça tanımlanmalıdır. Her VPC'nin bağlantı ihtiyacı gerçekten doğrulanmalıdır.

SD-WAN

SD-WAN çözümleri şube bağlantılarının hybrid cloud topolojisine entegrasyonunda rol oynayabilir. Trafik politikaları merkezi yönetilebilir. Cloud bağlantılarıyla birlikte planlanmalıdır. Güvenlik ve routing ekipleri ortak tasarım yapmalıdır. Operasyon monitoring'i tek ekranda birleştirilebilir.

Merkezi Hybrid Network Yönetimi

Merkezi yönetim network ekiplerinin farklı bağlantıları tek topolojide görmesini kolaylaştırır. Yeni şube veya region eklemek standardize edilebilir. Routing değişiklikleri kontrol altında tutulur. Capacity planlaması ortak veriler üzerinden yapılabilir. Merkezi yönetim uygulama ekiplerine uygun self-service mekanizmalarıyla desteklenmelidir.

Private Service Connect Nedir?

Private Service Connect servis odaklı private bağlantı modeli sağlar. Tüketici tarafı servise private endpoint üzerinden erişebilir. Bu yaklaşım geniş network peering yerine servis bazlı erişim senaryolarında faydalıdır. Google API'leri veya belirli servisler private bağlantı modeliyle kullanılabilir. On-premises erişim senaryolarında DNS ve routing tasarımı birlikte planlanmalıdır.

Service-Centric Connectivity

Service-centric model bütün network'leri birbirine açmak yerine yalnızca gereken servise erişim sağlar. Bu yaklaşım blast radius'ı azaltabilir. Consumer servis arayüzüne bağlanır. Producer kendi network ayrımını korur. Büyük organizasyonlarda servis sahipliği daha açık hale gelir.

Private Endpoint

Private endpoint servise özel IP üzerinden erişim sağlar. Uygulamanın public internet kullanmasına gerek kalmayabilir. DNS kayıtları endpoint'e yönlendirilebilir. Firewall ve IAM birlikte uygulanmalıdır. Endpoint lifecycle'ı IaC üzerinden yönetilebilir.

Producer

Producer servisi sunan taraftır. Servis tüketici network'ünü doğrudan paylaşmak zorunda kalmaz. Erişim kontrollü biçimde açılabilir. Service ownership açık tanımlanmalıdır. Monitoring producer ve consumer tarafını kapsamalıdır.

Consumer

Consumer servisi kullanan network veya projedir. Private endpoint üzerinden erişim kurar. Uygulama public adres kullanmak zorunda kalmaz. IAM ile servis yetkilendirmesi ayrıca uygulanabilir. Consumer sayısı arttıkça otomatik provisioning faydalı olur.

Google APIs

Bazı Google servislerine private bağlantı modeliyle erişim sağlanabilir. Bu yaklaşım hassas workload'larda public path kullanımını azaltabilir. DNS ve route tasarımı önemlidir. Uygulama authentication yine IAM üzerinden yapılır. Private connectivity tek başına erişim yetkisi sağlamaz.

SaaS Services

Uygun servislerde private connectivity modelinin kullanılması internet tabanlı erişimi azaltabilir. Producer ve consumer sınırları korunur. Authentication servis katmanında uygulanmalıdır. Network erişimi minimum gerekli portlarla sınırlandırılmalıdır. Latency ve availability ölçülmelidir.

On-Premises'ten Private Service Access

On-premises kullanıcıların private servislere erişimi hybrid bağlantı üzerinden tasarlanabilir. DNS çözümlemesi doğru endpoint'i göstermelidir. Routing yolu test edilmelidir. Firewall kuralları kaynak CIDR'larla sınırlandırılabilir. Connection monitoring ile erişim sağlığı izlenebilir.

Cloud DNS ile On-Premises DNS Entegrasyonu

Hybrid cloud projelerinde DNS çoğu zaman network kadar kritik hale gelir. Şirket içi uygulamalar Google Cloud private isimlerini çözmek isteyebilir. Cloud tarafındaki workload'lar da on-premises domain'lere erişmek zorunda olabilir. DNS forwarding, inbound ve outbound çözümleri bu trafiği yönlendirmek için kullanılabilir. Split-horizon tasarımında aynı domain farklı network'lerde farklı IP döndürebileceği için kayıt sahipliği açık biçimde yönetilmelidir.

Public DNS

Public DNS internetten çözülebilen domain kayıtlarını barındırır. Kurumsal external servisler bu yapıdan yararlanabilir. Değişiklikler kontrollü yapılmalıdır. TTL migration cutover süreçlerinde önemli rol oynar. DNS kayıtları IaC üzerinden yönetilebilir.

Private DNS

Private DNS yalnızca belirli network'lerde çözülebilen internal kayıtlar için kullanılabilir. Internal API ve veri tabanı adresleri burada tutulabilir. Public internetten görünmez. Zone erişim kapsamı dikkatle belirlenmelidir. Hybrid ortamda forwarding gereksinimi ayrıca planlanmalıdır.

DNS Forwarding

Forwarding belirli domain sorgularını başka DNS sunucusuna yönlendirir. On-premises domain'ler için kullanılabilir. Firewall üzerinden DNS trafiğine izin verilmelidir. Forwarder erişilebilirliği monitoring'e eklenmelidir. DNS loop oluşmaması için yönlendirme kuralları açık olmalıdır.

Inbound DNS

Inbound DNS on-premises sistemlerin Google Cloud private zone kayıtlarını çözmesine yardımcı olabilir. Hybrid bağlantı üzerinden erişim gerekir. Kaynak network'ler sınırlandırılmalıdır. DNS sorgu logları troubleshooting için kullanılabilir. Redundant resolver yolu planlanmalıdır.

Outbound DNS

Outbound DNS Google Cloud kaynaklarının dış DNS sistemlerine sorgu göndermesini sağlar. Şirket içi domain'lere erişimde kullanılabilir. Forwarding target'ların ulaşılabilir olması gerekir. Route ve firewall test edilmelidir. DNS timeout değerleri uygulama performansını etkileyebilir.

Split-Horizon DNS

Split-horizon aynı domain'in internal ve external kullanıcılar için farklı kayıt döndürmesidir. Kurumsal uygulamalarda sık kullanılır. Kayıt sahipliği açık olmazsa yanlış IP'ler yayınlanabilir. Migration sırasında internal ve external TTL değerleri planlanmalıdır. Testler farklı network lokasyonlarından yapılmalıdır.

Hybrid DNS Tasarımı

Hybrid DNS iki ortam arasında çift yönlü name resolution sağlar. Domain authority açıkça tanımlanmalıdır. Bir zone'un hangi DNS sisteminde yönetileceği dokümante edilmelidir. Redundant resolver ve forwarding tasarımı yapılmalıdır. DNS health check'leri production monitoring'e eklenmelidir.

Cloud NAT Nedir?

Cloud NAT private IP kullanan kaynakların public IP almadan internet yönüne çıkmasına yardımcı olur. Özellikle Compute Engine ve bazı GKE senaryolarında güvenli egress tasarımının önemli parçasıdır. Production VM'lerinin her birine external IP vermek yerine kontrollü NAT kullanımı tercih edilebilir. Port allocation kapasitesi trafik yoğunluğuna göre planlanmalıdır. NAT logging bağlantı sorunlarını ve egress davranışını anlamayı kolaylaştırır.

External IP Olmadan Internet Egress

Private VM'ler güncelleme veya dış API erişimi için internete çıkmak isteyebilir. Cloud NAT bu çıkışı public IP atamadan sağlar. Inbound internet erişimi otomatik olarak açılmaz. Güvenlik yüzeyi küçülür. Egress domain ve port kontrolleri ayrıca uygulanabilir.

Private VM

Private VM yalnızca internal IP kullanır. Hybrid network üzerinden erişilebilir. Yönetim için bastion yerine identity tabanlı erişim modelleri değerlendirilebilir. Internet çıkışı gerekiyorsa NAT kullanılabilir. DNS ve patch süreçleri ayrıca planlanmalıdır.

NAT Gateway

NAT merkezi egress noktası görevi görür. Uygulama kaynakları public address yönetmek zorunda kalmaz. Kapasite planı bağlantı sayısına göre yapılmalıdır. Routing ile birlikte değerlendirilmelidir. Kritik egress dependency'leri monitoring'e eklenmelidir.

Port Allocation

Yoğun outbound bağlantı oluşturan workload'larda NAT port kapasitesi önemlidir. Port tükenmesi uygulama bağlantılarının başarısız olmasına yol açabilir. Monitoring ile kullanım takip edilmelidir. Gerekirse ek external IP veya kapasite yapılandırması yapılabilir. Load test bu riski production öncesinde gösterebilir.

Logging

NAT logging hangi kaynakların hangi dış adreslere bağlandığını anlamaya yardımcı olur. Troubleshooting sırasında değerlidir. Log hacmi yüksek olabileceği için maliyet takip edilmelidir. Security analytics için seçilmiş kayıtlar merkezi sisteme gönderilebilir. Retention iş gereksinimine göre ayarlanmalıdır.

Centralized Egress

Merkezi egress güvenlik politikalarının ortak uygulanmasını kolaylaştırır. Ancak bütün trafiği tek noktadan geçirmek kapasite ve hata alanı oluşturabilir. Yedeklilik planlanmalıdır. Firewall ve proxy ihtiyaçları birlikte değerlendirilmelidir. Egress maliyeti FinOps raporlarına dahil edilmelidir.

Zero Trust Google Cloud Network Mimarisi

Zero Trust yaklaşımı kullanıcının veya workload'un güvenilir bir network içinde bulunmasını tek başına yeterli görmez. Erişim kimlik, cihaz durumu, kaynak ve bağlam üzerinden değerlendirilir. Private network yine önemlidir ancak güvenlik kararı yalnızca IP adresine dayanmaz. Identity-Aware Proxy ve context-aware kontroller belirli uygulamalarda kullanılabilir. Least privilege ve mikro segmentasyon network ve IAM katmanlarında birlikte uygulanmalıdır.

Network Location'a Güvenmemek

Internal network içinde bulunan her cihaz güvenilir kabul edilmemelidir. Ele geçirilmiş bir cihaz aynı network'teki diğer sistemlere saldırabilir. Kimlik doğrulama servis seviyesinde devam etmelidir. Network segmentasyonu saldırı hareket alanını azaltır. Loglar beklenmeyen erişim davranışlarını gösterebilir.

Identity-Based Access

Identity-based access erişim kararını kullanıcı veya workload kimliğine bağlar. IP adresi değişse bile aynı policy uygulanabilir. Grup ve role modeli yönetimi kolaylaştırır. MFA kullanıcı güvenliğini artırabilir. Workload'larda federation tercih edilebilir.

Identity-Aware Proxy

Identity-Aware Proxy bazı web uygulamalarına kimlik tabanlı erişim sağlamaya yardımcı olabilir. Kullanıcının doğrudan network erişimine ihtiyacını azaltabilir. Authentication merkezi identity sistemiyle entegre edilebilir. Uygulama seviyesinde authorization yine gerekebilir. Erişim logları audit için kullanılabilir.

Context-Aware Access

Context-aware access kullanıcı ve cihaz bağlamını erişim kararına dahil edebilir. Hassas uygulamalar için ek güvenlik katmanı sağlar. Her kullanıcı grubuna aynı koşullar uygulanmak zorunda değildir. Politika kullanıcı deneyimini tamamen engellemeyecek şekilde tasarlanmalıdır. İstisnalar kayıtlı süreç üzerinden yönetilmelidir.

Private Services

Private service erişimi public internet exposure'ını azaltabilir. Veri tabanı ve internal API'ler public IP olmadan sunulabilir. Network güvenliği IAM ile tamamlanmalıdır. Private endpoint kullanmak sınırsız erişim anlamına gelmez. DNS ve routing tasarımı dikkatle yapılmalıdır.

Least Privilege

Zero Trust modelinde erişim minimum gereksinimle sınırlandırılır. Network ve IAM seviyelerinde aynı ilke uygulanır. Kullanıcı yalnızca ihtiyacı olan servise ulaşmalıdır. Geniş internal subnet izinleri azaltılabilir. Erişimler düzenli olarak gözden geçirilmelidir.

Micro-Segmentation

Micro-segmentation workload'lar arasındaki erişimi daha küçük güvenlik alanlarına böler. Bir servisin ihlali bütün network'e erişim sağlamamalıdır. GKE ve VPC firewall politikaları bu yaklaşımı destekleyebilir. Çok ayrıntılı kural seti yönetimi zorlaştırabileceği için otomasyon önemlidir. Trafik gözlemi doğru segment sınırlarını belirlemeye yardımcı olur.

VPC Service Controls Nedir?

VPC Service Controls hassas Google Cloud servisleri çevresinde ek veri güvenliği sınırları oluşturmak için kullanılabilir. Amaç yalnızca network trafiğini engellemek değil, yetkili credential kullanılsa bile belirlenen perimeter dışına veri çıkarma riskini azaltmaktır. Ingress ve egress politikaları kontrollü erişim yolları tanımlar. Hassas veri servisleri için özellikle değerlidir. Production uygulamadan önce dry-run benzeri test yaklaşımıyla mevcut servis bağımlılıklarının etkilenip etkilenmeyeceği incelenmelidir.

Service Perimeter

Service perimeter korunan servis ve kaynakların mantıksal sınırını oluşturur. Hassas project'ler bu sınır içerisine alınabilir. Erişim politikaları açıkça tanımlanmalıdır. Yanlış perimeter konfigürasyonu uygulama erişimlerini kesebilir. Test ve kademeli rollout önemlidir.

Data Exfiltration Riski

Geçerli credential ele geçirilse bile verinin yetkisiz dış ortama taşınması istenmez. Service perimeter bu risk için ek kontrol sağlayabilir. IAM yine temel erişim katmanı olmaya devam eder. Veri sınıflandırması hangi servislerin korunacağını belirler. Audit loglar perimeter ihlallerini izlemek için kullanılabilir.

Ingress Policy

Ingress policy perimeter içine hangi kimlik ve kaynakların erişebileceğini belirler. Minimum gerekli erişim verilmelidir. Partner ve hybrid workload erişimleri ayrıca değerlendirilmelidir. Kimlik ve network koşulları birlikte kullanılabilir. Policy değişiklikleri test edilmelidir.

Egress Policy

Egress policy perimeter içinden hangi servis veya hedeflere çıkış yapılabileceğini belirler. Gereksiz veri hareketini sınırlandırır. Uygulama dependency'leri önceden keşfedilmelidir. Aksi halde production servisleri beklenmedik şekilde engellenebilir. Egress denemeleri merkezi loglanmalıdır.

Access Levels

Access level belirli kullanıcı veya bağlam koşullarını tanımlayabilir. Perimeter erişim kararlarında kullanılabilir. Çok geniş access level korumanın etkisini azaltır. Değişiklikler kontrollü review sürecinden geçirilmelidir. Kullanılmayan access level'lar kaldırılmalıdır.

Sensitive Data Services

Hassas veri depolayan analitik veya storage servisleri perimeter içine alınabilir. Hangi verinin hassas olduğu classification süreciyle belirlenmelidir. Veri erişimi IAM ile de sınırlandırılmalıdır. Audit ve DLP süreçleri eklenebilir. Tek güvenlik mekanizmasına güvenilmemelidir.

Perimeter Bridge

Bazı mimarilerde farklı güvenlik sınırları arasında kontrollü erişim ihtiyacı olabilir. Bridge yaklaşımı bu iletişim için değerlendirilebilir. Veri akışı açıkça dokümante edilmelidir. Geniş bağlantılardan kaçınılmalıdır. Her bridge gerçek iş gereksinimine dayanmalıdır.

Dry-Run ile Test

Yeni security control production servislerini beklenmedik biçimde engelleyebilir. Dry-run yaklaşımı policy'nin etkisini gözlemlemeyi sağlar. İhlaller loglardan incelenebilir. Eksik dependency'ler tespit edilir. Sonrasında policy kontrollü biçimde enforce edilebilir.

Kurumsal Uygulamalar Google Cloud ile Nasıl Entegre Edilir?

Kurumsal uygulama entegrasyonunda tek bir yöntem yoktur. Point-to-point bağlantılar küçük yapılarda hızlı olsa da sistem sayısı arttıkça yönetimi zorlaşır. API tabanlı, event-driven, message-based ve batch yaklaşımları ihtiyaca göre kullanılabilir. Uygulamalar arasındaki bağımlılığı azaltmak uzun vadede değişiklik yönetimini kolaylaştırır. Özellikle legacy sistemlerle yeni cloud servisleri arasında adapter veya facade katmanı kullanmak kademeli modernizasyon için güçlü bir yöntemdir.

Point-to-Point Integration

Point-to-point yaklaşım iki sistemi doğrudan bağlar. Başlangıçta basit ve hızlıdır. Sistem sayısı arttığında bağlantı sayısı hızla büyür. Credential ve hata yönetimi dağınık hale gelebilir. Küçük ve stabil entegrasyonlarda kullanılabilir.

API-Based Integration

API tabanlı model uygulamanın yeteneklerini kontrollü servis arayüzü üzerinden sunar. Authentication ve rate limit uygulanabilir. Backend sistemi tüketiciden ayrılır. Versioning değişiklik yönetimini kolaylaştırır. Legacy sistemler için facade API oluşturulabilir.

Event-Driven Integration

Event-driven model servislerin olaylar üzerinden haberleşmesini sağlar. Producer consumer'ın doğrudan adresini bilmek zorunda kalmaz. Bu loose coupling ölçeklenebilirliği artırabilir. Retry ve idempotency tasarımı zorunludur. Pub/Sub bu modelde kullanılabilecek servislerden biridir.

iPaaS

Integration Platform as a Service farklı sistemler arasında workflow ve connector tabanlı entegrasyon sağlar. Low-code tasarım bazı iş süreçlerinin daha hızlı oluşturulmasına yardımcı olabilir. Hata yönetimi merkezi yapılabilir. Connector kimlikleri güvenli biçimde yönetilmelidir. Çok kritik business logic için test ve version control süreci unutulmamalıdır.

Message-Based Integration

Message-based entegrasyon servisler arasında asenkron iletişim sağlar. Mesaj kuyruğu geçici servis kesintilerini absorbe edebilir. Consumer kendi hızında işlem yapabilir. Duplicate mesajlara karşı idempotent tasarım gereklidir. Dead-letter queue başarısız mesajların incelenmesini sağlar.

Batch Integration

Batch entegrasyon belirli zaman aralıklarında veri aktarır. Gerçek zaman gerektirmeyen büyük veri senaryolarında uygundur. Dosya veya tablo bazlı aktarım yapılabilir. Veri doğrulama süreci gereklidir. Batch penceresi ve tekrar çalıştırma davranışı açıkça tanımlanmalıdır.

Google Cloud Application Integration Nedir?

Application Integration kurumsal sistemleri görsel workflow ve connector yaklaşımıyla birbirine bağlamaya yardımcı olan entegrasyon servisidir. Trigger, task, data mapping ve error handling adımlarıyla süreçler oluşturulabilir. Şirket içi veya SaaS uygulamalarından gelen veriler ortak iş akışlarında işlenebilir. Bu servis özellikle çok sayıda sistem arasında tekrar eden entegrasyon süreçlerinde yararlı olabilir. Bununla birlikte kimlik, private connectivity ve secret yönetimi tasarımın ayrılmaz parçalarıdır.

Integration Platform as a Service

iPaaS farklı uygulamalar arasında yönetilen entegrasyon katmanı sağlar. Connector ve workflow kullanımını kolaylaştırabilir. Teknik ekiplerin her bağlantı için ayrı custom servis yazma ihtiyacını azaltabilir. Ancak kritik iş kuralları yine açıkça test edilmelidir. Entegrasyon sahipliği ve monitoring merkezi tutulmalıdır.

Visual Designer

Visual designer workflow adımlarını görsel olarak düzenlemeyi sağlar. İş akışı daha kolay okunabilir. Karmaşık süreçlerde isimlendirme standardı önemlidir. Version değişiklikleri dokümante edilmelidir. Görsel tasarım test ihtiyacını ortadan kaldırmaz.

Trigger

Trigger integration workflow'u başlatan olaydır. API çağrısı, event veya başka giriş olabilir. Trigger authentication ile korunmalıdır. Duplicate çalışma ihtimali değerlendirilmelidir. Monitoring hangi trigger'ın ne kadar çalıştığını göstermelidir.

Task

Task workflow içerisinde belirli işlemi gerçekleştirir. Veri dönüştürme veya dış servise çağrı örnek verilebilir. Her task için hata davranışı tanımlanmalıdır. Uzun süren işlemler timeout gereksinimiyle değerlendirilmelidir. Task çıktıları gereksiz hassas veri içermemelidir.

Data Mapping

Data mapping bir sistemdeki veri modelini diğer sisteme dönüştürür. Alan isimleri ve tipleri açıkça tanımlanmalıdır. Null veya eksik değer senaryoları test edilmelidir. Mapping değişiklikleri backward compatibility açısından değerlendirilmelidir. Hassas veri gereksiz yere aktarılmamalıdır.

Connector

Connector dış sistemle standart bağlantı sağlar. Authentication konfigürasyonu güvenli tutulmalıdır. Network erişimi private seçeneklerle sınırlandırılabilir. Connector health monitoring kurulmalıdır. Kullanılmayan connector'lar kaldırılmalıdır.

Error Handling

Entegrasyonlarda hata kaçınılmazdır. Retry her hata için aynı şekilde uygulanmamalıdır. Geçici network hataları yeniden denenebilirken validation hatası manuel inceleme gerektirebilir. Dead-letter veya hata kuyruğu tasarlanabilir. Kullanıcıya ve operasyon ekibine doğru hata bilgisi sağlanmalıdır.

On-Premises Uygulamaları Application Integration'a Bağlamak

On-premises uygulamaların cloud entegrasyon servisine bağlanmasında network ve authentication birlikte ele alınmalıdır. Private network bağlantısı mümkün olduğunda tercih edilebilir. Connector kimliklerinin minimum erişime sahip olması gerekir. Secret Manager credential saklama ve rotation süreçlerini iyileştirebilir. Connection monitoring sayesinde cloud ile şirket içi sistem arasındaki erişim sorunları production kullanıcılarından önce tespit edilebilir.

Private Network

Private network erişimi uygulamanın public internete açılmasını önleyebilir. Hybrid bağlantı üzerinden servis erişimi sağlanabilir. Routing ve DNS doğru yapılandırılmalıdır. Firewall yalnızca gerekli kaynaklara izin vermelidir. Network erişimi authentication yerine geçmez.

Private Service Connect

Private Service Connect servis odaklı private erişim senaryolarında değerlendirilebilir. Geniş network peering ihtiyacını azaltabilir. Endpoint ve DNS yönetimi önemlidir. Producer ve consumer sınırları açık kalır. Monitoring bağlantı durumunu takip etmelidir.

Connector Authentication

Connector'ın bağlandığı sisteme nasıl doğrulanacağı açıkça belirlenmelidir. Statik password yerine daha güvenli credential modeli varsa kullanılmalıdır. Credential minimum yetkiye sahip olmalıdır. Rotation otomatik hale getirilebilir. Authentication hataları merkezi loglanmalıdır.

Service Account

Cloud tarafındaki entegrasyon servisi ayrı service identity kullanmalıdır. Geniş project erişiminden kaçınılmalıdır. Her entegrasyon için ayrı kimlik gerekebilir. Anahtar saklamak yerine native identity seçenekleri tercih edilmelidir. IAM periyodik gözden geçirilmelidir.

Secret Manager

Secret Manager API key, password ve certificate gibi gizli bilgileri merkezi tutabilir. Source code içerisinde secret saklanmamalıdır. Versioning rotation süreçlerini destekler. IAM ile secret bazında erişim sınırlandırılabilir. Secret erişim logları audit için değerlidir.

Network Firewall

Firewall yalnızca gerekli port ve kaynaklara izin vermelidir. Geniş CIDR izinleri migration döneminde geçici olarak açılsa bile sonradan kapatılmalıdır. Rule sahipliği kayıt altında tutulmalıdır. Loglar beklenmeyen bağlantıları gösterebilir. Policy değişiklikleri IaC üzerinden yapılmalıdır.

Connection Monitoring

Bağlantının yalnızca kurulum günü çalışması yeterli değildir. Latency, packet loss ve erişilebilirlik sürekli izlenmelidir. DNS sorunları ayrıca kontrol edilmelidir. Alert doğru operasyon ekibine gitmelidir. Hybrid bağlantı probleminde hangi tarafın sorumlu olduğu hızlı belirlenebilmelidir.

Event-Driven Kurumsal Entegrasyon

Event-driven mimari servisler arasındaki doğrudan bağımlılığı azaltır. Bir sistem sipariş oluşturulduğunda event yayınlar ve farklı consumer servisler bu olayı kendi hızlarında işler. Producer consumer adresini veya çalışma durumunu bilmek zorunda kalmaz. Pub/Sub mesaj dağıtımında, Eventarc ise olay yönlendirme senaryolarında kullanılabilir. Bu modelin güvenilir olması için idempotency, retry, ordering ve dead-letter tasarımının daha ilk geliştirme aşamasında ele alınması gerekir.

Event-Driven Architecture Nedir?

Event-driven architecture sistem durum değişikliklerini olay olarak yayınlar. Consumer servisler ilgilendikleri event'lere abone olur. Sıkı point-to-point bağımlılığı azalır. Sistemler bağımsız ölçeklenebilir. Event schema ve versioning standartlaştırılmalıdır.

Pub/Sub

Pub/Sub asenkron mesajlaşma için kullanılabilir. Producer topic'e mesaj yayınlar. Consumer subscription üzerinden mesajı alır. Retry ve dead-letter senaryoları kurulmalıdır. Duplicate delivery ihtimaline karşı consumer idempotent tasarlanmalıdır.

Eventarc

Eventarc farklı Google Cloud event'lerini hedef servislere yönlendirmede kullanılabilir. Event tabanlı otomasyonları sadeleştirebilir. Trigger filtreleri gereksiz event tüketimini azaltır. Identity ve IAM doğru yapılandırılmalıdır. Event akışı monitoring ile takip edilmelidir.

Cloud Run

Cloud Run event consumer veya HTTP entegrasyon servisi olarak kullanılabilir. Stateless container modeli kolay ölçeklenebilir. Workload identity ile diğer servislere erişebilir. Private erişim seçenekleri değerlendirilebilir. Timeout ve concurrency değerleri workload'a göre ayarlanmalıdır.

Cloud Functions

Küçük event handler senaryolarında function tabanlı yaklaşım kullanılabilir. Kod doğrudan belirli olaya tepki verir. İş mantığı büyüdükçe daha modüler servis yapısı gerekebilir. Retry davranışı anlaşılmalıdır. Function kimliği minimum yetkiye sahip olmalıdır.

Event Producer

Producer business event'i yayınlayan sistemdir. Mesaja gereksiz hassas veri eklememelidir. Event schema açıkça tanımlanmalıdır. Producer consumer davranışına bağımlı olmamalıdır. Publish hataları monitoring ile izlenmelidir.

Event Consumer

Consumer event'i işleyen servistir. Aynı mesajı birden fazla kez işleme ihtimaline hazır olmalıdır. Hata durumunda retry veya dead-letter kullanılabilir. İşlem sonuçları gözlemlenebilir olmalıdır. Consumer kendi ölçekleme politikasına sahip olabilir.

Loose Coupling

Loose coupling servislerin birbirinden bağımsız değişmesini kolaylaştırır. Producer consumer'ın deployment zamanını bilmek zorunda kalmaz. Yeni consumer eklemek mevcut producer'ı değiştirmeyebilir. Ancak event contract yönetimi gerekir. Schema versioning iyi yönetilmezse bağımsızlık avantajı azalır.

Pub/Sub Kurumsal Sistemlerde Nasıl Kullanılır?

Pub/Sub kurumsal entegrasyonlarda event dağıtımı, veri pipeline'ı ve asenkron işlem akışlarında kullanılabilir. Topic producer ile consumer arasında ortak iletişim noktasıdır. Subscription her consumer'ın kendi tüketim hızında çalışmasına izin verir. At-least-once delivery modeli nedeniyle duplicate mesajların oluşabileceği varsayılmalıdır. Bu nedenle idempotency ve dead-letter yaklaşımı production tasarımının temel parçası olmalıdır.

Topic

Topic producer'ların mesaj yayınladığı mantıksal kanaldır. İsimlendirme standardı event amacını göstermelidir. Hassas veri içeriği kontrol edilmelidir. IAM yalnızca gerekli producer'lara publish yetkisi vermelidir. Topic sahipliği servis kataloğunda tutulabilir.

Subscription

Subscription consumer'ın topic mesajlarını almasını sağlar. Farklı consumer'lar ayrı subscription kullanabilir. Ack davranışı doğru yapılandırılmalıdır. Backlog monitoring yapılmalıdır. Yüksek backlog consumer kapasite sorunu olduğunu gösterebilir.

At-Least-Once Delivery

Mesajın birden fazla kez teslim edilmesi mümkün olabilir. Consumer işlemleri idempotent olmalıdır. Örneğin aynı ödeme event'i ikinci kez işlenmemelidir. Unique event ID kullanılabilir. Duplicate senaryoları test edilmelidir.

Dead-Letter Topic

Defalarca işlenemeyen mesajlar dead-letter topic'e gönderilebilir. Böylece normal queue bloke olmaz. Hatalı mesajlar operasyon ekibi tarafından incelenebilir. Alert oluşturulmalıdır. Düzeltildikten sonra kontrollü replay süreci kullanılabilir.

Retry

Geçici hatalarda retry faydalıdır. Kalıcı validation hatalarını sürekli tekrar etmek gereksiz kaynak tüketir. Backoff stratejisi kullanılabilir. Maksimum retry davranışı tanımlanmalıdır. Retry metrics monitoring'e eklenmelidir.

Ordering

Bazı business süreçlerinde event sırası önemlidir. Ordering gereksinimi varsa tasarım buna göre yapılmalıdır. Bütün event'leri global sıraya sokmaya çalışmak throughput'u etkileyebilir. Yalnızca gerekli entity düzeyinde ordering tercih edilebilir. Consumer eski event'lere karşı dayanıklı olmalıdır.

Idempotency

Idempotency aynı event'in tekrar işlenmesinin sonucu değiştirmemesini sağlar. Event-driven sistemlerde temel güvenilirlik ilkesidir. Database unique key veya processed-event tablosu kullanılabilir. İş mantığı bu davranışı açıkça desteklemelidir. Load ve retry testleri duplicate senaryoları kapsamalıdır.

Schema

Event schema producer ve consumer arasındaki contract'tır. Alan tipleri ve anlamları dokümante edilmelidir. Geriye uyumlu değişiklikler tercih edilmelidir. Breaking change yeni version gerektirebilir. Schema sahipliği platform standardına bağlanabilir.

Legacy Uygulamaları Google Cloud ile Entegre Etmek

Legacy uygulamaları tamamen yeniden yazmak çoğu kurum için gerçekçi değildir. Daha güvenli yaklaşım eski sistemi çalışır durumda tutarken API, event veya adapter katmanları ekleyerek yeni servislerle kontrollü bağlantı kurmaktır. Strangler Fig Pattern bu geçişi kademeli hale getirir. Yeni fonksiyonlar cloud tarafında geliştirilebilir ve trafik aşamalı biçimde yeni servislere yönlendirilebilir. Böylece işletme büyük tek seferlik dönüşüm riski almadan modernizasyon yapabilir.

Legacy Sistem Sorunları

Legacy sistemlerde eski protokoller, sınırlı dokümantasyon ve sıkı bağımlılıklar bulunabilir. Uygulamayı doğrudan cloud-native mimariye dönüştürmek yüksek risk yaratabilir. Önce gerçek kullanım ve dependency analizi yapılmalıdır. Kritik business logic korunmalıdır. Modernizasyon küçük ve ölçülebilir adımlara bölünmelidir.

API Facade

API facade eski sistemin fonksiyonlarını modern API arayüzüyle sunar. Consumer legacy protokolü bilmek zorunda kalmaz. Authentication ve rate limiting facade katmanında uygulanabilir. Backend zamanla değiştirilebilir. API contract stabil tutulmalıdır.

Anti-Corruption Layer

Anti-corruption layer yeni sistemin eski veri modeli ve iş kurallarından doğrudan etkilenmesini azaltır. Mapping ve adapter burada yapılır. Legacy kavramların yeni domain modeline yayılması engellenir. Bu katman migration döneminde geçici veya kalıcı olabilir. Sorumluluk sınırları açık tutulmalıdır.

Strangler Fig Pattern

Strangler Fig Pattern monolith sistemi bir anda değiştirmek yerine fonksiyonları kademeli ayırır. Yeni özellikler cloud servislerinde geliştirilebilir. Routing doğru servise yönlendirme yapar. Eski fonksiyonlar zamanla kapatılır. Bu yöntem rollback ve kontrollü geçiş açısından avantaj sağlar.

Event Adapter

Event adapter legacy sistemdeki değişiklikleri event formatına dönüştürebilir. Böylece yeni servisler eski veri tabanına doğrudan bağlanmak zorunda kalmaz. Duplicate event senaryoları ele alınmalıdır. Transaction sınırları iyi anlaşılmalıdır. Adapter monitoring'i production operasyonunda önemlidir.

Database Integration

Legacy veri tabanına doğrudan birçok yeni servis bağlamak güçlü bağımlılık oluşturur. API veya event katmanı daha kontrollü olabilir. Zorunlu database integration senaryolarında read-only erişim değerlendirilebilir. Schema değişiklikleri consumer'ları etkilememelidir. Replikasyon kullanılacaksa veri gecikmesi izlenmelidir.

Kademeli Modernizasyon

Kademeli modernizasyon her adımda ölçülebilir fayda üretmeyi hedefler. Önce düşük riskli fonksiyonlar ayrılabilir. Kullanıcı trafiği kontrollü şekilde yeni servise yönlendirilir. Monitoring iki sistemin davranışını karşılaştırır. Eski bileşen ancak yeni yapı doğrulandıktan sonra kapatılır.

Kurumsal Database Entegrasyonu ve Migration

Veritabanı migration'ı uygulama migration'ından ayrı düşünülmemelidir. Schema uyumluluğu, replication, downtime, data validation ve rollback birlikte planlanmalıdır. Yönetilen ilişkisel servisler operasyon yükünü azaltabilir. Analitik workload'lar için farklı veri platformları tercih edilebilir. Google Cloud kurumsal altyapıda Kubernetes veritabanı güvenlik ve monitoring mimarisi kurulurken stateful data katmanının container platformundan bağımsız yaşam döngüsü özellikle değerlendirilmelidir.

Cloud SQL

Cloud SQL yönetilen ilişkisel veri tabanı kullanım senaryolarında değerlendirilebilir. Backup ve yüksek erişilebilirlik özellikleri operasyonu sadeleştirebilir. Uygulama compatibility test edilmelidir. Private connectivity tercih edilebilir. Connection limit ve performance ihtiyacı workload bazında ölçülmelidir.

AlloyDB

AlloyDB belirli PostgreSQL uyumlu kurumsal workload'larda değerlendirilebilir. Performance gereksinimi ve uyumluluk birlikte analiz edilmelidir. Migration öncesi extension ve SQL davranışları test edilmelidir. Backup ve recovery modeli tasarlanmalıdır. Uygulama connection pooling kullanıyorsa yeni ortamda yeniden doğrulanmalıdır.

Spanner

Spanner yüksek ölçek ve dağıtık transaction gerektiren özel workload'larda değerlendirilebilir. Her ilişkisel uygulamanın varsayılan hedefi değildir. Veri modeli ve erişim desenleri baştan analiz edilmelidir. Uygulama tarafında mimari değişiklik gerekebilir. İş ihtiyacı olmadan platform değişimi gereksiz maliyet yaratabilir.

BigQuery

BigQuery analitik veri işleme ve data warehouse senaryolarında kullanılır. Transactional uygulama database'i yerine analitik sorgu modeli sunar. On-premises ve SaaS kaynaklarından veri aktarılabilir. Partition ve query tasarımı maliyeti etkiler. Veri erişimi dataset seviyesinde IAM ile sınırlandırılabilir.

Database Migration Service

Database Migration Service desteklenen veri tabanı geçişlerinde migration sürecini kolaylaştırabilir. Continuous replication düşük downtime hedeflerinde yararlı olabilir. Source ve target uyumluluğu önceden değerlendirilmelidir. Cutover kriterleri yazılı hale getirilmelidir. Rollback planı migration başlamadan hazırlanmalıdır.

Hangi Database Hangi Workload İçin?

Online transaction, analitik ve global dağıtık workload'ların ihtiyaçları farklıdır. Hedef platform uygulama erişim modeline göre seçilmelidir. Yönetilen servis kullanmak her zaman otomatik olarak daha ucuz değildir. Operasyon yükü, performance ve availability birlikte değerlendirilmelidir. Proof of concept kritik kararları doğrulamak için kullanılabilir.

Database Migration Nasıl Planlanır?

Database migration veri kaybına toleransı olmayan süreçlerden biridir. Source inventory, schema compatibility ve data size ilk olarak analiz edilmelidir. Replication modeli downtime hedefiyle birlikte belirlenir. Cutover öncesi validation ve performans testleri yapılmalıdır. Geri dönüş yolu yalnızca dokümante edilmemeli, uygulanabilirliği de test edilmelidir.

Source Database Inventory

Kaynak database sürümü, boyutu ve extension bilgileri kaydedilmelidir. Bağlanan uygulamalar listelenmelidir. Backup politikası doğrulanmalıdır. Peak transaction değerleri ölçülmelidir. Sahiplik ve bakım penceresi belirlenmelidir.

Technical Fit

Hedef database mevcut workload davranışını desteklemelidir. SQL özellikleri ve extension'lar kontrol edilmelidir. Performance gereksinimi benchmark ile ölçülebilir. Uygulama driver uyumluluğu test edilmelidir. Sadece isim benzerliğine göre servis seçilmemelidir.

Schema Compatibility

Schema object'leri hedef platformla uyumlu olmalıdır. Stored procedure ve custom function kullanımı ayrıca incelenmelidir. Otomatik migration araçları bütün farklılıkları çözemeyebilir. Test migration yapılmalıdır. Schema değişikliği gerekiyorsa uygulama ekibiyle birlikte planlanmalıdır.

Data Size

Data size transfer süresini ve maliyeti etkiler. Büyük database için ilk full copy ile incremental replication birlikte kullanılabilir. Network kapasitesi migration penceresine göre hesaplanmalıdır. Compression seçenekleri değerlendirilebilir. Cutover süresi son delta miktarına bağlı olabilir.

Replication

Replication source ile target arasındaki değişiklikleri aktarır. Replication lag sürekli izlenmelidir. DDL değişikliklerinin davranışı anlaşılmalıdır. Cutover öncesi lag kabul edilebilir seviyeye getirilmelidir. Replication credential'ı minimum yetkiye sahip olmalıdır.

Downtime Requirement

İş birimi kabul edilebilir downtime süresini tanımlamalıdır. Sıfıra yakın downtime daha fazla teknik hazırlık gerektirir. DNS, application connection ve final sync süresi hesaba katılmalıdır. Maintenance window kullanıcı trafiğine göre seçilebilir. Hedef gerçekçi değilse erken aşamada yeniden değerlendirilmelidir.

Validation

Validation yalnızca row count karşılaştırması olmamalıdır. Kritik tablolar için checksum veya business validation yapılabilir. Uygulama sorguları hedef database üzerinde test edilmelidir. Performance ölçülmelidir. Veri sahipleri cutover sonrasında iş doğrulamasına katılmalıdır.

Cutover

Cutover source yazmaların durdurulması ve trafiğin hedef sisteme çevrilmesidir. Final sync tamamlanmalıdır. Connection string veya DNS değişikliği planlanmalıdır. Smoke test hızlı biçimde çalıştırılmalıdır. Go veya rollback kararı önceden tanımlanan kriterlere göre verilmelidir.

Rollback

Rollback veri migration'ında özellikle zordur. Target üzerinde yeni yazma başladıysa source'a geri dönüş için veri tutarlılığı planlanmalıdır. DNS geri alınabilir ancak data divergence ayrıca çözülmelidir. Bu nedenle rollback kriteri erken tetiklenmelidir. Plan production öncesinde masa başı ve mümkünse teknik testle doğrulanmalıdır.

BigQuery Kurumsal Altyapıya Nasıl Entegre Edilir?

BigQuery kurumsal analitik katmanın merkezi bileşeni olarak kullanılabilir. Şirket içi veri kaynakları, uygulama database'leri ve SaaS verileri kontrollü ingestion süreçleriyle taşınabilir. Batch ve streaming yöntemleri farklı gecikme ihtiyaçlarına cevap verir. Veri katmanında erişim, maliyet ve governance birlikte ele alınmalıdır. BI araçlarına bağlantı açılırken kullanıcıların yalnızca ihtiyaç duyduğu dataset'lere erişmesi sağlanmalıdır.

Data Warehouse

BigQuery analitik sorgular için ölçeklenebilir data warehouse modeli sağlar. Veriler domain veya iş birimi bazında dataset'lerde tutulabilir. Partitioning ve clustering sorgu performansı ile maliyeti etkiler. Query limitleri ve budget kontrolleri kurulmalıdır. Veri sahipliği açık biçimde tanımlanmalıdır.

On-Premises Veri Kaynakları

Şirket içi kaynaklardan veri batch veya streaming olarak aktarılabilir. Network güvenliği ve transfer kapasitesi planlanmalıdır. Kaynak sistemi aşırı yüklememek önemlidir. Change data capture yaklaşımı bazı senaryolarda yararlı olabilir. Veri doğrulama süreci aktarımın parçası olmalıdır.

SaaS Data

SaaS kaynaklarından gelen veriler ortak analitik modele dönüştürülebilir. API limitleri ve veri gecikmesi takip edilmelidir. Credential'lar Secret Manager gibi merkezi yapıda tutulabilir. Veri sahipliği tanımlanmalıdır. Gereksiz kişisel veri analitik ortama taşınmamalıdır.

Batch Ingestion

Batch ingestion belirli periyotlarda veri yüklemek için uygundur. Büyük dosya veya tablo aktarımlarında kullanılabilir. İş başarısız olduğunda yeniden çalışma davranışı tanımlanmalıdır. Duplicate veri önlenmelidir. Batch SLA'sı dashboard üzerinden izlenebilir.

Streaming Ingestion

Streaming daha düşük veri gecikmesi gerektiren senaryolarda kullanılır. Event pipeline kapasitesi planlanmalıdır. Duplicate ve out-of-order event'ler ele alınmalıdır. Maliyet batch modelinden farklı olabilir. İş ihtiyacı gerçek zaman gerektirmiyorsa gereksiz streaming tasarımından kaçınılabilir.

Federated Queries

Federated query bazı veri kaynaklarına veriyi tamamen taşımadan sorgu yapılmasını sağlayabilir. Kullanım kolaylığı sağlasa da performance ve cost davranışı anlaşılmalıdır. Kritik dashboard için sürekli remote query uygun olmayabilir. Data locality ve erişim modeli değerlendirilmelidir. Gerekirse sık kullanılan veri native tablolara aktarılabilir.

BI Entegrasyonu

BI kullanıcıları dataset ve view seviyesinde kontrollü erişim almalıdır. Hassas kolonlar maskelenebilir veya ayrı view'larla sunulabilir. Query maliyeti izlenmelidir. Dashboard SLA'ları tanımlanabilir. Analytics kullanıcılarının doğrudan raw bütün verilere erişmesi gerekmeyebilir.

GKE ile Kurumsal Uygulama Modernizasyonu

GKE container tabanlı kurumsal uygulamaların yönetiminde güçlü platform seçeneklerinden biridir. Ancak Kubernetes'i yalnızca popüler olduğu için kullanmak doğru değildir. Çok servisli platform, gelişmiş deployment ihtiyacı ve ortak runtime standardı bulunan kurumlarda değer sağlar. Workload Identity, private cluster, ingress ve observability tasarımı birlikte yapılmalıdır. Platform engineering ekibi geliştiricilere güvenli golden path sunduğunda Kubernetes'in operasyon yükü daha yönetilebilir hale gelir.

Google Kubernetes Engine

GKE Kubernetes cluster yönetimini kolaylaştıran yönetilen servis yaklaşımı sunar. Control plane operasyonunun önemli bölümü servis tarafından yönetilir. Node ve workload güvenliği yine kurumun sorumluluğundadır. Cluster sayısı gereksiz artırılmamalıdır. Environment ve güvenlik sınırları cluster tasarımını belirlemelidir.

Containerization

Containerization uygulamayı bağımlılıklarıyla birlikte paketler. Ortam farklarını azaltabilir. Image'lar Artifact Registry benzeri kontrollü repository'de tutulmalıdır. Image scanning CI/CD sürecine eklenebilir. Container içinde secret saklanmamalıdır.

Workload Identity

GKE workload'larının Google Cloud servislerine güvenli erişimi için workload identity yaklaşımı kullanılabilir. Pod içerisinde statik service account key saklamak gerekmez. Her uygulama minimum IAM rolü alabilir. Namespace ve service account modeli açıkça tasarlanmalıdır. Identity mapping audit edilmelidir.

Private Cluster

Private cluster node'ların public IP kullanmasını azaltabilir. Control plane erişimi kurum güvenlik modeline göre sınırlandırılmalıdır. Cloud NAT veya private servis erişimi gerekebilir. Management bağlantıları test edilmelidir. Private olmak tek başına güvenli olduğu anlamına gelmez.

Ingress

Ingress dış veya internal HTTP trafiğini servislere yönlendirir. TLS, authentication ve rate limiting ihtiyaçları değerlendirilmelidir. Public endpoint sayısı minimumda tutulabilir. Internal uygulamalar private load balancing kullanabilir. Ingress logları merkezi observability sistemine gönderilmelidir.

Service Mesh

Service mesh servisler arası trafik yönetimi ve gözlemlenebilirlik sağlayabilir. Her cluster için zorunlu değildir. Büyük mikroservis ortamlarında mTLS ve traffic policy ihtiyaçlarında yararlı olabilir. Operasyon yükü hesaba katılmalıdır. Mesh kullanımı developer deneyimini gereksiz zorlaştırmamalıdır.

Hybrid Kubernetes

On-premises ve cloud cluster'ların ortak standartlarla yönetilmesi hybrid Kubernetes modelinin temelidir. Deployment ve policy yaklaşımı mümkün olduğunca ortaklaştırılabilir. Network ve identity farklılıkları açıkça yönetilmelidir. Observability tek platformda toplanabilir. Uygulamanın gerçekten iki ortamda çalışmasına ihtiyaç olup olmadığı değerlendirilmelidir.

Platform Engineering

Platform engineering geliştiricilerin Kubernetes ayrıntılarıyla her projede yeniden uğraşmasını azaltır. Golden path template'leri hazırlanabilir. CI/CD, logging ve security varsayılan olarak eklenebilir. Self-service deployment akışı oluşturulabilir. Platform ekibi ürün yaklaşımıyla geliştirici geri bildirimlerini takip etmelidir.

Cloud Run Kurumsal Entegrasyonda Nerede Kullanılır?

Cloud Run stateless container servislerini yönetilen serverless modelde çalıştırmak için kullanılabilir. REST API, webhook consumer, event consumer ve küçük integration microservice senaryolarında oldukça pratiktir. Kubernetes yönetim yükü olmadan container standardını korur. Workload identity ile diğer Google Cloud servislerine erişebilir. Private servis olarak konumlandırıldığında internal entegrasyonlarda da kullanılabilir.

Serverless Containers

Cloud Run container image üzerinden uygulama çalıştırır. Sunucu yönetimi büyük ölçüde platform tarafından yapılır. Trafiğe göre ölçeklenebilir. Stateless tasarım tercih edilmelidir. Startup süresi ve concurrency workload'a göre test edilmelidir.

REST API

Cloud Run HTTP tabanlı API servisleri için uygundur. Authentication IAM veya uygulama katmanında uygulanabilir. Public erişim yalnızca gerekli API'lerde açılmalıdır. Rate limiting ihtiyacı API katmanında ayrıca ele alınabilir. Log ve trace bilgileri observability sistemine gönderilebilir.

Integration Microservice

Küçük entegrasyon servisleri Cloud Run üzerinde bağımsız çalışabilir. Bir legacy sistemden veri alıp modern API'ye dönüştürme örnek olabilir. Her servis ayrı identity kullanabilir. Deployment CI/CD üzerinden otomatik yapılabilir. Uygulama sayısı büyüdükçe service catalog tutulmalıdır.

Webhook Consumer

Webhook consumer dış sistemlerden HTTP event alır. İmza doğrulaması yapılmalıdır. Duplicate delivery senaryosu göz önünde bulundurulmalıdır. Hızlı response verip işi asenkron queue'ya aktarmak bazı durumlarda daha güvenlidir. Hatalı webhook'lar merkezi loglanmalıdır.

Event Consumer

Cloud Run Pub/Sub veya event tabanlı akışlarda consumer olabilir. Trafiğe göre otomatik ölçeklenebilir. Idempotency uygulanmalıdır. Retry davranışı anlaşılmalıdır. Her event işleme süresi monitoring'e dahil edilmelidir.

Private Service

Internal API'ler public internetten erişilebilir olmak zorunda değildir. Private ingress seçenekleri değerlendirilebilir. Hybrid network üzerinden internal kullanıcılar erişebilir. Authentication yine zorunludur. DNS ve routing kuralları açıkça tasarlanmalıdır.

Workload Identity

Cloud Run service identity ile Google Cloud kaynaklarına erişebilir. Her servis ayrı identity kullanabilir. Geniş project rolleri verilmemelidir. Runtime identity deployment identity'den ayrılmalıdır. IAM policy'ler IaC üzerinden yönetilebilir.

Compute Engine Ne Zaman Kullanılmalı?

Compute Engine sanal makine tabanlı workload'lar için güçlü bir seçenektir. Özellikle legacy uygulamalar, özel işletim sistemi gereksinimleri ve hızlı lift-and-shift projelerinde kullanılabilir. Bütün sanal makinelerin kalıcı hedef olması gerekmez. Migration sonrasında bazı workload'lar GKE, Cloud Run veya yönetilen veri servislerine taşınabilir. VM modernizasyon yol haritası ilk migration aşamasında oluşturulursa rehost edilmiş sistemlerin yıllarca aynı durumda kalması önlenebilir.

Legacy VM Workloads

Eski uygulamalar işletim sistemi ve local file dependency nedeniyle VM gerektirebilir. Compute Engine bu workload'ları daha az uygulama değişikliğiyle taşıyabilir. Network ve disk performansı doğru boyutlandırılmalıdır. Backup politikası ayrıca kurulmalıdır. Uygulama destek ömrü takip edilmelidir.

Lift-and-Shift

Lift-and-shift migration hızını artırabilir. Büyük refactor gerekmez. Ancak mevcut teknik borç korunur. Bulut maliyeti rightsizing yapılmadan yüksek olabilir. Taşıma sonrasında optimization planı uygulanmalıdır.

Custom OS

Bazı uygulamalar özel işletim sistemi veya agent gerektirebilir. VM modeli daha fazla kontrol sağlar. Patch sorumluluğu kurumda kalabilir. Golden image yaklaşımı standardizasyon sağlayabilir. Unsupported OS kullanımı güvenlik riski oluşturur.

Stateful Applications

Stateful uygulamalar local disk veya belirli sistem özelliklerine ihtiyaç duyabilir. Compute Engine bu kontrolü sağlayabilir. Yüksek erişilebilirlik uygulama seviyesinde ayrıca tasarlanmalıdır. Disk snapshot backup yerine tek başına DR çözümü sayılmamalıdır. Failover testi yapılmalıdır.

Managed Instance Groups

Managed Instance Groups stateless VM workload'larını ölçeklemek için kullanılabilir. Instance template ile standart yapı sağlanır. Autoscaling trafik değişimlerine uyum sağlayabilir. Health check hatalı instance'ları tespit eder. Stateful workload için farklı tasarım gerekebilir.

VM Modernizasyon Yol Haritası

Rehost edilen her VM için uzun vadeli hedef belirlenebilir. Bazıları aynı platformda kalabilir. Bazıları container'a taşınabilir. Veri tabanı katmanı managed service'e geçirilebilir. Roadmap business değerine göre önceliklendirilmelidir.

Kurumsal AI ve Vertex AI Entegrasyonu

Kurumsal AI entegrasyonunda model kadar veri erişimi ve yönetişim önemlidir. Vertex AI üzerinden model endpoint'leri oluşturulabilir ve kurumsal uygulamalar kontrollü API erişimi sağlayabilir. RAG senaryolarında veri kaynaklarının IAM izinleri dikkate alınmalıdır. Model servislerinin mümkün olduğunda private connectivity ve merkezi logging ile korunması faydalıdır. Human review gerektiren iş süreçlerinde otomasyon çıktısı doğrudan geri dönüşsüz business işlemine bağlanmamalıdır.

Vertex AI

Vertex AI model geliştirme ve serving süreçlerini yönetilen platformda bir araya getirebilir. Kullanıcı ve workload erişimleri IAM ile sınırlandırılmalıdır. Model endpoint'leri uygulama mimarisine uygun network üzerinden sunulabilir. Maliyet kullanım bazında izlenmelidir. Model lifecycle'ı versiyonlu yönetilmelidir.

Kurumsal Veri

Model eriştiği kurumsal verinin sınıflandırmasına uymalıdır. Her kullanıcı aynı veri kaynaklarına erişmemelidir. RAG sorgularında kullanıcı yetkisi veri filtrelerine yansıtılabilir. Hassas veri loglara yazılmamalıdır. Data governance AI projelerinden bağımsız düşünülmemelidir.

RAG

RAG kurumsal içeriklerin model yanıtına bağlam olarak verilmesini sağlar. Kaynak dokümanın erişim izinleri korunmalıdır. Index güncelliği monitoring'e dahil edilmelidir. Yanıtın kaynak gösterme modeli belirlenebilir. Hassas içerik kullanıcı yetkisine göre filtrelenmelidir.

Model Endpoint

Model endpoint uygulamaların modele eriştiği servis noktasıdır. Authentication uygulanmalıdır. Public erişim zorunlu değilse private seçenekler değerlendirilebilir. Rate limit ve quota maliyeti kontrol eder. Endpoint latency SLO'su izlenebilir.

IAM

AI servislerine erişim minimum role ile verilmelidir. Deployment ve kullanım izinleri ayrılabilir. Kullanıcı bazlı geniş yetkilerden kaçınılmalıdır. Service identity uygulama bazında tanımlanabilir. Audit loglar hassas model işlemlerini izlemek için kullanılabilir.

Private Connectivity

Kurumsal workload'lar model servislerine private bağlantı üzerinden erişebilir. Bu yaklaşım internet exposure'ını azaltabilir. DNS ve network policy doğru planlanmalıdır. Private connectivity authorization yerine geçmez. IAM aynı şekilde uygulanmalıdır.

Model Monitoring

Model monitoring yalnızca sistem uptime'ını takip etmez. Latency, error rate ve model davranışları izlenebilir. Kullanım maliyeti de dashboard'a eklenmelidir. Kritik business süreçlerinde kalite metriği belirlenmelidir. Model değişiklikleri kontrollü rollout ile yapılabilir.

Responsible AI

Kurumsal AI sistemlerinde kullanım amacı açık olmalıdır. Hassas veya geri dönüşsüz kararlar insan kontrolü gerektirebilir. Kullanıcıya model çıktısının sınırları doğru aktarılmalıdır. Veri erişimi minimum düzeyde tutulmalıdır. Audit trail kritik işlemlerde korunmalıdır.

AI Agent'ları Kurumsal Sistemlere Bağlamak

Agent tabanlı sistemler kurumsal uygulamalara bağlanırken doğrudan sınırsız veri veya işlem yetkisi almamalıdır. Daha güvenli model, agent'ın kontrollü tool veya API katmanı üzerinden işlem yapmasıdır. Business rule validation deterministik servislerde tutulabilir. Kritik ERP veya finans işlemleri human-in-the-loop onayı gerektirebilir. Agent identity ayrı workload kimliği olarak yönetilmeli ve her tool çağrısı audit edilmelidir.

Agent Runtime

Agent runtime modelin tool çağrıları yaptığı çalışma ortamıdır. Runtime ayrı service identity kullanmalıdır. Network erişimi yalnızca gerekli servislerle sınırlandırılmalıdır. Secret bilgileri doğrudan prompt içine eklenmemelidir. Runtime logları hassas veri açısından filtrelenmelidir.

Application Integration Tool

Kurumsal sistemlere erişim kontrollü integration tool üzerinden sağlanabilir. Tool input validation yapmalıdır. Agent yalnızca izin verilen operasyonları çağırabilmelidir. Business rule kontrolü tool tarafında bulunmalıdır. Her çağrı audit trail oluşturmalıdır.

ERP

ERP işlemleri finansal ve operasyonel açıdan kritik olabilir. Agent'a doğrudan sınırsız yazma yetkisi verilmemelidir. Belirli operasyonlar API üzerinden sınırlandırılabilir. Yüksek riskli işlem insan onayı gerektirebilir. Transaction kayıtları audit edilmelidir.

CRM

CRM verisi kişisel veya ticari hassas bilgiler içerebilir. Agent yalnızca kullanıcı yetkisine uygun kayıtlara erişmelidir. Toplu veri export'u sınırlandırılabilir. Yazma işlemleri validation katmanından geçmelidir. Kullanıcıya agent işlemleri görünür hale getirilebilir.

ITSM

Agent ITSM süreçlerinde ticket özetleme veya sınıflandırma yapabilir. Kritik change veya incident kapatma işlemleri onay gerektirebilir. Tool-level authorization kullanılmalıdır. Kullanıcı rolü işleme yansıtılmalıdır. Audit loglar kim adına hangi işlemin yapıldığını göstermelidir.

Deterministik Business Logic

Kesin kurallar model kararına bırakılmamalıdır. Finans limiti, erişim kontrolü ve validation kod tarafında uygulanabilir. Agent yalnızca gerekli parametreleri toplar. Backend kuralı ihlal eden işlemi reddeder. Böylece model çıktısı güvenlik sınırlarını aşamaz.

Human-in-the-Loop

Yüksek etkili işlemlerde insan onayı güvenlik katmanı sağlar. Agent öneri hazırlayabilir. Kullanıcı sonucu inceleyip onay verir. Onay kaydı audit trail'e eklenir. Bu model otomasyon ile kontrol arasında dengeli yaklaşım sunar.

AI Agent Neden Doğrudan ERP'ye Sınırsız Erişmemelidir?

Agent çıktıları olasılıksal davranış gösterebilir ve yanlış yorumlama ihtimali tamamen ortadan kalkmaz. Bu nedenle finansal veya operasyonel sistemlere sınırsız yetki vermek gereksiz risk oluşturur. Agent identity minimum izinle sınırlandırılmalıdır. Tool-level authorization ve business validation gerçek erişim sınırını korumalıdır. Kritik işlem approval aldıktan sonra çalıştırılmalı ve bütün süreç audit edilmelidir.

Non-Deterministic Decisions

Model aynı bağlamda her zaman aynı sonucu üretmeyebilir. Bu özellik yaratıcı görevlerde yararlı olsa da finansal kural uygulamasında risklidir. Kesin kurallar backend kodunda tutulmalıdır. Agent yalnızca öneri üretmelidir. Geri dönüşsüz işlem doğrulanmadan çalıştırılmamalıdır.

Agent Identity

Agent ayrı workload identity kullanmalıdır. İnsan kullanıcı credential'ı paylaşılmamalıdır. Her agent yalnızca gerekli tool'lara erişmelidir. Erişim süresi ve kapsamı sınırlandırılabilir. Audit loglar agent işlemlerini ayrı kimlikle göstermelidir.

Least Privilege

Agent'ın bütün ERP modüllerine erişmesi gerekmez. Kullanım senaryosuna göre dar yetki verilmelidir. Read ve write izinleri ayrılabilir. Hassas operasyonlar ayrı tool'a taşınabilir. Kullanılmayan izinler düzenli review ile kaldırılmalıdır.

Tool-Level Authorization

Her tool kendi authorization kontrolünü yapmalıdır. Agent'ın tool'u çağırabilmesi işlemi otomatik olarak yapabileceği anlamına gelmemelidir. Kullanıcı kimliği de işleme aktarılabilir. Tool parametreleri validation'dan geçmelidir. Yetkisiz istek güvenli biçimde reddedilmelidir.

Business Rule Validation

Business rule model prompt'unda yalnızca metin olarak tutulmamalıdır. Kritik kural kod seviyesinde uygulanmalıdır. Limit, rol veya veri doğrulaması backend tarafından yapılabilir. Agent yanlış parametre gönderse bile işlem engellenir. Validation hataları audit edilmelidir.

Approval

Kritik işlemler insan onayı gerektirebilir. Agent işlem taslağını oluşturur. Yetkili kullanıcı ayrıntıları görür. Onaydan sonra backend işlemi gerçekleştirir. Onay zamanı ve kullanıcısı kayıt altında tutulur.

Audit Trail

Agent işlemlerinin kim adına yapıldığı izlenebilmelidir. Tool çağrısı, input ve sonuç gerekli ölçüde loglanmalıdır. Hassas veri maskelenmelidir. Incident incelemesinde işlem zinciri takip edilebilmelidir. Audit retention kurum gereksinimine göre ayarlanmalıdır.

Kurumsal Secret Yönetimi

Secret yönetimi API key, database password ve certificate gibi hassas bilgilerin source code dışında tutulmasını sağlar. Secret Manager merkezi saklama ve IAM kontrolü sunabilir. Versioning rotation süreçlerini kolaylaştırır. Uygulamalar yalnızca ihtiyaç duyduğu secret'a erişmelidir. Secret erişimlerinin loglanması hem güvenlik hem incident response açısından değerlidir.

Secret Manager

Secret Manager gizli bilgileri merkezi servis olarak tutabilir. Erişim IAM ile sınırlandırılır. Secret version'ları yönetilebilir. Uygulama runtime identity üzerinden erişebilir. Secret değerleri CI loglarına yazılmamalıdır.

API Key

API key source code'a gömülmemelidir. Repository history'den tamamen silmek zor olabilir. Secret storage içinde tutulabilir. Kullanım scope'u mümkün olduğunca sınırlandırılmalıdır. Düzenli rotation uygulanmalıdır.

Database Password

Database password uygulama config dosyasına açık metin olarak yazılmamalıdır. Runtime sırasında güvenli secret kaynağından alınabilir. Rotation uygulamanın kesintisiz devam edeceği şekilde planlanmalıdır. Mümkünse password yerine identity tabanlı bağlantı seçenekleri değerlendirilebilir. Kullanılmayan hesaplar kapatılmalıdır.

Certificate

Certificate ve private key'ler hassas secret kabul edilmelidir. Expiration monitoring yapılmalıdır. Otomatik rotation veya yenileme tercih edilebilir. Private key erişimi minimum kullanıcıyla sınırlandırılmalıdır. Eski sertifikalar kontrollü biçimde kaldırılmalıdır.

Secret Versioning

Versioning secret değişikliklerinin kontrollü yapılmasını sağlar. Yeni version önce test edilebilir. Uygulama geçişi tamamlandıktan sonra eski version kapatılabilir. Rollback ihtiyacı değerlendirilebilir. Eski secret sonsuza kadar aktif bırakılmamalıdır.

Secret Rotation

Rotation credential sızıntısı etkisini azaltır. Süreç manuel olmaktan çıkarılıp otomasyona bağlanabilir. Rotation sırasında uygulama kesintisi oluşmaması test edilmelidir. Kullanılmayan version'lar devre dışı bırakılmalıdır. Rotation failure için alert oluşturulmalıdır.

IAM

Secret erişimi yalnızca ilgili workload identity'ye verilmelidir. Kullanıcıların production secret okuma yetkisi sınırlı tutulmalıdır. Geniş project rolü yerine secret-specific erişim değerlendirilebilir. Access loglar periyodik incelenmelidir. IAM değişiklikleri review sürecine dahil edilmelidir.

Secret'ları Source Code'da Tutmamak

Source code secret saklamak için uygun yer değildir. Private repository bile credential güvenliği garantisi vermez. Commit history secret'ı uzun süre saklayabilir. Secret scanning CI sürecine eklenmelidir. Sızıntı tespit edilirse credential derhal rotate edilmelidir.

Cloud KMS ve CMEK

Kurumsal veri güvenliğinde encryption at rest temel kontrollerden biridir. Google tarafından yönetilen encryption seçeneklerine ek olarak belirli gereksinimlerde Customer-Managed Encryption Keys kullanılabilir. CMEK kurumun anahtar yaşam döngüsü üzerinde daha fazla kontrol sağlamasına yardımcı olur. Bunun karşılığında rotation, erişim ve anahtar erişilebilirliği operasyon sorumluluğu getirir. Key separation ve IAM tasarımı doğru yapılmazsa merkezi anahtar yönetimi yeni bir hata alanı oluşturabilir.

Encryption at Rest

Depolanan verinin şifrelenmesi fiziksel veya mantıksal erişim riskini azaltır. Google Cloud servisleri encryption mekanizmaları sunar. Kurumun ek key kontrol ihtiyacı ayrıca değerlendirilmelidir. Encryption veri erişim IAM'inin yerine geçmez. Key erişimleri audit edilmelidir.

Google-Managed Keys

Google-managed keys birçok standart workload için düşük operasyon yükü sağlar. Anahtar yönetiminin büyük bölümü platform tarafından yapılır. Ek compliance ihtiyacı yoksa basit çözüm olabilir. Veri classification yine uygulanmalıdır. Uygulama IAM'i bağımsız olarak yönetilmelidir.

Customer-Managed Encryption Keys

CMEK anahtar üzerinde müşteri kontrolünü artırır. Belirli servislerin encryption key'i kurum tarafından yönetilebilir. IAM separation of duties modeline göre tasarlanmalıdır. Key silme veya devre dışı bırakma data erişimini etkileyebilir. Operasyon prosedürleri açık biçimde hazırlanmalıdır.

Key Rotation

Key rotation anahtar yaşam döngüsünün parçasıdır. Rotation periyodu kurum politikasına göre belirlenmelidir. Otomatik süreçler tercih edilebilir. Eski key version'larının ne kadar tutulacağı tanımlanmalıdır. Rotation uygulama erişimini kesmemelidir.

Key Separation

Farklı environment veya hassasiyet seviyeleri için ayrı key kullanılabilir. Tek anahtarın çok geniş kaynak grubunu etkilemesi önlenir. Key yönetim sorumluluğu da ayrılabilir. Çok fazla key operasyon yükü yaratabileceği için anlamlı sınırlar kullanılmalıdır. Sahiplik dokümante edilmelidir.

Compliance Gereksinimleri

Bazı kurumlar encryption key üzerinde daha fazla kontrol talep edebilir. Teknik gereksinimler hukuk ve compliance ekipleriyle birlikte değerlendirilmelidir. Her workload için CMEK zorunlu olmayabilir. Operasyon maliyeti ve risk birlikte düşünülmelidir. Policy dokümanları servis tasarımına bağlanmalıdır.

Security Command Center ile Merkezi Güvenlik

Security Command Center güvenlik posture, misconfiguration, vulnerability ve threat finding'lerini merkezi görünürlük altında toplamaya yardımcı olabilir. Çok sayıda project bulunan organizasyonlarda tek tek kaynak kontrol etmek ölçeklenebilir değildir. Merkezi güvenlik görünümü risklerin önceliklendirilmesini kolaylaştırır. Ancak finding üretmek tek başına yeterli değildir. Her finding türü için remediation sahibi, öncelik seviyesi ve kapanış süresi belirlenmelidir.

Security Posture

Security posture kurumun kaynaklarının belirlenen güvenlik standartlarına ne kadar uyduğunu gösterir. Misconfiguration verileri bu görünümü destekler. Trend takibi iyileştirmeyi ölçmeye yardımcı olur. Kritik kontroller önceliklendirilmelidir. Platform ekibi posture sonuçlarını landing zone geliştirmelerinde kullanabilir.

Misconfiguration

Yanlış yapılandırma public erişim veya geniş IAM rolü gibi riskler oluşturabilir. Otomatik taramalar bunları daha hızlı bulur. Finding sahibi belirlenmelidir. Tekrarlanan hatalar Project Factory veya policy ile kalıcı olarak engellenebilir. Yalnızca manuel düzeltme kök nedeni çözmez.

Vulnerability

Container veya workload vulnerability'leri düzenli taranmalıdır. Severity tek başına öncelik belirlemek için yeterli olmayabilir. Internet exposure ve kullanılan paket durumu değerlendirilmelidir. Patch veya image rebuild süreci otomasyona bağlanabilir. Kapanan finding'ler doğrulanmalıdır.

Threat Detection

Threat detection beklenmeyen veya şüpheli davranışları bulmaya yardımcı olur. Alarm üretildiğinde incident response süreci tetiklenmelidir. Yanlış pozitifler zamanla tune edilebilir. Kritik servislerde detection daha detaylı olabilir. Log retention investigation gereksinimini desteklemelidir.

Findings

Finding güvenlik ekibi için aksiyon kaydıdır. Severity, kaynak ve sahip bilgisiyle birlikte takip edilmelidir. Ticket sistemine otomatik aktarım yapılabilir. SLA seviyesi risk derecesine göre belirlenebilir. Kapanış yalnızca ticket kapatmak değil gerçek remediation doğrulaması olmalıdır.

Security Operations

Security operations bulguları günlük iş akışına dönüştürür. Incident, vulnerability ve misconfiguration süreçleri ortak yönetilebilir. SOC ekiplerinin bulut ortamı hakkında yeterli context'e sahip olması gerekir. Otomasyon düşük riskli tekrar eden işleri azaltabilir. Kritik kararlar insan incelemesiyle desteklenmelidir.

Remediation Workflow

Remediation finding'in düzeltilmesi sürecidir. Kaynak sahibi otomatik belirlenebilirse müdahale hızlanır. IaC ile yönetilen kaynakta düzeltme repository üzerinden yapılmalıdır. Manual hotfix sonradan koda aktarılmalıdır. Finding kapanmadan önce tekrar tarama yapılabilir.

Google Cloud Logging ile Merkezi Log Yönetimi

Merkezi log yönetimi incident response ve compliance süreçlerinin temelidir. Cloud Logging uygulama ve altyapı loglarını toplarken Cloud Audit Logs yönetim ve veri erişim olaylarını görünür hale getirir. Büyük organizasyonlarda organization-level log sink ile kayıtlar merkezi logging project'e yönlendirilebilir. Gerekirse analitik veya SIEM amaçlı export yapılabilir. Retention politikası maliyet ve hukuki gereksinimler birlikte değerlendirilerek belirlenmelidir.

Cloud Logging

Cloud Logging uygulama ve altyapı kayıtlarını merkezi olarak yönetebilir. Structured logging sorgu kalitesini artırır. Gereksiz debug logları production maliyetini yükseltebilir. Log seviyesi standardı belirlenmelidir. Hassas bilgi loglara yazılmamalıdır.

Cloud Audit Logs

Audit loglar yönetim ve erişim işlemlerini izler. Incident incelemesinde kim ne yaptı sorusuna cevap verir. Kritik log türleri merkezi projeye aktarılmalıdır. Log silme yetkileri sınırlandırılmalıdır. Retention compliance ihtiyacına göre planlanmalıdır.

Organization-Level Log Sink

Organization seviyesinde sink alt kaynakların loglarını merkezi hedefe yönlendirebilir. Yeni project açıldığında logging entegrasyonu unutulmaz. Filter ile yalnızca gerekli loglar aktarılabilir. Sink identity IAM izinleri doğru verilmelidir. Export maliyeti takip edilmelidir.

Central Logging Project

Merkezi logging project güvenlik ve operasyon ekiplerinin ortak görünümünü sağlar. Uygulama ekiplerinin loglara erişimi ihtiyaç bazında sınırlandırılabilir. Production logları development kullanıcılarına otomatik açılmamalıdır. Project güvenliği ayrı policy ile korunabilir. Log kaynakları service catalog ile ilişkilendirilebilir.

Log Router

Log Router kayıtları farklı hedeflere yönlendirebilir. Security logları SIEM'e, analitik logları veri platformuna gönderilebilir. Filter kuralları dikkatle test edilmelidir. Yanlış filter kritik kayıtların kaybolmasına neden olabilir. Configuration IaC üzerinden yönetilebilir.

BigQuery Export

Logların BigQuery'ye aktarılması uzun dönem analitik için kullanılabilir. Sorgu maliyeti partition tasarımıyla kontrol edilebilir. Hassas log alanları erişim açısından sınırlandırılmalıdır. Retention ihtiyacı ayrı tanımlanabilir. Her logu süresiz saklamak gerekli değildir.

SIEM Export

Security ekipleri cloud loglarını mevcut SIEM platformuna aktarabilir. Audit ve threat logları önceliklendirilir. Network kapasitesi ve export maliyeti takip edilmelidir. Duplicate ingestion önlenmelidir. Alert correlation olay müdahalesini hızlandırabilir.

Retention

Retention süresi iş, güvenlik ve hukuk gereksinimlerine göre belirlenmelidir. Uygulama debug logları ile audit logları aynı süreyi gerektirmeyebilir. Uzun retention maliyet getirir. Silme politikası otomatik uygulanabilir. Kritik incident dönemlerinde ilgili logların korunması gerekebilir.

Cloud Audit Logs Neden Kritiktir?

Audit loglar güvenlik olayı veya production hatası sonrasında değişiklik zincirini anlamanın en güçlü kaynaklarından biridir. Admin Activity sistem yönetim işlemlerini, Data Access ise veri erişim olaylarını gösterebilir. Policy Denied kayıtları başarısız yetki denemelerini anlamaya yardımcı olur. Merkezi loglama olmadan yüzlerce project içinde olay araştırmak zorlaşır. Audit log erişimi ve retention politikası bu nedenle landing zone'un başında tasarlanmalıdır.

Admin Activity

Admin Activity yapılandırma değişikliklerini izlemeye yardımcı olur. IAM veya resource değişiklikleri burada görülebilir. Incident sırasında zaman çizelgesi oluşturulabilir. Merkezi log sink ile kayıtlar korunabilir. Kritik işlemler için alert tanımlanabilir.

Data Access

Data Access hangi principal'ın hangi veriye eriştiğini anlamaya yardımcı olabilir. Hassas servislerde özellikle değerlidir. Log hacmi yüksek olabilir. Bu nedenle retention ve maliyet planlanmalıdır. Erişim anomalileri security analytics ile tespit edilebilir.

System Event

System Event platform tarafından gerçekleştirilen bazı sistem olaylarını gösterir. Beklenmeyen resource değişikliklerinin nedenini anlamaya yardımcı olabilir. Incident timeline'a dahil edilmelidir. Monitoring alarmıyla birlikte incelendiğinde daha fazla context sağlar. Log kaynağına göre anlamı dokümante edilmelidir.

Policy Denied

Policy Denied yetki veya policy nedeniyle engellenen işlemleri gösterebilir. Kullanıcı sorunlarını troubleshooting etmekte faydalıdır. Tekrarlanan denied denemeleri güvenlik açısından incelenebilir. Yanlış policy rollout'u erken fark edilebilir. Loglar doğru operasyon ekibine yönlendirilmelidir.

Kim Ne Yaptı?

Audit'in temel sorusu işlemin hangi kimlik tarafından yapıldığıdır. İnsan kullanıcı, service account veya federated principal ayrıştırılmalıdır. Ortak credential kullanımı bu görünürlüğü zayıflatır. Her workload ayrı identity kullanmalıdır. Audit trail uygulama transaction kayıtlarıyla ilişkilendirilebilir.

Incident Investigation

Incident sırasında loglar olayın ne zaman başladığını anlamaya yardımcı olur. IAM değişikliği, deployment veya network policy aynı zaman çizelgesine eklenebilir. Merkezi log olmadan farklı project'lerden veri toplamak zaman kaybettirir. Log timestamp standardı önemlidir. Kritik kayıtların yeterli süre saklanması gerekir.

Compliance

Audit loglar belirli compliance kanıtlarının oluşturulmasına yardımcı olabilir. Kimlik ve erişim geçmişi kayıt altına alınır. Retention politikası resmi gereksinime göre ayarlanmalıdır. Loglara kimlerin erişebildiği de kontrol edilmelidir. Compliance yalnızca log saklamak değil süreçlerin doğrulanabilir olmasıdır.

Google Cloud Monitoring ile Observability

Observability altyapının yalnızca çalışıp çalışmadığını değil neden belirli davranış gösterdiğini anlamayı hedefler. Metrics, dashboards, logs ve traces birlikte değerlendirildiğinde sorunların kök nedeni daha hızlı bulunabilir. Google Cloud Monitoring altyapı ve uygulama metriklerini takip etmek için kullanılabilir. SLO ve error budget tanımları operasyon ekiplerinin alarm yorgunluğunu azaltır. Her metrik için alarm oluşturmak yerine kullanıcı deneyimini etkileyen göstergeler önceliklendirilmelidir.

Metrics

Metrics sistem davranışını sayısal olarak ölçer. CPU ve memory dışında request rate, latency ve error rate önemlidir. Business metrics de dashboard'a eklenebilir. Çok fazla metrik takip etmek yerine anlamlı göstergeler seçilmelidir. Metric label cardinality maliyet ve performansı etkileyebilir.

Dashboards

Dashboard operasyon ekibine sistemin genel durumunu gösterir. Her ekip kendi servis görünümüne sahip olabilir. Ortak platform dashboard'ları network ve IAM olaylarını gösterebilir. Renkli grafik sayısı yerine karar vermeyi kolaylaştıran metrikler seçilmelidir. Dashboard düzenli olarak sadeleştirilmelidir.

Alerting

Alert yalnızca aksiyon gerektiren durumda üretilmelidir. Sürekli kapanıp açılan alarmlar ekipleri duyarsızlaştırır. Threshold gerçek SLO değerlerine göre ayarlanmalıdır. Alert sahibi ve escalation yolu belirlenmelidir. Her kritik alarm için runbook bulunması faydalıdır.

Uptime Checks

Uptime check dışarıdan veya belirli noktadan servisin erişilebilirliğini kontrol eder. Kullanıcıya yakın test noktaları seçilebilir. Yalnızca HTTP 200 dönmesi business işlemin çalıştığı anlamına gelmeyebilir. Kritik fonksiyonlar için synthetic check kullanılabilir. Failover sırasında uptime davranışı gözlenebilir.

SLO

Service Level Objective kullanıcıya sunulan güvenilirlik hedefini tanımlar. Availability veya latency üzerinden belirlenebilir. Her sistem için yüzde yüz hedef koymak maliyeti gereksiz artırabilir. İş etkisine uygun gerçekçi hedef seçilmelidir. SLO ekiplerin reliability kararlarında ortak dil oluşturur.

Error Budget

Error budget SLO altında kabul edilebilir hata payını ifade eder. Sistem stabilse ekip daha hızlı değişiklik yapabilir. Budget tüketimi yüksekse reliability çalışmalarına öncelik verilebilir. Bu yaklaşım geliştirme hızı ile stabilite arasında denge kurar. Yönetim ve teknik ekip aynı metriği kullanabilir.

Infrastructure Monitoring

Infrastructure monitoring compute, disk, network ve servis sağlığını takip eder. Capacity trendleri erken uyarı sağlar. Hybrid bağlantı durumları aynı görünümde izlenebilir. Sadece resource utilization yerine service impact de gösterilmelidir. Alertlerin ilgili ekip sahiplerine yönlendirilmesi gerekir.

Application Monitoring

Application monitoring request latency, error rate ve dependency durumunu gösterir. Distributed tracing mikroservis ortamlarında faydalıdır. Release sonrası değişiklikler deployment annotation ile ilişkilendirilebilir. Business transaction health ayrıca izlenebilir. Uygulama loglarında kişisel veri bulunmamasına dikkat edilmelidir.

OpenTelemetry ile Vendor-Neutral Observability

OpenTelemetry metrics, logs ve traces için açık bir telemetry standardı sunar. Multi-cloud veya hybrid ortamda farklı platformlardan gelen veriyi ortak collector yapısında toplamak operasyon modelini sadeleştirebilir. Uygulama kodunun tek bir backend'e sıkı bağlanması azalır. OpenTelemetry Collector filtreleme ve yönlendirme katmanı olarak kullanılabilir. Bununla birlikte telemetry hacmi ve cardinality kontrol edilmezse observability maliyeti hızla artabilir.

Metrics

OpenTelemetry metrics uygulama ve altyapı ölçümlerini ortak formatta toplar. Naming convention standardı önemlidir. Çok yüksek label cardinality maliyeti artırabilir. Ortak semantic conventions kullanmak ekiplerin veriyi anlamasını kolaylaştırır. Collector üzerinden filtreleme yapılabilir.

Logs

Log telemetry farklı servislerden merkezi pipeline'a aktarılabilir. Structured logging tercih edilmelidir. Hassas alanlar collector aşamasında filtrelenebilir. Log seviyesi standardı gereksiz hacmi azaltır. Kaynak servis bilgisi her kayıtta bulunmalıdır.

Traces

Distributed traces bir isteğin mikroservisler arasındaki yolunu gösterir. Latency problemlerini bulmada yararlıdır. Sampling oranı trafik hacmine göre ayarlanmalıdır. Her request'i tam trace etmek maliyetli olabilir. Error transaction'ları daha yüksek oranla saklamak değerlendirilebilir.

OpenTelemetry Collector

Collector telemetry verisini alır, işler ve backend'e gönderir. Merkezi veya agent tabanlı kurulabilir. Buffer ve retry ayarları önemlidir. Collector kesintisi telemetry kaybına yol açabilir. Yüksek erişilebilir deployment düşünülmelidir.

Google Cloud Observability

OpenTelemetry verileri Google Cloud observability servislerine yönlendirilebilir. Uygulama instrumentation platformdan daha bağımsız kalır. Migration sırasında backend değiştirmek daha kolay olabilir. Native cloud telemetry ile birlikte kullanılabilir. Veri hacmi maliyet açısından izlenmelidir.

Multi-Cloud Telemetry

Multi-cloud ortamlarda ortak telemetry formatı operasyon ekiplerine tek dil sağlar. Farklı ortamların metrikleri aynı dashboard'a taşınabilir. Servis isimlendirme standardı önemlidir. Network üzerinden telemetry transfer maliyeti hesaplanmalıdır. Veri yerleşimi gereksinimleri göz önünde bulundurulmalıdır.

Vendor Lock-In'i Azaltmak

Açık telemetry standardı uygulamanın belirli monitoring SDK'sına bağımlılığını azaltabilir. Backend değiştirmek daha kolay hale gelir. Bununla birlikte her platformun native özellikleri yine farklı olabilir. Tam portability hedefi maliyetli olabilir. Açık standartlar stratejik esneklik sağlar.

Kurumsal Backup Stratejisi

Backup almak tek başına veri koruma stratejisi değildir. Hangi verinin ne sıklıkla yedekleneceği, ne kadar tutulacağı ve nasıl restore edileceği tanımlanmalıdır. Immutable backup kritik ransomware senaryolarında yararlı olabilir. Cross-region kopyalar bölgesel arıza riskini azaltabilir. En önemli kontrol ise düzenli restore testidir, çünkü hiç geri yüklenmemiş backup'ın çalıştığı varsayılmamalıdır.

Backup Politikası

Backup policy veri sınıfına göre hazırlanmalıdır. Kritik veri daha sık yedeklenebilir. RPO hedefi backup sıklığını etkiler. Retention süresi compliance gereksinimine göre belirlenebilir. Policy otomasyonla uygulanmalıdır.

Immutable Backup

Immutable backup belirli süre değiştirilemeyen veya silinemeyen kopya sağlar. Yetkili hesabın ele geçirilmesi durumunda ek koruma sunar. Retention süresi dikkatle belirlenmelidir. Storage maliyeti hesaba katılmalıdır. Restore prosedürü ayrıca test edilmelidir.

Cross-Region Backup

Cross-region backup bölgesel olaylara karşı koruma sağlar. Hangi region çiftinin kullanılacağı veri yerleşimi gereksinimiyle uyumlu olmalıdır. Transfer maliyeti hesaplanmalıdır. Recovery sırasında network kapasitesi yeterli olmalıdır. Backup başarı durumu merkezi monitoring'e eklenmelidir.

Retention

Retention yedeklerin ne kadar süre saklanacağını belirler. Her veri aynı süreyi gerektirmez. Çok uzun süre maliyeti artırabilir. Çok kısa süre eski hata veya güvenlik olaylarında geri dönüşü engelleyebilir. Hukuki gereksinimler planlamaya dahil edilmelidir.

Encryption

Backup verileri şifrelenmelidir. Hassas veriler için key yönetimi ayrıca değerlendirilmelidir. Backup erişim IAM'i production erişiminden ayrılabilir. Anahtar kaybı backup'ı kullanılamaz hale getirebilir. Recovery prosedürleri key erişimini de kapsamalıdır.

Backup Monitoring

Başarısız backup otomatik alert üretmelidir. Son başarılı yedek zamanı dashboard'da görülebilir. Backup job süresi beklenmedik şekilde uzarsa kapasite sorunu olabilir. Storage doluluk oranı takip edilmelidir. Monitoring yalnızca job başladı bilgisini değil başarı sonucunu doğrulamalıdır.

Restore Testi

Restore testi backup stratejisinin en önemli doğrulamasıdır. Ayrı test ortamında düzenli geri yükleme yapılabilir. Süre ölçülerek RTO ile karşılaştırılmalıdır. Uygulama seviyesinde veri doğrulaması yapılmalıdır. Test sonucu kayıt altına alınmalıdır.

Disaster Recovery Nasıl Tasarlanmalı?

Disaster recovery işletmenin kabul edebileceği veri kaybı ve kesinti hedefleriyle başlar. RPO ne kadar veri kaybının kabul edileceğini, RTO ise servisin ne kadar sürede geri dönmesi gerektiğini tanımlar. Backup and restore en ekonomik model olabilirken warm standby daha hızlı recovery sağlayabilir. Multi-region active-active en yüksek availability ihtiyacında kullanılabilir ancak operasyon maliyeti de artar. Her modelin failover ve failback prosedürü gerçek testlerle doğrulanmalıdır.

RPO

Recovery Point Objective kabul edilebilir veri kaybı süresini tanımlar. Beş dakikalık RPO ile yirmi dört saatlik RPO aynı replication maliyetine sahip değildir. İş birimi bu değeri belirlemelidir. Teknik mimari hedefe göre tasarlanmalıdır. Backup sıklığı ve replication modeli RPO ile ilişkilidir.

RTO

Recovery Time Objective servisin ne kadar sürede yeniden çalışması gerektiğini belirtir. Çok düşük RTO daha fazla hazır kapasite gerektirebilir. İş etkisi ile maliyet dengelenmelidir. Restore testlerinde gerçek süre ölçülmelidir. Dokümanda yazan RTO test sonucu ile doğrulanmalıdır.

Backup and Restore

Backup and restore düşük maliyetli DR modeli olabilir. Felaket sırasında altyapı yeniden oluşturulur ve veri geri yüklenir. RTO daha uzun olabilir. IaC recovery süresini azaltır. Backup bütünlüğü düzenli test edilmelidir.

Pilot Light

Pilot light modelinde kritik temel bileşenler DR ortamında minimum kapasiteyle çalışır. Felaket sırasında kapasite hızla büyütülür. Veri replication sürekli olabilir. Automation recovery hızını artırır. Ölçekleme prosedürü düzenli test edilmelidir.

Warm Standby

Warm standby ikincil ortamın çalışan fakat düşük kapasitede tutulmasını sağlar. Failover süresi backup modeline göre daha kısadır. Ek sürekli maliyet oluşturur. Data replication dikkatle izlenmelidir. Trafik yönlendirme prosedürü test edilmelidir.

Multi-Region Active-Active

Active-active model iki veya daha fazla region'ın aynı anda trafik taşımasını sağlar. Çok düşük RTO hedeflerinde kullanılabilir. Uygulama ve veri katmanı dağıtık çalışma için tasarlanmalıdır. Conflict resolution ve consistency gereksinimleri önemlidir. Maliyet ve operasyon yükü diğer modellerden daha yüksektir.

Failover

Failover trafiğin yedek ortama geçirilmesidir. Otomatik veya manuel olabilir. Tetikleme kriterleri açıkça tanımlanmalıdır. DNS veya global load balancing stratejisi kullanılabilir. Failover sonrası business validation yapılmalıdır.

Failback

Failback ana ortama kontrollü dönüş sürecidir. Failover kadar dikkat gerektirir. İki ortam arasındaki veri farkı çözülmelidir. Trafik kademeli geri alınabilir. Incident sonrası postmortem ile süreç iyileştirilmelidir.

Google Cloud Well-Architected Framework

Well-Architected yaklaşım mimari kararların yalnızca performans açısından değil operasyon, güvenlik, güvenilirlik, maliyet ve sürdürülebilirlik açısından değerlendirilmesini sağlar. Bir servisin teknik olarak çalışması onun kurumsal olarak doğru seçim olduğu anlamına gelmez. Örneğin yüksek availability sağlayan bir mimari gereksiz maliyet oluşturuyorsa business ihtiyacıyla tekrar değerlendirilmelidir. Güvenlik veya operasyon yükü de aynı kararda yer almalıdır. Entegrasyon kararlarını ortak kriterlerle değerlendirmek ekipler arasında daha tutarlı mimari dili oluşturur.

Operational Excellence

Operational excellence sistemin nasıl deploy edildiği, izlendiği ve iyileştirildiğiyle ilgilidir. Manuel operasyonlar mümkün olduğunca otomasyona taşınmalıdır. Runbook ve incident süreçleri hazırlanmalıdır. Değişiklikler version kontrolünde tutulmalıdır. Postmortem sonuçları platform iyileştirmelerine dönüştürülmelidir.

Security, Privacy and Compliance

Güvenlik bütün mimari katmanlara uygulanmalıdır. IAM, encryption ve network kontrolleri birlikte düşünülmelidir. Veri classification privacy kararlarını yönlendirir. Compliance gereksinimleri teknik kontrollerle eşleştirilmelidir. Audit kanıtları otomatik üretilebilmelidir.

Reliability

Reliability sistemin hata durumunda beklenen hizmet seviyesini korumasıdır. Redundancy ve failover tasarımı iş ihtiyacına göre yapılmalıdır. SLO ve error budget kullanılabilir. Backup ve restore testi zorunludur. Failure injection veya DR tatbikatı gerçek dayanıklılığı gösterir.

Cost Optimization

Cost optimization yalnızca kaynak küçültmek değildir. Doğru servis seçimi ve autoscaling önemli rol oynar. Idle kaynaklar temizlenmelidir. Network egress ve logging maliyeti izlenmelidir. Optimization sürekli süreç olmalıdır.

Performance Optimization

Performance workload gereksinimine göre ölçülmelidir. Büyük instance kullanmak her zaman çözüm değildir. Caching, data locality ve concurrency tasarımı değerlendirilebilir. Load test gerçek trafik modeline benzemelidir. Performance değişiklikleri maliyet etkisiyle birlikte izlenmelidir.

Sustainability

Sustainability kaynakların gereksiz tüketilmemesini de kapsar. Idle kapasite azaltılabilir. Autoscaling ve managed services verimliliği artırabilir. Veri retention gereksiz yere sonsuz tutulmamalıdır. Mimari kararların uzun vadeli kaynak etkisi değerlendirilebilir.

Her Entegrasyon Kararını Altı Pilarla Değerlendirmek

Yeni servis seçildiğinde operasyon, güvenlik, reliability, cost, performance ve sustainability birlikte sorulmalıdır. Bu yaklaşım ekipleri tek metrikle karar vermekten uzaklaştırır. Mimari review checklist'e bu sorular eklenebilir. Trade-off'lar açıkça kaydedilmelidir. Böylece gelecekte kararın neden verildiği anlaşılabilir.

Kurumsal CI/CD Google Cloud'a Nasıl Entegre Edilir?

Kurumsal CI/CD hattı Google Cloud deployment'larında identity, artifact güvenliği ve policy kontrollerini birlikte ele almalıdır. Build sistemi production'a erişirken uzun ömürlü service account key saklamak yerine federation kullanabilir. Container ve paketler Artifact Registry gibi kontrollü repository'de tutulabilir. Deployment öncesi IaC, secret ve image taramaları çalıştırılabilir. Production erişiminin repository, environment ve branch koşullarına göre sınırlandırılması keyless CI/CD modelini daha güvenli hale getirir.

Cloud Build

Cloud Build build ve deployment pipeline'ları için kullanılabilir. Service identity minimum yetkiye sahip olmalıdır. Build artifact'leri kontrollü registry'ye gönderilmelidir. Secret'lar build loglarına yazılmamalıdır. Production deployment için onay adımı uygulanabilir.

Workload Identity Federation

Harici CI sistemleri federation üzerinden Google Cloud'a erişebilir. Statik JSON key saklama ihtiyacı azalır. Repository ve branch attribute'ları erişim koşulunda kullanılabilir. Production yalnızca yetkili workflow tarafından deploy edilebilir. Federation policy düzenli review edilmelidir.

Artifact Registry

Artifact Registry container ve paketlerin merkezi olarak tutulmasını sağlar. IAM ile publish ve pull yetkileri ayrılabilir. Vulnerability scanning güvenlik sürecine eklenebilir. Immutable release yaklaşımı tercih edilebilir. Production deployment yalnızca onaylı artifact kullanmalıdır.

Deployment

Deployment environment bazında farklı policy'lere sahip olabilir. Development otomatik deploy edilirken production onay gerektirebilir. Canary veya gradual rollout riski azaltabilir. Deployment sonrası monitoring otomatik kontrol yapmalıdır. Başarısız release için rollback prosedürü bulunmalıdır.

Keyless CI/CD

Keyless model uzun ömürlü credential kullanımını azaltır. CI platformu kısa ömürlü identity token üzerinden erişir. Her pipeline ayrı policy ile sınırlandırılabilir. Credential rotation yükü azalır. Audit loglar hangi pipeline'ın hangi işlemi yaptığını gösterebilir.

DevSecOps ile Google Cloud Entegrasyonu

DevSecOps güvenliği deployment'ın son kontrol noktası olmaktan çıkarıp geliştirme sürecine dağıtır. IaC scanning, secret scanning, container scanning ve policy as code kontrolleri pull request aşamasında çalışabilir. Geliştirici hatayı production yerine kod incelemesi sırasında görür. Runtime security ise deployment sonrasında oluşabilecek riskleri izler. Amaç geliştiricileri daha fazla manuel forma yönlendirmek değil, güvenli varsayılanları platformun içine yerleştirmektir.

Security by Design

Security by Design güvenlik gereksinimlerini mimarinin ilk aşamasında ele alır. Network ve IAM sonradan eklenmez. Data classification servis seçimlerini etkiler. Threat model kritik uygulamalar için hazırlanabilir. Tasarım kararları security review sürecine dahil edilir.

Shift Left

Shift left hataları geliştirme sürecinin erken aşamasında bulmayı hedefler. Pull request kontrolleri buna örnektir. Geliştirici hızlı geri bildirim alır. Production remediation maliyeti azalır. Çok fazla gereksiz kontrol pipeline süresini uzatmamalıdır.

IaC Scanning

IaC scanning Terraform gibi dosyalarda güvenlik risklerini bulur. Public erişim veya yanlış encryption ayarları tespit edilebilir. Tarama kuralları kurum policy'leriyle eşleştirilebilir. False positive sonuçları düzenli tune edilmelidir. Kritik finding deployment'ı engelleyebilir.

Secret Scanning

Secret scanning repository'ye yanlışlıkla eklenen credential'ları bulmaya yardımcı olur. Tespit edilen secret yalnızca dosyadan silinmemelidir. Credential rotate edilmelidir. Pre-commit kontrolleri erken uyarı sağlayabilir. Repository geçmişi de değerlendirilmelidir.

Container Scanning

Container image bağımlılıkları vulnerability açısından taranabilir. Severity ve gerçek exploitability birlikte değerlendirilmelidir. Base image düzenli güncellenmelidir. Production yalnızca güvenlik kriterini geçen image'ı kullanabilir. Image rebuild otomasyona bağlanabilir.

Policy as Code

Policy as Code kurumsal kuralları pipeline içinde uygular. Environment farklarına göre farklı kurallar kullanılabilir. İstisnalar süreli ve kayıtlı olmalıdır. Policy değişiklikleri review edilmelidir. Geliştiriciye açık hata mesajı verilmesi adoption'ı kolaylaştırır.

Deployment Controls

Deployment control kimlerin hangi environment'a deploy yapabileceğini belirler. Production pipeline ayrı onay gerektirebilir. Artifact provenance ve image digest doğrulanabilir. Manuel bypass işlemleri audit edilmelidir. Acil hotfix süreci ayrıca tasarlanmalıdır.

Runtime Security

Runtime security çalışan workload'larda şüpheli davranışları izler. Container ve VM olayları merkezi security platformuna gönderilebilir. Anomali tespitinde incident response otomasyonu çalıştırılabilir. Runtime erişimler minimum privilege ile sınırlandırılmalıdır. Güvenlik yalnızca build aşamasında bitmez.

Kurumsal Platform Engineering Yaklaşımı

Platform engineering, geliştirici ekiplerin her projede network, IAM, CI/CD ve observability yapılarını yeniden kurmasını önlemeyi hedefler. Internal Developer Platform güvenli self-service altyapı sunabilir. Golden path yaklaşımı önerilen deployment modelini hazır template olarak sağlar. Guardrail'ler güvenlik sınırlarını korurken ekipler belirli alanlarda kendi kararlarını verebilir. Bu controlled autonomy modeli hem hız hem governance açısından güçlü bir denge sağlar.

Internal Developer Platform

Internal Developer Platform ortak altyapı yeteneklerini geliştiricilere ürün gibi sunar. Project oluşturma, deployment ve observability tek arayüzden sağlanabilir. Platform ekibi kullanıcı geri bildirimlerini toplamalıdır. Gereksiz özellik eklemek yerine sık kullanılan akışlar sadeleştirilmelidir. Platform adoption metriği izlenebilir.

Golden Path

Golden path güvenli ve desteklenen geliştirme yoludur. Örneğin Cloud Run servisi için hazır CI/CD ve logging template'i sunulabilir. Ekip sıfırdan IAM tasarlamak zorunda kalmaz. İstisna gerektiğinde kontrollü alternatif yol bulunmalıdır. Golden path zorunlu olmayan ama en kolay seçenek olmalıdır.

Project Factory

Project Factory platformun self-service temelidir. Yeni project standart label, IAM ve network ayarlarıyla oluşturulur. Manuel ticket sayısı azalır. Platform ekibi standartları kod üzerinden yönetir. Proje oluşturma süresi dakikalara indirilebilir.

Self-Service Infrastructure

Geliştirici ekip güvenli sınırlar içinde kaynak oluşturabilir. Terraform modülleri veya service catalog kullanılabilir. Production için daha sıkı approval uygulanabilir. Self-service açık uçlu admin yetkisi anlamına gelmez. Guardrail'ler arka planda otomatik çalışmalıdır.

Service Catalog

Service catalog desteklenen platform servislerini listeler. Her servisin sahibi ve kullanım dokümanı bulunur. Kullanılmayan veya deprecated template'ler kaldırılabilir. Maliyet ve güvenlik özellikleri geliştiriciye açık gösterilebilir. Catalog standardizasyonu teşvik eder.

Standard CI/CD

Ortak CI/CD template'i security scanning ve artifact yönetimini otomatik ekler. Her ekip pipeline'ı sıfırdan kurmaz. Deployment identity modeli standardize edilir. Production onayları ortak süreçte yürütülür. Template değişiklikleri merkezi güncellenebilir.

Guardrails

Guardrail ekiplerin belirlenen güvenlik sınırları içinde özgür çalışmasını sağlar. Organization Policy ve policy as code bu modele katkı verir. Amaç her değişiklik için manuel izin istemek değildir. İhlal durumunda geliştiriciye açık hata mesajı verilmelidir. Guardrail'ler ekip deneyimine göre sürekli geliştirilmelidir.

Controlled Autonomy

Controlled autonomy platform ekibi ile uygulama ekipleri arasındaki dengeyi kurar. Geliştirici standart servisleri self-service kullanır. Riskli değişiklikler review sürecine gider. Bu model merkezi kontrol ile yerel hız arasında orta yol sağlar. Net sorumluluk sınırları RACI ile desteklenmelidir.

FinOps ile Google Cloud Maliyet Yönetimi

FinOps bulut maliyetini yalnızca finans departmanının takip ettiği fatura olmaktan çıkarır ve teknik ekiplerin günlük kararlarına bağlar. Billing Account, project, label ve cost center verileri üzerinden maliyet sahipliği görünür hale getirilebilir. BigQuery billing export daha ayrıntılı analiz imkânı sağlar. Budget ve alert mekanizmaları beklenmeyen harcamaları erken gösterir. En iyi sonuç, ekiplerin kendi servislerinin maliyetini görebildiği ve optimizasyon aksiyonlarını kendilerinin alabildiği modelde ortaya çıkar.

Billing Account

Billing Account projelerin faturalandırma sınırını oluşturur. Hangi project'in hangi hesaba bağlı olduğu kayıt altında tutulmalıdır. Finans erişimleri IAM ile sınırlandırılmalıdır. Maliyet raporları düzenli hazırlanabilir. Billing yapısı şirketin cost center modeliyle ilişkilendirilebilir.

Project Cost

Project bazlı maliyet uygulama veya environment sahipliğini gösterir. Production ve development ayrımı analiz kolaylığı sağlar. Ortak servis projeleri ayrıca raporlanmalıdır. Ani maliyet değişimleri alert üretebilir. Project owner optimization sorumluluğuna dahil edilmelidir.

Labels

Labels cost allocation için kullanışlı metadata sağlar. Environment, team ve product bilgisi eklenebilir. Standart isimlendirme zorunlu tutulmalıdır. Eksik label bulunan kaynaklar otomatik tespit edilebilir. Çok fazla serbest label raporlamayı zorlaştırabilir.

Cost Center

Cost center maliyetin hangi iş birimine ait olduğunu gösterir. Project Factory bu bilgiyi başlangıçta zorunlu alabilir. Ortak servis maliyetleri paylaştırılabilir. Finans ekibi raporları cost center bazında tüketebilir. Sahipliği bilinmeyen maliyet azaltılmalıdır.

Billing Export

Billing export ayrıntılı tüketim verisini analitik ortama aktarabilir. Kaynak ve servis bazında trend analizi yapılabilir. Dashboard oluşturulabilir. Anomali detection süreçleri eklenebilir. Export dataset erişimi finans ve platform ekibiyle sınırlandırılabilir.

BigQuery

Billing verisi BigQuery üzerinde analiz edilebilir. Günlük ve aylık trendler çıkarılabilir. En pahalı project veya servisler bulunabilir. Query maliyeti için partition kullanılabilir. Raporlar otomatik dashboard'a bağlanabilir.

Budget

Budget harcama hedefini tanımlar. Environment veya proje bazında oluşturulabilir. Belirli yüzde eşiklerinde bildirim gönderilebilir. Budget harcamayı otomatik durdurmak zorunda değildir. Ekiplerin aksiyon süreci ayrıca tanımlanmalıdır.

Alert

Cost alert beklenmeyen harcamayı erken fark etmeye yardımcı olur. Yalnızca toplam fatura yerine servis bazlı anomali de izlenebilir. Alert ilgili uygulama sahibine ulaşmalıdır. Yanlış pozitif eşikler düzenli ayarlanmalıdır. Kritik maliyet artışları incident benzeri süreçle ele alınabilir.

Google Cloud Maliyetleri Nasıl Optimize Edilir?

Maliyet optimizasyonu migration sonrasında bir kez yapılan temizlik çalışması değildir. Rightsizing, autoscaling, idle resource detection, storage lifecycle ve network egress analizi sürekli yürütülmelidir. Committed kullanım modelleri yalnızca tüketim profili yeterince öngörülebilir olduğunda değerlendirilmelidir. Logging maliyeti birçok kurumda gözden kaçan başlıklardan biridir. FinOps dashboard'ları teknik ekiplerin maliyeti performans ve reliability ile birlikte değerlendirmesine yardımcı olur.

Rightsizing

Rightsizing kaynak kapasitesini gerçek kullanıma göre ayarlar. Çok büyük VM veya database gereksiz maliyet oluşturabilir. CPU kadar memory ve disk performansı da incelenmelidir. Peak değerler göz önünde bulundurulmalıdır. Değişiklik sonrası performance monitoring yapılmalıdır.

Committed Use Discounts

Uzun süreli ve öngörülebilir tüketimde committed kullanım modeli maliyet avantajı sağlayabilir. Ancak gereğinden fazla kapasite taahhüt etmek ters etki yaratır. Önce kullanım trendi ölçülmelidir. Migration'ın ilk günlerinde acele karar verilmemelidir. Finans ve platform ekipleri birlikte değerlendirme yapmalıdır.

Autoscaling

Autoscaling trafik azaldığında kapasiteyi düşürebilir. Statik overprovisioning ihtiyacını azaltır. Minimum ve maksimum sınırlar doğru belirlenmelidir. Ani trafik artışlarında startup süresi test edilmelidir. Scaling metrics business workload'a uygun seçilmelidir.

Idle Resource Detection

Kullanılmayan disk, IP ve VM kaynakları düzenli tespit edilmelidir. Development ortamlarında bu sorun sık görülür. Otomatik kapanma politikaları uygulanabilir. Resource owner'a bildirim gönderilebilir. Silme öncesinde retention süresi bırakılabilir.

Storage Lifecycle

Eski veriler daha uygun storage sınıfına taşınabilir. Log ve backup retention buna dahil edilebilir. Her veriyi yüksek performanslı katmanda tutmak gerekmez. Lifecycle rule otomatik uygulanabilir. Silme politikası compliance gereksinimiyle uyumlu olmalıdır.

Network Egress

Egress maliyeti hybrid ve multi-region tasarımda önemli olabilir. Uygulama ile veri tabanını farklı bölgelerde tutmak sürekli trafik oluşturabilir. Data locality mimari kararda değerlendirilmelidir. Büyük transferler önceden tahmin edilmelidir. Egress dashboard üzerinden izlenebilir.

Logging Cost

Debug loglarının sürekli production'da açık kalması yüksek maliyet oluşturabilir. Gereksiz alanlar filtrelenebilir. Retention log tipine göre farklılaştırılabilir. Sampling yüksek hacimli telemetry'de kullanılabilir. Security logları maliyet nedeniyle kontrolsüz biçimde kapatılmamalıdır.

Continuous Optimization

Optimization aylık veya haftalık rutin haline getirilmelidir. Yeni servis ve fiyat değişiklikleri düzenli değerlendirilir. Ekipler kendi cost dashboard'larını görür. Tasarruf aksiyonları backlog'a eklenir. Maliyet ile reliability arasında denge korunur.

Veri Yerleşimi ve KVKK

KVKK açısından değerlendirme yapılırken yalnızca cloud region seçmek yeterli değildir. Önce hangi verinin kişisel veri olduğu ve nasıl sınıflandırıldığı anlaşılmalıdır. Data minimization yaklaşımı gereksiz kişisel verinin sisteme taşınmasını önler. Encryption, access control, audit log ve retention teknik kontrolleri veri yaşam döngüsüyle birlikte uygulanmalıdır. Kuruma özel hukuki değerlendirme gereken konularda yetkili hukuk ve uyum uzmanlarından görüş alınması gerekir.

Data Classification

Data classification veriyi hassasiyet seviyesine göre gruplar. Public, internal ve sensitive gibi sınıflar kullanılabilir. Her sınıf için farklı erişim ve retention kuralı tanımlanabilir. Uygulama sahipleri veri sınıfını bilmelidir. Classification yalnızca security ekibinin görevi değildir.

Kişisel Veri

Kişisel veri içeren sistemlerin erişimleri daha sıkı yönetilmelidir. Gereksiz kopyalar azaltılmalıdır. Test ortamına gerçek production verisi taşınmamalıdır. Masking veya synthetic data değerlendirilebilir. Audit erişimleri düzenli gözden geçirilmelidir.

Bölge Seçimi

Region seçimi latency ve resilience kadar veri yerleşimi açısından da değerlendirilmelidir. Servisin gerçek data location davranışı anlaşılmalıdır. Backup bölgesi ayrıca hesaba katılmalıdır. Multi-region servis kullanılıyorsa kapsam doğrulanmalıdır. Hukuki gereksinim teknik konfigürasyona dönüştürülmelidir.

Data Residency

Data residency verinin hangi coğrafi bölgede tutulduğuyla ilgilidir. Uygulama data flow diagramı hazırlanmalıdır. Log ve backup kopyaları da analize dahil edilmelidir. Third-party entegrasyonlara gönderilen veriler unutulmamalıdır. Policy ve monitoring ile kurallar doğrulanabilir.

Data Minimization

İş ihtiyacı olmayan verinin toplanmaması güvenlik riskini azaltır. Analitik sistemlere yalnızca gerekli alanlar taşınabilir. Loglarda kişisel bilgi maskelenebilir. Retention sonunda veri otomatik silinebilir. Daha az veri daha az risk ve maliyet anlamına gelir.

Encryption

Veri at rest ve transit durumunda korunmalıdır. Yönetilen encryption mekanizmaları kullanılabilir. Ek key kontrol ihtiyacında CMEK değerlendirilebilir. Anahtar erişimleri ayrı IAM modeliyle yönetilmelidir. Encryption yanlış yetkilendirmeyi tek başına çözmez.

Access Control

Access control kullanıcı rolüne ve iş ihtiyacına dayanmalıdır. Hassas dataset'lere geniş grup erişimi verilmemelidir. Temporary access süreçleri değerlendirilebilir. Access review düzenli yapılmalıdır. Kullanıcı ayrıldığında erişim otomatik kaldırılmalıdır.

Audit Log

Hassas veri erişimleri audit edilmelidir. Data Access logları gerekli sistemlerde etkinleştirilebilir. Logların kendisi de hassas bilgi içerebilir. Merkezi güvenli projede tutulabilir. Incident investigation için yeterli retention sağlanmalıdır.

Retention

Verinin sonsuza kadar saklanması çoğu durumda gerekli değildir. İş ve hukuki gereksinime göre retention belirlenmelidir. Süre dolduğunda otomatik silme uygulanabilir. Backup kopyaları da aynı lifecycle planına dahil edilmelidir. Silme işlemlerinin doğrulanabilir olması faydalıdır.

Vendor Lock-In Nasıl Yönetilir?

Vendor lock-in tamamen ortadan kaldırılması gereken bir durum değildir. Yönetilen servislerin sağladığı operasyon avantajı bazen taşınabilirlik maliyetinden daha değerlidir. Burada önemli olan stratejik bağımlılıkların bilinçli seçilmesidir. Kubernetes, PostgreSQL, OpenTelemetry ve Terraform gibi açık teknolojiler bazı katmanlarda taşınabilirliği artırabilir. Kritik sistemler için exit strategy hazırlanması, başka ortama geçişin sıfır maliyetli olacağı varsayımından daha gerçekçi bir yaklaşımdır.

Managed Service Avantajı

Managed service operasyon işini azaltabilir. Patch, backup veya scaling gibi görevler sadeleşir. Bunun karşılığında servis API'sine bağımlılık oluşabilir. Business değeri bu trade-off'u haklı çıkarabilir. Karar açıkça dokümante edilmelidir.

Portability Maliyeti

Her sistemi tamamen portable tasarlamak geliştirme hızını düşürebilir. Ortak denominator yaklaşımı platformun güçlü özelliklerinden yararlanmayı engelleyebilir. Kritik workload'larda portability daha önemli olabilir. Migration maliyeti önceden tahmin edilmelidir. Exit strategy gerçek risk seviyesine göre hazırlanmalıdır.

Kubernetes

Kubernetes container orchestration katmanında ortak standardizasyon sağlar. Uygulama manifestleri farklı ortamlara taşınabilir. Buna rağmen storage, load balancer ve IAM entegrasyonları platforma göre değişebilir. Tam portability varsayılmamalıdır. Uygulama bu farkları abstraction katmanında yönetebilir.

PostgreSQL

PostgreSQL uyumlu veri servisleri uygulama taşınabilirliğini destekleyebilir. Ancak extension ve yönetilen servis özellikleri farklı olabilir. SQL compatibility migration testiyle doğrulanmalıdır. Backup formatı ve replication modeli değerlendirilmelidir. Açık standart kullanmak geçiş maliyetini azaltabilir.

OpenTelemetry

OpenTelemetry observability instrumentation'ını backend'den daha bağımsız hale getirir. Metrics ve traces ortak formatta üretilebilir. Collector farklı hedeflere veri gönderebilir. Platform-specific özellikler yine bulunabilir. Temel telemetry katmanını standardize etmek uzun vadeli esneklik sağlar.

Terraform

Terraform farklı platformlarda IaC yaklaşımını standardize eder. Provider kaynakları yine platforma özeldir. Aynı kodun hiçbir değişiklik olmadan başka cloud'da çalışacağı varsayılmamalıdır. Modüler tasarım ortak süreçleri paylaşmayı kolaylaştırır. GitOps ve review modeli platformlar arasında ortak tutulabilir.

Open Standards

Açık standartlar API, identity ve telemetry katmanında bağımlılığı azaltabilir. OIDC, OpenTelemetry ve Kubernetes buna örnek verilebilir. Standart kullanımı entegrasyon ekiplerinin beceri transferini kolaylaştırır. Ancak her teknoloji seçimi sırf açık olduğu için yapılmamalıdır. Operasyon desteği ve business değeri değerlendirilmelidir.

Exit Strategy

Exit strategy kritik sistemin başka ortama nasıl taşınacağını tanımlar. Veri export formatı ve migration süresi değerlendirilmelidir. Contract ve retention gereksinimleri dahil edilmelidir. Düzenli olarak güncellenebilir. Her servisi çift ortamda çalıştırmak exit strategy değildir.

Kurumsal Google Cloud Entegrasyonunda Test Stratejisi

Production migration'dan önce yalnızca uygulama fonksiyonunu test etmek yeterli değildir. Network connectivity, DNS, IAM, security policy, data validation, performance, failover ve restore testleri birlikte yürütülmelidir. Testlerin gerçek production koşullarına benzemesi önemlidir. Özellikle hybrid bağlantıların yalnızca normal durumda değil failover sırasında nasıl davrandığı ölçülmelidir. Sonuçlar checklist yerine ölçülebilir pass veya fail kriterlerine bağlandığında go-live kararı daha güvenilir hale gelir.

Network Connectivity Test

Gerekli port ve endpoint'lere erişim doğrulanmalıdır. Route yolu beklenen bağlantı üzerinden geçmelidir. Redundant bağlantı ayrı test edilmelidir. Packet loss ve latency ölçülmelidir. Sonuçlar migration runbook'a eklenmelidir.

DNS Test

Internal ve external domain çözümlemeleri test edilmelidir. Farklı network segmentlerinden sorgu yapılmalıdır. TTL davranışı cutover öncesi doğrulanmalıdır. Split-horizon kayıtları ayrıca kontrol edilmelidir. Failover DNS senaryosu test edilmelidir.

IAM Test

Yetkili kullanıcı erişebilmeli, yetkisiz kullanıcı erişememelidir. Negative test önemlidir. Workload identity izinleri ayrıca kontrol edilmelidir. Production admin erişimleri doğrulanmalıdır. Audit logların olayları kaydettiği görülmelidir.

Security Policy Test

Organization Policy ve firewall kontrolleri test edilmelidir. Yasaklanan resource gerçekten oluşturulamamalıdır. İstisna süreci doğrulanmalıdır. Public erişim taraması yapılabilir. Policy update etkileri test ortamında gözlenmelidir.

Application Integration Test

API ve event akışları uçtan uca çalıştırılmalıdır. Retry ve timeout senaryoları test edilmelidir. Harici dependency kesildiğinde uygulama davranışı incelenmelidir. Error message operasyon ekibine anlamlı bilgi vermelidir. Duplicate event senaryoları ayrıca doğrulanmalıdır.

Data Validation

Migration sonrası veri bütünlüğü kontrol edilmelidir. Row count yeterli olmayabilir. Kritik business kayıtları karşılaştırılabilir. Checksum veya reconciliation raporu kullanılabilir. İş birimi doğrulaması cutover kriterine eklenmelidir.

Performance Test

Load test gerçek trafik modeline yakın yapılmalıdır. Average latency yanında percentile değerler incelenmelidir. Hybrid dependency'ler ekstra gecikme oluşturabilir. Autoscaling davranışı gözlenmelidir. Performance sonucu SLO ile karşılaştırılmalıdır.

Failover Test

Ana network veya region bağlantısı kontrollü olarak devre dışı bırakılabilir. Sistemin yedek yola geçiş süresi ölçülmelidir. Kullanıcı hataları izlenmelidir. Failover sonrasında veri tutarlılığı kontrol edilmelidir. Test sonucu DR planına işlenmelidir.

Restore Test

Backup'tan gerçek restore yapılmalıdır. Süre RTO hedefiyle karşılaştırılmalıdır. Uygulama restore edilen veriye bağlanıp test edilmelidir. Credential ve key erişimleri doğrulanmalıdır. Test periyodik olarak tekrar edilmelidir.

Migration Cutover Nasıl Planlanır?

Cutover migration'ın en görünür aşamasıdır ancak başarı önceki hazırlıklara bağlıdır. Change freeze ile source sistemde beklenmeyen değişiklikler sınırlandırılabilir. Final data sync tamamlandıktan sonra DNS veya trafik hedefi değiştirilir. Smoke test ve business validation hızlı biçimde uygulanır. Monitoring sonuçlarına göre önceden tanımlanan go veya no-go kriteri kullanılır.

Change Freeze

Cutover öncesi değişiklikleri sınırlandırmak risk azaltır. Uygulama ve database schema değişiklikleri durdurulabilir. Acil change için ayrı onay süreci bulunmalıdır. Freeze süresi gereksiz uzatılmamalıdır. Bütün ekipler başlangıç ve bitiş zamanını bilmelidir.

Final Data Sync

Son veri değişiklikleri target sisteme aktarılmalıdır. Replication lag kabul edilebilir seviyeye getirilmelidir. Source write işlemleri gerektiğinde durdurulabilir. Veri doğrulama yapılmalıdır. Sync tamamlanmadan trafik çevrilmemelidir.

DNS Değişikliği

DNS cutover öncesi TTL planlanmalıdır. Yeni endpoint kayıtları önceden test edilebilir. Internal ve external zone'lar ayrı kontrol edilmelidir. Rollback için eski kayıtlar hazır tutulmalıdır. DNS propagation süresi kullanıcı iletişimine dahil edilmelidir.

Traffic Cutover

Trafik yeni ortama kademeli veya tam olarak yönlendirilebilir. Kritik uygulamalarda düşük yüzdeli başlangıç güvenli olabilir. Error rate ve latency yakından izlenmelidir. Backend kapasitesi gözlenmelidir. Sorun çıkarsa rollback kriteri gecikmeden uygulanmalıdır.

Smoke Tests

Smoke test en kritik kullanıcı akışlarını hızlı biçimde doğrular. Login, temel işlem ve veri erişimi kontrol edilebilir. Test otomasyonu süreyi azaltır. Harici entegrasyonlar ayrıca doğrulanmalıdır. Başarısız smoke test go-live kararını durdurmalıdır.

Business Validation

Teknik test başarılı olsa bile business süreç yanlış çalışabilir. İş birimi temsilcileri kritik işlemleri doğrulamalıdır. Finans veya sipariş gibi gerçek süreçler kontrol edilebilir. Validation sonucu kayıt altına alınmalıdır. Go-live onayı teknik ve iş ekiplerinin ortak kararı olmalıdır.

Monitoring

Cutover sırasında monitoring ekranları önceden hazırlanmalıdır. Latency, errors ve resource utilization gerçek zamanlı izlenmelidir. Network ve database metrics aynı görünümde bulunabilir. Alarm eşikleri cutover için geçici olarak sıkılaştırılabilir. Sorun başladığında ilgili ekip hızlı yönlendirilmelidir.

Go/No-Go Decision

Go veya no-go kararı kişisel hissiyata dayanmamalıdır. Ölçülebilir başarı kriterleri kullanılmalıdır. Veri tutarsızlığı veya kritik error oranı rollback sebebi olabilir. Karar sahibinin kim olduğu önceden belirlenmelidir. Toplantı sırasında yeni kriter icat edilmemelidir.

Migration Rollback Planı

Rollback planı migration başarısız olduğunda kontrollü biçimde eski ortama dönüşü tanımlar. DNS ve network geri dönüşü çoğu zaman kolay görünür ancak veri tutarlılığı en zor konudur. Target ortamda yeni transaction oluştuysa bunların source sisteme nasıl aktarılacağı planlanmalıdır. Rollback kriterleri migration başlamadan yazılmalıdır. Olay sonrasında postmortem yapılarak sonraki wave için süreç güncellenmelidir.

Rollback Criteria

Rollback hangi durumda tetikleneceği açıkça tanımlanmalıdır. Kritik business fonksiyonunun çalışmaması örnek olabilir. Belirli error rate veya latency eşiği kullanılabilir. Karar geciktikçe veri divergence artabilir. Bu nedenle kriter ölçülebilir olmalıdır.

Data Consistency

Target sistemde yazılan yeni verinin source'a dönmesi gerekebilir. Bu süreç migration öncesinde tasarlanmalıdır. Dual-write modeli ekstra risk oluşturabilir. Rollback penceresi mümkün olduğunca kısa tutulabilir. Veri sahipleri reconciliation sürecine katılmalıdır.

DNS Rollback

DNS kayıtları eski endpoint'e geri çevrilebilir. TTL süresi kullanıcıların dönüş hızını etkiler. Eski servis rollback penceresi boyunca hazır tutulmalıdır. Internal ve external kayıtlar birlikte yönetilmelidir. DNS değişikliği sonrası smoke test tekrar yapılmalıdır.

Network Rollback

Routing veya firewall değişiklikleri eski haline getirilebilir. IaC üzerinden geri dönüş tercih edilmelidir. Manuel acil değişiklikler sonradan repository'ye işlenmelidir. Failback sonrası bağlantılar test edilmelidir. Network logları incident analizi için saklanmalıdır.

Application Rollback

Application deployment önceki stabil release'e dönebilir. Artifact'ler immutable ve version'lu tutulmalıdır. Database schema breaking change rollback'ı zorlaştırabilir. Backward-compatible deployment tercih edilebilir. Rollback otomasyonu düzenli test edilmelidir.

Communication Plan

Rollback teknik ekip kadar kullanıcı iletişimini de gerektirir. Kimlerin bilgilendirileceği önceden belirlenmelidir. Mesajlarda mevcut etki ve beklenen aksiyon açık olmalıdır. Farklı ekipler çelişkili bilgi vermemelidir. Incident owner iletişimi koordine etmelidir.

Postmortem

Rollback sonrasında amaç hata yapan kişiyi bulmak değildir. Teknik ve süreç nedenleri analiz edilmelidir. Eksik test veya monitoring tespit edilebilir. Aksiyonlar sahibi ve tarihiyle kaydedilmelidir. Sonraki migration wave bu derslerle güncellenmelidir.

Kurumsal Google Cloud Entegrasyonunda Sık Yapılan Hatalar

Kurumsal cloud projelerinde büyük sorunlar çoğu zaman tek bir servis seçiminden değil, temel mimari kararların atlanmasından çıkar. Landing zone kurmadan workload taşımak, IP planını düşünmemek ve production ile development'ı aynı sınırda tutmak sık karşılaşılan örneklerdir. Service account key kullanımı ve geniş IAM rolleri zamanla güvenlik yükü oluşturur. Backup alıp restore test etmemek ise olay anında en pahalı sürprizlerden biridir. Maliyet yönetiminin migration sonrasına bırakılması da teknik olarak başarılı bir projenin finansal açıdan başarısız görünmesine neden olabilir.

Landing Zone Kurmadan Workload Taşımak

İlk birkaç project manuel kurulunca sorun görünmeyebilir. Proje sayısı arttıkça standartlar dağılır. Sonradan network ve IAM düzenlemek zorlaşır. Merkezi logging eksik kalabilir. Bu nedenle foundation workload'dan önce kurulmalıdır.

Resource Hierarchy'yi Plansız Oluşturmak

Folder ve project yapısı rastgele büyürse policy yönetimi zorlaşır. Organizasyon şemasını birebir kopyalamak uzun vadede sorun yaratabilir. Teknik ve güvenlik sınırları önceliklendirilmelidir. Hierarchy değişikliğinin operasyon etkisi vardır. İlk tasarım gelecekteki büyümeyi düşünmelidir.

IP Planlamasını Atlamak

Overlapping CIDR hybrid cloud bağlantısını zorlaştırır. Sonradan renumbering maliyetli olabilir. GKE secondary ranges ek adres alanı tüketir. Gelecekteki region'lar için alan bırakılmalıdır. Merkezi IPAM süreci kullanılmalıdır.

Service Account Key Kullanmak

Statik key dosyaları sızıntı riski taşır. CI/CD ve workload erişiminde federation değerlendirilebilir. Eski key'ler envanterlenmelidir. Kullanılmayanlar kaldırılmalıdır. Yeni key oluşturma Organization Policy ile sınırlandırılabilir.

Basic IAM Roles Kullanmak

Basic roller geniş permission içerebilir. Predefined role tercih edilmelidir. Grup bazlı erişim yönetimi uygulanmalıdır. Production admin erişimleri süreli olabilir. IAM periyodik review gerektirir.

Production'ı Public IP'lerle Doldurmak

Her VM'e external IP vermek gereksiz attack surface oluşturur. Private IP ve Cloud NAT kullanılabilir. Internal servisler private endpoint üzerinden erişilebilir. Public uygulamalar authentication ve WAF benzeri kontrollerle korunmalıdır. Public exposure envanteri tutulmalıdır.

Tek Bağlantı Noktası Kullanmak

Tek VPN tüneli veya tek router kritik risk oluşturur. Cloud tarafında yedekli tasarım on-premises tek cihaz sorununu çözmez. Farklı hata alanları kullanılmalıdır. Failover test edilmelidir. Backup bağlantı kapasitesi gerçek trafiği taşıyabilmelidir.

Dev ve Production'ı Aynı Project'te Tutmak

Aynı project blast radius'ı büyütür. IAM ayrımı zorlaşır. Billing görünürlüğü azalır. Yanlış deployment production kaynağını etkileyebilir. Environment'lar ayrı project'lerde tutulmalıdır.

Central Logging Kullanmamak

Dağınık loglar incident response'u yavaşlatır. Yeni project'lerin logları unutulabilir. Organization-level sink merkezi görünürlük sağlar. Retention standartlaştırılabilir. Security ekibi olayları daha hızlı araştırabilir.

Backup Alıp Restore Test Etmemek

Backup job'un başarılı görünmesi restore garantisi değildir. Permission veya encryption key problemi geri yüklemeyi engelleyebilir. Düzenli restore testi yapılmalıdır. Süre RTO ile karşılaştırılmalıdır. İş verisi uygulama seviyesinde doğrulanmalıdır.

Maliyeti Migration Sonrasına Bırakmak

Cloud maliyeti tasarım kararlarının sonucudur. Network egress ve logging baştan düşünülmelidir. Resource labels ilk günden uygulanmalıdır. Budget ve alert kurulmalıdır. FinOps migration programının parçası olmalıdır.

Her Workload'u Aynı Migration Stratejisiyle Taşımak

Bütün uygulamalar rehost için uygun değildir. Bazıları retire edilebilir. Bazıları replatform veya refactor gerektirebilir. Workload classification karar sürecini kolaylaştırır. Portföy bazlı yaklaşım migration maliyetini azaltır.

Production Öncesi Google Cloud Entegrasyon Kontrol Listesi

Production öncesi checklist teknik ve operasyonel hazırlığın son kontrolüdür. Organization, landing zone, Shared VPC, identity ve logging bileşenleri hazır olmalıdır. Hybrid bağlantının yalnızca çalışması değil redundant olması da doğrulanmalıdır. Backup restore, RPO, RTO ve rollback testleri tamamlanmalıdır. Budget, monitoring ve Security Command Center gibi operasyon araçlarının da go-live öncesinde aktif olması gerekir.

Organization ve Folder Yapısı Hazır mı?

Resource hierarchy onaylanmış olmalıdır. Production ve development ayrımı net görünmelidir. Policy inheritance test edilmelidir. IAM sahipleri belirlenmelidir. Yeni project creation süreci dokümante edilmelidir.

Landing Zone Kuruldu mu?

Network, IAM, logging ve billing temel servisleri hazır olmalıdır. Automation çalışmalıdır. Project Factory test edilmelidir. Security policy'ler enforce edilmelidir. Foundation sahibi belirlenmelidir.

Shared VPC Tasarlandı mı?

Host ve service project rolleri açık olmalıdır. Subnet kapasitesi yeterli olmalıdır. Firewall kuralları test edilmelidir. Hybrid routing doğrulanmalıdır. Network change süreci belirlenmelidir.

IP Çakışmaları Kontrol Edildi mi?

On-premises CIDR ile cloud subnet'ler karşılaştırılmalıdır. Gelecekteki environment'lar hesaba katılmalıdır. GKE secondary ranges dahil edilmelidir. IPAM güncel olmalıdır. Çakışma varsa production öncesinde çözülmelidir.

Hybrid Bağlantı Redundant mı?

İki bağlantının gerçekten bağımsız olduğu doğrulanmalıdır. Farklı router veya fiziksel yol kullanılabilir. BGP failover test edilmelidir. Backup capacity ölçülmelidir. Monitoring alert'leri çalışmalıdır.

DNS Çalışıyor mu?

Internal ve external name resolution test edilmelidir. On-premises ve cloud yönleri ayrı kontrol edilmelidir. Failover DNS senaryosu çalışmalıdır. TTL değerleri cutover'a uygun olmalıdır. DNS sahibi belirlenmelidir.

Workforce Identity Hazır mı?

Kullanıcı authentication merkezi sisteme bağlanmalıdır. Grup ve role eşlemeleri test edilmelidir. Eski kullanıcı hesapları kontrol edilmelidir. Production erişimleri sınırlandırılmalıdır. MFA politikaları doğrulanmalıdır.

Workload Identity Kullanılıyor mu?

Uygulamalar statik credential yerine workload identity kullanmalıdır. Her servis ayrı kimliğe sahip olabilir. IAM minimum izinle sınırlandırılmalıdır. Federation config test edilmelidir. Audit loglar identity kullanımını göstermelidir.

Service Account Key'ler Kaldırıldı mı?

Mevcut key'ler envanterlenmelidir. Kullanılmayan credential derhal kaldırılmalıdır. Kalan istisnaların sahibi ve expiration tarihi olmalıdır. Yeni key oluşturma policy ile sınırlandırılabilir. Rotation planı hazırlanmalıdır.

Organization Policy Aktif mi?

Resource location ve public erişim gibi temel policy'ler doğrulanmalıdır. İstisnalar kayıt altında olmalıdır. Policy inheritance test edilmelidir. Production enforcement öncesi etki analizi yapılmalıdır. Policy değişiklik süreci belirlenmelidir.

Central Logging Aktif mi?

Audit ve application logları merkezi hedefe akmalıdır. Yeni project'ler otomatik bağlanmalıdır. Retention tanımlanmalıdır. SIEM export gerekiyorsa test edilmelidir. Log kaybı için alert mekanizması bulunmalıdır.

Security Command Center İzleniyor mu?

Security finding'lerin sahibi olmalıdır. Kritik bulgular ticket sistemine aktarılabilir. SLA tanımlanmalıdır. Yanlış yapılandırmalar production öncesinde kapatılmalıdır. Dashboard güvenlik ekibi tarafından düzenli takip edilmelidir.

Backup ve Restore Testi Yapıldı mı?

Son backup'ın alınması yeterli değildir. Restore işlemi gerçek ortamda test edilmelidir. Süre RTO ile karşılaştırılmalıdır. Veri doğrulaması yapılmalıdır. Test sonucu kaydedilmelidir.

Budget ve Alert'ler Var mı?

Production ve development için budget tanımlanmalıdır. Maliyet artışında sorumlu ekip bildirim almalıdır. Billing export çalışmalıdır. Cost labels eksiksiz olmalıdır. İlk ay günlük maliyet takibi faydalıdır.

RPO/RTO Test Edildi mi?

RPO ve RTO yalnızca dokümanda yazmamalıdır. Gerçek failover veya restore testleriyle ölçülmelidir. Sonuç hedefi karşılamıyorsa mimari güncellenmelidir. İş birimi sonuçları onaylamalıdır. Test periyodik olarak tekrar edilmelidir.

Rollback Planı Hazır mı?

Rollback kriterleri açık olmalıdır. DNS ve network geri dönüş adımları yazılmalıdır. Data consistency süreci hazırlanmalıdır. Karar sahibi belirlenmelidir. Plan en az masa başı tatbikatla doğrulanmalıdır.

Uçtan Uca Örnek: On-Premises Kurumsal Altyapıyı Google Cloud'a Entegre Etmek

Pratik bir örnekte kurumun fiziksel veri merkezi, eski sanal makineleri ve ilişkisel veri tabanları bulunduğunu düşünelim. İlk olarak mevcut ortam keşfedilir, ardından landing zone oluşturulur. Kullanıcı identity sistemi federated modelle bağlanır, Shared VPC hazırlanır ve ilk hybrid bağlantı HA VPN üzerinden kurulur. Trafik büyüdükçe Interconnect'e geçiş yapılabilir. Legacy uygulama önce Compute Engine'e taşınıp daha sonra GKE veya Cloud Run üzerinde kademeli modernize edilebilir.

Mevcut Altyapıyı Migration Center ile Keşfetmek

Sunucu ve VM envanteri çıkarılır. CPU, memory ve disk kullanımı ölçülür. Database bağımlılıkları belirlenir. Kullanılmayan sistemler retire adayı olarak işaretlenir. Workload'lar risk ve kritik seviyesine göre sınıflandırılır.

Landing Zone Oluşturmak

Organization ve Folder yapısı oluşturulur. Project Factory hazırlanır. Merkezi logging ve billing yapılandırılır. Organization Policy uygulanır. Network ve IAM standartları IaC repository'sinde tutulur.

Shared VPC Kurmak

Network host project oluşturulur. Production ve development subnet'leri ayrılır. Service project'ler ortak VPC'ye bağlanır. Firewall politikaları merkezi uygulanır. IP address planı şirket içi network ile birlikte doğrulanır.

HA VPN ile İlk Bağlantıyı Kurmak

On-premises router ile HA VPN tunnel'ları kurulur. Cloud Router üzerinden BGP etkinleştirilir. Route advertisement test edilir. DNS forwarding yapılandırılır. Failover testi yapılarak yedeklilik doğrulanır.

Cloud Interconnect'e Geçmek

Trafik hacmi ve latency ihtiyacı büyüdüğünde Interconnect değerlendirilir. Fiziksel ve routing hazırlığı yapılır. VPN backup olarak tutulabilir. Trafik kademeli şekilde yeni bağlantıya alınır. BGP ve failover davranışı yeniden test edilir.

Private DNS Entegrasyonu

On-premises domain'ler cloud tarafından çözülebilir hale getirilir. Cloud private zone'ları şirket içi resolver tarafından kullanılabilir. Forwarding kuralları açıkça tanımlanır. Split-horizon kayıtlar test edilir. DNS monitoring production sürecine eklenir.

Legacy Uygulamayı Compute Engine'e Taşımak

İlk wave'de düşük riskli VM rehost edilir. Rightsizing gerçek kullanım verisine göre yapılır. Private IP kullanılır. Monitoring ve backup etkinleştirilir. Uygulama stabil hale geldikten sonra modernizasyon fırsatları değerlendirilir.

Database'i Cloud SQL veya AlloyDB'ye Taşımak

Schema compatibility kontrol edilir. Test migration çalıştırılır. Replication üzerinden veri senkronize edilir. Cutover sırasında final sync yapılır. Business validation tamamlanmadan eski database kapatılmaz.

Uygulamayı GKE veya Cloud Run ile Modernize Etmek

Uygulama component'leri ayrıştırılır. Stateless servisler container haline getirilir. Basit API'ler Cloud Run üzerinde çalışabilir. Daha kapsamlı platform gereksiniminde GKE değerlendirilebilir. Workload identity ve centralized observability varsayılan olarak eklenir.

Application Integration ile ERP/CRM Bağlamak

Legacy business sistemleri doğrudan yeni servis database'ine bağlanmaz. API veya integration workflow katmanı kullanılır. Authentication merkezi identity modeline bağlanır. Retry ve error handling uygulanır. Hassas credential Secret Manager içerisinde tutulur.

Merkezi Logging ve Monitoring

Bütün project logları merkezi logging projesine aktarılır. Uygulama ve network dashboard'ları hazırlanır. SLO ve alert kuralları oluşturulur. Audit kayıtları security ekibiyle paylaşılır. Maliyet ve telemetry hacmi birlikte izlenir.

Backup ve DR

Database ve workload backup politikaları tanımlanır. Cross-region ihtiyaçları değerlendirilir. Restore testi yapılır. Failover runbook hazırlanır. RPO ve RTO gerçek testlerle doğrulanır.

FinOps

Her project cost center etiketi alır. Billing export analitik ortama aktarılır. Budget ve alert tanımlanır. İlk migration aylarında günlük maliyet takip edilir. Rightsizing ve idle resource cleanup rutin hale getirilir.

Optimization

Migration tamamlanınca proje bitmiş kabul edilmez. VM'ler rightsizing ile yeniden değerlendirilir. Rehost edilen servisler modernizasyon roadmap'ine alınır. Network ve logging maliyeti optimize edilir. Platform her wave sonrasında geliştirilmeye devam eder.

Open Source ve İşbirliği ile Google Cloud Altyapısı Geliştirmek

Açık kaynak yaklaşımı cloud ekiplerinin ortak bilgi ve standart üretmesini kolaylaştırır. Terraform, Kubernetes ve OpenTelemetry gibi projeler altyapı, orchestration ve observability alanlarında güçlü ortak beceriler oluşturur. GitOps süreçleri ekiplerin değişiklikleri pull request üzerinden incelemesine yardım eder. Kurumsal Terraform modüllerinin ekip içinde paylaşılması her projenin sıfırdan başlamasını önler. Diyarbakır Yazılım Topluluğu içerisindeki teknik proje yaklaşımını incelemek isteyenler https://www.diyarbakiryazilim.com.tr/projects adresindeki çalışmalara göz atabilir.

Terraform

Terraform altyapıyı version kontrollü kodla yönetmeyi sağlar. Ortak modüller ekipler arasında paylaşılabilir. Pull request review bilgi transferini artırır. Security policy kontrolleri otomatik eklenebilir. Platform standartları kod üzerinden geliştirilebilir.

Kubernetes

Kubernetes container orchestration bilgisini ortaklaştırır. Geliştiriciler deployment ve service kavramlarını öğrenir. Platform ekipleri reusable template oluşturabilir. Açık kaynak ekosistemi teknik öğrenmeyi destekler. Yine de her workload için Kubernetes kullanmak zorunlu değildir.

OpenTelemetry

OpenTelemetry observability tarafında ortak standart sunar. Farklı projelerin metrics ve traces formatı uyumlu hale getirilebilir. Collector konfigürasyonları paylaşılabilir. Açık kaynak katkıları teknik derinliği artırır. Multi-cloud telemetry tasarımında özellikle faydalıdır.

GitOps

GitOps değişiklikların review üzerinden ilerlemesini sağlar. Altyapı ve uygulama konfigürasyonu repository'de tutulur. Ekip üyeleri birbirinin değişikliklerinden öğrenir. Audit geçmişi doğal olarak oluşur. Rollback daha anlaşılır hale gelir.

Cloud Foundation Toolkit

Foundation yaklaşımı kurumsal altyapı standartlarını oluşturmak için örnekler sunabilir. Hazır modüller öğrenme süresini kısaltır. Kurum ihtiyaçlarına göre uyarlama yapılmalıdır. Modül version'ları kontrollü güncellenmelidir. Production kullanımı öncesi güvenlik review yapılmalıdır.

Açık Kaynak Modüller

Açık kaynak modüller tekrar eden altyapı kodunu azaltır. Ancak kullanılan modülün sahipliği ve güncelliği kontrol edilmelidir. Production için version pinning yapılabilir. Security review uygulanmalıdır. Kuruma özel wrapper modüller standart oluşturabilir.

GitHub Issue ve Pull Request

Issue ve pull request süreçleri teknik tartışmayı görünür hale getirir. Hata veya yeni özellik önerisi kayıt altında tutulur. Kod review bilgi paylaşımını artırır. Küçük katkılar yeni geliştiricilerin projeye alışmasını kolaylaştırır. Teknik topluluk kültürünün önemli parçalarından biridir.

Kurumsal Terraform Modüllerini Paylaşmak

Aynı VPC veya project yapısını her ekip yeniden yazmamalıdır. Ortak modüller merkezi repository'de tutulabilir. Versioning ve release notları hazırlanabilir. Security varsayılanları modülün içine eklenebilir. Uygulama ekipleri yalnızca gerekli parametreleri değiştirir.

Platform Standartlarını Ekip Olarak Geliştirmek

Platform standardı yalnızca merkezi ekibin kararı olmamalıdır. Uygulama ekipleri kullanım deneyimini paylaşmalıdır. Gereksiz adımlar azaltılabilir. Yeni ihtiyaçlar roadmap'e alınabilir. Böylece platform yaşayan bir iç ürün haline gelir.

Google Cloud İçin En İyi Programlama Dili Hangisidir?

Google Cloud için tek bir en iyi programlama dili yoktur. Dil seçimi uygulama türüne, ekip becerisine ve performans gereksinimine göre yapılmalıdır. Python otomasyon ve veri işlemede pratikken Go altyapı araçlarında güçlü bir seçenek olabilir. Java, JavaScript, TypeScript, C# ve Bash farklı kurumsal ihtiyaçlarda kullanılabilir. Cloud platformunda uzun vadede programlama dilinden daha önemli olan network, IAM, distributed systems, observability ve architecture bilgisidir.

Python

Python otomasyon, veri ve backend servislerinde yaygın kullanılır. Cloud API'leriyle hızlı entegrasyon sağlar. Öğrenme eğrisi yeni geliştiriciler için uygundur. Büyük uygulamalarda type ve dependency yönetimi disiplin gerektirir. Script ile production servis kodu arasındaki fark korunmalıdır.

Go

Go cloud-native tooling ve network servislerinde güçlü seçenektir. Tek binary dağıtımı operasyonu kolaylaştırabilir. Concurrency modeli yüksek bağlantılı servislerde faydalıdır. Dil sade tutulmuştur. Platform engineering ekipleri için iyi beceri alanıdır.

Java

Java büyük kurumsal uygulamalarda uzun geçmişe sahiptir. Güçlü framework ekosistemi bulunur. Container veya VM üzerinde çalışabilir. Startup ve memory gereksinimi workload bazında değerlendirilmelidir. Mevcut Java ekiplerini tamamen farklı dile geçirmek her zaman gerekli değildir.

JavaScript ve TypeScript

JavaScript ve TypeScript web ve API geliştirmede sık kullanılır. TypeScript büyük projelerde type safety sağlar. Cloud Run gibi container platformlarında rahat çalışabilir. Dependency güvenliği düzenli takip edilmelidir. Frontend ve backend ekipleri ortak dil kullanabilir.

C#

C# kurumsal backend uygulamalarında güçlü seçenektir. Modern runtime'lar container ortamlarında rahat çalışabilir. Mevcut ekip becerisi seçimde önemli avantajdır. Cloud servisleri SDK üzerinden kullanılabilir. Platform değişimi dil değişimini zorunlu kılmaz.

Bash

Bash küçük otomasyon ve sistem operasyonlarında kullanışlıdır. Çok büyüyen script'ler bakım açısından zorlaşabilir. Kritik business logic için uygun değildir. Error handling açık biçimde yapılmalıdır. Uzun script'ler gerektiğinde Python veya Go gibi dile taşınabilir.

HCL / Terraform

HCL infrastructure tanımlarını yazmak için kullanılır. Uygulama programlama dilinin yerini almaz. Terraform modülleri ile network, IAM ve project kaynakları oluşturulabilir. Kod review sürecine uygundur. Platform mühendisleri için önemli becerilerden biridir.

Kullanım Senaryosuna Göre Dil Seçimi

API için ekip bilgisi yüksek olan dil tercih edilebilir. Infrastructure automation için Go veya Python kullanılabilir. Data pipeline'larında Python pratik olabilir. Büyük kurumsal backend mevcut Java veya C# ekosistemini sürdürebilir. Dil seçimi moda yerine bakım ve ekip verimliliğine dayanmalıdır.

Programlama Dilinden Daha Önemli Olan Cloud Architecture Bilgisi

Cloud sistemlerinde yanlış network veya IAM tasarımı iyi yazılmış kodu kullanılmaz hale getirebilir. Developer DNS, HTTP, identity ve observability kavramlarını anlamalıdır. Container ve deployment bilgisi production sorunlarını çözmeyi kolaylaştırır. Distributed system failure senaryoları öğrenilmelidir. Dil bilgisi bu mimari temelin üzerine oturur.

Yazılımcı Olmak İçin Ne Yapmalı? Google Cloud Yol Haritası

Google Cloud öğrenmek isteyen bir yazılımcının doğrudan yüzlerce servisi ezberlemeye çalışmasına gerek yoktur. Önce Linux, networking, Git ve bir programlama dili sağlam öğrenilmelidir. Ardından Docker, Kubernetes, Terraform, IAM, CI/CD ve observability alanlarına geçilebilir. En fazla gelişimi sağlayan yöntem gerçek bir hybrid cloud projesi geliştirmektir. Örneğin local container uygulamasını private network üzerinden Google Cloud servisine bağlamak, yalnızca video izlemekten çok daha öğretici olur.

Linux

Linux cloud sistemlerinin temel çalışma ortamlarından biridir. Process, file permission ve network komutları öğrenilmelidir. Log okumak troubleshooting becerisini geliştirir. Systemd ve package management temel seviyede bilinmelidir. Gerçek VM üzerinde pratik yapmak faydalıdır.

Networking

IP, subnet, DNS, routing ve HTTP kavramları öğrenilmelidir. Cloud network servisleri bu temeller üzerine kuruludur. CIDR hesabı yapabilmek faydalıdır. Firewall davranışı anlaşılmalıdır. Packet flow düşünme becerisi troubleshooting'i hızlandırır.

Git

Git yalnızca kod saklama aracı değildir. Infrastructure ve policy değişiklikleri de Git üzerinden yönetilebilir. Branch ve pull request süreçleri öğrenilmelidir. Merge conflict çözmek günlük ekip çalışmasının parçasıdır. Commit mesajlarının anlamlı olması audit ve review'u kolaylaştırır.

Python veya Go

Bir otomasyon dili seçip gerçek proje geliştirmek önemlidir. Python hızlı başlangıç sağlar. Go cloud-native tooling için güçlü seçimdir. Her ikisini aynı anda öğrenmek zorunlu değildir. Bir dili iyi kullanıp API ve concurrency kavramlarını anlamak daha değerlidir.

Docker

Docker uygulamayı taşınabilir container halinde paketlemeyi öğretir. Image, layer, volume ve network kavramları öğrenilmelidir. Multi-stage build image boyutunu azaltabilir. Secret image içine gömülmemelidir. Konuya giriş için https://www.diyarbakiryazilim.com.tr/posts/docker-ile-izole-edilmis-gelistirme-ve-dagitim-ortamlari adresindeki çalışma incelenebilir.

Kubernetes

Pod, Deployment, Service ve Ingress kavramları temel başlangıç noktasıdır. Sonrasında resource limit ve autoscaling öğrenilebilir. IAM ve network policy konuları production için önemlidir. Küçük lab cluster'ı kurmak pratik sağlar. Her detayı ezberlemek yerine çalışma modelini anlamak gerekir.

Terraform

Terraform Infrastructure as Code pratiği kazandırır. Küçük VPC ve project modülleriyle başlanabilir. State mantığı anlaşılmalıdır. Plan ve apply farkı öğrenilmelidir. GitOps süreciyle birleştirmek kurumsal deneyim sağlar.

IAM

IAM cloud güvenliğinin temelidir. Principal, role ve permission ilişkisi öğrenilmelidir. Least privilege pratik edilmelidir. Service account key riskleri anlaşılmalıdır. Federation modern cloud becerilerinin önemli parçasıdır.

Google Cloud Networking

VPC, subnet, firewall, DNS ve Cloud NAT temel servislerdir. Sonrasında VPN ve Interconnect kavramları öğrenilebilir. Shared VPC kurumsal kullanım için önemlidir. IP planlama pratiği yapılmalıdır. Hybrid lab gerçek network bilgisi kazandırır.

CI/CD

Build, test ve deployment pipeline'ı oluşturmak cloud kariyerinde önemlidir. Artifact versioning öğrenilmelidir. Production approval ve rollback süreçleri eklenebilir. Federation ile keyless deployment denenebilir. Pipeline güvenliği uygulama güvenliği kadar önemlidir.

Observability

Metrics, logs ve traces birlikte öğrenilmelidir. Basit dashboard oluşturmak iyi başlangıçtır. Alert tuning gerçek operasyon deneyimi kazandırır. OpenTelemetry ile uygulama instrument edilebilir. SLO kavramı reliability düşüncesini geliştirir.

Security

IAM, network security ve secret management birlikte çalışılmalıdır. Public exposure azaltılmalıdır. Audit loglar incelenmelidir. Policy as Code lab'ı yapılabilir. Security ayrı uzmanlık alanı olsa da her cloud geliştiricisinin temel sorumluluğudur.

Gerçek Bir Hybrid Cloud Projesi Geliştirmek

Local veya şirket içi benzeri bir ortamdan Google Cloud VPC'ye VPN benzeri bağlantı modeli kurulabilir. Private API oluşturulabilir. Terraform ile altyapı hazırlanabilir. Monitoring ve CI/CD eklenebilir. Böyle bir proje teorik bilgileri tek mimaride birleştirir.

Diyarbakır Yazılım Topluluğu ile Google Cloud Ekosistemi

Cloud öğrenmenin en etkili yollarından biri gerçek projeler üzerinde ekip halinde çalışmaktır. Diyarbakır Yazılım Topluluğu, yazılım geliştirme, açık kaynak, container, cloud ve altyapı odaklı konuların birlikte çalışılabileceği bir paylaşım ortamı oluşturabilir. Özellikle Terraform, Kubernetes, observability ve hybrid network gibi alanlar laboratuvar projelerine oldukça uygundur. Topluluk yapısı ve yaklaşımı hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresi ziyaret edilebilir. Proje odaklı teknik çalışmalar için de https://www.diyarbakiryazilim.com.tr/projects adresindeki içerikler incelenebilir.

Diyarbakır Yazılım Topluluğu İçinde Cloud Çalışmaları

Cloud projeleri ekip halinde öğrenmeye oldukça uygundur. Bir ekip network tasarımını yaparken başka ekip Terraform modüllerini geliştirebilir. Monitoring ve security çalışmaları ayrı görevler olarak ele alınabilir. Sonuçta gerçek kurumsal mimariye benzeyen ortak laboratuvar ortaya çıkar. Bu yöntem bireysel tutorial çalışmalarından daha fazla operasyon deneyimi kazandırır.

Google Cloud ve Kubernetes Workshopları

Workshop formatı teoriyi kısa sürede pratiğe çevirebilir. Katılımcılar container uygulamasını GKE veya Cloud Run benzeri ortama deploy edebilir. IAM ve network hataları gerçek örneklerle çözülebilir. Monitoring dashboard'u birlikte hazırlanabilir. Workshop sonunda çalışan proje bırakmak öğrenme kalitesini artırır.

Terraform ve Infrastructure as Code Atölyeleri

Terraform atölyesinde VPC, subnet ve IAM kaynakları modüler şekilde oluşturulabilir. Pull request üzerinden code review yapılabilir. Drift senaryosu üretilebilir. Policy validation pipeline'a eklenebilir. Böylece katılımcılar yalnızca syntax değil ekip çalışma modelini de öğrenir.

Hybrid Cloud Laboratuvarları

Hybrid lab gerçek kurumsal network problemlerini öğretir. İki private network arasında VPN benzeri bağlantı kurulabilir. DNS forwarding senaryosu hazırlanabilir. Route ve firewall hataları troubleshooting egzersizi olarak kullanılabilir. Monitoring ile bağlantı kaybı alarmı üretilebilir.

Open Source ve İşbirliği Projeleri

Açık kaynak proje ekiplerin gerçek code review deneyimi kazanmasını sağlar. Issue ve pull request kullanımı doğal hale gelir. Dokümantasyon geliştirme kültürün parçası olur. Küçük katkılar yeni katılımcıların projeye girmesini kolaylaştırır. Teknik bilginin tek kişide kalması önlenir.

Diyarbakır'daki En İyi Yazılımcılarla Teknik Deneyim Paylaşımı

Teknik gelişimde farklı deneyim seviyelerindeki geliştiricilerin birlikte çalışması oldukça değerlidir. Bir geliştirici network bilgisi paylaşırken başka biri container veya backend deneyimi aktarabilir. Code review sırasında farklı çözüm yolları görülebilir. Gerçek problem tartışmaları teorik bilgiyi pekiştirir. Topluluk çalışmaları yerel teknik iletişimi güçlendirebilir.

Yerel Şirketler İçin Cloud Proje Fikirleri

Yerel şirketler için cloud dönüşümü büyük ve pahalı projeyle başlamak zorunda değildir. Küçük hybrid network pilotu, merkezi log platformu veya backup sistemiyle başlanabilir. Kurumsal RAG asistanı yalnızca kontrollü dokümanlar üzerinde pilot olarak denenebilir. ERP veya CRM entegrasyonlarında küçük workflow otomasyonu seçilebilir. Başarılı pilotlardan sonra kapsam kontrollü biçimde büyütülebilir.

Hybrid Network Pilot Projesi

İlk pilotta tek bir test subnet'i cloud ortamına bağlanabilir. VPN bağlantısı ve private DNS denenebilir. Küçük internal API üzerinden latency ölçülebilir. Connection monitoring eklenebilir. Sonuçlar production network tasarımı için veri sağlar.

Merkezi Log Platformu

Farklı uygulamaların logları ortak projeye aktarılabilir. Structured logging standardı belirlenebilir. Security ve application logları ayrı retention politikasına sahip olabilir. Basit dashboard oluşturulabilir. Alarm kuralları gerçek olaylarla test edilebilir.

Cloud Backup Sistemi

Kritik olmayan bir sistemin backup'ı pilot olarak cloud storage'a aktarılabilir. Encryption ve retention politikası uygulanabilir. Restore testi yapılabilir. Recovery süresi ölçülebilir. Sonuçlar daha kritik sistemler için yol haritası oluşturur.

Kurumsal RAG Asistanı

Belirli ve kontrollü doküman seti üzerinde RAG sistemi geliştirilebilir. Kullanıcı erişimi doküman yetkileriyle ilişkilendirilebilir. Yanıtlar kaynakla birlikte sunulabilir. Hassas içerik filtrelenebilir. Pilot kullanım sonucunda doğruluk ve maliyet ölçülebilir.

ERP/CRM Integration Workflow

Küçük bir business süreç entegrasyonuyla başlanabilir. Örneğin belirli kaydın oluşturulması event olarak başka sisteme aktarılabilir. Authentication ve retry mekanizması eklenir. Hatalı kayıtlar ayrı queue'da tutulur. Başarı metriği manuel işlem süresindeki azalma olabilir.

Sık Sorulan Sorular

Google Cloud kurumsal entegrasyonu hakkında sorular genellikle network, identity, maliyet ve migration yaklaşımı çevresinde toplanır. Aşağıdaki yanıtlar karar verirken temel çerçeve sunar. Ancak her kurumun network, veri ve güvenlik gereksinimi farklıdır. Bu nedenle production tasarımı gerçek workload envanteri üzerinden yapılmalıdır. Özellikle KVKK, güvenlik ve kritik iş sürekliliği konularında kuruma özel analiz gerekir.

Google Cloud nedir?

Google Cloud compute, storage, network, veri, container, güvenlik ve diğer cloud servislerini sağlayan platformdur. Kurumlar sanal makineden yönetilen Kubernetes'e kadar farklı çalışma modelleri kullanabilir. Platform hybrid ve global mimarilerde kullanılabilir. Her servisin çalışma ve fiyatlandırma modeli farklıdır. Kurumsal kullanımda landing zone ve governance yapısı kurulması önerilir.

Kurumsal Google Cloud entegrasyonu nedir?

Kurumsal entegrasyon mevcut identity, network, uygulama ve veri sistemlerinin Google Cloud ile birlikte çalışmasını sağlar. Amaç yalnızca sunucu taşımak değildir. IAM, connectivity, logging, security ve FinOps aynı mimaride ele alınır. Migration workload wave'leriyle yapılabilir. Uzun vadede platform sürekli geliştirilen kurumsal altyapıya dönüşür.

Google Cloud landing zone nedir?

Landing zone workload'lar taşınmadan önce hazırlanmış cloud foundation yapısıdır. Organization, Folder, Project, network ve IAM burada standardize edilir. Logging, billing ve security policy'ler hazır hale getirilir. Project Factory gibi otomasyonlar eklenebilir. Böylece yeni workload'lar güvenli başlangıç noktasına sahip olur.

Shared VPC nedir?

Shared VPC network kaynaklarının host project'te merkezi yönetilmesini sağlar. Uygulamalar farklı service project'lerde çalışabilir. Network ekibi VPC ve subnet yönetimini korur. Application ekipleri kendi workload kaynaklarını yönetir. Kurumsal görev ayrımı için yararlı modeldir.

Google Cloud on-premises sisteme nasıl bağlanır?

Şirket içi sistem ile Google Cloud arasında Cloud VPN veya Interconnect benzeri hybrid connectivity modeli kurulabilir. Cloud Router ve BGP dinamik routing için kullanılabilir. IP adresleri çakışmamalıdır. DNS entegrasyonu ayrıca yapılmalıdır. Kritik sistemlerde bağlantı redundant tasarlanmalıdır.

Cloud VPN ve Cloud Interconnect arasındaki fark nedir?

Cloud VPN internet üzerinden IPsec bağlantısı sağlar ve hızlı başlangıç için uygundur. Interconnect yüksek bandwidth ve daha öngörülebilir network performansı isteyen yapılarda değerlendirilebilir. VPN pilot ve backup bağlantı olarak kullanılabilir. Interconnect fiziksel veya partner bağlantı modeli gerektirir. Seçim trafik, latency, availability ve maliyet ölçümlerine göre yapılmalıdır.

Network Connectivity Center ne işe yarar?

Network Connectivity Center hybrid bağlantıları merkezi topoloji altında organize etmeye yardımcı olabilir. Farklı VPN, VPC ve Interconnect bağlantıları hub ve spoke yaklaşımıyla yönetilebilir. Büyük network yapılarında görünürlüğü artırır. Routing standardizasyonunu destekler. Monitoring ve IPAM süreçleriyle birlikte kullanılması faydalıdır.

Workforce Identity Federation nedir?

Workforce Identity Federation kullanıcıların harici identity provider üzerinden Google Cloud'a erişmesini sağlar. Her kullanıcı için ayrı senkronize hesap gerekmeyen senaryolarda kullanılabilir. Attribute mapping ve conditions uygulanabilir. Partner ve geçici kullanıcı modellerinde yararlıdır. IAM erişimleri yine minimum role göre sınırlandırılmalıdır.

Workload Identity Federation nedir?

Workload Identity Federation uygulamaların statik service account key saklamadan Google Cloud'a erişmesine yardımcı olur. Harici identity token kısa süreli Google credential'a dönüştürülebilir. CI/CD ve on-premises workload'larda kullanılabilir. Credential sızıntı riskini azaltır. IAM policy'leri yine minimum yetki prensibine göre uygulanmalıdır.

Service Account Key kullanmak güvenli midir?

Service account key kontrollü kullanıldığında çalışabilir ancak uzun ömürlü credential riski taşır. Anahtarın repository veya sunucuya sızması ciddi sorun oluşturabilir. Mümkün olduğunda federation veya platform-native identity seçenekleri tercih edilmelidir. Zorunlu key kullanımında rotation ve inventory uygulanmalıdır. Kullanılmayan key'ler kaldırılmalıdır.

Application Integration nedir?

Application Integration farklı uygulamalar arasında workflow ve connector tabanlı entegrasyon kurmaya yardımcı olan yaklaşımdır. Trigger, task ve data mapping kullanılabilir. SaaS ve kurumsal servisler ortak süreçte bağlanabilir. Authentication ve private connectivity planlanmalıdır. Error handling ve monitoring production tasarımının parçası olmalıdır.

Application Integration ile Workflows arasındaki fark nedir?

Application Integration iş uygulamaları ve connector tabanlı entegrasyonlara odaklanabilir. Workflows ise cloud servisleri ve HTTP API çağrılarının orchestration'ında güçlü olabilir. Bazı projelerde iki servis birlikte kullanılabilir. Integration katmanı business sistemini bağlarken workflow altyapı adımlarını yönetebilir. Seçim kullanım senaryosuna göre yapılmalıdır.

Google Cloud'da legacy uygulamalar nasıl taşınır?

Legacy uygulamalar önce Compute Engine üzerinde rehost edilebilir. Ardından API facade veya event adapter ile yeni servislerden ayrıştırılabilir. Strangler Fig Pattern kademeli modernizasyon sağlar. Yeni fonksiyonlar Cloud Run veya GKE üzerinde geliştirilebilir. Eski sistem yalnızca yeni yapı doğrulandıktan sonra devreden çıkarılmalıdır.

Google Cloud Migration Center ne işe yarar?

Migration Center mevcut altyapıyı keşfetme ve migration açısından değerlendirme sürecine yardımcı olur. Sunucu ve VM kullanım verileri analiz edilebilir. Rightsizing ve hedef servis seçimine veri sağlayabilir. Dependency bilgileri migration wave planlamasını destekler. TCO değerlendirmesi daha gerçekçi hale gelir.

Google Cloud migration maliyeti nasıl hesaplanır?

Maliyet yalnızca compute fiyatıyla hesaplanmamalıdır. Storage, network egress, backup, logging, lisans ve operasyon giderleri eklenmelidir. Source altyapının mevcut bakım maliyeti de hesaba katılmalıdır. Rightsizing yapılmalıdır. Migration sonrası gerçek tüketim billing export üzerinden ölçülmelidir.

Google Cloud KVKK açısından kullanılabilir mi?

Teknik platform seçimi tek başına KVKK uygunluğu sağlamaz. Veri sınıflandırması, region seçimi, erişim kontrolü, encryption ve retention birlikte değerlendirilmelidir. Kurumun işleme faaliyetleri ve hukuki yükümlülükleri ayrıca incelenmelidir. Gereksiz kişisel veri aktarılmamalıdır. Kuruma özel hukuki yorum için yetkili uzman görüşü alınmalıdır.

Google Cloud için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Python, Go, Java, TypeScript ve C# farklı kullanım senaryolarında güçlü seçeneklerdir. Ekip becerisi önemli kriterdir. Cloud architecture bilgisi dil seçiminden daha kalıcı avantaj sağlar. Bir dili iyi öğrenip network, IAM ve deployment konularına geçmek daha verimli olabilir.

Google Cloud öğrenen bir yazılımcı nereden başlamalıdır?

Linux ve networking temelleriyle başlamak güçlü bir yol oluşturur. Git ve Python veya Go öğrenilebilir. Ardından Docker, Kubernetes ve Terraform çalışılabilir. IAM, CI/CD ve observability mutlaka eklenmelidir. Son aşamada gerçek hybrid cloud projesi geliştirmek bilgileri birleştirir.

Open source ve işbirliği cloud kariyerine nasıl katkı sağlar?

Açık kaynak proje gerçek code review deneyimi kazandırır. Issue ve pull request süreçleri ekip iletişimini geliştirir. Terraform, Kubernetes ve OpenTelemetry gibi projeler sektör standardı beceriler sağlar. Küçük katkılar bile dokümantasyon ve debugging deneyimi oluşturur. Topluluk içinde proje geliştirmek öğrenme hızını artırabilir.

Google Cloud hizmetleri kurumsal altyapıya nasıl entegre edilir?

Entegrasyon mevcut altyapının envanteriyle başlamalıdır. Ardından landing zone, identity ve network foundation kurulmalıdır. Workload'lar business criticality ve dependency durumuna göre wave'lere ayrılabilir. Hybrid bağlantılar ve DNS production öncesinde test edilmelidir. Google Cloud Hizmetleri ile Kurumsal Altyapı Entegrasyonu tek seferlik taşıma yerine sürekli geliştirilen platform yaklaşımıyla yürütüldüğünde daha sağlıklı sonuç verir.

Şirket içi (on-premise) sistemler Google Cloud’a Cloud VPN veya Cloud Interconnect ile nasıl bağlanır?

İlk olarak şirket içi ve cloud CIDR aralıklarının çakışmadığı doğrulanır. Düşük ve orta trafik için HA VPN değerlendirilebilir. Daha yüksek bandwidth ve öngörülebilir latency için Interconnect kullanılabilir. Cloud Router ve BGP routing'i dinamik hale getirebilir. Kritik bağlantılarda yedek cihaz ve fiziksel yol kullanılması tavsiye edilir.

Google Cloud entegrasyonunda VPC, IAM, güvenlik ve erişim politikaları nasıl yapılandırılmalıdır?

VPC adres planı ve environment sınırlarına göre tasarlanmalıdır. IAM grup bazlı ve minimum yetki prensibiyle uygulanmalıdır. Service account key yerine federation seçenekleri değerlendirilmelidir. Organization Policy public erişim ve riskli konfigürasyonları sınırlandırabilir. Logging ve audit kontrolleri bütün katmanlara varsayılan olarak eklenmelidir.

Hibrit ve multi-cloud mimarilerde Google Cloud kaynaklarının yönetimi, ölçeklendirilmesi ve maliyet optimizasyonu nasıl yapılır?

Kaynaklar Terraform ve GitOps gibi ortak süreçlerle yönetilebilir. OpenTelemetry ortak observability standardı oluşturabilir. Autoscaling ve rightsizing kapasiteyi gerçek talebe göre ayarlamaya yardımcı olur. Billing export, label ve cost center verileri FinOps raporlamasını destekler. Network egress, idle kaynak ve logging maliyeti sürekli izlenmelidir.

Google Cloud kurumsal altyapı entegrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Google Cloud altyapı ve bulut danışmanlığı yakınımda şeklinde arama yapan ekipler için ilk adım ihtiyacın eğitim mi, mimari değerlendirme mi yoksa uygulamalı proje desteği mi olduğunu belirlemektir. Diyarbakır bölgesinde yazılım, cloud, container ve altyapı konularında teknik iletişim kurmak isteyenler Diyarbakır Yazılım Topluluğu çalışmalarını inceleyebilir. Topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Güncel proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresi ziyaret edilebilir. Kurumsal ihtiyaçlarda mevcut altyapı, network, güvenlik ve migration hedeflerinin birlikte değerlendirilmesi doğru başlangıç noktasıdır.

Sonuç: Sağlıklı Bir Google Cloud Kurumsal Entegrasyonu Nasıl Kurulur?

Google Cloud Hizmetleri ile Kurumsal Altyapı Entegrasyonu başarılı olduğunda kurum yalnızca workload taşımış olmaz, tekrar kullanılabilir bir cloud platformu oluşturur. Bunun için mevcut altyapı keşfedilmeli, workload'lar sınıflandırılmalı ve landing zone migration'dan önce kurulmalıdır. Identity, network, security, logging, backup ve FinOps aynı mimari program içinde ele alınmalıdır. Legacy sistemler API ve event katmanlarıyla kademeli biçimde ayrıştırılabilir. En önemli nokta, entegrasyonu bitiş tarihi olan tek seferlik proje yerine düzenli olarak ölçülen ve geliştirilen kurumsal platform olarak görmektir.

Önce Mevcut Altyapıyı Keşfedin

Sağlam mimari gerçek envanter verisiyle başlar. Sunucu, database ve dependency bilgileri toplanmalıdır. Kullanılmayan workload'lar ayıklanmalıdır. Business sahipleri belirlenmelidir. Bu bilgiler migration roadmap'in temelini oluşturur.

Workload Taşımadan Önce Landing Zone Kurun

Landing zone olmadan başlayan migration ileride standardizasyon maliyeti yaratır. Resource hierarchy hazırlanmalıdır. Shared VPC ve IAM standardı belirlenmelidir. Logging ve billing merkezi hale getirilmelidir. Project Factory yeni workload onboarding'ini hızlandırmalıdır.

Identity ve Network'ü Temel Tasarım Unsuru Olarak Ele Alın

Identity ve network uygulama deployment'ından önce hazır olmalıdır. Kullanıcı ve workload kimlikleri ayrılmalıdır. Hybrid routing ve DNS test edilmelidir. Production erişimleri minimum yetkiyle sınırlandırılmalıdır. Bu temel doğru kurulursa uygulama migration'ı çok daha kolay ilerler.

Uzun Ömürlü Credential Yerine Federation Kullanın

Statik service account key kullanımını azaltmak önemli güvenlik kazanımıdır. CI/CD ve on-premises workload'lar federation kullanabilir. Credential kısa ömürlü hale gelir. Rotation yükü azalır. IAM erişimleri yine minimum gerekli role göre verilmelidir.

Hybrid ve Multi-Cloud Bağlantılarını Redundant Tasarlayın

Tek VPN veya tek router kritik sistemler için yeterli değildir. Farklı hata alanları planlanmalıdır. Interconnect kullanılıyorsa backup yolu değerlendirilebilir. BGP failover düzenli test edilmelidir. Availability gerçek uçtan uca bağlantıyla ölçülmelidir.

Legacy Sistemleri API ve Event Katmanlarıyla Ayrıştırın

Legacy sistemi tek seferde yeniden yazmak şart değildir. API facade yeni servisleri eski protokolden koruyabilir. Event adapter asenkron entegrasyon sağlayabilir. Strangler yaklaşımı fonksiyonları kademeli ayırır. Her aşama production metrics ile doğrulanmalıdır.

Infrastructure as Code ve Policy as Code Kullanın

Terraform değişiklikleri tekrar edilebilir hale getirir. GitOps review ve audit sağlar. Policy as Code hatalı konfigürasyonu erken bulur. Manuel console işlemleri azaltılmalıdır. Break-glass değişiklikleri sonradan repository'ye geri aktarılmalıdır.

Logging, Security, Backup ve FinOps'u Sonradan Eklemeyin

Bu servisler production sonrası ek özellik değildir. Logging olmadan incident araştırmak zorlaşır. Backup restore edilmeden güvenilir sayılmaz. Security policy ilk günden enforce edilmelidir. FinOps maliyet sahipliğini migration başlangıcından itibaren görünür hale getirmelidir.

Migration'ı Workload Wave'leriyle Kademeli Yapın

Düşük riskli workload'larla başlamak ekibe gerçek deneyim kazandırır. Her wave sonunda lessons learned çıkarılmalıdır. Automation ve checklist güncellenmelidir. Production kritik sistemler daha sonraki wave'lere alınabilir. Bu yaklaşım büyük tek seferlik geçiş riskini azaltır.

Google Cloud Entegrasyonunu Tek Seferlik Proje Değil Sürekli Gelişen Kurumsal Platform Olarak Yönetin

Google Cloud Hizmetleri ile Kurumsal Altyapı Entegrasyonu migration tamamlandığında bitmez. Platform ekipleri güvenlik, maliyet, reliability ve geliştirici deneyimini sürekli ölçmelidir. Yeni servisler yalnızca gerçek business ihtiyacı olduğunda eklenmelidir. Project Factory, IaC modülleri ve observability standartları ekip geri bildirimleriyle geliştirilmelidir. Diyarbakır'da cloud, yazılım, container ve açık kaynak alanlarında teknik çalışmalarla bağlantı kurmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret ederek Diyarbakır Yazılım Topluluğu çalışmalarına ulaşabilirsiniz.