Bulut göçü hakkında yazılan içeriklerin çoğu, bulut göçü satan insanlar tarafından yazılıyor. Bu yazı öyle değil. Colocation rack’lerinden ve VMware kümelerinden AWS, Azure ve GCP’ye yeterince üretim iş yükü taşıdık; pazarlama sayfalarındaki matematiğin tam olarak nerede çöktüğünü ve bulutun gerçekten nerede değer kattığını biliyoruz.
“6 ayda %30 maliyet tasarrufu” vaat eden bir göç planına bakıyorsanız, önce bunu okuyun. Tasarruf gerçek olabilir. Takvim neredeyse hiç gerçek değildir.
6 R çerçevesi — ve her birinin gerçekten ne zaman doğru olduğu
Gartner’ın 6 R çerçevesi, triyaj için ihtiyacınız olan tek zihinsel modeldir. Sorun çerçevede değil; ekiplerin envantere bile başlamadan strateji seçmesinde. Bunu yapmayın.
Rehost (lift and shift). VM’i olduğu gibi taşıyın. EC2, Azure VM, GCE. Bulut-native hiçbir fayda almazsınız, operasyonel maliyet de aşağı yukarı aynıdır — ama veri merkezinden hızla çıkarsınız. Kira sözleşmeniz 90 gün içinde bitiyorsa, uygulama kimsenin dokunmaya cesaret edemediği kadar eskiyse veya yönetim daha zor işi finanse etmek için hızlı bir kazanım istiyorsa kullanın. İlk yılda optimizasyon öncesi %10-15 maliyet artışı bekleyin.
Replatform (lift, tinker, shift). Aynı mimari, ama self-managed parçaları managed muadilleriyle değiştirirsiniz. MySQL’i EC2’den RDS’e taşıyın. Redis’i ElastiCache’e alın. Çoğu orta ölçekli uygulama için tatlı nokta budur — kod yeniden yazmadan operasyonel yükten kurtulursunuz. Maliyet nominal olarak artar, ama mühendis-saati geri kazanırsınız.
Refactor (yeniden mimari). Monolith’i servislere bölün, konteyner veya serverless’a geçin, veri katmanını yeniden tasarlayın. Yüksek efor, yüksek getiri, yüksek risk. Yalnızca uygulama stratejikse ve mevcut mimarinin darboğaz olduğu kanıtlanmışsa yapın. Karar vermeden önce monolith ve microservices karşılaştırmamızı okuyun — çoğu ekip çok erken refactor eder.
Repurchase (drop and shop). Kendi yaptığınız CRM’in yerini HubSpot alır. Dahili ticketing sisteminiz Linear olur. Farklılaştırıcı olmayan yazılım için neredeyse her zaman doğru karardır, ama orijinali birileri yazdığı için politik olarak en zorudur.
Retire. VM’lerinizi denetleyin. Düzenli olarak %15-30’unun sıfır trafikle çalıştığını, her ay faturalandığını ve 2021’de ayrılmış bir çalışanın sahipliğinde olduğunu görüyoruz. Taşımadan önce kapatın.
Retain. Bazı iş yükleri on-prem kalır. Kimsenin anlamadığı COBOL’la çalışan mainframe’ler. Veri yerleşimi yasası altındaki sistemler. Gecikmeye duyarlı endüstriyel kontrol. Hybrid sorun değil — başarısızlık demek değil.
Doğru cevap neredeyse her zaman karışımdır: %40 rehost, %35 replatform, %10 refactor, %10 retire, %5 repurchase. Sunum slaytında her şeyi refactor eden bir danışmana güvenmeyin.
Maliyet gerçeği: bulutun gerçek bedeli
Sağlayıcı fiyat sayfaları teknik olarak doğru ama pratikte işe yaramaz. Faturanızda gerçekten görünen matematik şu.
Compute. us-east-1’de on-demand m6i.large aylık yaklaşık 70 dolar. 3 yıllık reserved instance ve all-upfront ödemeyle aylık ~30 dolara düşer — ama az önce 3 yıllık bir taahhüt imzaladınız ve göçün gerekçesi olan “elastikiyetin” yarısını sildiniz. Spot instance’lar, iş yükünüz kesintiye toleranslıysa %60-70 daha kazandırır.
Storage. AWS S3 Standard 0,023 $/GB/ay. Birkaç yüz TB’a ulaşana kadar bedava gibi gelir. S3 Glacier Deep Archive 0,00099 $/GB/ay — 23 kat daha ucuz, ama geri alma saatler sürer ve GB başına ek ücret çıkar. Acımasızca katmanlayın.
Veritabanları. Faturaların patladığı yer burası. RDS Multi-AZ, standby replika için instance maliyetinizi ikiye katlar. Multi-AZ Postgres olarak db.r6g.xlarge, 500GB gp3 ve backup’larla, read replica, IOPS provisioning veya Performance Insights eklenmeden ~650 $/ay. Aurora ölçekte sık sık daha ucuz, küçük ölçekte daha pahalı — ikisini de modelleyin. Göçten sonra değil önce neyi düzelteceğiniz için veritabanı optimizasyonu rehberimize bakın.
Sessiz katil: network egress. AWS’den internete giden çıkış trafiği, ilk 100 GB ücretsiz sonrası 0,09 $/GB. Ayda 50 TB taşırsanız yalnızca kendi kullanıcılarınızla konuşmak için 4.500 $/ay ödüyorsunuz. Cross-AZ trafiği her yönde 0,01 $/GB — gevezesi mikroservisleriniz günde 10 TB’ı availability zone’lar arasında savurmaya başlayana kadar masum görünür. Inter-region replikasyon başka bir katmandır. Egress’i ilk günden tasarıma alın veya lansman öncesi devreye bir CDN (CloudFront, Cloudflare) koyun.
Görünmeyen maliyetler. NAT Gateway: 0,045 $/saat + işlenen 0,045 $/GB. Load balancer’lar: her biri ~20 $/ay ve beklediğinizden fazla olacak. CloudWatch logları ölçekte sizi şaşırtacak — bir ekibin DEBUG logging’i production’da açık unutmasıyla aylık 15 bin dolarlık faturalar gördük.
Pratik kural: bulut sağlayıcısının TCO hesap aracının çıktısını 1,4 ile çarpın. Birinci yıl gerçek faturanız budur.
Doğru pilotu seçmek
Auth servisini pilotlamayın. Faturalama pipeline’ını pilotlamayın. Üç özelliği olan bir iş yükü seçin:
- Gerçek trafik — sentetik yük hiçbir şey kanıtlamaz.
- Sınırlı blast radius — iki saat bozulursa şirket bozulmasın.
- Dürüst bağımlılıklar — entegrasyon sürprizlerini burada, ucuzken bulun.
Dahili admin araçları, analitik dashboard’ları, pazarlama sitesi altyapısı ve batch raporlama job’ları genellikle ideal ilk göçlerdir. İyi bir pilot 6-10 hafta sürer ve geriye bir runbook, bir maliyet modeli ve yanlış çıkan her varsayımın listesini bırakır. O liste, göçün kendisinden daha değerlidir.
DevOps ve CI/CD: kimsenin kapsamlandırmadığı iş
Bir VM üzerinde çalışan ve production sunucusuna scp atan mevcut Jenkins pipeline’ınız, bulutla temas anında hayatta kalmaz. Göç, planlasanız da planlamasanız da bir CI/CD modernizasyonunu zorlar.
İhtiyacınız olacaklar: infrastructure-as-code (Terraform, Pulumi veya CDK — birini seçin ve bağlı kalın), bir container registry, secret yönetimi (IaC repo’sundaki environment variable’lara secret koymayın), merkezi loglama ve bir alerting stratejisi. Sadece bunun için paralel bir iş kolu planlayın. DevOps en iyi pratikleri yazımız neyin iyi göründüğünü anlatıyor — kısa versiyonu: bir deploy merge’den production’a 15 dakikadan uzun sürüyorsa, buluta girdiğiniz anda katlanacak teknik borcunuz var demektir.
Bir de: branching environment’lar. Bulut, PR başına ephemeral preview environment’ı gerçekten ucuz ve kolay hâle getirir. Ekibiniz göçten 6 ay sonra hâlâ bunu kullanmıyorsa, bulutun en iyi parçasını masada bırakıyorsunuz.
Paylaşılan sorumluluk modeli — ve SOC 2 denetiminiz neden başarısız olur
AWS, Azure ve GCP’nin hepsi paylaşılan sorumluluk modeli yayınlar. Okuyun. Sağlayıcı bulutu güvenli kılar; siz bulutta çalışanı güvenli kılarsınız. Bunu yanlış okumak, bulut güvenlik olaylarının en yaygın tek kaynağıdır.
Sağlayıcı: fiziksel güvenlik, hypervisor patch’leri ve network omurgası. Siz: IAM politikaları, security group kuralları, VM’lerde OS patch’leri, uygulama açıkları, şifreleme anahtarı yönetimi, S3 bucket izinleri (hâlâ herkese açık veri sızıntılarının 1 numaralı sebebi) ve audit log konfigürasyonu. Varsayılan-reddet duruşu, least-privilege IAM ve birinci günden açık CloudTrail/Azure Activity Log pazarlık konusu değildir. Uygulama katmanı için güvenli web uygulamaları yazımız daha derine iniyor.
Yer imine değer bir dış kaynak: AWS Well-Architected Framework — sağlayıcıya özel, ama güvenlik ve güvenilirlik sütunları evrensel.
Gerçekçi takvim
Vendor’lar size 4 ay diyecek. 8-14 ay planlayın.
50 kişilik bir SaaS için ~30 servis, birincil bir Postgres veritabanı, bir avuç background worker ve olağan dahili araç koleksiyonuyla, uçtan uca tipik olarak şunu görüyoruz:
- Ay 1-2: Envanter, bağımlılık haritalama, TCO modelleme, iş yükü başına 6 R sınıflandırması.
- Ay 2-4: Pilot göç, IaC temeli, networking tasarımı (VPC, subnet, peering, multi-account ise transit gateway), kimlik federasyonu.
- Ay 4-9: Önce stateless servislerin, sonra stateful olanların dalga bazlı göçü. Veritabanı cutover’ı kendi başına en az bir ay sürer.
- Ay 9-12: On-prem’in dekomisyonu, right-sizing, reserved instance alımları, maliyet optimizasyonu.
- Ay 12-14: “Bunu unutmuşuz” kuyruğu — kimsenin bahsetmediği o tek servis, bir partner’la olan SFTP entegrasyonu, birinin laptop’undaki cron job.
Aşamaları atlamanın bedeli ağırdır. 6 ayda biten ekiplerin ya başlangıçta önemsiz basit bir stack’i vardı ya da iki yıl sonra hâlâ kestirme yolların faturasını ödüyorlar.
Başarı gerçekte neye benzer?
Göçten bir yıl sonra önemli olan metrikler “bulutta olduğumuz” değildir. Şunlardır: deploy sıklığı 3-5 kat artmış, mean time to recovery yarıya inmiş, yeni environment provisioning haftalardan dakikalara düşmüş ve altyapı harcaması öngörülebilir — ham dolar olarak mutlaka daha düşük değil, ama gelirle daha önce olmadığı şekilde bağlı. Bunları alamıyorsanız, rehost edip durmuşsunuzdur.
Göç desteği ister misiniz?
Ekipleri rack’lerden buluta, buluttan hybrid’e geri ve fatura mantıklı olmaktan çıktığında bir sağlayıcıdan diğerine taşıdık. Bir göç kapsamlandırıyor, TCO modelliyor veya ilk hangi iş yükünü taşıyacağınızı bulmaya çalışıyorsanız, bizimle iletişime geçin. Gerçekten ne yapacağımızı söyleriz — cevabın “henüz göç etme” olduğu durumlar dahil.
