.NET Tabanlı Kurumsal Yazılım: Neden ve Ne Zaman?

Bir kurumsal yazılım satın alırken sorulan sorular genelde ekran ve özellik üzerinedir: "şu raporu veriyor mu, şu ekranı var mı?" Oysa yazılımın hangi teknoloji üzerine kurulu olduğu, beş yıl sonra onu güncelleyip güncelleyemeyeceğinizi belirler. Bu yazıda .NET tabanlı kurumsal yazılımın ne sağladığını ve hangi durumlarda doğru seçim olmadığını ele alıyoruz.

Uzun vadeli destek ve sürüm disiplini

Kurumsal yazılımın gerçek maliyeti ilk kurulumda değil, sonraki yıllarda ortaya çıkar. .NET, uzun vadeli destek (LTS) sürümleriyle bilinen ve güvenlik yamaları öngörülebilir bir takvimle yayımlanan bir platformdur.

Bunun pratik anlamı: aldığınız sistem beş yıl sonra da güvenlik güncellemesi alabilir. Ekosistemi dar olan veya tek kişiye bağımlı teknolojilerde aynı güvence yoktur — yazılımı geliştiren kişi ayrıldığında sistem güncellenemez hale gelebilir.

Ürünlerimizin teknik tercihi: Sıra Yönetim Sistemi .NET 10 Framework üzerinde çalışır ve Windows 10 veya daha güncel sürümlerle uyumludur; minimum 4 GB, önerilen 16 GB bellek gerektirir.

Sürüm takvimini bilmek, karar verirken işe yarar. .NET'te çift numaralı sürümler LTS (uzun vadeli destek), tek numaralı sürümler STS (standart destek) olarak yayımlanır; LTS sürümleri üç yıl, STS sürümleri on sekiz ay desteklenir. Bu, iki şeyi beraberinde getirir: destek süresi biten bir sürüm güvenlik yaması almaz, ve yükseltmeyi ertelemek "yükseltme borcu" biriktirir.

Bu yüzden tedarikçinize iki soru sorun: ürün hangi sürümde ve bu sürümün destek bitiş tarihi ne? Yükseltme planı, destek bitişinden önce yapılmalıdır; sonrasında yükseltme bir seçenek değil zorunluluk haline gelir ve acil yapılan yükseltmeler en riskli olanlardır.

Sürüm yükseltmesi nasıl planlanır?

Kurumsal bir sistemde yükseltme, yalnızca uygulama kodunu ilgilendirmez. Kapsamlı bir yükseltme planı şu adımları içerir:

• Bağımlılık envanteri. Kullanılan üçüncü taraf kütüphanelerin listesi ve her birinin yeni sürümü destekleyip desteklediği.
• Kırıcı değişiklik taraması. Ana sürüm geçişlerinde davranış değişiklikleri ve kaldırılan uygulama programlama arayüzleri.
• Test ortamında doğrulama. Yükseltmenin canlıya çıkmadan önce gerçek veriyle denenmesi.
• Geri dönüş planı. Yükseltme sonrası bir sorun çıkarsa önceki sürüme dönüş adımlarının hazır olması.
• Bakım penceresi. Hizmet kesintisi gerekiyorsa hangi saat aralığında yapılacağının duyurulması.

Bu adımlar yazılı bir plana bağlanmadığında yükseltme, çalışan sisteme dokunma korkusuna dönüşür ve teknik borç büyür.

Performans: eşzamanlı yük altında kararlılık

Kurumsal yazılımın sınandığı an, yoğunluk anıdır. Ay sonu, kampanya günü veya ders çıkışı gibi anlarda sistem ya ayakta kalır ya da kalabalığın ortasında durur.

.NET'in asenkron programlama modeli ve çalışma zamanı altyapısı, çok sayıda eşzamanlı isteği verimli karşılamak üzere tasarlanmıştır. Sahadaki karşılığı ölçülebilir olmalıdır: anket sistemimizde .NET tabanlı altyapı sayesinde binlerce anket cevabı milisaniyeler içinde işlenir.

