Teknoloji Yığını Seçimi: Teknik Olmayan Kurucular İçin Rehber

Teknoloji yığını seçimi, bir yazılımın hangi programlama dilleri, çatılar (framework), veritabanı ve barındırma altyapısıyla geliştirileceğine karar vermektir. Teknik olmayan bir kurucu veya ürün sahibi için iyi haber şudur: Doğru karar, en yeni ya da en popüler teknolojiyi seçmekle değil; yaygın, iyi belgelenmiş, ekibin iyi bildiği ve ileride başka geliştiricilerin de devralabileceği bir yapı seçmekle ilgilidir. Bu yazıda teknoloji yığınının parçalarını sade bir dille açıklıyor ve kararı değerlendirmek için sorabileceğin soruları paylaşıyoruz.

Teknoloji yığını neyi kapsar?

Bir web uygulamasının teknoloji yığını genellikle şu katmanlardan oluşur:

• Ön yüz (frontend): Kullanıcının tarayıcıda gördüğü arayüz. React, Vue veya Svelte gibi kütüphaneler ve bunların üzerine kurulan Next.js, Nuxt gibi çatılar bu katmanda kullanılır.
• Arka uç (backend): İş kurallarının çalıştığı, verilerin işlendiği sunucu tarafı. Node.js, Python, PHP, Go, Java veya .NET gibi ekosistemler yaygındır.
• Veritabanı: Verilerin saklandığı yer. PostgreSQL ve MySQL gibi ilişkisel veritabanları çoğu iş uygulaması için güvenli bir varsayılandır; belirli ihtiyaçlar için doküman tabanlı veya gerçek zamanlı veritabanları da kullanılır.
• Barındırma ve altyapı: Uygulamanın çalıştığı ortam. Yönetilen platformlar, bulut sağlayıcılar veya kendi sunucuların olabilir.
• Üçüncü taraf servisler: Kimlik doğrulama, ödeme, e-posta gönderimi, dosya depolama, hata izleme ve analitik gibi hazır hizmetler.

Mobil uygulama veya tarayıcı eklentisi varsa, bunların da kendi teknolojileri yığına eklenir.

Teknoloji yığını seçimi neden önemlidir?

Teknoloji kararı, ilk sürümden çok sonraki yılları etkiler:

• İşe alım ve devir: Yaygın bir teknolojiyle geliştirilen yazılımı devralacak geliştirici bulmak kolaydır. Az bilinen bir teknolojide ekip değişikliği ciddi bir risk olabilir.
• Bakım maliyeti: Aktif olarak geliştirilen, güvenlik güncellemeleri düzenli çıkan teknolojilerde bakım daha öngörülebilirdir.
• Geliştirme hızı: Olgun bir ekosistemde hazır kütüphaneler, belgeler ve topluluk desteği geliştirmeyi hızlandırır.
• Barındırma ve işletme maliyeti: Bazı mimariler daha az sunucu yönetimi gerektirir; bazıları daha fazla altyapı bilgisi ister.

Buna karşılık, ilk sürüm için "en hızlı" veya "en ölçeklenebilir" teknolojiyi aramak çoğu zaman gereksizdir. Yaygın teknolojilerin neredeyse tamamı, iş uygulamalarının çok büyük bir kısmı için yeterince hızlı ve ölçeklenebilirdir. Performans sorunları genellikle dil seçiminden değil, veri modeli ve sorgu tasarımından kaynaklanır.

İyi bir teknoloji yığınının özellikleri

Bir öneriyi değerlendirirken şu ölçütlere bakabilirsin:

1. Yaygınlık: Teknolojinin geniş bir kullanıcı ve geliştirici topluluğu var mı?
2. Olgunluk ve destek: Aktif olarak geliştiriliyor mu, düzenli sürümler ve güvenlik güncellemeleri çıkıyor mu?
3. Ekibin deneyimi: Projeyi yapacak ekip bu teknolojide üretim ortamına çıkmış işler yapmış mı?
4. İhtiyaca uygunluk: Gerçek zamanlı özellikler, yoğun veri işleme veya yapay zekâ entegrasyonu gibi özel gereksinimler için uygun mu?
5. Basitlik: Yığındaki parça sayısı ihtiyaçla orantılı mı? Her ek servis, bakım ve izleme yükü getirir.
6. Taşınabilirlik: Belirli bir sağlayıcıya aşırı bağımlılık var mı? İleride sağlayıcı değiştirmek ne kadar zor olur?

Kaçınılması gereken yaklaşımlar

