Web-masaüstü uygulamasından SaaS’a

Bir tebliğ ile 2010 yılında geliştirilmeye başlanılan uygulamaya 2 yıl sonra 2012'de dahil oldum. 2010 yılına kadar uygulama isteğe bağlı iki müşteri tarafından kullanıldığı için talepler doğrultusunda şekilden şekle girmiş durumdaydı. Kullanılmayan bir çok fonksiyonelite ve kodlar mevcuttu. Uygulama aslında bir web uygulamasıydı ancak işlem süresi uzun olduğu için bazı istekleri masaüstü bir uygulamaya TCP/IP protokolüyle iletiyordu.

2012 yılında yayınlanan bir tebliğ ile bazı şirketlere zorunluluk geldi, müşteri sayısı hızla artacaktı. Çözümün o zamanki belli başlı sorunları:

• Web uygulaması masaüstü uygulamaya erişmediğinde veri kaybediyordu.
• Masaüstü uygulama hata aldığında veri kaybediyordu.
• Tek bir masaüstü uygulamaya bağlandığından yatayda büyütülemiyordu.
• Hata yönetimi liste kutusuna yazılan metinlerden ibaretti.
• Kurumsal yapılarda çalışabilmesi için AD, LDAP desteği yoktu.
• Kurumsal müşteriler güncel olmayan tarayıcı ve işletim sistemleri kullanıyordu, birçoğu sadece IE’ye izin vermekteydi. Bu nedenle arayüzde sıkıntılar vardı.
• Yetkilendirme bir çok kısımda eksikti.
• Dokümantasyon eksikti (Kullanıcı, kurulum, uyarlama ve entegrasyon).
• Versiyon yönetimi yoktu ancak kodlar TFS’deydi.
• Tüm kritik ve kritik olmayan süreçler aynı uygulama içinde çalışıyordu.
• Web ya da masaüstü uygulama hata aldığında tüm sistem duruyordu.
• Şirket şimdiye kadar sağlam bir framework üzerinde (SAP NW) geliştirme yaptığından genel yazılım geliştirme tecrübesi zayıftı.

Bazılarınızın tahmin edebileceği gibi iş, e-fatura ile başlayan elektronik dönüşüm projesiydi. Konuya uzak olanlar için özetlemek gerekirse;

• Kuralları bir devlet kurumu tarafından koyulmakta ve haber vermeksizin değişiklik yapılabilmekteydi.
• Müşteri sistemlerinden çeşitli formatlarda veri almak/göndermek gerekliydi.
• Müşteriden sisteme, sistemden devlete, devletten sisteme, sistemden de müşteriye doğru giden ve gelen bir entegrasyon projesiydi.
• Asenkron şekilde yürüyen bir entegrasyondu.
• Geriye dönük verilerde güncelleme ihtiyacı vardı.
• Konu fatura-muhasebe-finans olduğu için kritik görülüyordu, sistemin 7/24 ayakta ve işler olması beklenmekteydi.
• Veriler elektronik olarak imzalı olduğundan tekrar üretilmesi imkansızdı, bu nedenle veri kaybının 0'a yakın olması gerekiyordu.

Çalışmaya başlarken yazılı olmasa da 2 temel kuralımız vardı;

• Müşteriye özgü versiyon oluşturulmayacak tek bir ürün olacaktı.
• Web uygulamasında 30 saniyeden uzun süren hiç bir süreç çalıştırılmayacaktı.

Halihazırdaki uygulama yeterince karışık olduğundan teknik borçlanmayı göze alarak uygulamanın önüne müşteri ve devlet kurumu ile iletişimi sağlayacak, gerekli veri dönüşümlerini yapacak bir uygulama yazmaya karar verdik. Bu uygulamayı yazmadan önce Biztalk gibi hazır alternatiflerini de değerlendirdik. Uygulama aşağıdaki görevleri yerine getiriyordu;

• Devletten gelen SOAP isteklerini karşılamak.
• Müşteriden gelen SOAP ve Http Post isteklerini karşılamak.
• Windows ortamındaki klasörleri takip ederek sürece dahil etmek.
• Txt, Csv, Excel, PDF, Xml gibi formatlarda gelen veriyi işlemek ve ortak bir formata dönüştürmek. Gerekliyse eksik verilerini tamamlamak.
• Ortak bir formatla sistemlerimizden gelen veriyi müşterinin isteğine göre Txt, Csv, Excel, PDF, Xml gibi formatlara dönüştürerek isteyen müşteriye Http Post veya SOAP ile iletmek ya da FTP üzerinden alabilmeleri için ilgili klasöre bırakmak.

