Teknoloji Modernizasyon Sürecimiz
Teknoloji güncelleme ve modernizasyon isteğimiz ile gerçekleştirdiğimiz çalışmaları artık tamamladık ve çalışmaya açtığımız için artık paylaşma kararını aldık . Bu çalışma aslında çok uzun zamandan beri üzerinde planladığımız bir durumdu. Bu nokta teknoloji olarak kullandıklarımız ve başımıza gelenleri burada kısaca paylaşmak istiyorum. Bir teknolojiyi tercih ederken diğerini neden tercih etmediniz soruları hep olacaktır, bizde de olmaya devam edecektir. Ancak her zaman bir tarafın diğer tarafa göre bir kötü yanı bulunurken üstün yanları olduğunu da düşünmek gerekiyor. Burada ütün yönden kastım tabiki sizin senaryonuzda işinize yarayacak bir özelliktir bu. Bunun için zaten pros cons , benchmark çalışmaları bu aşamada bizi bir noktaya doğru itti.
Mevcutta kullanmakta olduğumuz monolithic yapının kademeli olarak terk ederek yeni oluşturduğumuz microservice yapısına geçişini sağlamak motivasyonu ile yola çıktık. Bunun sebebi hem sistemi optimize etmek hemde faklı müşteriler için ürünün kurulması gereken durumlarda istenilen modülün ayrı bir ürün olarak çalıştırılabilmesi gibi nedenler vardı. Her iki mimarinin de bazı avantajları ve dezavantajları vardır. Burada mimari seçimi aslında çözülmesi gereken soruna bağlıdır. Yürütülen yük testleri, bir uygulamanın daha fazla sayıda isteği işlemesi gerekiyorsa, Mikro hizmet mimarisinin daha verimli olduğunu göstermiştir. Ölçeklenmesi kolay, daha güvenilir ve uzun vadede bakımı daha kolay olan yüksek kaliteli bir yazılım oluşturmaya izin verme gibi pek çok avantajı vardır.
Tabi bu aşamada öncelikle bu uzun yolculuğu planlamakla geçti. Seçeceğimiz teknolojinin kullanım yöntemine kadar vermemiz gerekiyordu. Microservice mimari ile devam edecektik ve buna göre yolumuzu seçmeliydik. Yöntem olarak choreography veya orchestration yollarından birini izlememiz gerekiyordu. Yani mikro uygulamalarımız ve servislerimiz bir orkestra mantığı ile orkestra şefinin yönetimi ile mi devam edilecek, yoksa dans ekibinin bir karegrofi mantığı, yani event brocker ile mikroservisin mesajı gönderdiği anda işini tamamlayacağı şekilde mi olmalıydı. Bizim düşüncemize göre mikroservisler kareografiye göre çalışan dansçılar gibi aynı kareografinin aynı yerinde aynı davranışı göstermelidir.
Distributed uygulamalarda herbir context’in veritabanı farklı DB lerde olacaktı ki raporlama veri tabanını doğru tasarlamak ve ardından brocker’daki her datayı okuyan ve raporlama veri tabanına doğru bir şekilde güncelleyen bir ana dinleyici yazmak gerekiyordu. CAP teoremine göre düşünüldüğünde tutarlılık (consistency), ulaşılabilirlik (availability) ve bölünebilme toleransı (partition tolerance) koşullarında 3 noktadan 2'sinden fazlasını sağlamının imkanı yoktur. Dağıtılmış hiçbir sistem ağ arızalarına karşı güvenli değildir. Raporlama veri tabanını doğru tasarlamak ve ardından brocker’daki her datayı okuyan ve raporlama veri tabanına doğru bir şekilde güncelleyen bir ana dinleyici yazmak gerekiyor. Tabi bu veri tabanları ihtiyacına göre NOSQL ya da RDBMS’de olabilir. Bu arada karar verdiğimiz önemli konu bu ilişkileri oluşturma yöntemini belirlemek oluyor. Yani raporda göstereceğimiz bir column değeri A DB den alınmalı, diğer comumn’lar B DB den alınarak join edilmeli. Bu durumda join edilecek veri prostre , mongo vs. DB arasında olacağı için bir yöntem belirlemek gerekiyor. Burada tercihimiz “Event Push Model with Dedicated Database” ile rapor için bir db oluşturup ilgili microservice’ten event brocker ile data match edilmesi oldu.
Bu çalışmaya karar vermek ve kurgulamak ta tahmin edileceği üzere ciddi bir çalışma ve mimari çalışmalardan geçti. Bunun sonucunda ortada ne kadar yeni teknoloji varsa kullanalım mantığına kapılmadan biz ne yapıyoruz ihtiyaçlarımız nelerdir, bunları belirleyerek başlamamız gerekiyordu.
Tabi ki öncelikli olarak büyük bir kadroda kod kalitesinin arttırılması, kod güvenlik kontrollerinin bir otomasyondan geçmesi, unit testlerinin yapılarak özellikle multi tenant güncelleme geçişinin farklı tenant işleyişini etkimediğinden emin olma , sistem requirement artması durumunda self scale edilebilecek, yaşayan ve kendini koruyup optimize eden bir ekosisteminin yaşama geçmesi , sistemsel takiplerin arttırılması ve anlık takipler ile destek eforunun optimize edilmesi, sahaya çıkan ve perseverance misali marsa indirilecek olan cihazların:) kendi hayatını desteğe ihtiyacı olmadan sürdürebilmesi ve Huston’a bir sorun olduğunda iletebilmesi ve bu haberleşme sırasında anlık latency veya network sorunlarının yaşanması durumunda veri kaybını tamamen ortadan kaldırmak için haberleşme protokollerinde consumer/publisher yapılarına geçerek gerekli exchange yapılarının kurulması gerekliliğinin bilincineydik. Yani mevcut hayatımızda bulunduğumuz süreçte buna ciddi anlamda ihtiyacımız bulunmaktaydı. Message Queue Telemetri Transport veya MQTT, şu anda IoT dünyasında de facto standart iletişim protokolü olarak kabul görüyor. Basit, hafif, bant genişliğine sahip ve düşük güç tüketiminin şart olduğu cihazlar için ideal.
Tabi bu geçişi yaparken veya yaptıktan sonra oluşabilecek sorunlara maalesef pek toleransımız olamıyor çünkü örnek olarak şehir için bir ulaşım aracına bindiğinizde ulaşım kartını okutma sırasında 2–3 sn. bekletme şansımız yok. Günde 1 milyardan fazla transaction yönetilen bir sistemin geçişi olacağı için ve 20TB ye yakın günlük oluşan veriden bahsedilince bu konunun ciddiyetini arttırıyor. Tabi olabilecek tüm kötü senaryoları değerlendirerek iş parçalarını ve geçişleri olabildiğince parçalayarak ve onay alındıktan sonra bir sonraki aşamaya geçecek şekilde planlamalarımızı yaptık. Buna yardımcı olması için ayrıca haberleşme paketlerinin olabildiğince küçük ve asynchronous olması gerekiyordu. Bu gibi durumlar için backend ve cihazlar arasında haberleşme için TCP ve UDP yerine proto dosyaları ile protokol oluşturularak gRPC kullanılmasına kadar verdik. Backend tarafında veri ise komut ile sorgu işlemleri birbirinden ayrımı CQRS pattern kullanarak aştık.
Her yazılım sistemi içinbir model belirlenmiştir. Tabi bu model eğer ortak dili konuşmanızı sağlayacaksa daha da önem kazanır. Model, geliştiricinin kafasındakiler olarak düşünülebilir. Bunu ortak dile dönüştürmek için bounded contextleri belirleyip bu iş alanlarına göre model(Domain Driven Design = DDD) oluşturmak önem az etmeye başladı. Özellikle yurt dışından gelen proje yöneticileri öncelikli olarak DDD ile çalışılıyorsa bounded contextleri görmeyi talep ettiğini belki sizlerde yaşamışsınızdır. Bu ortak dile kavuşmak ve daha girift ve sinerjik çalışmanın ortamını sağlar. Dolayısı ile bu yolda ilerlemeye devam ettik.
DevOps yönetimi için çıktığımız yolda GitLab ve Gitlab CI kullanmayı tercih ettik. Projelerimiz için Pipeline’lar bu ortamda oluşturuldu. Tabi QT, dotnet core ve dotnet framework vs için farklı pipeline’lar oluşturuldu. Bunları base ve inherit yml kurguları ile projede ihtiyaca yönelik hızlı kurulum sağlayarak çalıştıracak şekilde hazırladık. Kullandığımız stegelerde kod kalitesi ve güvenliği kontrolü için Sonarqube ve Clair kullandık. Pipeline stages artifact barındırmak için Nexus repository manager kullanarak NuGet, Maven package ve docker imageları burada barındırılmaya başladık. Helm chartların tanımlanması ile kubernates worker’ların üzerinde çalışan container’ların ingress kurallarını tanımladık. Pipeline da stagelerin çalıştığı sunucuların kurulumları için playbook’ları yazılarak Ansible ile kurulumları sağlandık.
Önyüzde Angular framework kullanmayı tercih ettik. Bunun yerine React’ı da tercih edebilirdik ancak ek kütüphane gerektirmemesi ve tam teşekküllü , en olgun framework olması Angular’ı tercih etmemize neden oldu.
Aşağıdaki trendleri de değerlendirdik;
Vue jobs, React jobs, Angular jobs — Keşfedin — Google Trendler
Bu yukarıdakiler artık yaşayan bir sistem, ekosistem yola çıktı ve konteynerleri yüklenmeye başladı…
Kullandığımız ve yukarıda adı geçen başlıca teknolojileri aşağıdaki gibi paylaşabilirim;
