Monolitik Uygulamadaki Modüllerin Bağımsız Hizmetlere Dönüşümü

Bu yazıda monolitik yapıdaki uygulamamızda yaşadığımız sorunlardan ve bu uygulamadaki kullanıcı paneli modülünün uygulama içerisinden çıkarılıp yeni modern bir önyüz ve servis olarak yeniden düzenleme sürecimizde karşılaştığımız zorluklardan ve izlediğimiz yöntemlerden bahsedeceğim.

Bu değişimi gerçekleştirmeden önce, farklı kullanıcı kanalları için farklı modlarda çalışacak şekilde dizayn edilmiş, farklı makinelerde barınan monolitik bir uygulama üzerinden hizmet vermekteydik.

Dönüşüme neden ihtiyaç duyduk?

Scrum metodolojisini uygulamaya başlamamızla birlikte teknoloji ekibimiz farklı kullanıcı kitlelerine hitap eden ve farklı hedeflere koşturan ayrı takımlar haline gelmişti. Farklı takımların aynı uygulamada yazılım geliştirmesi gerekiyordu. Dolayısıyla takımlar ayrışmış olsa da birbirine bağımlılık sürüyordu.

Önyüzde yapılan en ufak bir kelime değişikliği için bile tüm uygulamanın deploy edilmesi gerekmekteydi. Yazılım geliştirme sürecinde farklı ekiplerin değişiklikleri birbirinden etkilenebilir ve bir fonksiyonalitede yapılan değişiklik başka bir noktada istenmeyen bir sonuç ortaya çıkarabilirdi. Dolayısıyla kontrollü ilerlenmeli, test sürecinde olası sorunlar saptanarak bunun yaşanmasının önüne geçilmeliydi. Statik class’lardan oluşan bir uygulama olduğu için unit test yazmak da oldukça zor oluyordu, eksik testlerden dolayı yapılan hataları düzeltmek iyice maliyetli hale gelmişti. Ayrıca aynı proje üzerinde yazılım geliştirilmesi bağımlılıklar sebebiyle beklenenden daha fazla zaman alabiliyordu. Takımların geliştirdiği yeni feature’lar nedeniyle de uygulama gün geçtikçe büyüyerek yönetilmesi daha da zor hale gelmişti.

Yönetilmesi zor, birbirine birçok noktada bağımlı, yeni teknoloji kullanma imkanı olmayan bu uygulama yerine mevcut yapının farklı amaçlara hizmet edecek uygulamalar olarak ayrıştırılması gerekliliği ortaya çıkmıştı.

Dönüşümü nasıl gerçekleştirdik?

Yazılım yaşam döngüsünün ilk adımı olan analizle sürece başladık. Mevcut yapı analiz edildi ve ayrıştırılması gereken fonksiyonalite, API ve metodları tespit edildi. Müşterilerin yeni uygulamaya geçiş süreci planlandı ve yol planı hazırlandı.

Bu dönüşüm planı ile birlikte bağlı olduğum takımın sorumluluğundaki fonksiyonaliteyi ayrı ve modern uygulamalarla sunar hale gelecektik. Backend servisi olarak .NET Core MVC framework’ünü kullanan bir uygulama oluşturduk ve takımın sorumlu olduğu kanaldaki tüm fonksiyonaliteyi sağlayacak yeni metotlar geliştirdik. Önyüz için React kullanan farklı bir client uygulaması oluşturduk. Böylece hem ekip olarak yeni bir teknolojiyi projeye kazandırmış olduk, hem de kendimize yeni bir gelişim alanı oluşturduk. Önyüz componentlerini mevcut UI tasarımını mümkün olduğunca koruyacak şekilde geliştirdik. Böylece müşteri memnuniyetinin olumsuz etkilenmemesini amaçladık.

Dönüşüm sürecinde uygulamalarımızda bazı gelişme noktaları gördük. Bu geliştirme noktalarından örneğin UI’daki ufak tefek değişiklikler, UI’da tasarım iyileştirmesi gibi olsa iyi olur olmasa da olur dediğimiz işleri listeleyip fonksiyonaliteyi daha çabuk şekilde sunarak, müşteri memnuniyeti yaratma adına daha sonrasına bıraktık. Bu sebeple de bir sonraki dönem planlamamıza düşük bir eforla da olsa ertelediğimiz bu işler için maddeler almamız gerekti.

Bunlara ek olarak ekipten rotasyonla başka takıma geçenler, işe yeni başlayanlar olmasıyla projenin çekirdek kadrosunun değişmesi tüm bu süreçte yaşadığımız diğer bir zorluk olarak karşımıza çıktı. Ancak şirketimizde hoşgörülü yaklaşım, takım olarak çalışmamız ve oryantasyon süreçlerimizle bu sorunu da aşmayı başardık.

Dönüşüm sürecinde neler yaptık?

Authentication yapısını geliştirdik ve uygulamamıza dahil ettik.

