PaaS Fiyatlandırması: Kullanım Bazlı ve Sabit Instance Maliyetleri
PaaS fiyatlandırmasını açıklıyoruz: dakika bazında kullanım ile sabit instance ücretlerini karşılaştırın, CPU/RAM/disk maliyetini hesaplayın, Dockup planlarını anlayın ve güvenli tahminler yapın.
PaaS fiyatlandırması, bir plan kartında basit görünebilir ancak production ortamında karmaşıklaşabilir. Bir abonelik ücreti kullanım kredisi içerebilir, sabit bir instance rezerve edilen boyut üzerinden ücretlendirme yapabilir ve kullanım bazlı bir platform gerçek CPU, RAM ve disk tüketimini ölçebilir. Yalnızca ilk dolar tutarını karşılaştırmak yanlış bir karara yol açar.
Dockup, plan aboneliğini ölçümlenen tüketimden ayırır. Free tek seferlik başlangıç kredisi içerir; Pro aylık kullanım kredisi içerir. CPU, RAM ve disk kullanımı dakika bazında ölçülür ve bakiyeden düşülür.
Kullanım bazlı ve sabit instance fiyatlandırması arasındaki fark nedir?
Sabit instance fiyatlandırması, uygulama rezerve edilen kapasitenin tamamını kullansın veya kullanmasın, faturalandırma dönemi boyunca seçilen makine ya da servis boyutu üzerinden ücret alır. Kullanım bazlı fiyatlandırma ise ölçülen tüketim üzerinden ücretlendirir; bazı modellerde minimum kullanım veya plan kredileri bulunabilir.
| Model | Ana birim | Avantaj | Risk |
|---|---|---|---|
| Sabit instance | Zaman içindeki seçili boyut | Öngörülebilir fatura kalemi | Atıl kapasite için ödeme |
| Gerçek kullanım | Zaman içindeki CPU/RAM/disk tüketimi | Faturayı tüketime uydurur | Değişken tahmin |
| Abonelik ve kredi | Plan ücreti ve dahil bakiye | Erişim ile harcamayı birleştirir | Kredi yanlış anlaşılabilir |
| Serverless request | Çağrı sayısı/süre | Bazı işlerde sıfıra kadar ölçeklenir | Yüksek hacimde maliyet artışları |
| Kullanıcı ve kaynak | Ekip erişimi ve compute | İş birliği özellikleri | Kullanıcı başına büyüme |
Dockup, abonelik ve kullanım kredisi modelini kullanır. Ücretli planlarda kaynak sayısı sınırsızdır ancak compute ve disk ücretsiz değildir. “Unlimited deployments”, deployment oluşturma sayısında limit olmadığı anlamına gelir; bunların tükettiği kaynaklar yine plan bakiyesini kullanır.
Dakika bazında ölçüm, aylık sabit instance modelinden daha ayrıntılıdır. Ayın bir bölümünde durdurulan bir servis, sürekli çalışan bir servisten daha az tüketebilir; sürekli açık ve yoğun çalışan bir servis ise mevcut bakiyesini düzenli olarak tüketebilir.
Dockup planları ve dahil olan krediler nelerdir?
Plan tablosu şöyledir:
| Plan | Fiyat | Dahil kredi | Workspace/database/deployment limitleri |
|---|---|---|---|
| Free | $0/ay | $10 başlangıç kredisi | 1 workspace, 3 database, 3 deployment |
| Hobby | $5/ay | $0 | Ücretli planlarda sınırsız |
| Pro | $20/ay | $20 aylık kullanım kredisi | Sınırsız; önerilen |
CPU, RAM ve disk tüketimi bakiyeden düşülür. Ücretli bir planı değerlendirirken ücreti, hem sınırsız kaynak sayısına erişim hem de aynı tutarda ön ödemeli kullanım bakiyesi olarak düşünün.
Pro planı, aylık $20 kredi sağlarken birkaç küçük servis veya temsili bir production workload'u çalıştırmaya alan bıraktığı için önerilir. Yine de doğru plan, gerçek tüketime bağlıdır.
Hesap bakiyesini ve servis tüketimini app.dockup.ai üzerinden inceleyin. Abonelik tutarını faturanın tamamı olarak değerlendirmek yerine CPU, memory, disk ve mevcut plan bakiyesini birlikte gözden geçirin.
Gerçekçi bir PaaS maliyetini nasıl hesaplarsınız?
Tahmini, workload-saatleri ve ölçülen kaynaklar üzerinden oluşturun.
Basit bir kavramsal formül şöyledir:
monthly cost =
subscription
+ CPU consumption
+ RAM consumption
+ disk consumption
+ other metered services
- included usage credit
Kesin birim fiyatları, kimsenin güncellemediği kopyalanmış bir spreadsheet yerine güncel fiyatlandırma kaynağından alınmalıdır. Metodoloji ise değişmez.
Her servis için şunları kaydedin:
- Günlük çalışma süresi.
- Ortalama ve peak CPU kullanımı.
- Ortalama memory working set.
- Persistent disk boyutu ve büyümesi.
- Database kaynakları.
- Preview ortamının yaşam süresi.
- Ortam sayısı.
- Sezonluk trafik.
- Beklenen build ve deployment sıklığı.
Launch sonrasında ölçülen değerleri kullanın. İstenen memory, kullanım bazlı bir modelde gerçek memory tüketimiyle aynı değildir. Buna karşılık sabit instance faturası, gerçek kullanım düşük olsa bile istenen boyutu yansıtabilir.
Örnek workload çalışma tablosu
| Kaynak | Miktar | Çalışma düzeni | Güven düzeyi |
|---|---|---|---|
| Web servisi | 1 | 7/24 | Yüksek |
| Worker | 1 | Günde 8 saat | Orta |
| PostgreSQL | 1 | 7/24 | Yüksek |
| Redis | 1 | 7/24 | Orta |
| Preview servisi | Ortalama 3 | Her biri 6 saat | Düşük |
| Volume | 20 GB | Sürekli | Yüksek |
Güncel birim fiyatlar ve gerçek kullanım değerleri olmadan bu tabloyu sahte bir dolar karşılaştırmasına dönüştürmeyin. Bu bir talep modelidir.
Kullanım bazlı fiyatlandırma ne zaman tasarruf sağlar?
Kullanım bazlı faturalandırma; workload'ların değişken olduğu, boşta kaldığında durabildiği veya istenen üst sınır ile gerçek tüketim arasında büyük fark bulunduğu durumlarda avantajlıdır.
Örnekler:
- Çalışma saatlerinde kullanılan development ortamları.
- Yalnızca review süresince var olan preview deployment'ları.
- Sınırlı bir zaman aralığında çalışan batch worker'ları.
- Başlangıç aşamasındaki, temel trafiği düşük ürünler.
- Kampanyalar arasında durdurulabilen servisler.
- Ortalama CPU kullanımı düşük küçük API'ler.
Workload sürekli yoğun ve öngörülebilir olduğunda sabit instance rekabetçi olabilir. Bu durumda ekip, ayrıntılı ölçüm yerine istikrarlı ve rezerve edilmiş bir fiyatı tercih edebilir.
Kullanım bazlı tasarruf için workload'un gerçekte daha az kaynak tüketmesi gerekir. Gerçekten etkin olmayan development ortamları için desteklenen bir lifecycle tanımlayın ve boşta görünen bir servisin maliyetsiz olduğunu varsaymak yerine platformdaki güncel davranışı doğrulayın.
Preview lifecycle da önemlidir. Onlarca preview'ı çalışır durumda bırakan bir ekip, kısa ömürlü ortamların maliyet avantajını ortadan kaldırabilir. Sahiplik ve sona erme kuralları tanımlayın.
Database'ler, volume'lar ve preview'lar PaaS fiyatlandırmasını nasıl etkiler?
Application compute, maliyetin yalnızca bir satırıdır.
Managed database'ler
PostgreSQL, MySQL, MongoDB ve Redis CPU, RAM ve disk tüketir. Database workload'ları genellikle sürekli çalışır ve storage zaman içinde büyür. Plan kapsamındaki ayrı limitler olmasa bile backup ve migration gereksinimlerini operasyonel modele dahil edin.
Persistent volume'lar
Volume'lar deployment'lar arasında verileri korur ve sürekli disk tüketir. Gerçek kullanımı izleyin:
dockup volume usage <volumeId> production/web --json
20 GB allocation'ın yalnızca 2 GB'ı kullanılıyorsa bu, büyüme payına veya israfa işaret ediyor olabilir. Karar, Dockup'ın diski nasıl ölçtüğüne ve uygulamanın yakın vadeli büyümesine bağlıdır.
Preview deployment'ları
Her PR veya branch, izole bir ortam ve URL alabilir. Bir preview aktif olduğu sürece kaynak tüketir. Private-network preview'lar, otomatik olarak oluşturulan read-only user üzerinden production database'e sorgu gönderebilir; bu da ayrı bir database olmasa bile database yükünü artırabilir.
Windows VM'leri ve Linux box'lar
OS seviyesindeki compute, küçük bir application container'dan daha yüksek sabit bir kaynak ayak izine sahip olabilir. Boyutlandırmayı ölçülen software gereksinimlerine göre yapın ve geçici kaynakları görevleri sona erdiğinde durdurun veya kaldırın.
Ücretli planlarda kaynak sayısı sınırsızdır; bu nedenle yönetişim, katı sayısal limitlerin yerini almalıdır. Platform izin veriyor diye bir agent on test servisi oluşturmamalıdır.
Kendinizi yanıltmadan PaaS sağlayıcılarını nasıl karşılaştırırsınız?
Önce workload'u normalize edin. Adil bir karşılaştırmada aşağıdakiler aynı olmalıdır:
- CPU ve memory ihtiyacı.
- Çalışma saatleri.
- Database engine ve storage.
- Persistent disk.
- Preview sayısı ve yaşam süresi.
- Ücretlendirilen team seat'leri.
- Network transfer varsayımları.
- Backup ve support gereksinimleri.
- Region'lar ve availability modeli.
- Operasyonel iş gücü.
Ardından her kalemi fixed, metered, credited veya uncertain olarak sınıflandırın.
| Maliyet kalemi | Provider A | Provider B | Dockup |
|---|---|---|---|
| Abonelik | Güncel değeri kaydedin | Güncel değeri kaydedin | $0/$5/$20 |
| Dahil kullanım | Güncel değeri kaydedin | Güncel değeri kaydedin | $10 başlangıç veya plana karşılık gelen aylık kredi |
| CPU | Fixed veya metered | Fixed veya metered | Dakika bazında ölçülür |
| RAM | Fixed veya metered | Fixed veya metered | Dakika bazında ölçülür |
| Disk | Güncel değeri kaydedin | Güncel değeri kaydedin | Dakika bazında ölçülür |
| Database | Ayrı veya dahil | Ayrı veya dahil | Managed resource tüketimi |
| Preview'lar | Yaşam süresini modelleyin | Yaşam süresini modelleyin | Aktif oldukları sürece kaynak tüketimi |
| Seat'ler | Güncel değeri kaydedin | Güncel değeri kaydedin | Güncel team plan koşullarını doğrulayın |
Üç yaygın hatadan kaçının:
- Bir platformdaki production servisini, diğer platformdaki uyuyan free servisle karşılaştırmak.
- Dahil krediyi iki kez düşmek.
- Sınırsız kaynak sayısını sınırsız kullanım olarak değerlendirmek.
Dockup vs Render vs Fly.io yazısı, rakip fiyatlarını sabitlemeden bu yöntemi uygular.
Ekipler PaaS harcamalarını nasıl izlemeli ve kontrol etmelidir?
Maliyet kontrolü, sürekli işletilen bir döngüdür. app.dockup.ai üzerinden servis tüketimini ve hesap bakiyesini gözden geçirin; ardından değişiklikleri deployment'lar, trafik ve kaynak büyümesiyle ilişkilendirin.
Kaynak sahipliği atayın. Her servis, database, volume, Windows VM, Linux box ve preview'ın bir amacı ve sahibi olmalıdır. Kullanılmayan kaynakları onaylanmış bir süreç üzerinden silin veya durdurun.
Bir AI agent; kaynakları listeleyebilir, kullanımı özetleyebilir ve aksiyonlar önerebilir. Yalnızca düşük aktiviteye dayanarak kaynakları otonom biçimde yok etmemelidir. Durdurulmuş bir incident-recovery database'i veya nadiren kullanılan bir administrative service kasıtlı olarak boşta olabilir.
Bütçe eşikleri
Şunları tanımlayın:
- Beklenen aylık aralık.
- Uyarı eşiği.
- İnceleme eşiği.
- Yeni always-on kaynaklar için gerekli onay.
- Maksimum preview yaşam süresi.
- Volume büyüme eşiği.
- Açıklanamayan harcamadan sorumlu kişi.
Bir forecast bir aralıktır, garanti değildir. Trafik ve preview aktivitesi için düşük, beklenen ve yüksek senaryolar kullanın.
Unit economics
Infrastructure harcamasını aktif customer, işlenen job, API request veya oluşturulan artifact gibi bir ürün birimiyle ilişkilendirin. Toplam maliyet artarken birim maliyeti iyileşebilir. Kullanılmayan servisler operasyonel karmaşıklık yaratırken sabit $20 abonelik de ucuz görünebilir.
Engineering zamanının maliyeti
Ekip deployment wrapper'ları, monitoring, preview orchestration, backup veya agent safety mekanizmalarını oluşturup sürdürmek zorundaysa daha düşük platform faturası daha kötü bir karar olabilir. Operasyonel iş gücünü ve incident riskini de dahil edin.
Dockup'ın değer önerisi yalnızca fiyat tablosundan ibaret değildir. AI agent'lar için deployment katmanını managed service'ler ve operasyonlarla tek bir CLI üzerinden birleştirir.
30 günlük doğrulama planı
- Testi destekleyen en küçük planla başlayın.
- Temsili bir servis ve database deploy edin.
- Gerçekçi trafik veya workload çalıştırın.
- Preview'ları normal review süresi kadar açık tutun.
- Kullanımı haftalık olarak izleyin.
- Volume ve database büyümesini inceleyin.
- Projeksiyonu gerçek ay sonu harcamasıyla karşılaştırın.
- Plan değişikliğini yalnızca kanıta dayanarak yapın.
Free planı, ilk doğrulama için $10 başlangıç kredisi sağlar. Pro planı, daha kapsamlı bir production testi için aylık $20 bakiye sunar.
Son PaaS fiyatlandırması kararı
PaaS fiyatlandırması, her kalemin birimi, zaman aralığı ve sahiplik kuralı olduğunda anlaşılır hale gelir. Kullanım bazlı ölçüm verimli ve aralıklı workload'ları ödüllendirir; sabit instance'lar ise kapasitenin sürekli gerekli olduğu öngörülebilir workload'larda avantaj sağlar.
Dockup'ın dakika bazında CPU, RAM ve disk modeli gerçek servis kullanımı üzerinden değerlendirilmelidir. Uygun dahil bakiyeyi ve hesap özelliklerini sağlayan planı seçin; ardından abonelik ücretinin tüm tüketimi sınırladığını varsaymak yerine ölçmeye devam edin.
Güncel kullanım komutları için Dockup CLI referansını kullanın. Dockup vs Railway ve Dockup vs Heroku karşılaştırmalarında komşu platformları inceleyin ve yayından önce güncel resmi fiyatlarını kontrol edin.
Nakit akışını ekonomik maliyetten ayırın
Dahil kredi, paranın hesaptan ne zaman çıktığını değiştirir; ancak workload'u ücretsiz hale getirmez. Brüt kaynak tüketimini ve net ödenecek tutarı takip edin. Brüt kullanım verimliliği, net harcama ise nakit etkisini gösterir.
Örneğin Pro aboneliği aylık $20 kredi sağlar. Ölçülen kaynaklar bakiyeden daha az tüketirse nakit bedeli $20 abonelik olarak kalabilir. Tüketim bakiyeyi aşarsa aşan tutar ek harcamaya dönüşür. Kesin sonuç, güncel ölçüm ve hesap bakiyesine bağlıdır.
Ekiplerin yalnızca kredi tükendikten sonra optimizasyon yapmaması için her iki rakamı da gösteren PaaS fiyatlandırması raporlarını kullanın.
Belirsizliği açıkça modelleyin
İlk forecast'ler üç senaryo içermelidir:
| Değişken | Düşük | Beklenen | Yüksek |
|---|---|---|---|
| Trafik | Planın %50'si | Forecast | Planın %200'ü |
| Preview yaşam süresi | 2 saat | 8 saat | 3 gün |
| Database büyümesi | 1 GB/ay | 5 GB/ay | 20 GB/ay |
| Worker aktivitesi | 2 saat/gün | 8 saat/gün | 24 saat/gün |
| Incident overhead | Yok | Bir recovery | Tekrarlanan debugging |
Mevcut birim fiyatlarını her senaryoda kullanın. Amaç kuruşuna kadar kesinlik değil; hangi varsayımın kararı değiştirebileceğini belirlemektir.
Sabit instance'larda da belirsizlik vardır: ekip seçilen boyutu aşabilir ve bir sonraki tier'a geçmek zorunda kalabilir. Bu kademe değişikliklerini dahil edin.
Ortam çoğalmasını dahil edin
Bir production architecture nadiren tek bir servisten oluşur. Staging, preview'lar, worker'lar, database'ler, Redis, volume'lar, Windows VM'leri, Linux box'lar ve geçici migration kaynaklarının tümünü hesaba katın.
Tek bir küçük servis başlangıç kredisine rahatça sığabilir. Aynı servisin production, staging ve beş kalıcı preview boyunca çalışması ise farklı bir PaaS fiyatlandırması problemidir.
Hangi ortamların sürekli çalışacağını tanımlayın:
- Production: Normalde sürekli açık.
- Staging: Yalnızca gerektiğinde sürekli açık.
- Preview: Açık bir PR veya branch'e bağlı.
- Load test: Planlanmış bir zaman aralığı için oluşturulur.
- Migration: Doğrulamadan sonra kaldırılır.
- Disaster recovery: Hazırlık hedeflerine göre maliyetlendirilir.
Ücretli plandaki sınırsız kaynak sayısı, yönetişimi daha az değil, daha önemli hale getirir.
Optimizasyon seçeneklerini riskle birlikte karşılaştırın
Memory'yi azaltmak, bir worker'ı durdurmak, retention süresini kısaltmak veya bir volume'u silmek harcamayı düşürebilir; ancak her aksiyon güvenilirliği değiştirir. Tahmini tasarrufun yanına servis seviyesindeki sonucu da kaydedin.
İyi bir optimizasyon önerisi şunları içerir:
- Kaynak ve sahibi.
- Mevcut ölçülen tüketim.
- Önerilen değişiklik.
- Beklenen aylık aralık.
- Performans veya recovery riski.
- Geri alma yöntemi.
- Gözlem süresi.
Bir agent, platformda gösterilen ölçülmüş tüketimi özetleyebilir; ancak kullanılabilirliği veya data retention'ı etkileyebilecek değişiklikleri bir insan onaylamalıdır.
Architecture değişikliklerinden sonra PaaS fiyatlandırmasını gözden geçirin
Yeni bir cache, Redis maliyeti eklerken database CPU'sunu azaltabilir. Bir background worker, API latency'sini iyileştirirken daha fazla saat çalışabilir. Private networking, aynı temel CPU/RAM/disk birimlerini değiştirmeden architecture'ı değiştirebilir. Bir Dockerfile image boyutunu azaltabilir ancak engineering zamanı tüketebilir.
Şu değişikliklerden sonra yeniden forecast yapın:
- Managed database eklemek.
- Çok sayıda preview etkinleştirmek.
- Büyük bir volume bağlamak.
- Kubernetes autoscaling'e geçmek.
- Bir Windows VM veya Linux box oluşturmak.
- Retention politikasını değiştirmek.
- Yeni bir region veya customer tier başlatmak.
PaaS fiyatlandırması, tek seferlik bir satın alma spreadsheet'i değil, architecture'a bağlı yaşayan bir modeldir.
Aylık inceleme şablonu
Planı, başlangıç bakiyesini, brüt kullanımı, kalan bakiyeyi, en çok kaynak tüketen beş kaynağı, beklenmeyen değişiklikleri, durdurulan kaynakları, preview sayısını, disk büyümesini ve gelecek ay senaryolarını kaydedin.
Sonucu önceki ayla karşılaştırın ve farkı açıklayan deployment veya trafik olaylarına not ekleyin. Böylece maliyet incelemesi engineering için faydalı hale gelir ve finance tarafında sürpriz oluşturmaz.
Aynı şablon sabit instance sağlayıcılarını da karşılaştırabilir: ölçülen kaynak satırlarını seçilen instance ücretleriyle değiştirin ve atıl kapasitenin görünür kalması için utilization'ı dahil edin.
Her tahminle birlikte varsayımları yayınlayın
Varsayımları olmayan bir PaaS fiyatlandırması rakamı incelenemez. Çalışma saatlerini, kaynak kullanımını, disk büyümesini, preview yaşam süresini, database sayısını ve güncel birim fiyat tarihini ekleyin. Değerleri measured, estimated veya unknown olarak işaretleyin.
Modeli ilk hafta ve ilk tam aydan sonra güncelleyin. Forecast ile gerçek sonuç arasındaki fark, yalnızca bir muhasebe hatası değil, workload hakkında bilgidir.
Bu disiplin, sağlayıcılar fiyatlarını değiştirdiğinde veya architecture büyüdüğünde PaaS fiyatlandırması karşılaştırmalarının geçerliliğini korur.
Modeli version control altında tutun
Varsayımları ve review tarihini architecture notlarının yanında commit edin. Version'lanmış bir PaaS fiyatlandırması modeli, ekibin planları neden değiştirdiğini gösterir ve eski bir spreadsheet'in açıklanamayan bir bütçe hedefine dönüşmesini önler.
Doğrulanabilir bir deployment ile başlayın
Tek bir temsili workload deploy edin, 30 gün boyunca gözlemleyin ve ölçülen servis, database, preview ve disk tüketimini plan bakiyesiyle karşılaştırın.
app.dockup.ai'de ücretsiz başlayın. Free planı aylık $0'dır, $10 başlangıç kredisi içerir ve bir workspace, üç database ve üç deployment destekler.
FAQ
Dockup ne kadar tutar?
Free $0 olup $10 başlangıç kredisi içerir. Hobby aylık $5'tir ve kullanım ayrıca faturalandırılır; Pro ise aylık $20'dir ve ilk $20 kullanım dahildir.
Dockup'ın ücretli planlarında neler sınırsızdır?
Ücretli planlar, sayısal olarak sınırsız workspace, database ve deployment kullanımına izin verir. CPU, RAM ve disk tüketimi yine plan bakiyesini kullanır.
Dockup kullanımı nasıl ölçer?
CPU, RAM ve disk tüketimi dakika bazında ölçülür ve hesabın dahil olan veya yüklenmiş bakiyesinden düşülür.
Kullanım bazlı fiyatlandırma her zaman sabit instance'dan daha mı ucuzdur?
Hayır. Değişken veya boşta kalan workload'larda tasarruf sağlayabilir; sürekli yoğun ve öngörülebilir bir workload ise sabit instance ile daha iyi karşılaştırılabilir. Aynı talebi modelleyin.
İki PaaS fiyatını nasıl karşılaştırmalıyım?
Çalışma saatlerini, CPU'yu, memory'yi, diski, database'leri, preview'ları, transferi, seat'leri ve support'u normalize edin; ardından sabit ücretleri, ölçümlenen kullanımı, dahil kredileri ve belirsizlikleri belirleyin.