Performans iddiasını değerlendirirken soyut ifadelerden kaçının; tedarikçiden kendi senaryonuzdaki eşzamanlı kullanıcı sayısı için ölçüm isteyin. Buna ek olarak şu üç ayrıntı gerçek kapasiteyi belirler:

• Ölçekleme yönü. Sistemi daha güçlü bir sunucuya taşımak (dikey) ile birden fazla sunucuda çalıştırmak (yatay) aynı şey değildir. Yatay ölçekleme uygulamanın durumsuz tasarlanmasını gerektirir.
• Bellek ve çöp toplama davranışı. Yoğun sistemlerde bellek yönetimi yapılandırması, gecikme sürelerini belirgin şekilde etkiler. Uzun süre çalışan bir serviste bellek birikimi, haftalar sonra ortaya çıkan yavaşlamaya yol açar.
• Başlangıç süresi ve dağıtım biçimi. Sağlık kontrolü (health check) uç noktaları yoksa, bir servisin ayakta olup olmadığı ancak kullanıcı şikâyetiyle anlaşılır.

Veri erişimi ve veritabanı tarafı

Performansın en sık tıkandığı yer veritabanıdır, sunucu değil. Değerlendirmede sorulacak somut başlıklar:

• Sorgu davranışı. Arayüzde bir liste açıldığında kaç sorgu çalışıyor? Kayıt sayısıyla sorgu sayısı birlikte artıyorsa (bilinen adıyla N+1 problemi), sistem veri büyüdükçe yavaşlar.
• Bağlantı havuzu. Yoğunluk anında veritabanı bağlantıları yeniden kullanılıyor mu, yoksa her istek yeni bağlantı mı açıyor?
• Şema değişiklikleri. Sürüm yükseltmeleri veritabanı şemasını değiştiriyorsa, bu değişikliğin nasıl ve ne zaman uygulandığı tanımlı olmalıdır.
• Raporlama yükü. Ağır raporlar, işlem yapan kullanıcıları yavaşlatmadan çalışabiliyor mu?

Gözlemlenebilirlik: sahadaki sistem nasıl izlenir?

Kurumsal yazılımda "çalışıyor mu?" sorusu, kullanıcı söylemeden cevaplanabilmelidir. Bunun için üç şey aranır: Sahadaki donanımın arıza anındaki davranışı da yazılım kadar belirleyicidir; kiosk donanımı seçimi yazımızda güç ve ağ kesintisi senaryolarını ele aldık.

• Yapılandırılmış günlük kaydı. Hata anında ne olduğunu anlatan, aranabilir kayıtlar; düz metin dosyalarında kaybolan satırlar değil.
• Metrikler. İstek sayısı, yanıt süresi ve hata oranı gibi göstergelerin izlenebilmesi.
• Sağlık kontrolü uç noktası. Servisin kendi durumunu bildirmesi; izleme sistemi bunu belirli aralıklarla sorgular ve sorun kullanıcıya yansımadan haber verir.

Bu üçü yoksa, arıza her zaman müşteri şikâyetiyle öğrenilir ve tanı süresi uzar.

Kimlik doğrulama ve yetkilendirme

Kurumsal ortamda kullanıcı yönetimi, uygulamaya özel bir liste olarak kurulmamalıdır. Aranması gereken yetenekler:

• Kurumsal dizin desteği. Kullanıcı girişinin mevcut dizin (LDAP veya Active Directory) üzerinden yapılabilmesi; personel işe girdiğinde ve ayrıldığında ikinci bir liste güncellenmesin.
• Rol bazlı yetkilendirme. Kimin hangi ekranı görebileceğinin ve hangi işlemi yapabileceğinin rol tanımıyla belirlenmesi.
• Erişim kaydı. Kim ne zaman hangi veriye erişti bilgisinin tutulması; kişisel veri işleyen sistemlerde bu bir gereklilik haline gelir.
• Çok faktörlü doğrulama. Yönetim panellerine erişimde, tek şifreye ek bir doğrulama katmanı.

