Neden on-prem'i ciddiye alıyoruz
SaaS'ın bulut-only refleksi her kurum için doğru değil. On-prem'i ürünün ilk gününden destekleyince ne kazanıyoruz?
Çoğu modern SaaS “we’re cloud-first, on-prem’i isterseniz Enterprise’da konuşuruz” diyor. Bu ürünün mimarisini bulutta donduruyor; on-prem ihtiyacı geldiğinde 6-12 aylık bir refactor başlıyor.
Biz Kerte’yi ilk günden on-prem deploy edilebilir tasarladık. Maliyetli bir karar — ama gerekçeleri net.
Türkiye’de on-prem niye anlamlı
- Veri egemenlik — bordro/kimlik gibi hassas veri kurum dışına çıkmasın baskısı yüksek
- KVKK uyum — bazı sektörlerde data residency’yi denetim eski tarz isterken
- Bağlantı esnekliği — bazı işyeri lokasyonları sınırlı internet
- IT politikası — bankalar, kamuya yakın kurumlar, defans sanayi için bulut otomatik diskalifiye
Mimari sonuçları
Bunu sağlamak için:
- Stateless servisler — secret/state hep harici store’da (Postgres, Redis, MinIO)
- Tek-bundle Docker compose — müşteriye verilen, içinde her şey olan klasör
- Self-contained images — runtime CDN bağımlılığı yok, FE assets bundle edilmiş
- Optional external dependencies — SGK e-Bildirge gibi network çağrıları opt-in, offline mod var
- Dahili Keycloak — auth da on-prem; LDAP/AD entegrasyonu standart
SaaS yine de standart
Bulut hâlâ “default” deneyim. On-prem ek lisans olarak gelir. Ama kod bazında tek branch — same image, different deployment. Bu sayede on-prem müşterisi de yeni feature’ları aldığımızda ertesi sürümle alır.
Tradeoff
On-prem destekli ürün daha disiplinli olmak zorunda. Cloud-only takım “monkey-patch hot-fix” lüksüne sahip; biz değiliz. Karşılığında ürün daha kararlı, daha taşınabilir — bu da bulut müşterisine de yarıyor.