• Moda olana yönelmek: Yeni çıkmış, topluluğu küçük teknolojiler heyecan verici olabilir, ama birkaç yıl sonra desteklenmeyebilir.
• Gereğinden karmaşık mimari: Küçük bir ürün için birçok ayrı servise bölünmüş (mikroservis) bir yapı kurmak, geliştirmeyi ve işletmeyi gereksiz yere zorlaştırır. Çoğu yeni ürün için iyi organize edilmiş tek bir uygulama daha sağlıklıdır.
• Her şeyi sıfırdan yazmak: Kimlik doğrulama, ödeme veya e-posta altyapısını sıfırdan geliştirmek, güvenlik riski ve zaman kaybı yaratır. Olgun servisler çoğu zaman daha güvenilirdir.
• Tek kişiye özgü tercihler: Yalnızca bir geliştiricinin bildiği, belgelenmemiş bir yapı, o kişi ayrıldığında projeyi kilitleyebilir.

Teknik olmayan biri olarak sorabileceğin sorular

Ekibin önerdiği teknoloji yığınını anlamak ve değerlendirmek için şu soruları sor. Cevapların teknik ayrıntısını anlaman gerekmez; cevapların net ve gerekçeli olup olmadığına bak.

• Bu teknolojiler neden seçildi? Alternatifler nelerdi?
• Bu yığınla daha önce yayına alınmış projeler var mı?
• Yarın başka bir ekiple çalışmak istesem, bu kodu devralacak geliştirici bulmak kolay olur mu?
• Barındırma nerede olacak ve aylık maliyeti hangi etkenlere göre değişir?
• Hangi üçüncü taraf servisler kullanılacak? Bunlardan biri kapanır veya fiyatını değiştirirse ne olur?
• Veritabanı yedekleri nasıl alınacak ve kimde duracak?
• Kaynak kodu, sunucu hesapları ve alan adı kimin adına olacak?

Son soru teknik değil ama en önemlilerinden biridir. Barındırma, alan adı ve servis hesaplarının şirketin adına açılması ve yönetici erişiminin sende olması, ileride yaşanabilecek erişim sorunlarını önler.

Örnek: Tipik bir SaaS ürünü için sade bir yığın

Somut olması için, orta ölçekli bir B2B SaaS ürünü için sık tercih edilen sade bir yapıyı örnek verelim. Bu bir reçete değil, değerlendirme için bir başlangıç noktasıdır:

• Ön yüz ve sunucu tarafı: TypeScript ile yazılmış, hem arayüzü hem sunucu işlevlerini barındırabilen bir web çatısı (örneğin Next.js).
• Veritabanı: Yönetilen bir PostgreSQL hizmeti.
• Kimlik doğrulama: Olgun bir kimlik doğrulama servisi veya çatının yaygın kimlik doğrulama kütüphanesi.
• Ödeme ve abonelik: Abonelik yönetimini destekleyen bir ödeme sağlayıcısı.
• E-posta: İşlemsel e-postalar için bir gönderim servisi.
• Barındırma: Otomatik yayın ve önizleme ortamları sunan yönetilen bir platform.
• İzleme: Hata izleme ve temel performans takibi.

Bu yapının avantajı, az sayıda parçadan oluşması, yaygın teknolojiler kullanması ve tek bir dil (TypeScript) ile hem ön yüzün hem sunucu tarafının yazılabilmesidir. Weras Labs'te de web projelerinde çoğunlukla bu tür sade, yaygın ve devredilebilir yapıları tercih ediyoruz.

Teknoloji kararını belgele

Hangi yığını seçersen seç, kararın gerekçesini kısa bir belgeye yazmak iyi bir alışkanlıktır. Belgede seçilen teknolojiler, alternatifler, seçim gerekçesi ve bilinen sınırlamalar yer almalıdır. Bu belge, ileride projeye katılan geliştiricilerin kararları anlamasını sağlar ve "bunu neden böyle yaptık?" tartışmalarını kısaltır.

Belgenin uzun olması gerekmez. Örneğin: "Veritabanı olarak PostgreSQL seçildi. Alternatif olarak doküman tabanlı bir veritabanı değerlendirildi; ancak verilerimiz büyük ölçüde ilişkisel (müşteri, sipariş, fatura) olduğu ve raporlama ihtiyacı yüksek olduğu için ilişkisel veritabanı tercih edildi. Bilinen sınırlama: Çok büyük ölçekte okuma yükü için ileride ek önbellek katmanı gerekebilir." Bu kadar kısa bir not bile, aylar sonra kararın gerekçesini hatırlamayı kolaylaştırır.

Sonuç

Teknoloji yığını seçimi, teknik olmayan bir ürün sahibi için korkutucu görünebilir, ama doğru sorularla değerlendirilebilir bir karardır. Yaygın, olgun, ekibin iyi bildiği ve devredilebilir bir yapı, çoğu projede en güvenli tercihtir. Projen için önerilen teknolojileri birlikte değerlendirmek istersen hizmetler sayfamızdan çalışma şeklimize göz atabilir veya bize yazabilirsin.