Sır yönetimi ve yapılandırma

Sahada en sık görülen güvenlik açığı, yapılandırma dosyasına yazılmış veritabanı şifresidir. Aranması gereken yaklaşım: hassas değerlerin kaynak koddan ve yapılandırma dosyalarından ayrı tutulması, ortama göre (test/canlı) farklı yapılandırma kullanılması ve sertifika ile şifrelerin düzenli döndürülebilmesi.

Test edilebilirlik

Otomatik testi olan bir sistem, değişikliğin yeni bir hata üretip üretmediğini hızlıca gösterir. Bunun altyapı koşulu, uygulamanın bağımlılıklarının dışarıdan verilebilir (enjekte edilebilir) tasarlanmasıdır.

Pratik soru şudur: tedarikçi, yükseltme veya değişiklik sonrası sistemi nasıl doğruluyor? Yalnızca elle test yapılıyorsa, her yükseltme bir risk kalemidir.

Dağıtım: Windows servisi mi, konteyner mi?

Yerel sunucuda çalışan bir uygulama, Windows servisi olarak kurulabilir veya konteyner içinde çalıştırılabilir. İki yaklaşımın pratik farkı şudur: konteyner, uygulamanın bağımlılıklarıyla birlikte paketlenmesini sağlar ve "benim makinemde çalışıyordu" sorununu azaltır; servis kurulumu ise mevcut bilgi işlem ekibinizin alışkın olduğu bir yönetim modelidir.

Seçim, kurumunuzun işletim alışkanlığına bağlıdır; belirleyici olan, dağıtımın tekrarlanabilir ve geri alınabilir olmasıdır.

Lisans maliyeti

.NET açık kaynaklıdır ve çalışma zamanı için lisans ücreti yoktur. Bu, bazı ticari platformlarda sunucu veya kullanıcı başına ödenen lisans kalemlerinin toplam sahip olma maliyetinden çıkması anlamına gelir.

Mevcut altyapıyla uyum

Kurumsal ortamlarda en yaygın istemci işletim sistemi Windows'tur. .NET tabanlı bir uygulama için ayrı bir sunucu filosu veya özel donanım gerekmez; mevcut bilgisayarlar istemci olarak kullanılabilir. Bu uyumun somut örneği sıra yönetim sistemidir; seçim kriterlerini ayrı bir yazıda topladık.

Bu, toplam sahip olma maliyetini doğrudan düşürür: yeni donanım yerine mevcut donanımın kullanılması, kurulum süresini ve saha maliyetini azaltır.

Bakım ve yetenek bulunabilirliği

Yazılımı ilk geliştiren ekip kadar, onu devralacak ekibin bulunabilirliği de önemlidir. .NET geniş bir geliştirici havuzuna sahiptir; bu, tedarikçi değiştirmeniz gerekirse sistemi devam ettirebilecek birinin bulunabileceği anlamına gelir.

Nadir bir teknolojiye bağlı sistemlerde bu esneklik yoktur: tek kaynaklı hale gelirsiniz. Bu yüzden tedarikçi değerlendirmesinde şu soruları sorun: kaynak koda erişim veya kaynak kodu emaneti mümkün mü, veriyi tam olarak dışa aktarma yolu var mı, ve projeyi devralacak bir ekip ne kadar sürede sisteme hâkim olur?

Tedarikçiden isteyeceğiniz teknik bilgiler

Ürün değerlendirmesinde özellik listesinin yanına şu bilgileri de isteyin:

• Kullanılan platform ve sürüm; sürümün destek bitiş tarihi
• Üçüncü taraf bağımlılıkların listesi ve lisansları
• Güvenlik güncellemelerinin hangi sıklıkta yayımlandığı
• Eşzamanlı kullanıcı ve kayıt hacmi için ölçüm sonuçları
• Yedekleme ve geri yükleme prosedürü; geri yüklemenin ne kadar sürdüğü
• Veriyi dışa aktarma biçimi ve yöntemi
• Bilinen sınırlar ve desteklenmeyen senaryolar

