SaaS mimarisi: ölçeklenmeden önce ne gerekir?

SaaS mimarisi ne demek?

SaaS, İngilizce "software as a service" ifadesinin kısaltmasıdır: müşterinin satın alıp kurmadığı, internet üzerinden abonelikle kullandığı yazılım. Tek bir uygulama, birçok müşteriye aynı anda hizmet verir.

Mimari ise ürünün ana parçalarının ve aralarındaki sınırların nasıl kurulduğudur. Kullanılan programlama dili ya da sunucu markası değil; verinin nasıl ayrıldığı, yetkinin nerede denetlendiği, parçaların birbirine nasıl bağlandığıdır.

Erken aşamada mimari gösterişli olmak zorunda değildir. Doğru soruları yanıtlamış olması yeter. Aşağıdaki beş başlık, sonradan değiştirmesi en zor olanlardır.

Müşteri hesabını baştan modelleyin

Bir SaaS ürününde iki ayrı kavram vardır: kullanıcı ve müşteri hesabı. Kullanıcı, giriş yapan kişidir. Müşteri hesabı ise ürünü kullanan şirket ya da ekiptir; teknik dilde buna "tenant", yani kiracı denir.

Birçok ilk sürüm bu ikisini tek şey sayar: bir kullanıcı, bir hesap. Sonra ilk müşteri ekibinden ikinci bir kişiyi eklemek ister ve model yetmez. Bu ayrımı sonradan yapmak, verinin tamamına dokunmayı gerektirir.

Baştan yanıtlanması gereken sorular şunlardır.

• Bir müşteri hesabı neyi temsil ediyor: bir şirketi mi, bir şubeyi mi, bir ekibi mi?
• Bir kullanıcı birden fazla hesaba üye olabilir mi?
• Hesaba yeni kişi nasıl davet edilir, nasıl çıkarılır?
• Hesap kapatıldığında veriye ne olur?

Veri ayrımını ilk günden kurun

Birçok müşteriye aynı uygulamadan hizmet veriyorsanız en ciddi hata, bir müşterinin başka bir müşterinin verisini görmesidir. Bu hata güveni bir anda bitirir.

Erken aşamada en yaygın ve yeterli yöntem şudur: tüm müşteriler aynı veritabanını paylaşır, her kayıt hangi hesaba ait olduğunu taşır ve her sorgu bu bilgiyle sınırlanır. Önemli olan bu sınırın tek tek ekranlara bırakılmaması, tek bir ortak katmanda zorunlu tutulmasıdır.

Her müşteriye ayrı veritabanı vermek daha güçlü bir ayrım sağlar, ama işletmesi daha zordur. Bunu ancak bir müşteri sözleşmeyle isterse ya da bir düzenleme gerektirirse düşünün.

Rolleri ve yetkileri sade tutun

Yetki, bir kullanıcının ne yapabileceğidir. İlk sürümde iki ya da üç rol çoğu ürüne yeter: hesap sahibi, üye ve belki yalnızca görüntüleyen.

Her müşterinin kendi rollerini tanımlayabildiği esnek bir yetki sistemi cazip görünür. Erken aşamada neredeyse hiçbir zaman gerekmez ve her yeni özelliği yavaşlatır. Gerçek bir müşteri isteyene kadar erteleyin.

Dikkat edilmesi gereken tek şey, yetki denetiminin sunucu tarafında yapılmasıdır. Bir düğmeyi ekranda gizlemek yetki değildir; isteği sunucuda reddetmek yetkidir.

Kendi ekibinizin müşteri hesaplarına nasıl eriştiğini de baştan düşünün. Destek verirken bir müşterinin hesabına bakmanız gerekecek. Bu erişim kayıt altına alınmalı ve müşteriye açıklanabilir olmalıdır.

Paketleri yetkilerden ayırın

Yetki, kullanıcının ne yapabileceğini söyler. Paket ise müşterinin ne satın aldığını söyler. Teknik dilde ikincisine "entitlement", yani kullanım hakkı denir. İkisi farklı sorulardır ve ayrı tutulmalıdır.

Karıştırıldığında şu olur: "rapor alabilir" yetkisi bir yerde role, başka bir yerde pakete bağlanır. Fiyatlandırmayı değiştirmek istediğinizde kodun her yerine dağılmış koşulları tek tek bulmanız gerekir. Bir fiyat değişikliği, yetki hatasına dönüşür.

Doğru kurulduğunda soru hep aynı sırayla sorulur: önce bu hesabın paketi bu özelliği içeriyor mu, sonra bu kullanıcının rolü buna izin veriyor mu. Paket tanımları tek bir yerde durur; fiyatlandırmayı kod değiştirmeden güncelleyebilirsiniz.

İşletmeyi de tasarlayın

Bir SaaS ürünü yayına alındığında iş bitmez; başlar. İlk müşteri sorun bildirdiğinde ne olduğunu ne kadar hızlı anlayacağınızı, o güne kadar kurduklarınız belirler.

• İşlem kayıtları: kim, ne zaman, neyi değiştirdi? Hem destek hem güven için gereklidir.
• Hata izleme: bir hata oluştuğunda müşteri yazmadan sizin haberiniz olur.
• Arka plan işleri: e-posta gönderimi ya da rapor üretimi gibi işler takıldığında görünür olmalıdır.
• Yedekleme ve geri yükleme: yedeğin alındığı değil, geri yüklenebildiği sınanmalıdır.
• Basit bir yönetim ekranı: bir hesabın durumunu veritabanına girmeden görebilmek.

Ölçüme göre ölçeklenin

