Bir müşterimizin üretim ortamını public buluttan çıkardık ve altyapısını sıfırdan yeniden kurduk. Bu, bir LinkedIn paylaşımına sığmayan türden bir iş — bu yüzden tüm hikâyeyi, kabul ettiğimiz ödünleşmeleri ve büyüyen her şirketin bir sonraki AWS faturasını imzalamadan önce kendine sorması gereken soruları burada yazıyoruz.
Sorun aslında basitti — ve tanıdıktı
Büyüyen pek çok şirket gibi müşterimiz de uygulamalarını büyük bir bulut sağlayıcısında host ediyordu. Her ay yönetim toplantısında aynı iki soru gündeme geliyordu.
Neden bu kadar fatura ödüyoruz? Bulut faturası on sekiz ayda sessizce üçe katlanmıştı. Büyümenin çoğu yeni özelliklerden veya yeni müşterilerden değildi — kimsenin izlemediği “küçük” kalemlerden geliyordu: NAT gateway trafiği, AZ-arası veri transferi, atıl yönetilen-servis tamponları ve bir yıldır kimsenin temizlemediği replike depolama. Ekip artık faturayı detaylı okumayı bırakmıştı çünkü okumak hiçbir şeyi değiştirmiyordu.
Neden her müşteriyi farklı yönetmek zorunda kalıyoruz? Her kiracı tek seferlik olarak devreye alınmıştı — özel bir VPC, özel bir veritabanı, özel bir IAM rol seti. On ikinci müşteriye gelindiğinde operasyonel yüzey yönetilemez hâle gelmişti. Bir müşteri için yapılan bir konfigürasyon değişikliği, platform ekibi için dört saatlik bir tikete dönüşüyordu. Büyümede kaldıraç yoktu.
İlki bütçeyi tüketiyordu, ikincisi ekibin zamanını. Her ikisini de gördük ve önerimiz netti: artık ayrılma zamanı.
Dürüst çerçeve. Public bulut kötü değil. Belirli bir iş yükü şekli için kötü uyuyor — öngörülebilir trafik, tasarımı gereği çok kiracılı, maliyete duyarlı, elastiklik priminin artık kendini ödemediği bir profil. Müşterimizin profili tam buydu.
Ne inşa ettik?
Tamamen kendi kontrolümüzde, özel VDS (Sanal Adanmış Sunucu) örnekleri üzerinde çok kiracılı bir Platform-as-a-Service altyapısı kurduk. Sistemin şekli:
- Tek bir kontrol düzlemi — kiracıları sağlar, deploy süreçlerini yürütür, yükseltmeleri yönetir.
- Kiracı başına izolasyon namespace düzeyinde — her müşteri kendi Kubernetes namespace’ine, kendi veritabanı şemasına, kendi izleme kapsamına sahip — ama maliyet verimliliği için altyapıdaki node’ları paylaşırlar.
- Kimlik ve politika merkezi olarak Keycloak ile yönetiliyor — aynı erişim modeli, bir kiracı bir kullanıcıya sahipken de elli kullanıcıya sahipken de geçerli.
- Self-servis onboarding dahili portal üzerinden — yeni bir müşteri için doğru servis kombinasyonunu seçmek artık 10 dakikalık bir form, platform ekibi koordinasyonu için bir hafta değil.
- Kapalı yönetim yüzeyi — orkestrasyon katmanına yalnızca VPN-korumalı bir jump host üzerinden erişilebilir. Her şeyi kontrol eden katmana public internetten geçen bir yol yok.
Bu, Render, Fly.io veya Heroku’nun platformlarını inşa etme şekline yakın — sadece tek bir şirketin ihtiyaçlarına göre boyutlandırılmış ve onu her gün kullanan kişiler tarafından işletiliyor.
Önemli olan sonuçlar
Üç ay üretim sonrası:
- Aylık altyapı maliyeti belirgin şekilde düştü. Kesin yüzdeyi alenen vermiyoruz, ama harcama eğrisi ikinci ayda eski bulut taban çizgisinin altına indi ve düşmeye devam etti.
- Yeni müşteri onboarding’i günlerden on dakikaya indi. Eskiden çok-ekip devri olan iş, artık dahili portaldaki bir form.
- Tüm ortamlar tek noktadan izlenebilir hâle geldi. Tek Grafana, tek Loki, tek Tempo. Tüm platform tek ekrandan okunabilir.
- Yönetim katmanı public erişime tamamen kapatıldı. Public-internete açık dashboard yok. “SSO’yu sonra kuracağız” yok. Erişilebilir yüzey önemli ölçüde küçüldü.
- Sağlayıcı bağımlılığı ortadan kalktı. Aynı Helm chart’lar, aynı altyapı-kod tanımları herhangi bir VDS API’si olan sağlayıcıda çalışır. Yarın çoklu-ev yapmak istersek yapabiliriz.
Bu sonuçlar bir pazarlama sayfasında görünmez. Finans raporunda ve platform ekibinin moralinde görünür.
Bu projenin asıl mesajı
“Dijital dönüşüm” çoğu zaman yeni araçlar eklemek olarak konuşuluyor. Yeni bir dashboard, yeni bir AI entegrasyonu, yeni bir izleme ürünü. Araçlar önemli, ama görünen %10. Kalıcı bir fark yaratan şey, araçların üzerine oturduğu temelin doğru kurulmuş olması.
Üç yıl sonra hâlâ ölçeklenecek bir temel. Kilit bir ekip üyesi ayrıldığında hâlâ güvende kalacak bir temel. 2028’de hangi bütçeniz olursa olsun sürdürülebilir kalacak bir temel — sadece bugün sahip olduğunuzla değil.
Bu, çoğu şirketin kırılana kadar yetersiz yatırım yaptığı katmandır. Kırıldığı zaman düzeltmenin maliyeti, ilk seferinde doğru kurmanın maliyetinden çok daha yüksek olur.
İşimizin başladığı yer
IWWOMI olarak yaptığımız iş tam burada başlıyor. Yalnızca uygulama veya yapay zekâ çözümleri geliştirmiyoruz — bu çözümleri ayakta tutan altyapının tamamını tasarlıyor ve devreye alıyoruz. Veri katmanından deploy süreçlerine, güvenlikten izlemeye kadar. AI dönüşüm çalışmamızı üretim-düzeyi yapan disiplinin aynısı, altyapı işimizin de büyümeyle temas ettiğinde ayakta kalmasını sağlıyor.
Ekibimizden konuyla ilgili diğer yazılar:
- Bulut Taşıma Stratejisi: Eksiksiz Rehber — neyin taşınacağına ve neyin kalacağına karar vermek için kullandığımız çerçeve.
- Modern Geliştirme Ekipleri İçin DevOps İyi Uygulamaları — self-hosted’ı ölçekte tutan operasyonel pratikler.
- Mikroservis Mimarisi: Ne Zaman ve Nasıl Kullanılır? — çok kiracılılığı mümkün kılan mimari şekil.
- Yüksek Trafikli Uygulamalar İçin Veritabanı Optimizasyon Teknikleri — veritabanı darboğaz hâline geldiğinde yaptığımız ayarlar.
Bunu ne zaman düşünmeli?
Şu durumlarda public buluttan çıkmamalısınız:
- Trafiğiniz gerçekten dalgalıysa ve kendi ekibinizle gerekçelendiremeyeceğiniz otomatik ölçeklendirmeye ihtiyacınız varsa.
- Operasyonel derinliği olmayan küçük bir ekipseniz ve kurucularınızdan biri nöbetteyse.
- Yönetilen servislere (RDS, Aurora, DynamoDB) bir yıl içinde kopyalanması zor şekilde bağımlıysanız.
Şu durumlarda düşünmelisiniz:
- Trafik profiliniz öngörülebilirse ve bulut faturanız müşteri tabanınızdan daha hızlı büyüyorsa.
- Yapısal olarak benzer birden fazla kiracıya hizmet veriyorsanız.
- Uyumluluk gereksinimleri (KVKK, GDPR, sektöre özgü) paylaşımlı altyapıda karşılanması zor yeni şartlar ekliyorsa. KVKK’nın yurt dışı veri aktarımı (madde 9) ve veri sorumlusu kayıt yükümlülüğü (VERBİS) konuları, self-hosted altyapıda çok daha kolay savunulur duruma gelir.
- Tek bir sağlayıcının tek bir API fiyat değişikliği marjlarınıza anlamlı zarar verebilirse.
Üçüncü seçenek — ve çoğu zaman doğrusu — tamamen çıkmak değildir. Sabit-durum iş yükü için bir self-hosted çekirdek inşa etmek ve patlama için küçük bir bulut ayak izi tutmaktır. Hibrit inişin ekonomisi genellikle saf bulut veya saf on-prem’i geçer.
Teknik derin dalış
Tam teknik yazı için — mimari diyagramlar, kabul ettiğimiz ödünleşmeler, farklı yapacağımız şeyler ve spesifik araç seçimleri (Kubernetes, Cilium, Longhorn, Tempo, Loki, Argo CD) — ekip liderimiz Abdullah Taş’ın Medium yazısını okuyun:
Sıfırdan Production’a: Bir Self-Hosted PaaS Mimarisi Kurma Hikayemiz →
Konuşmaya hazır mısınız?
Büyüyen iş yüküne ayak uydurmaya çalışan bir altyapınız varsa veya bulut maliyetleri sürdürülebilir olmaktan çıktıysa, tam olarak bu tür işleri yapıyoruz. İlk konuşma 30 dakikalık bir görüşme: mevcut kurulumunuza, gidişatınıza ve farklı bir şeklin sizin için ne anlama geleceğine bakarız. Taahhüt yok, slayt yok, dürüst bir okuma.
İletişime geçin — ne inşa ettiğinizi duymak isteriz.
