Bir toplantıda finans ekibinden bir arkadaş sordu: "biz şu an bulutta mıyız yoksa kendi sunucumuzda mıyız, kafam karıştı, faturaya göre üçe bölünmüş görünüyor." Haklıydı, çünkü platformumuz gerçekten de aynı anda üç farklı katmanda üç farklı modelle çalışıyor. O gün tahtaya bizim gerçek altyapımızı çizip "işte bu SaaS, bu PaaS, bu da IaaS" diye anlatınca herkesin kafasında bir şeyler oturdu. Aynı çizimi burada da paylaşayım, çünkü bu üçlü genelde birbirinin yerine kullanılan, ama mimari kararlarda birbirinden tamamen farklı sorumluluk sınırları çizen üç kavram.
IaaS: duvarları biz örüyoruz, temeli kiralıyoruz
Altyapı-hizmet-olarak (Infrastructure as a Service), sanal makineyi, ağı, depolamayı size kiralar; işletim sisteminden yukarısı sizindir. Kubernetes kümemizin çalıştığı worker node'lar bizim için tam olarak bu katman: sağlayıcı bize CPU, bellek ve ağ veriyor, geri kalan her şeyi — konteyner orkestrasyonu, ölçekleme kuralları, güvenlik yamaları, izleme — biz kuruyoruz. Bunun bedeli sorumluluk: bir node'un kernel'i güvenlik açığı çıkardığında yama takvimi bizim takvimimiz, gece 3'te bir node çöktüğünde nöbetçi mühendis bizim nöbetçi mühendisimiz. Karşılığında aldığımız şey esneklik: mikroservis mimarimizin gerektirdiği tuhaf ağ topolojisini, özel disk yapılandırmasını, servisler arası mTLS kurgusunu istediğimiz gibi şekillendirebiliyoruz. IaaS'i seçtiğimiz yer basit bir kural izliyor: mimari kontrolün rekabet avantajına dönüştüğü her yerde IaaS'i tercih ediyoruz.
PaaS: temel de duvar da hazır, siz mobilyayı yerleştirin
Platform-hizmet-olarak, işletim sistemi ve çalışma zamanı yönetimini de üstlenir; siz sadece kodunuzu ve verinizi getirirsiz. Yönetilen veritabanı servisimiz tam olarak bu katmanda: replikasyon, yedekleme, failover, sürüm yükseltmeleri sağlayıcının işi. Bunu bilinçli olarak seçtik, çünkü veritabanı motorunun iç işleyişini özelleştirmemiz gereken bir senaryomuz yok — istediğimiz şey sıkı SLA'lı, bakımı bizi uyandırmayan bir veri katmanı. Mesajlaşma altyapımızın bir kısmı da PaaS: kendi Kafka kümemizi işletiyoruz çünkü konfigürasyon detayları (partition stratejisi, retention politikası) bizim için kritik, ama CI/CD boru hattımızın derleme ortamı tamamen yönetilen bir PaaS üzerinde — hangi Node.js veya PHP sürümünün altyapısını kimin yamadığını düşünmek istemiyoruz, o zamanı ürün geliştirmeye harcamayı tercih ediyoruz. PaaS'i seçtiğimiz yer de bir kuralla özetlenebilir: alt katmanı özelleştirmenin bize hiçbir rekabet avantajı getirmediği her yerde PaaS'e geçiyoruz.
SaaS: mobilya da hazır, anahtarı teslim alıyorsunuz
Yazılım-hizmet-olarak, uçtan uca hazır bir ürünü kullanmaktır; sizin işiniz sadece yapılandırmak ve veriyi akıtmak. Grafana panellerimizin bir kısmını, e-posta teslim altyapımızı ve müşteri destek bilet sistemimizi SaaS olarak kullanıyoruz. Burada da net bir ilke var: iş modelimizin çekirdeği olmayan, ama olmazsa olmaz her destek fonksiyonu SaaS'e aday. Kendi e-posta teslim motorumuzu yazıp SPF/DKIM itibarını sıfırdan inşa etmek bize hiçbir katma değer katmıyor, üstelik bu alanda yıllarca birikmiş itibar ve altyapıya sahip oyuncularla rekabet etmenin anlamı yok. Buna karşılık, platformun kalbi olan sipariş motoru, öneri sistemi, ödeme akışı gibi parçalar asla SaaS olmayacak — çünkü orası tam da rekabet avantajımızın yaşadığı yer.
Bir kez yanlış seçtik, öğrendik
İlk yıllarda arama motorunu SaaS bir servisten aldık; hızlı kuruldu, entegrasyonu bir günde bitti, ekip mutluydu. Kataloğumuz büyüdükçe iki şey rahatsız etmeye başladı: Türkçe karakter normalizasyonunda ("ı" ile "i", "ş" ile "s" eşleştirmesi) servisin sunduğu ayarlar yetersiz kaldı ve arama gecikmesi trafik arttıkça bizim kontrolümüz dışında dalgalanmaya başladı. SaaS'in verdiği hız, özelleştirme ihtiyacımız gerçek bir rekabet avantajına dönüştüğü an bir kısıta döndü. Kendi arama kümemize geçtik; kurulumu iki hafta sürdü ama Türkçe aramanın kalitesi, doğrudan dönüşüm oranına yansıdı. Buradan çıkardığımız ders şuydu: SaaS'e "kolay diye" değil, "bu katmanda asla özelleşmeyeceğiz diye" karar vermek gerekiyor; ilkini seçtiğinizde büyüme sizi cezalandırıyor.
Kilitlenme riskini baştan fiyatlandırın
Her üç modelde de gözden kaçan bir maliyet var: çıkış maliyeti. IaaS'te taşınma nispeten kolay, çünkü elinizde zaten işletim sistemi seviyesinde kontrol var. PaaS'te orta seviye risk var; yönetilen veritabanından çıkmak, veri taşıma ve uyumluluk testi gerektirir ama imkansız değil. SaaS'te risk en yüksek — veri formatı, iş akışı, hatta ekip alışkanlıkları o servise göre şekillenir. Yeni bir SaaS servisine geçmeden önce artık standart bir soru soruyoruz: "bu servisten bir gün ayrılmak zorunda kalırsak veri ve iş mantığını ne kadar sürede çıkarabiliriz?" Cevap net değilse, o servisi platformun çekirdeğine değil, çeperine yerleştiriyoruz.
Karar çerçevesi: soru hep aynı
Üç modeli birbirinden ayıran teknik detaylar değil, tek bir soru: "bu katmanı özelleştirmek bize gerçekten avantaj sağlıyor mu, yoksa sadece bakım yükü mü ekliyor?" Cevap "avantaj sağlıyor" ise aşağı iniyoruz — daha fazla kontrol, daha fazla sorumluluk, IaaS'e doğru. Cevap "sadece yük ekliyor" ise yukarı çıkıyoruz — daha az kontrol, daha az sorumluluk, SaaS'e doğru. Yeni bir bileşen eklerken ekipte artık bu üç harfli kısaltmaları tartışmıyoruz bile; direkt "bunu özelleştirmemiz bize ne kazandırır" diye soruyoruz, cevap kendiliğinden hangi katmana ait olduğumuzu söylüyor. Bir de sık unutulan bir gerçek var: bu üç katman sabit değil. Bugün PaaS olarak kullandığımız bir servisi, ölçek büyüyüp özelleştirme ihtiyacı gerçek bir avantaja dönüştüğünde IaaS'e indirmek gayet mümkün — nitekim mesajlaşma altyapımızda tam olarak bunu yaptık. Doğru soru "hangi model daha modern" değil, "bugün bize hangisi hizmet ediyor" sorusu; cevap zamanla değişebiliyor, mimari de onunla birlikte değişmeli.
Finans ekibindeki arkadaşın faturadaki üçe bölünmüş görünümü, aslında kafa karışıklığı değil, doğru kurgulanmış bir mimarinin doğal görüntüsüydü. Altyapı kararları hakkında konuşmayı her zaman severim, iletişim sayfam açık.