Konektör olarak isimlendirdiğimiz bu uygulama, gerek devlet gerekse müşteriler hisetmeden asıl süreçleri yöneten diğer uygulamaları güncellememize, yeniden başlatmamıza imkan sağlamıştı. Konektör yatayda büyüyebilecek şekilde tasarlanmıştı.

İlerleyen dönemlerde Apache Camel gibi ek araçlar kullanarak müşteriye özgü farklı özel entegrasyonlara da destek verme imkanımz oldu.

Konektör geliştirilirken bir taraftanda masaüstü uygulama Windows servise çevrildi, web uygulaması ile windows servis veri tabanı üzerinden asenkron çalışacak hale getirildi. Hata yönetimi geliştirildi ve günlüklerin önce veri tabanına olmazsa sabit diske o da olmazsa Olay Görüntüleyici’ye yazılması sağlandı. Süreç bazlı da olsa test sınıfları yazılmaya başlandı. Test sınıfları yeni başlayan arkadaşların süreç bilmeden hata ayıklamasında büyük kolaylık sağladı.

Bu süreçte şirket büyük bir holdingin işlerini aldı ve onların IT şirketi ile beraber çalışılma kararı alındı. Holding IT şirketi yazılım geliştirme metodolojilerine hakim olduğundan bizlere çok şey kattı. Uygulamanın ilk dokümantasyonları oluşturuldu, yol haritaları çıkarıldı, müşterilerden gelen isteklerin değerlendirilip uygulamaya dahil edilip edilmeyeceğine karar verilen toplantılar yapılmaya başlandı.

6–8 aylık süreçte geliştirmeler devam ederken, Türkiye’nin en büyük ilk 500 şirketi arasında yer alan 70–80 firma canlıya alındı. Aynı süreçte e-defter zorunluğu da başlamıştı. Aynı uygulama içine bu çözümde birleştirilerek tek versiyon hedefi korundu.

Yıl 2015 olduğunda devlet özel entegratörlük kavramını çıkardı. Bu kavram, şirketlerin tek tek devlete entegre olması yerine ortak bir platforma entegre olması, oradan devlete entegre olması şeklindeydi. özetle SaaS uygulamasıydı.

Kaynak: https://www.computenext.com/blog/when-to-use-saas-paas-and-iaas/

Uygulamamız canlı kullanıma başlanıldığından beri multi tenant bir yapıya sahipti. Her bir tenant için ayrı veri tabanı oluşturuluyordu. Diğer ortak veriler için farklı veri tabanları da mevcuttu. Operasyonel borçlanma (teknik borçlanma gibi operasyonel insan kaynağına borçlanma) yapılarak bu işler manuel yürütülüyordu.

Aynı veritabanından birden fazla olması güncelleme sürecinde zorluk çıkarıyordu çünkü işlem manuel yapılmaktaydı. Ancak aşağıdaki avantajları nedeniyle kullanılmaya devam edildi:

• Farklı veri tabanı sunucularına taşınabilmesi.
• Yoğun veri trafiği olan şirketlerin, diğer şirketleri daha az etkilemesi.
• Şirketlerden sadece bir kaçının devreden çıkarılabilmesi.
• Paas modelinden Saas’a sadece veri tabanı taşınarak minumum kesinti ile çalışmaya devam edilebilmesi.
• Yedek alma sürecinin tüm sistemi etkilememesi.
• İsteyen müşterinin veri tabanı şifreleme özelliklerinden yararlanabilmesi.

SaaS modeliyle hizmet verilmeye başlanması ile birlikte yeni ihtiyaçlar doğdu;

• Entegrasyon yapacak yazılım firmalarına farklı dillerde örnek projeler hazırlama
• Destek sistemi oluşturma
• Uzaktan eğitim ve destek
• Borç çıkarma(charging)
• Faturalama (billing)
• Hizmet durdurma
• Ödeyene göre fatura birleştirme
• Çeşitli tarayıcılarla çalışma

