PaaS Nedir?
Bir web uygulaması geliştirdin. Şimdi onu insanların erişebileceği bir yere koyman gerekiyor. İki yolun var: sunucu kiralayıp işletim sistemi kur, Docker ayarla, SSL sertifikası al, reverse proxy yapılandır, güncelleme scriptleri yaz… Ya da kodunu bir Git deposuna push'la ve gerisini platforma bırak.
İkinci yol PaaS — Platform as a Service'tir.
PaaS, geliştiricilerin uygulama kodunu altyapı yönetimi olmadan üretime taşımasını sağlayan bulut hizmet modelidir. Sunucu tedariki, işletim sistemi bakımı, ağ yapılandırması ve ölçeklendirme gibi işlemleri platform otomatik üstlenir. Sen yalnızca kod yazarsın.
PaaS Nasıl Çalışır?
PaaS platformlarının çoğu perde arkasında benzer bir boru hattı işletir. Kodun canlıya çıkana kadar geçtiği adımlar şöyle sıralanır:
- Kaynak kod bağlantısı: GitHub, GitLab veya Bitbucket deposunu platforma bağlarsın.
- Kaynak kod analizi: Platform, depodaki dosyalara bakarak projenin dilini ve yapısını algılar.
- Framework algılama:
package.json,composer.json,requirements.txtgibi dosyalardan framework ve bağımlılık yöneticisi tespit edilir. - Bağımlılık kurulumu:
npm install,composer install,pip installgibi komutlar otomatik çalıştırılır. - Build: Varsa derleme adımları (asset build, TypeScript compile vb.) yürütülür.
- Container oluşturma: Uygulama izole bir container image'ına paketlenir.
- Runtime başlatma: Container çalıştırılır; port, bellek ve CPU limitleri uygulanır.
- Domain ve SSL: Geçici alt alan adı (veya özel domain) atanır; SSL sertifikası otomatik üretilir.
- Health check: Uygulamanın doğru yanıt verdiği kontrol edilir.
- Log ve rollback: Her deploy kaydedilir. Hata durumunda önceki sürüme tek komutla dönülür.
Bu adımların hepsi senin için otomatik gerçekleşir. Sen sadece git push yaparsın.
IaaS, PaaS ve SaaS Arasındaki Fark
Bulut hizmetleri üç temel katmana ayrılır. Her katman, kullanıcıya farklı bir sorumluluk seviyesi bırakır:
| Katman | Sen Yönetirsin | Sağlayıcı Yönetir | Örnek |
|---|---|---|---|
| On-Premise | Her şey (donanım dahil) | — | Kendi sunucu odası |
| IaaS | OS, runtime, uygulama, veri | Donanım, ağ, sanallaştırma | AWS EC2, Hetzner, DigitalOcean |
| PaaS | Uygulama kodu, veri | OS, runtime, ağ, ölçeklendirme, güvenlik yamaları | Heroku, Railway, Skyversal |
| SaaS | Yalnız kullanım | Her şey | Gmail, Slack, Notion |
Aşağı indikçe kontrol azalır ama operasyonel yük de azalır. PaaS, "işletim sistemiyle uğraşmak istemiyorum ama kodumun nasıl çalıştığını kontrol etmek istiyorum" diyen geliştirici için ideal dengededir.
PaaS Sağlayıcısı Neyi Yönetir, Kullanıcı Neyi Yönetir?
PaaS kullanmak, tüm sorumluluğu sağlayıcıya devretmek değildir. Sorumluluk sınırı şöyle çizilir:
Platform yönetir:
- İşletim sistemi güncellemeleri ve güvenlik yamaları
- Runtime altyapısı (container orchestration, kaynak tahsisi)
- Ağ yönlendirme, yük dengeleme ve DNS
- Deployment mekanizması, rollback ve sürüm yönetimi
- SSL sertifika yönetimi
Kullanıcı yönetir:
- Uygulama kodunun güvenliği (SQL injection, XSS vb.)
- Environment değişkenleri ve secret yönetimi
- Uygulamanın yetki ve erişim kontrol katmanı
- Veri modeli tasarımı ve veritabanı şeması
- Üçüncü parti entegrasyonların güvenliği
Bu ayrımı anlamak önemli çünkü "PaaS kullanıyorum, güvendeyim" diye düşünmek yaygın bir yanılgıdır. Platformun sunduğu altyapı güvenliği, uygulama katmanındaki açıkları kapatmaz.
PaaS Hangi İşleri Otomatikleştirir?
- Build: Kod her push'ta otomatik derlenir ve paketlenir.
- Runtime: Container yönetimi, kaynak izolasyonu ve süreç denetimi platform tarafından yapılır.
- Ölçeklendirme: Trafik artışında yatay veya dikey ölçek platformun sorumluluğundadır.
- SSL: HTTPS sertifikası üretilir, yenilenir ve uygulanır — müdahale gerekmez.
- Veritabanı: Yönetilen veritabanı servisi ile kurulum, yedekleme ve bağlantı otomatiktir.
- İzleme: Deploy logları, health check ve temel metrikler kutudan çıktığı gibi gelir.
Kimler ve Hangi Projeler İçin Uygundur?
- Startup / MVP: Ürün-pazar uyumunu test ederken altyapıya değil, ürüne odaklanmak istiyorsan.
- Freelancer / Ajans: Müşteri projeleri için tekrar tekrar sunucu kurmak yerine birkaç dakikada deploy etmek istiyorsan.
- SaaS kurucuları: Erken aşamada DevOps mühendisi kiralamadan ürününü canlıda tutmak istiyorsan.
- Yan projeler ve deneyler: Bir fikri hızlıca test edip validasyon almak istiyorsan.
- Backend API'leri: Stateless REST veya GraphQL servisleri PaaS'ta çok verimli çalışır.
PaaS Ne Zaman Uygun Değildir?
Dürüst olmak gerekirse, PaaS her proje için doğru tercih değildir. Şu durumlarda doğrudan altyapı yönetimi daha mantıklı olabilir:
- Kernel veya özel ağ kontrolü: Özel firewall kuralları, VPN tünelleri veya kernel modülleri gerekiyorsa PaaS yeterli esneklik sunmaz.
- Özel donanım / GPU: Machine learning eğitimi veya video işleme gibi GPU-yoğun iş yükleri PaaS modeliyle uyuşmaz.
- Sıra dışı daemon ve sistem servisleri: Standart HTTP request-response döngüsünün dışında çalışan, uzun ömürlü sistem servisleri gerektiren projeler.
- Sabit yüksek iş yükü: 7/24 %90+ CPU kullanan, öngörülebilir trafik desenli uygulamalarda doğrudan sunucu işletmek ekonomik olarak avantajlı hâle gelebilir.
- Sağlayıcı bağımlılığı endişesi: Platformdan tamamen bağımsız, taşınabilir bir altyapı şart ise — ki bu meşru bir tercih olabilir.
Buradaki kriter basit: eğer uygulamanın ihtiyaçları standart bir HTTP servisi modelinin dışına çıkıyorsa, PaaS kısıtlayıcı olabilir.
PaaS ile VPS/VDS Karşılaştırması
| Kriter | PaaS | VPS / VDS |
|---|---|---|
| Kontrol seviyesi | Uygulama katmanı | Tam (root erişim) |
| Bakım yükü | Minimum (platform üstlenir) | Yüksek (sen yönetirsin) |
| Deploy hızı | Dakikalar (git push) | Saatler–günler (ilk kurulum) |
| Maliyet modeli | Kullanım bazlı veya sabit plan | Sabit aylık (kullanmasan da ödersin) |
| Gerekli uzmanlık | Uygulama geliştirme | Uygulama + sistem yönetimi |
| Ölçeklendirme | Platform tarafından (hızlı) | Manuel (yeni sunucu + konfigürasyon) |
| Esneklik | Platforma bağlı sınırlar | Neredeyse sınırsız |
Kısaca: zaman ve operasyonel basitlik öncelikliyse PaaS, kontrol ve maliyet optimizasyonu öncelikliyse VPS daha uygun. İkisi de meşru seçimdir — biri diğerinden "daha iyi" değildir.
Popüler Platformların Yaklaşım Farkları
Tüm PaaS platformları aynı şeyi yapmaz. Her biri farklı bir mimari yaklaşımla farklı ihtiyaçlara odaklanır:
| Platform | Ana Yaklaşım | Güçlü Olduğu Alan | Kontrol Seviyesi |
|---|---|---|---|
| Heroku | Klasik uygulama PaaS | Basit deploy ve add-on ekosistemi | Düşük–orta |
| Render | Managed web servisleri | Web app, worker, managed DB | Orta |
| Railway | Geliştirici odaklı PaaS | Hızlı servis kurulumu, şık UX | Orta |
| Vercel | Frontend ve serverless platform | Next.js, edge functions, statik siteler | Düşük |
| Fly.io | Bölgesel uygulama makineleri | Dağıtık runtime, düşük gecikme | Orta–yüksek |
| Skyversal | Otomatik container deployment | Türkiye lokasyonu, çoklu servis, yerel deneyim | Orta |
Önemli not: Vercel özellikle frontend/serverless tarafında uzmanlaşmışken, Fly.io uygulamaları birden fazla coğrafi bölgedeki sanal makinelerde çalıştıran farklı bir modele sahiptir. Heroku, Render ve Railway ise daha geleneksel genel amaçlı PaaS yaklaşımını benimser. Hepsini aynı kategoride değerlendirmek yanıltıcı olur.
Türkiye Lokasyonlu PaaS Hangi İhtiyaçları Çözer?
Uygulamanın hedef kitlesi Türkiye'deyse, altyapının fiziksel konumu birkaç somut avantaj sağlayabilir:
- Ağ gecikmesi: Türkiye'deki kullanıcılara daha düşük ping süresi sunarsın. Yurt dışı sunucuda 80-120ms olan gecikme, yerel altyapıda 5-15ms düzeyine inebilir.
- Veri yerleşimi: Bazı sektörel düzenlemeler ve müşteri sözleşmeleri, verinin belirli bir ülkede barınmasını gerektirebilir. Türkiye lokasyonlu altyapı bu ihtiyacı doğrudan karşılar.
- TL fiyatlandırma: Dolar kuru dalgalanmalarından bağımsız, öngörülebilir maliyet.
- Türkçe destek: Teknik sorunlarda kendi dilinde, kendi saat diliminde iletişim.
- Yerel ödeme yöntemleri: Kredi kartı, banka kartı ve yerel ödeme altyapılarıyla doğrudan çalışır.
Önemli açıklama: Verinin Türkiye'de barınması, tek başına herhangi bir yasal uyumluluk garantisi vermez. KVKK uyumu; uygulama mimarisi, veri işleme süreçleri, sözleşmeler, güvenlik tedbirleri ve organizasyonel kontrollerin tamamına bağlıdır. Altyapı lokasyonu bu denklemin yalnızca bir parçasıdır.
Gerçek Deploy Akışı
Bir PaaS platformunda (örneğin Skyversal'da) tipik deploy süreci şöyle işler:
- Repo bağla: GitHub, GitLab veya Bitbucket hesabını bağla ve projenin deposunu seç.
- Framework algılansın: Platform, depodaki dosyaları analiz ederek framework'ü otomatik tanır (Laravel, Next.js, Django vb.).
- Environment değişkenlerini gir: Veritabanı URL'si, API anahtarları gibi değişkenleri güvenli şekilde tanımla.
- Build başlasın: Platform bağımlılıkları kurar, derleme adımlarını çalıştırır ve container image'ını oluşturur.
- Health check: Container ayağa kalktıktan sonra uygulamanın doğru yanıt verdiği otomatik kontrol edilir.
- Geçici adresle kontrol et: Platform sana bir alt alan adı atar; uygulamanı hemen tarayıcıda görebilirsin.
- Özel domain bağla: Kendi domain'ini ekle; SSL sertifikası otomatik üretilir ve uygulanır.
Projenin boyutuna ve bağımlılık sayısına göre bu süreç birkaç dakika içinde tamamlanır. Sonraki her git push aynı boru hattını otomatik tetikler.
Sonuç
PaaS, altyapıyı yönetmek yerine ürün geliştirmeye odaklanmak isteyen geliştiriciler için güçlü bir araçtır. Ama her araç gibi, doğru bağlamda kullanıldığında değer üretir.
Eğer projen standart bir web uygulaması, API veya microservice ise — ve DevOps operasyonu yerine ürüne zaman ayırmak istiyorsan — PaaS doğru tercih olabilir. Eğer kernel-seviye kontrol, GPU veya çok özel ağ yapılandırmaları gerekiyorsa, doğrudan sunucu yönetimi daha uygun olacaktır.
Skyversal'ı denemek istersen: İlk deploy'unu başlat. Kredi kartı gerekmeden projeni bağla, framework'ünü algılat ve birkaç dakika içinde canlıda gör.