Ölçeklenme, yani artan kullanıcıyı ve veriyi taşıyabilme, çoğu kurucunun gereğinden erken kaygılandığı konudur. Erken aşamada darboğaz neredeyse hiçbir zaman sunucu gücü değildir; ürünün yeterince hızlı değişememesidir.

Bir şeyi değiştirmeden önce ölçün. Hangi sorgu yavaş? Hangi iş kuyrukta bekliyor? Kullanıcı gecikmeyi nerede hissediyor? Tahmine dayanarak yapılan iyileştirme çoğu zaman yanlış yeri iyileştirir.

Yavaşlığın büyük kısmı basit yollarla çözülür: eksik bir veritabanı dizini, gereksiz yere tekrarlanan bir sorgu, anında yapılması gerekmeyen bir işin arka plana alınması. Sunucu eklemek ya da sistemi parçalara bölmek bunlardan sonra gelir.

Sistemi ne zaman parçalara bölmek gerektiğini monolit mi, mikroservis mi yazımızda ayrıca anlatıyoruz. Kısa yanıt: çoğu erken aşama ürünü için gerekmez.

Neyi şimdi, neyi sonra yapmalı?

Her kararı ilk gün vermek gerekmez. Ölçüt şudur: sonradan değiştirmesi pahalı olanı şimdi, ucuz olanı sonra yapın.

MVP aşamasında bunların ne kadarı gerekir?

İlk sürümde hepsi gerekmez, ama ilk ikisi gerekir: hesap ve kullanıcı ayrımı ile veri ayrımı. Bunlar ucuzdur ve sonradan eklemesi en zor olanlardır. Geri kalanı ürün gerçek kullanıcı buldukça eklenir.

İlk sürümün ne kadar süreceğini ve süreyi neyin uzattığını MVP geliştirme süresi yazımızda anlatıyoruz.

Abonelik ve faturalama

SaaS ürünlerinde ödeme, tek seferlik bir satış değil, süren bir ilişkidir: deneme süresi, paket yükseltme, iptal, başarısız ödeme. Bunların her biri ürünün içinde bir durum olarak karşılık bulmalıdır.

Ödeme altyapısını sıfırdan yazmayın. Abonelik yöneten hazır bir ödeme sağlayıcısı kullanın ve ürününüzde yalnızca sonucu tutun: bu hesap hangi pakette, aboneliği etkin mi, ne zaman bitiyor.

Önemli olan, ödeme sağlayıcısındaki durum ile ürününüzdeki durumun birbirinden kopmamasıdır. Sağlayıcı bir ödemenin başarısız olduğunu bildirdiğinde ürününüz bunu işlemeli ve müşteriye ne olacağını açıkça söylemelidir.

Güvenliğin asgarisi

Erken aşamada kapsamlı bir güvenlik programı gerekmez, ama bazı temeller ilk günden yerinde olmalıdır. Bunlar sonradan eklemesi zor olanlar değil, eksikliği pahalıya patlayanlardır.

• Girişi kendiniz yazmayın; sınanmış bir kimlik doğrulama servisi ya da kütüphanesi kullanın.
• Parolaları asla düz metin olarak saklamayın.
• Her isteğin hangi hesaba ait olduğunu sunucuda denetleyin.
• Gizli anahtarları kodun içinde değil, ortam ayarlarında tutun.
• Yönetici işlemlerini kayıt altına alın.
• Düzenli yedek alın ve geri yüklemeyi sınayın.

Geç verilen kararın bedeli

Örnek senaryo: Küçük ekipler için görev takibi yapan bir ürün düşünelim. İlk sürümde her kullanıcının kendi görev listesi var; hesap kavramı yok. Ürün ilgi görüyor ve ilk müşteri, ekibindeki beş kişinin aynı listeyi görmesini istiyor.

Ekip bunu hızlıca çözmek için "paylaşım" özelliği ekliyor. Sonra bir müşteri yöneticinin tüm listeleri görmesini istiyor. Bir başkası ayrılan çalışanın görevlerinin kimde kalacağını soruyor. Fatura kime kesilecek? Her soru, hesap kavramının eksikliğine çıkıyor.

Sonunda veri modeli yeniden kuruluyor ve var olan tüm kayıtlar bir hesaba bağlanıyor. Baştan birkaç günlük bir karar, sonradan haftalar süren bir işe dönüşüyor. Bu anlatım kurgusaldır; gerçek bir ürünü tarif etmez.

Kararları yazılı bırakın

Mimari, yalnızca kodda yaşamaz; kararların gerekçesinde de yaşar. Neden tek veritabanı seçildi? Paketler nerede tanımlı? Hangi koşulda müşteriye özel veritabanına geçilir? Bu yanıtlar yazılı değilse, ekibe katılan her yeni kişi aynı tartışmayı yeniden açar.

Uzun belgeler gerekmez. Her önemli karar için birkaç satır yeter: ne karar verildi, hangi seçenekler vardı, neden bu seçildi, hangi koşulda yeniden düşünülmeli. Bu notlar ürünü devralacak bir ekip ya da teknik inceleme yapan bir yatırımcı için de değerlidir.

Özet

SaaS mimarisinde erken verilmesi gereken kararlar bellidir: müşteri hesabını kullanıcıdan ayırın, veri ayrımını ortak bir katmanda zorunlu tutun, rolleri sade bırakın, paketleri yetkilerden ayırın ve ürünü işletmek için gereken kayıtları kurun. Ölçeklenmeyi tahmine göre değil, ölçüme göre yapın.

Bu kararları ilk sürümde birlikte veririz ve yazılı olarak bırakırız. Kapsamı, fiyatı ve süreyi MVP geliştirme sayfamızda görebilirsiniz.