SaaS uygulaması ile birlikte daha önce müşteri sistemlerinde ve özel bulut (private cloud) ortamında çalıştırdığımız uygulamalarımızı daha geniş ölçekli olarak veri merkezinde sanal sunucular üzerinde çalıştırmaya başladık. Daha öncesinde pek ilgilenmediğimiz veri merkezi tarafı yoğun yük altında her tökezlediğinde yeni şeyler öğrendik, geliştirmeler yaptık. Sanal sunucular ile ilgili önemsiz görünen ama can sıkıcı bazı başlıklar şöyle;

• RAM erişim hızları fiziksel bir makinaya göre çok düşük.
• İşlemcilerin saat hızları genelde düşük.
• Dikey olarak büyüme imkanı sınırlı.
• Diskler sanal, hatalı bir silme yaptığınızda ya da teknik olarak sanal diskler silindiğinde fiziksel verinin nerede olduğunu bulup kurtarmak imkansıza yakın.

Sanal disk olayı için detay vermek gerekirse; Uygulama içinde verdiğiniz kaydet komutu ya da veri tabanındaki commit ile bir veri fiziksel diske yazılmadan önce aşağıdaki önbelleklerde bekliyor:

• İşletim sisteminin ön belleği.
• Sanallaştırma yazılımın ön belleği.
• Sanallaştırma yazılımının çalıştığı işletim sisteminin ön belleği.
• Disk ünitesinin işletim sisteminin ön belleği.
• Disk ünitesinin kontrol kartının ön belleği.
• Fiziksel diskin ön belleği.

Veri kaybedebileceğiniz bir çok nokta olmasına rağmen bu bilgiyi veri merkezlerinden genelde alamazsınız. Verimiz kritik olduğu için aynı veri 3 farklı noktada farklı geçici sürelerle saklanıyordu:

• Başarılı olsun olmasın tüm gelen ve giden veri, dosya sistemine kaydediliyordu.
• Konektör uygulamasının veri tabanında bir kopyası bulunyordu.
• Müşterilerin her birinin veri tabanında kalıcı olarak bulunuyordu.

TFS içinde branch almak ve eski versiyonlarda hata gidermek zor olduğu için 2017 yılında kodlar git ortamına taşındı.

Bulutta ve müşeri tarafında koşan uygulamaların sağlığını kontrol etmek en büyük sorunlardan biriydi. Bulut tarafı tamamen bizim kontrolümüzde olduğu için bir nebze kolay olsada, müşteri tarafındaki sunuculara erişmek pek kolay olmuyordu. Bu amaçla logların merkezi bir sistemde toplanmasının uygun olacağını düşündük. O yıllarda uygulama loglama konusunda Graylog daha yeni yeni gelişyordu. Sistem seviyesinde yaygın olarak Zabbix kullanılmaktaydı. Müşteri sistemlerinden günlükleri anlık olarak çıkmak da pek kolay görünmüyordu. Çözüm olarak SNMP kullanmayı düşündük. Müşteri tarafından da firewall cihazlarında kolay ayırt edilebilmesi için şirketin adına 1.3.6.1.4.1.47009 numaralı OID’i kayıt ettirdik. Böylece güncel firewallardan bakıldığında giden paketin kime ait olduğu kolayca anlaşılabiliyordu. Görünebilir olması müşterilere güven vermişti. Her ne kadar günlükleri merkezi bir sistemde toplayabilsekte yeterince işleyip otomatik aksiyon alabilir hale gelemedik.

Uygulamayı yatayda daha kolay büyütebilmek ve süreçlerden kaynaklı hataların bir birini etkisini azaltmak için micro servis tabanlı mimariye geçmeye başladık. Bağımsız süreçleri ayırarak REST servisler olarak yayınlamaya başladık. Bu konuda bizi en çok geliştirici kalitesi zorladı. Ekibe yeni katılan ya da junior arkadaşların sistemi anlamları, debug etmeleri ya da test kodlarını çalıştırmaları zorlaştı.

2018 yılına gelindiğinde SaaS uygulamasını 650 şirket 5.000 kullanıcı ile kullanmaktaydı. Sadece SaaS uygulamasında aylık 8 milyon fatura işlenmekteydi. Saas ve Paas uygulaması tek versiyon olarak kalmaya devam etti. 8. kişi olarak işe başladığım şirket 70 kişiye kadar büyümüş, bilişim 500 sıralamasında 246. sıraya kadar yükselmişti .

Şirket, 2018 yılında en büyük rakibine satıldı ve ürünler çalışmaya devam ediyor.