Bu dönüşüm ile beraberinde, önceden planlamış olduğumuz authentication yapısını geliştirerek yeni uygulamamız içerisinde kullanmaya başladık. Kullanıcı bilgileri eski uygulamada link üzerinden alınan değerler ile belirleniyordu, yeni uygulamamızda token ile doğrulama yöntemini uyguladık. Ancak yeni uygulamada giriş yapmış kullanıcının bilgilerini, token ile doğrulama gerçekleştirmeyen sistemdeki başka bir uygulamaya iletmemiz gerekiyordu. Bunu sağlamak için mevcut diğer uygulamaya geçildiği noktada, ilgili token’ı işaret eden bir key üreterek mevcut diğer uygulamanın da erişebileceği ortak bir alanda bu key ile birlikte kullanıcının oturum bilgilerini saklayacak, yönlendirdiğimiz link içerisine parametre olarak bu key bilgisini ekleyecek ve link açıldığında ise bu key ilişkili oturum bilgisi ile token bilgisini karşılaştırarak kullanıcıyı doğrulayacak geliştirmeler yaptık.

Bu dönüşüm planının kapsamına almadığımız raporlama modülümüzün çalışmasını sürdürebilmek için de bazı geçici çözümler uyguladık. Raporlama uygulamamızda şifre ile oturum açılan bir sayfamız bulunuyordu. Hem kullanıcı ekranında hem de içerisinde bulunan raporlama sayfalarında iki farklı oturum açma işlemi olması müşteri deneyimini kötü etkileyeceğinden raporlama uygulamasındaki oturum açma sayfasını bypass etmemiz gerekiyordu. Raporlama uygulamamızın token ile doğrulama gerçekleştirebiliyor olması nedeniyle kullanıcının token değerini rapor sayfalarının isteği içerisine ekledik ve iframe içerisine yerleştirdik.

Hem iş ortaklarının kendi sitelerinde hem de içerisinde bulunan kullanıcı ekranlarımızda iki farklı oturum açma işlemi olması deneyimi kötü etkileyeceğinden yeni uygulamamıza iş ortakları eriştiğinde oturum açma sayfasını bypass etmemiz gerekiyordu. Bunun için ilk olarak iş ortaklarımız hem kendilerini doğrulamaları hem de kullanıcılarını doğrulamalarını sağlayacak authentication metotlarımıza entegre oldular. İş ortaklarımız kendi sitelerinde, iframe içerisine yerleştirme veya yeni sekmede açma şeklinde iki yöntem ile bizim uygulamamızı kullanıyorlardı. Iframe içerisinde açan iş ortaklarımız için authentication servisimizden aldığı token’ı iletmesi ve uygulamamız tarafında kabul edilip kaydedebilmemiz için EventListener yapısını ekledik. Bunu gerçekleştirirken kullanabilecekleri örnek önyüz kodunu da dokümantasyonda paylaştık. Ayrıca geliştirmelerimiz sırasında kontrollerimizi sağlayabileceğimiz bir iframe test ortamı oluşturduk. İkinci bir yöntem olarak ise linkteki parametre içerisinden alınan değer ile oturum bilgisini doğrulayıp sonrasında parametreyi linkten kaldırarak uygulama sayfasına yönlendirdik.

Müşterilerimizi yeni uygulamamıza yönlendirdik.

Müşterilerimizde eski uygulamanın linki vardı ve müşterilere yeni uygulamayı kullandırmamız için bu link üzerinden yeni adrese yönlendirmeyi sağlayacak işler yapmamız gerekti. Hem kullanıcı ekranı hem de raporlama modülünde, açılan sayfanın path’ine göre yeni uygulama sayfasına yönlendirecek bir filter yazdık.

Kazançlarımız ne oldu?

• Takımın codebase’i ayrıştırıldı. Takımların daha verimli ve hızlı bir şekilde çalışması sağlandı. Yeni feature’ler bağımlılıklara takılmadan kolaylıkla geliştirilebilir hale geldi.
• Takımın codebase’inin ayrıştırılmasıyla takımda çalışmaya yeni başlayan arkadaşlar, codebase de kaybolmadan kolay bir şekilde adapte olabildi.
• Daha modern ve gelişime açık bir sisteme geçildi.
• Bağımlılıklar azaltıldı, oluşabilecek hataların önüne geçildi.
• Herhangi bir değişiklikte tüm sistemin deploy edilmesi yerine sadece ilgili servisin, uygulamanın deploy edilmesi sayesinde sistemdeki farklı kanalların etkilenmesi riski azaltıldı.
• Modüler bir sisteme geçilmesi, bu yapıyı saas olarak sunma yönünde bir vizyon ve altyapı sağladı.
• Detaylı test / analiz süreçlerinin işletilmesi, test otomasyon ve unit teste uygun bir yapı oluştu.

Bu dönüşüm sürecinin devamında ne yapmayı hedefliyoruz?

Diğer modüllerimizin önyüzünü de yeni sistemimize geçirerek bağımlılıklarımızı azaltmak ve client uygulamalarındaki iframe kullanımını da kaldırarak yaşanabilecek sorunlardan kurtulmayı hedefliyoruz. Bunların yanında backlog’daki UI / UX iyileştirmelerine efor harcamayı hedefliyoruz.

Tüm müşterileri yeni sisteme geçirmek için oluşturulmuş bir yol haritasını yürütüyoruz. Böylece tamamen geçiş sağlandığında eski uygulamayı sürdürmek için ekstra efor harcamamız gerekmeyecek.

Tüm müşteriler yeni uygulamayı kullanır duruma geldikten sonra, ana uygulamadaki kodları temizlemeyi hedefliyoruz. Ana uygulamada bunun gibi başka modüller de tespit ettik, onları da monolit içinden çıkarmayı hedefliyoruz.