Microservis dönüşüm projelerini destekleyen değişim dinamikleri
Değişmeyen tek şey değişimin kendisidir boşuna söylenmemiş. Sürekli bir değişim içerisindeyiz. Yazılım alanında ise insan hayatı için çok kısa denebilecek zaman aralıklarında bile çok büyük değişimler yaşanıyor. Zaman içerisinde uygulamalarımızda eskiyor günün ihtiyaclarının gerisinde kalıyor hatta uygulamayı geliştirğimiz teklonojiler eskiden herkesin ulaşmak istediği seviyede iken bir gün artık kimsenin kullanmadığı, destekleyecek insan bulmakta zorlandığınız bir hale bürünüyor. Bu durumda mevcut operasyonunuzu yürütmekte ve destekelemekte zorluklar yaşamaya başlıyorsunuz.
E-ticaret sistemimiz distributed monolith diye tariflenen dışarıdan bakıldığıda servislerden oluşan ancak ortak veritabanı ve code base kullanımı olan bir yapıda idi. Bu yapı bizi birçok alanda zorluyordu. Zaman içinde microservis dönüşümü kapsamında yapılan iyileştirmelerin kazanımlarını dört temel eksende gözlemledik. Sürdürülebilir değişim, yeni teknolojilerden faydalanmak, yetenek ve kültür ve risk yönetimi. Bu konulardan kısa kısa bahsetmek istiyorum.
1- Sürdürülebilir Değişim: Eski yapımızda sürüm yapmak zor ve riskli idi. Bu sebeple de gece 0400 de haftada iki kez planlı sürüm yapıyorduk. Sonraları takım iyice yıprandığı için bunu haftada bire indirdik. Bu durumda en ufak bir değişiklik için bir hafta beklediğimiz durumlar ortaya çıktı. Haftada bir yapılan sürümlerdeki değişiklik sayısı fazla olduğu için testlerimizin maliyeti de artıyordu. İstemesekde gözden birşeylerin kaçıp hata oluşturma riskimiz artıyordu. İşin kötüsü sürm sonrasında hataya hangi değişikliğin yol açtığının tesbiti de bir o kadar zor oluyor kesinti süreleri uzuyor idi. Şu an takımlar servisleri için kendi repolarını kullandıkları ve burada değişiklik yaparken farklı takımlara ihtiyaçları olmadığı için hem çok daha sık hem de çok daha sağlıklı sürümler yapabiliyoruz. Planlı sürümü uzun bir zaman önce hayatımızdan çıkardık. Takım / Servis bazlı repo kullanımı olduğu için takımlara kod kalitesi, code smell, unit test , test covarage gibi hedefleri verebiliyoruz.
2- Teknolojiden Faydalanmak: Eski yapımızda .Net Framework, MS SQL Server, Elastic Search (katalog amaçlı) ve Redis teknolojilerinden yararlanılıyordu. Sisteme kazandırılmış mevcut teknolojiler olabildiğince iyi kullanılmıştı. Ancak bu karmaşıklıkta ve farklı problemler içeren bir sistem için çok daha farklı teknolojilerin kullanılması bir çok avantaj sağladı. Şu an veritabanı olarak MS SQL devam ediyor ancak Couch DB, Mongo DB, Elastic Search ve PostgreSql de micro servislerimizde kullanmaya başladık. Asenkron yapılarımız işlerin tablolar üzerinde tutulup schedule edilen batchlerle genellikle de tek makinalı workerlar ile yürütülüyordu. Şu an Pars.Core standart gelen inbox, outbox ve deadletter implentasyonu ile birlikte bu tarz yapıları Kafka üzerinden mesajlar ile ve partitiona göre çok sayıda worker ile yönetiyoruz. Bu tarz bir entegrasyonu yazılım olarak daha az maliyet ile işletim olarak da çok daha hızlı, scalable ve izlenebilir şekilde depo entegrasyo, kargo entegrasyonu, marketplace entegrasyonu, mesajlaşma entegrasyonu gibi birçok alanda etkin bir şeklide kullanıyoruz. Teknolojinin dönüşümünün en önemli bileşeni .net frameworkten .net core a geçmemiz ve bu sayede de kubernetes ortamında uygulamalarıımızı çalıştırıp scale edebilmemiz oldu. Dotnet Core mimari olarak .net framework den daha hızlı, daha az kaynak tüketecek asenkron bir şekilde tasarlanmış. Eskiden 5 ila 8 sunucuda host ettiğimiz servislerimizi şu an onda biri kaynak ile windows lisans maliyeti olmadan elastik bir sekilde host edebiliyoruz. Bu da bize hem sunucu kaynağı hem de lisans anlamında maliyet avantajı sağlıyor.
3- İnsan ve Kültür: Sistem düşüncesinde bir sistem sistemi oluşturan bileşenler, bu bileşenler arası ilişkiler ve sistemin amacı ile tanımlanır. Takımları, departmanları şirketleri oluşturanlarda çalışanlardır. Şirketin rekabet ve yenilik kaliyetini çalışanları belirler. Bu insanlar arasındaki ilişkilere de kurumun kültürü olarak bakabiliriz. Bu sebeple her şirketin yetkin insanları elde tutmak, yeni yetnekleri çekmek ve mevcutları geliştirmek zorunluluğu vardır. Değişim projelerinde bu üç hedefi de aynı anda geçekleştirebildiğimizi düşünüyorum. E-ticarette dönüşüm projesine başladığımız günden bugüne hem dışarıdan çok yetenekli arkadaşlarımızı ekibimize dahil ettik, hem mevcut arkadaşlarımızın yeni teknolojiler konusunda kendilerini geliştirmelerini bir çok yeniliği sisteme katmalarını sağladık ve asıl önemli değerli bilgi birikimi olan arkadaşlarımızın bir çoğunu pandemi dönemindeki yoğun talebe rağmen elde tutmayı başardık. Yapılan çalışmalar birçok arkadaşımıza ilham verdiği için mevcut bir business problemini çözmek için farklı yaklaşımlar geliştirme konusunda insiyatif alma, takımlarına liderlik etme ve genel olarak bir öğrenme kültürü oluşturduğumuzu gönül rahatlığı ile söylebilirim. Bilginin yayılması amacı ile ortak toplantılarda farklı ekiplerin uyguladıkları geliştirmelerin detaylarının aktarıldığı developer days düzenliyoruz. Takımların wikilerinin yanı sıra Medium gibi kanallar ile de yazılı olarak da tecrübelerimizi aktarıyoruz.
4- Risk Yönetimi: Üretim ortamında çalışan bir sistem için sistemin tamamen ya da bir parçasının çalışmaması, hatalı çalışarak operasyonel hata oluşturması, iç ve dıştan gelebilecek güvenlik tehtidleri, elektirik internet network gibi kaynak kesintileri gibi bir çok risk vardır. Burada iki temel yaklaşımız buluyor. Öncelikle işler bir şekilde ters gider ise en hızlı şekilde haberdar olmak ve soruna mudahale edebilmek. İkinci olarak da güncel teknolojileri kullanarak sistemimizi sürekli güncel tutarak hatta mimari olarak güvenliği ön plana koyarak tasarım yapmak. Micro servis dönüşümü sayesinde iki öneliğimizi de daha kolay gerçekliştirebilecek noktaya geldik. Hatalardan çok hızlı şekilde haberdar olabilmek için Pars.Core’un sistem izlemebilirği yetkinliklerinden faydalanıyoruz. Microservislerin bağımsız yapısı sayesinde sistemin bir bölümünde oluşan bir aksaklığn genele yayılmasını engelleyebiliyoruz. MS SQL veritabanımızda yoğun zamanlarda yük oluşturan ürün favorileri fonksiyonunu CouchbaseDB de olacak sekilde microservise dönüştürdük. Bu sayede yoğun trafikte database darboğazı sebebi ile oluşan ürün satınalma sürecindeki riski tamamen bertaraf ettik. Dönüşüm sırasında bize kullanıcılarımızdan sık olarak hata kaydı olarak gelen bileşenleri önceliklendirerek hem müşteri memnuyetini hem de operasyonel mükemmelliği arttırabildik. Servislerin parçalı yapısı sayesinde farklı güvenlik seviyesine ihtiyac duyan servsileri farklı sekilde alabiliyor hem de daha küçük ve düşük riskli sekilde güncelleyebiliyoruz.
Yazının sonuna gelmişken lise edebiyat derslerimizden hatırladığımız sanat sanat için midir yoksa sanat toplum için midir tartışmasını da hatırlatmak istedim. Son tahlilde sürdürülebilirlik ve risk kapsamında eski sürümleri emekli etmemiz, güvenlik açıklarını kapatmamız bazı teknik borçları adreslememiz gerekir. Yani IT nin sadece IT den doğan işleri vardır. Ancak değişimin sağlıklı ilerleyebilmesi için iş çıktılarına hizmet edecek şekilde iş strajesine hizalayarak önceliklendirme yapılması dönüşünün çok daha kolay ilerlemesini sağlayacaktır. Yani yeni bir feature talep edildiğinde bunu yeni alt yapı ile yapmak kazan — kazan olacaktır.
Bu yazı ve fonksiyonel olmayan gereksinimler yazısının ortaya çıkışı her sene başında yaptığımız modernizasyon roadmap toplantısında iş birimlerine yaptığımız sunumun kazanımlar bölümünün yazıya dökülmüş hali şeklinde oldu. Söz uçar yazı kalır diyerek yazma kararı aldım.
