- SaaS entegrasyonu geliştiricilerin yalnızca ürüne odaklanmasını sağlıyormuş gibi sunulsa da, gerçekte her seferinde gizli 5 maliyet (vergi) bulunur
- Devreye almadan önce keşif, kayıt, entegrasyon, yerel geliştirme, üretim aşamalarının her birinde zaman, karmaşıklık ve zihinsel yük sürekli ortaya çıkar
- SaaS yerine entegre platformlar (Cloudflare, Supabase vb.) seçilirse bu tekrarlayan maliyet ve karmaşıklık büyük ölçüde azaltılabilir
- Vendor lock-in kaçınılmaz bir gerçek olduğundan, birçok hizmeti karıştırmak yerine tek bir entegre platformda geliştirme akışını (Flow) korumak en iyi yaklaşımdır
- Sonuçta en önemli şey framework ya da hizmetin kendisi değil, benim yapmak istediğim yazılımdır
SaaS, sadece daha iyi markalanmış bir vendor lock-in'dir
- Geliştiriciler sık sık “yalnızca ürün geliştirmeye odaklanın” sözünü duyar, ancak gerçekte auth, kuyruk, dosya depolama, görsel optimizasyon gibi SaaS sağlayıcılarını devreye alırken çeşitli yükler ortaya çıkar
- Sadece parasal maliyetler değil, zaman kaybı, sürtünme ve zihinsel yorgunluk da vardır.
1. Keşif Vergisi (Discovery Tax)
- Bir SaaS hizmetini devreye almadan önce, gerçekte hangi işlevi ve değeri sattığını anlamak gerekir
- Sorun çözme kapsamı, mevcut stack ile uyumluluk, ölçeğe göre makul fiyatlandırma, dokümantasyonun açıklığı, sıra dışı uygulama biçimleri gibi ayrıntıları değerlendirmek gerekir
- Bu araştırma süreci önceki deneyimlerden kolayca paylaşılan ya da tekrar kullanılabilen bir şey değildir; önemli bir kısmı öznel kararlardır
- Pazarlama mesajının size uyup uymadığını ve hizmetin gerçekten yararlı olup olmayacağını bizzat değerlendirmeniz gerekir
2. Kayıt Vergisi (Sign-Up Tax)
- Bir hizmet seçtikten sonra e-posta ve kart bilgilerinizi vermeniz gerekir
- Kullanıma dayalı ücretlendirme mümkün mü, yoksa sadece abonelik temelli lock-in mi destekleniyor, bunu incelemek gerekir
- Ekip üyelerinin dashboard erişimi için ek ücret çıkması gibi opak fiyatlandırma yapıları sorun yaratır
- Ücretsiz deneme olmadan da test mümkün mü, daha en başta ödeme isteniyor mu, bunları kontrol etmek gerekir
- Daha tek satır kod yazmadan sağlayıcıyla sözleşmesel bir ilişki kurulmuş olur
3. Entegrasyon Vergisi (Integration Tax)
- Gerçek devreye alma sürecinde dokümantasyonu incelemek, kütüphane kurmak, framework'e bağlamak, dokümantasyon dışı ek sorunları çözmek zorunludur
- Sık sık araç çakışmaları veya beklenmedik sorunlarla karşılaşılır
- SaaS yalnızca en düşük ortak paydayı hedeflediğinde, en yeni stack'lerde veya özelleşmiş ortamlarda daha fazla iş gerekir
4. Yerel Geliştirme Vergisi (Local Development Tax)
- SaaS hizmetinin yerel ortam desteği sunup sunmadığı belirsiz olabilir
- Yerel emülatör sağlanması veya test amacıyla stub kullanılabilmesi gerekir
- Bazı işlevleri doğrulamak için cloud tunneling gibi şeyler gerekebilir ve bu da ortam kurulumunu karmaşıklaştırır
- production, staging, local için ayrı yapılandırma dallanmaları kaçınılmaz hale gelir
5. Production Vergisi (Production Tax)
- Hizmet entegre edildikten sonra production ortamında yeni yükler ortaya çıkar
- Staging ve PR preview ortamlarında da kullanılabilirlik, API key yönetimi, izleme ve loglama, uyarılar gibi ek yönetim gerekir
- Geliştirme ortamında sorun çıkarmayan ama yalnızca gerçek işletim ortamında görülen hata veya tutarsızlıklara hazırlıklı olmak gerekir
- Hizmetin kararlılığını koruma sorumluluğu sonunda yine geliştiricinin üzerine kalır
Sonuç
- Modern SaaS sloganı “tekerleği yeniden icat etmeyin” olsa da, her yeni hizmet sürtünmeyi de beraberinde getirir
- Bir hizmeti devreye almak basit bir entegrasyon değil, bir sözleşmedir; bağımlılıkların artmasını ve mimarinin değişmesini beraberinde getirir. Vendor lock-in kaçınılmazdır ve değiştirme anında ciddi bir kodu yeniden yazma yükü doğurur.
- Bu nedenle, bu tür kararları tekrar tekrar vermek yerine en baştan hepsi bir arada bir platform seçmek daha verimlidir
- Önemli olan geliştiricinin gerçekten yapmak istediği yazılımdır
- Cloudflare, Supabase gibi entegre platformlar veritabanı, kuyruk, görsel ve depolamayı aynı ortamda sunarak yukarıda sözü edilen vergi yükünü büyük ölçüde azaltır.
- Birden çok sağlayıcı arasında geçiş yapma (context switching) ihtiyacı yoktur
- API key ile uğraşma sorunlarının sıklığı azalır
- Uyumluluk ve ortama göre dallanan yapılandırmaları yönetme ihtiyacı en aza iner
- Geliştirme ve production ortamlarında tutarlı bir entegrasyon deneyimi sunar
- Bu tür platformlar sanki her şey aynı makinede çalışıyormuş hissi verir; kod ile hizmetler arasındaki mesafeyi en aza indirerek hiçbir SaaS'ın sağlayamadığı geliştirme odağını ("Flow") geri kazandırır.
> Önemli olan framework veya hizmet seçimi değil, yapmak istediğim yazılımı ve akışı (Flow) korumaktır
2 yorum
Supabase iyi bir örnek olarak gösteriliyor; peki o zaman hangi SaaS'ler kaçınılması gereken hizmetler olur?
Hacker News görüşü
Bu, Adam Smith’in “rent seeking (rant arayışı)” kavramının modern çağda aşırı büyütülmüş bir versiyonu olarak görülebilir.
Bu tür ekonomik davranışların toplumsal olarak zararlı olduğu için kaçınılması, hatta suç sayılması gerektiğini düşünüyorum.
Öte yandan, özgür yazılımın uç noktası da ekonomik olarak sorunlu; çünkü yazılımı üreten kişinin emeği, kullanıcının elde ettiği değerle orantılı olmayabiliyor.
Yazılımın satın alınması ile ayrı bir hizmet sözleşmesinin yapılması ve her birinin gerçekten ayrı bir değer sunması gerektiğini savunuyorum.
SaaS’ta bunların tek pakette birleşmesi, gerçekte hizmetin kendisinden çok paketlemenin aşırı biçimde çarpık hale gelmesi bakımından sorunlu.
Madem bu konuda bu kadar tutkuluyum, o zaman doğrudan bir SaaS kurup on-premise dağıtım ve işletim yapan bir şirket açarak bunu bugünkü SaaS’lara benzer fiyatla sunmam gerektiği söyleniyor.
Eğer şirketler veri kontrolünü koruyup vendor lock-in’i önlerken SaaS ile aynı kaliteyi, garantiyi ve fiyatı sunabilirse pazara hakim olabilecekleri söyleniyor.
Sürekli bunu düşünüyorum: Acaba sadece binary sunup kullanıcıların bunu AWS, GCP veya Cloudflare Workers üzerinde çalıştırmasına izin vermek yeterli olmaz mı?
Benim açımdan SaaS, geliştirici olarak cazip ama tüketici olarak sevmediğim bir yapı; bu yüzden etik bir ikilem yaşıyorum.
Diyelim ki yazılım satıyorum; kullanıcı bunu izinsiz yeniden dağıtırsa ne olacak? SaaS’taki gibi dağıtımı kontrol edemeyeceğim.
Ben bir FOSS (açık kaynak) destekçisiyim ama dediğiniz gibi bu yaklaşımın da ekonomik sorunları var.
GitHub Sponsors üzerinden lisans vermek gibi yöntemleri düşünüyorum; bazı projelerde kimlik doğrulama için SSPL, lisans satın alındığında BSD/MIT’e geçme modeli de aklımda (eski Redis’e benzer şekilde).
Yine de bunu gerçekten uygulasam insanların satın alıp almayacağından emin değilim; iki yöntemi birden desteklemeyi de düşünüyorum ama net bir cevabım yok, tavsiye istiyorum.
Bu arada yaptığım projeler arasında herkesin ücretsiz kripto para oluşturabildiği bir araç, YouTube’dan blog içe aktarma özelliği ve YouTube topluluğu ile videolarını Google Photos alternatifi olarak kullanan sınırsız depolama gibi şeyler var; gizlilik tarafını da düşünüyorum. Para kazanma fikriniz varsa duymak isterim.
SaaS’ın büyük kısmında sağlayıcı tarafında hosting, destek, Ar-Ge gibi sürekli maliyetler oluştuğunu belirtmek gerekir.
Bu yapının neden “rant arayışı” sayılması gerektiği fikrine mantıken katılmak zor.
Her SaaS’ı rant arayışı olarak görmek doğru değil; yazılımın “stickiness”inin (yapışkanlık, çıkması zor olma hali) özünde rent-seeking’e benzediği söylenebilir.
Çoğu SaaS şirketi stickiness peşinde koşar ama bunun SaaS’a özgü bir nitelik olmadığı görüşündeyim.
Ben kendi SaaS ürünümü, piyasada makul bir fiyat ödemeye hazır müşterilere satan taraftayım.
Vendor lock-in’i genelde şirket içinde “Neden NEWTHING aracını kullanmıyoruz?” diye sorulduğunda, Oracle, MS, IBM ya da Salesforce ile zaten 5 yıllık uzun vadeli sözleşmelerimiz var, o yüzden yapamıyoruz cevabını aldığınızda hissedersiniz.
Sonra yaklaşık 10 yıl geçince gerçekten o şirkete tamamen bağlanmış olursunuz ve artık değiştiremez hale gelirsiniz.
İş 10 yıl sürecek kadar sağlam gidiyorsa bu aslında bir nimet ya da sıkıcı bir problem olabilir; ama girişimin ilk dönemlerinde araç seçimine fazla vakit harcamayıp hızlıca tek bir platform seçip odaklanmanızı tavsiye ederim.
Böyle durumlarda bile servisleri standartlaştırılmış arayüzlerle soyutlamak iyi bir fikir.
Böylece daha sonra başka bir servise geçmek gerektiğinde yalnızca alternatif bir implementasyon sunmanız yeterli olur.
Bu yaklaşım geleceğe dönük ama bugün birçok şirketin buna hazırlıksız olduğunu düşünüyorum.
Bağımlılıkları en aza indirmenin, ürünün ve işin sürdürülebilirliğini artıran en önemli unsurlardan biri olduğunu düşünüyorum.
Önceki işimde ürünümüze DocuSign benzeri bir elektronik imza deneyimi entegre etme işinden sorumluydum.
DocuSign, Adobe ve diğer büyük sağlayıcılarla görüştük ama API kısıtları çok fazlaydı ve ürün ile müşteri ihtiyaçlarına iyi uymadığını gördük; sonunda bunu şirket içinde kendimiz geliştirmeye karar verdik.
Normalde DocuSign benzeri bir aracı sıfırdan yapmak kötü bir fikir olurdu ama bizim ürünümüz zaten müşterilerin güvenini kazanmıştı, bu yüzden benimsenme eşiği düşüktü.
Kendimiz geliştirdiğimizde başta çok iş çıktı ama müşteriye özel küçük değişikliklere hızlı cevap verebildik; bir vendor kullanıyor olsaydık bunlar çok daha zahmetli büyük işler olurdu. Bu yüzden kendi çözümümüzü kurma kararı doğruydu.
Yazarın söylediğini, SaaS vendor lock-in’dir, bu yüzden satın almayın şeklinde anlıyorum.
Ama metnin kendisinde Cloudflare gibi belirli bir platforma tamamen bağlanmayı öneriyor.
Sonuçta hangi seçimi yaparsanız yapın her şey bir tür lock-in; açık kaynak ve self-hosting bile değiştirmek isterseniz tonla kodu yeniden yazmanız gerekebilir.
Sadece bir sağlayıcıya özgü özellikleri kullanmakla “gerçek lock-in” aynı şey değil; gerçek lock-in, değiştirmenin mevcut durumu sürdürmekten daha fazla maliyet ve zaman gerektirdiği noktada oluşur.
Yazılımı gevşek bağlı ve yüksek iç uyumlu kurarsanız belirli parçaları değiştirmek daha kolay olur.
Çünkü arayüz ne kadar basitse değiştirmek de o kadar kolaydır.
Bu yüzden “nasıl olsa her şey lock-in, o halde bari daha da net biçimde tek platforma bağlanalım” yaklaşımı geliştirici için rahat olabilir ama yönetici için iyi bir strateji değildir; şirketin esnekliğine ve değişebilme kapasitesine odaklanmak gerekir.
İşletme sahibi açısından bakınca, şirkete esneklik ve değişebilme imkanı veren çözümleri seçmek gerekir; hiçbir alternatif olmadan SaaS’a bağlanmak bu yüzden akıllıca değildir.
Başlangıç aşamasında veya gelir yokken SaaS yerine platform kullanmak daha avantajlı olabilir; büyüyüp ölçeklenme aşamasına gelince uzun vadeli teknolojik değişimleri de düşünmek gerekir.
Ben Cloudflare Workers’ı sık kullanıyorum ve kodu da her yere taşınabilir olacak şekilde yazıyorum.
wrangler devile yerelde çalıştırmak mümkün ve gerçekten de pure Node/Bun/Deno üzerinde büyük değişiklik yapmadan çalıştırabiliyorum.OP’nin (orijinal gönderi sahibi) SaaS’ın kendisine karşı çıkmadığını düşünüyorum (sonuçta Cloudflare veya Supabase gibi as-a-service çözümleri öneriyor); asıl mesele çok fazla sağlayıcıyla sözleşme yapmanın, bunları yönetmenin ve ilişkileri yürütmenin operasyonel maliyeti.
Sağlayıcı sayısı ne kadar azsa, bağımlılık ne kadar azsa operasyon o kadar kolay olur.
Elbette her şeyi standart kütüphanelerle uygulamak fazla idealist bir hayal; pratikte oldukça zor.
Başlangıçta birçok servisi birbirine karıştırmak yerine tek bir platform kullanmayı denemenizi önermemin nedeni bu.
Cloudflare’ı sevmemin sebebi, binding’leri
fetchgibi standartlaştırması;fetchbana web dünyasında Unix pipe’larını hatırlatıyor.Vendor lock-in’den kaçınmak isterken her şeyi tek bir platforma yığıp kendinizi daha da sert biçimde tek bir şirkete bağlamak ironik görünüyor.
Çünkü SaaS’ın da parçalı maliyetleri, yani bir tür “vergisi” var.
Bence bu tartışma aslında açık kaynak savunusuna daha yakın.
Açık kaynak ve self-host yaklaşımı benimsenirse yazıda geçen “vergilerin” çoğu (keşfetme, kaydolma, entegrasyon, yerel geliştirme ile ilgili maliyetler) ortadan kalkar.
Açık kaynağın production tax’i (operasyon yükü) ise canlı bir ekosistem, eklentiler ve modüllerle çözülebilir diye düşünüyorum.
(Din ile kült arasındaki farka benzeterek) Verinizi standart bir formatta dışa aktararak ayrılabiliyorsanız, bu vendor lock-in değildir.
Müşteriler kendi verilerini alabildiklerinde daha az mağduriyet hisseder; ama çok fazla SaaS hizmeti bunu imkansız hale getiriyor.
Şu anda çoğu şeyi MIT ile açık yayınlayıp önemli parçaları kapalı tutma şeklinde ilerliyorum.
SaaS’ın sınırı, yazılımın “neredeyse sıfır marjinal maliyet” avantajından müşterinin yararlanamamasıdır.
SaaS sağlayıcıları bunun bir kısmını fiyatlara yansıtarak ücretleri düşürse de kullanıcı sayısı yeterince büyüyüp birim gelir yükseldiğinde sonunda SaaS müşterisi dezavantajlı duruma düşer.
Ama bir girişimin ilk döneminde her şeyi kendiniz kurmaya çalışmak çoğu zaman gözü kara bir tercihtir; “hayatta kalma” ve “ilk maliyeti en aza indirme” aşamasında SaaS çok akıllı bir stratejidir.
İş büyüyüp SaaS günlük işleyişin derin bir parçası haline geldikten sonra ancak lock-in, taşıma ve geçiş maliyetleri sorun yaratmaya başlar.
SaaS sorunu denen şeyin de aslında başarının bir yan etkisi olduğunu düşünüyorum.
Zaten bu yüzden bu kadar çok SaaS modeli var.
Emeklilik maaşı gibi düzenli gelir getiren ve üstüne fiyat belirleme gücü de sağlayan bir iş modeli son derece çekici.