Bu seride şimdiye kadar DigitalOcean’ın hemen her ürününü ayrı ayrı ele aldım: Droplet, App Platform, Nginx ve SSL, Managed Database, Spaces, Docker, Kubernetes, Functions. Bu son yazıda hepsini bir araya getirip, sıfırdan bir MVP’nin (minimum viable product) bu altyapı üzerinde nasıl yayına alınacağını uçtan uca bir senaryo üzerinden anlatıyorum.
MVP İçin Doğru Ölçek Neresi
Bir yan projeye ya da MVP’ye başlarken en sık yapılan hata, gereğinden fazla altyapı kurmak. Kubernetes kümesi, çoklu bölge dağıtımı, otomatik ölçeklendirme kuralları gibi konular henüz kullanıcı sayısı belli olmayan bir proje için zaman ve dikkat israfına dönüşüyor. MVP aşamasında asıl öncelik, fikri hızlıca test edebilecek kadar sağlam ama gereğinden karmaşık olmayan bir altyapı kurmak.
Bu yüzden bu senaryoda ağır bir Kubernetes kurulumu yerine, App Platform ve gerektiğinde bir Droplet üzerinden ilerleyen, kolayca büyütülebilir ama başlangıçta minimal kalan bir yaklaşım izliyorum.
Adım 1: Backend’i App Platform Üzerinde Yayına Alma
Bir MVP genellikle bir API ve bir frontend’den oluşuyor. Backend tarafı için App Platform, sunucu yönetimiyle uğraşmadan hızlıca yayına almak için ideal bir başlangıç noktası sunuyor. Daha önceki yazıda anlatıldığı gibi bir GitHub reposu bağlanıp, Node.js, Python ya da tercih edilen dilde yazılmış API doğrudan Git push ile yayına alınabiliyor.
Bu aşamada paylaşımlı CPU’lu temel plan genellikle yeterli oluyor, çünkü MVP aşamasında trafik henüz düşük seviyede kalıyor. Otomatik ölçeklendirme ya da dedicated CPU gibi ek maliyetli özellikler, gerçek kullanıcı verisi görülüp ihtiyaç netleştikten sonra devreye alınabiliyor.
Adım 2: Veritabanını Ayrı Bir Katmanda Tutma
MVP’ler genellikle küçük başlasa da, veritabanının baştan itibaren ayrı ve yönetilen bir katmanda tutulması ileride büyük bir taşıma zahmetinden kurtarıyor. Bu yüzden veritabanını App Platform’un içine gömmek yerine, ayrı bir Managed Database olarak kurmak daha sağlıklı bir yaklaşım oluyor. Giriş seviyesindeki bir PostgreSQL ya da MySQL kümesi, çoğu MVP için fazlasıyla yeterli kapasite sunuyor.
Bu yaklaşımın avantajı, backend API’sini App Platform üzerinde yeniden yapılandırmaya ya da farklı bir yere taşımaya karar verildiğinde veritabanının bu değişiklikten etkilenmemesi. Veritabanı bağımsız bir bileşen olarak kaldığı sürece, üzerine kurulu uygulama tarafında yapılacak değişiklikler çok daha az riskli hale geliyor.
Adım 3: Kullanıcı Yüklemeleri için Spaces Kullanmak
Bir MVP’de kullanıcı profil fotoğrafı, dosya yüklemesi ya da herhangi bir medya içeriği söz konusuysa, bu dosyaları uygulamanın kendi sunucusunda tutmak yerine baştan Spaces üzerinde saklamak mantıklı bir tercih. Bu, hem uygulamanın stateless (durumsuz) kalmasını sağlıyor hem de ileride ölçeklenme ihtiyacı doğduğunda dosya depolama katmanının ayrı olması işleri kolaylaştırıyor.
App Platform üzerindeki her bir uygulama örneği kendi geçici dosya sistemine sahip olduğu için, dosyaları oraya kaydetmek veri kaybı riski taşıyor. Spaces’i baştan entegre etmek, bu riski ortadan kaldıran basit bir önlem oluyor.
Adım 4: Frontend’i Statik Olarak Yayına Alma
MVP’nin frontend’i React, Vue ya da benzer bir framework ile yazıldıysa ve statik bir build çıktısı üretiyorsa, bu da App Platform üzerinde ayrı bir statik site bileşeni olarak ücretsiz şekilde barındırılabiliyor. Böylece backend API ve frontend, aynı App Platform uygulaması içinde farklı bileşenler olarak ya da tamamen ayrı iki uygulama olarak yönetilebiliyor.
Adım 5: Domain Bağlama ve Test Etme
Backend ve frontend hazır olduğunda, kendi alan adı App Platform üzerinden bağlanıp SSL otomatik olarak sağlanıyor. Bu noktada MVP artık gerçek kullanıcılara açılmaya hazır bir durumda. İlk kullanıcı testleri, geri bildirimler ve trafik verileri toplanmaya başlanabiliyor.
Ne Zaman Daha Fazla Altyapıya Geçmeli
MVP gerçek kullanıcı ilgisi görüp büyümeye başladığında, bu noktaya kadar kurulan basit yapı doğal olarak genişletilebiliyor. Trafik artıp App Platform’un paylaşımlı CPU planı yetersiz kalırsa dedicated CPU’ya ya da otomatik ölçeklendirmeye geçilebiliyor. Backend karmaşıklaştıkça, örneğin arka planda çalışan işler (e-posta gönderimi, veri işleme gibi) ihtiyacı doğduğunda App Platform’un Worker bileşenleri devreye alınabiliyor.
Uygulama container’lara ayrılacak kadar büyürse ve birden fazla mikroservis birbirinden bağımsız ölçeklenmesi gereken bir noktaya gelirse, önceki yazılarda anlatılan Docker ve DOKS adımları bu noktada anlamlı hale geliyor. Fakat MVP aşamasında bu adımları önden atmak, henüz var olmayan bir soruna çözüm üretmek anlamına geliyor.
Maliyet Perspektifinden Bakış
Bu şekilde kurulan bir MVP’nin aylık maliyeti genellikle oldukça düşük kalıyor: App Platform’un temel planı, giriş seviyesindeki bir Managed Database ve gerekiyorsa küçük bir Spaces paketi bir araya geldiğinde toplam maliyet, birçok yan proje için bütçeyi zorlamayan bir seviyede duruyor. Bu düşük maliyet, fikri test etme aşamasında finansal riski minimumda tutmayı sağlıyor.
Sonraki Adımlar
Bu seri boyunca ele alınan Droplet, App Platform, Nginx, Managed Database, Spaces, Docker, Kubernetes ve Functions konuları, bir araya geldiğinde DigitalOcean üzerinde küçük bir fikirden büyük bir projeye kadar uzanan bütün bir yolculuğu kapsıyor. Bir MVP’ye bugün başlayıp, ihtiyaç doğdukça bu yazılarda anlatılan adımlara geri dönerek altyapıyı adım adım büyütmek, hem zaman hem de bütçe açısından en sürdürülebilir yaklaşım oluyor.
Kendi MVP’ni yayına almak istersen, referans linkim üzerinden kayıt olarak bana destek olabilirsin.
Tüm projelerim ve üzerinde çalıştığım konuları incelemek istersen https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.