Bu bilgiler yazılı olarak alındığında, karar özellik listesine değil ölçülebilir kriterlere dayanır.

Ne zaman .NET doğru seçim değildir?

Dürüst olmak gerekirse her durumda değildir:

• Masaüstü istemcisi Apple ekosisteminde olacak bir kurum için Windows'a özgü masaüstü teknolojileri ek yük getirebilir. Sunucu tarafı .NET Linux ve macOS üzerinde de çalışır; kısıt, masaüstü istemci teknolojileriyle ilgilidir.
• Yalnızca birkaç statik sayfadan oluşan bir ihtiyaç için bu ölçekte bir teknoloji gereksizdir.
• Teknik ekibi olmayan ve yazılımı hiçbir şekilde kendi sunucusunda barındırmak istemeyen kurumlar için barındırılan (SaaS) çözümler daha uygun olabilir.

Bu durumlarda zorlamak yerine alternatifi değerlendirmek doğrudur. Teknoloji seçimi bir prestij meselesi değil, beş yıllık bakım planıdır.

Sıkça Sorulan Sorular

.NET 10 ne kadar süre desteklenir?

.NET'te çift numaralı sürümler uzun vadeli destek (LTS) kapsamında üç yıl, tek numaralı sürümler standart destek (STS) kapsamında on sekiz ay desteklenir. .NET 10 bir LTS sürümüdür. Yükseltme planı bu destek penceresi kapanmadan yapılmalıdır; sonrasında yükseltme zorunluluk haline gelir ve aceleyle yapılan yükseltmeler en riskli olanlardır.

Sürüm yükseltmesi neden riskli?

Çünkü yükseltme yalnızca uygulama kodunu değil, üçüncü taraf bağımlılıkları ve veritabanı şemasını da etkiler. Bağımlılık envanteri, kırıcı değişiklik taraması, test ortamında gerçek veriyle doğrulama ve geri dönüş planı olmadan yapılan yükseltmeler risklidir. Bu adımlar yazılı bir plana bağlanmadığında yükseltme, çalışan sisteme dokunma korkusuna dönüşür.

Bir arızadan nasıl zamanında haberdar olunur?

Kullanıcı şikâyetini beklemeden haberdar olmanın yolu üç yetenektir: sağlık kontrolü uç noktası, yapılandırılmış günlük kaydı ve metrikler. Sağlık kontrolü uç noktasını izleme sistemi belirli aralıklarla sorgular ve sorun kullanıcıya yansımadan haber verir. Bu üçü yoksa arıza her zaman müşteriden öğrenilir ve tanı süresi uzar.

.NET için lisans ücreti ödenir mi?

.NET açık kaynaklıdır ve çalışma zamanı için lisans ücreti yoktur. Bu, bazı ticari platformlarda sunucu veya kullanıcı başına ödenen lisans kalemlerinin toplam sahip olma maliyetinden çıkması anlamına gelir. Lisans kalemi düşse de toplam maliyet bakım, sarf ve operasyon kalemlerini içermeye devam eder.

Sonuç

.NET tabanlı kurumsal yazılım; öngörülebilir güvenlik güncellemesi, eşzamanlı yük altında kararlılık, mevcut Windows altyapısıyla uyum ve devredilebilirlik sağlar. Değerlendirirken özellik listesinden önce şu soruyu sorun: bu sistemi beş yıl sonra kim, nasıl güncelleyecek?

Bu soruya verilecek cevap üç başlığa dayanır: kullanılan sürümün destek takvimi, yükseltmenin yazılı bir plana bağlı olması ve sistemi devralabilecek bir geliştirici havuzunun bulunması. Bu üçü sağlanıyorsa teknoloji tercihi, kurumun beş yıllık bakım yükünü hafifletir.

Ürünlerimizin teknik altyapısı için ürünlerimize, sektörünüze uygun kurgu için çözümlerimize bakabilirsiniz.