Kurumsal Firmaların “Mikroservis Mimarisi Bize Uymaz” Demesi Ne Kadar Doğru?
IT dünyasında bulunuyorsanız, özellikle de işin yazılım kısmındaysanız Mikroservis kavramını büyük ihtimalle duymuşsunuzdur. Duymadıysanız Google’a mikroservis mimarisi yazın, bir sürü makale karşınıza çıkacaktır. Dilerseniz benim şu makalemi de okuyabilirsiniz.
Mikroservis konusunda bilgi sahibi olmaya başlayan IT insanlarının söylemleri genelde ikiye ayrılır (zaten konuyu bilip de ürünlerinde uygulayanları saymıyorum):
1) Bu mimari bize uymaz kardeşim, bizim sistemleri bu yaklaşımla kurgulayamayız.
2) Biz de bu mikroservis denen şeyden bir deneyelim bakalım.
Neden farklı iki yaklaşım ortaya çıkıyor? Neden bir grup “Bu uygun” derken, aşağı yukarı aynı tür ürünleri üreten başka bir grup “Uymaz” diyor. Acaba olay psikolojik mi, yoksa somut, elle tutulur doneler mi var?
Bu arada yeni başlayan bir ürün veya projenin mimarisinden bahsetmiyorum. Yeni bir ürünü eğer zaman ve paranız çok yoksa zaten monolitik başlamalısınız. Biz burada zaten var olan ama hantallaşmış bir ürün veya ürünler grubunun mikroservis mimarisi ile kurgulanıp kurgulanamayacağını veya bunu neden yapıp yapmamanız gerektiğini irdeleyeceğiz.
O zaman bu konuyu; Kurumsal firmalara uyar mı?, Uymaz mı? veya Uymak zorunda mı? sorularını içeren üç yönden inceleyelim.
1-İşin Strateji Yönü
Çok başarılı kurumlar yazılımlarını da çok hızlı üretirler ve sahaya sürerler. Bunun için standart monolitik bir mimari kullanmanız bu ihtiyacı çok da karşılamaz. Mikroservis mimarisi kullanırsanız uygulamanızı sürekli canlı ortama alabilirsiniz. Çünkü ortada tek büyük bir uygulamadan çok minik minik servisler bulunmaktadır. Belki duymuşsunuzdur, Amazon her 0.6 saniyede bir yaygınlaştırma (deployment) yapar. Bunu yapabilmesi sadece mikroservis mimarisi sayesindedir.
İşin strateji yönüne bakınca “Bu mimari bize uyar mı, uymaz mı?” soruları yerine “Bu mimari bize uymak zorunda mı?” sorusu öne çıkıyor. Kurumsal firma olarak şunları amaçlıyorsanız bu mimariye geçmekten başka seçeceğiniz yok, olmayacak da:
• Rakiplerinize üstünlük kurmak istiyorsanız.
• Yeni marketlere hızlıca girmek istiyorsanız.
• Değişen market şartlarına hızlıca cevap verebilmek istiyorsanız.
• Market yıkıcılara (Market Disruptors) karşı kaybetmemek istiyorsanız.
• İnovasyon temelli ürünler geliştirebilmek istiyorsanız.
• İş gerekliliklerine mimari olarak hızlı bir şekilde cevap verebilmek istiyorsanız.
• Hızlı karar verebilme ve hızlıca uygulama yeteneği kazanmak istiyorsanız.
Az önce bahsettiğim gibi Amazon her 0.6 saniyede bir deployment yapıyor. Peki eskiden de bu böyle miydi? Tabi ki hayır. Amazon’un amiral gemisi ürünü olan e-ticaret web sitesi yani eski monolitik sistemi o kadar hantallaşmıştı ki mikroservis çözümüne gitmek zorunda kaldılar. Basit bir bug çözümü veya bir kütüphane güncellemesi bile çok zor yapılıyordu. Sistemin karmaşıklığı arttıkça basit konular bile büyük sorunlar üretmeye başlamıştı. Amazon örneğinin yanında benzer diğer iki örnek de Uber ve Netflix’tir. Uber, tek bir şehirde çok iyi çalışan monolitik uygulamasını yüzlerce şehre çıkartınca yaşadığı sorunlar nedeniyle mikroservis mimarisine geçirmek zorunda kaldı. Yine Netflix gibi ölçeklenme konusunun çok önemli olduğu bir firma monolitik uygulamasında bunu çözemeyince mecburen mikroservis mimarisine geçmek zorunda kaldı.
2-İşin Teknik Yönü
Mikroservis mimarisi fikrine sıcak bakmayanlar genelde daha tecrübeli kişiler oluyor. Örneğin; 15 yıl üzerinde monolitik uygulama geliştiren IT çalışanları genelde mikroservis fikrine sıcak bakmıyorlar. Özellikle finans sektöründe hiç bakmıyorlar. Çünkü işin içine para girerse eventual consistency konusu bu arkadaşları ürkütüyor. Düşünün, bir müşteri mobil şubeden para transferi yapıyor, işlem arka tarafta mikroservislerden geçip işini tamamlıyor. Ancak müşteri varlıklarım ekranına geçince, varlıklarım aggregate servisi daha henüz eventual olarak az önceki işlemi kendi özet veri tabanına yansıtamadığı için müşteri varlığını azalmamış görüyor. Veya dekont servisi işlemi alıp henüz dekont kesmediği için dekont görüntülemek istediği zaman dekontu göremiyor. Bu senaryolar finans sistemlerinde mikroservis mimarisinin yerleşmesini en çok zorlaştıran konular. Çok tecrübeli IT çalışanları bu senaryolar nedeniyle mikroservisi toptan reddetme eğilimindeler. Oysaki mümkün olduğunca bu gibi senaryolar senkron servislerde yaşamaya devam etmeli, geriye kalan büyük orandaki senaryolar ise mikroservise dönmelidir.
İşin teknik yönü olarak mikroservis birçok sisteme aslında uyar ama şunu da bilmek gerekir ki mikroservis mimarisine geçerseniz gökten gül yağmayacak. Monolitik mimaride olmayan bir sürü sorun karşınıza çıkacak ve bunları çözmek zorunda kalacaksınız. “Teknik olarak bu bize zor gelir” bakış açısı ile ilerlerseniz işin stratejik tarafına hiçbir zaman yardımcı olamazsınız. Örneğin; sıfır kesinti (zero-time) hedefiniz varsa bunu monolitik bir mimari ile yapma şansınız yok. Ya da eğer anlık bir kampanya yapacak ve satışları 1 günde 5 katına çıkartacaksanız, bunun için gereksiz yere tüm yıl 4 katı fazla sistem donanımı yatırımı mı yapacaksınız? Yoksa mikroservis mimarisi ve cloud based bir tüketim ile hızlıca sadece bu kampanyalık kullanımı 1 günlük yapıp sonra kaynakları gerisin geri mi indirirsiniz. Başka bir örnek ise yük altında çalışma. Yük altında çalışan uygulamaların asenkron yapılar olması çok önemlidir. Eğer tek bir noktadan geçen monolitik bir uygulamanız varsa o tek nokta (single point of failure) her zaman size sorun çıkartacaktır. Bunu aşmak için sistemi mikroservislere bölmeli ve fail olunca sistemin genelinin durmaması için point sayısını mümkün olduğunca arttırmalısınız.
Sonuç olarak, işin stratejik boyutunun ihtiyaçlarını karşılayabilmek için işin teknik boyutunun buna destek olması lazım.
3-İşin Firma Uygunluğu Yönü
Stratejik olarak mikroservis mimarisinin firmanıza çok uygun olduğuna, kurumsal ürünlerinize çağ atlattıracağına karar verdiniz. İşin teknik boyutu konusunda da çok soru işaretiniz yok. Konuyu kavradınız ve bu mimarinin size uyduğunu gördünüz. Ancak şirketinizin, bunun için bazı kültürel hazırlıkları yapması ve kendini biraz değiştirmesi gerekecektir.
Mikroservis Mimarisi İçin Ön Şartlar
*İnanmak ve Sabır
Bir kere inanan bir ekip, ekip lideri ve sponsor olmak zorunda. Eğer bu zincirden 1 tanesinde bile sorun olursa proje başlar ama kısa zamanda da biter. Yukarıda bahsettiğimiz büyük firmalar bu işlere giriştiklerinde bunu inanarak yaptılar. Genelde üst yönetimler bu tarz konuları anlamakta güçlük çekerler veya firma CTO’su bunu yukarıda anlatabilmek için kıvranıp durur. Eğer konuyu anlayan ve destekleyen bir yönetim olursa işler çok daha kolay olur.
Ayrıca sabırlı olmak inanmak kadar önemlidir. Çünkü hiç karşılaşmadığınız zorlu konular ile karşılaşıp çözmek zorunda kalacaksınız.
*Uygun Şartlar
Bu tarz bir dönüşüm için finansman ve zaman gerekmekte. İlk başladığınız zaman mikroservis mimarisini kurgulamak, düşündüğünüzden daha fazla zaman alacak ve daha fazla para yakacak. Bu gözünüzü korkutmasın. Özellikle son zamanlarda open source ürünlerin çığ gibi büyümesi ile bir kısım konuları bu ürünler vasıtasıyla çözmek zorundasınız. Böylelikle hem para hem de zaman tasarrufu sağlayabilirsiniz.
*İyi Bir Ekip, İyi Mimarlar
“Ekip inanmalı ve sabırlı olmalı” dedik ama bu yetmez. Sistemin geneline büyük resim olarak hâkim olacak bir / birkaç mimarınız olmalı. Ancak her şey bu arkadaşlarda darboğaz olmamalı. Ekipler kendi başlarına (self organized) sistemleri kurmalılar ama bu mimarlar da sürekli sistemi inceleyerek rotayı doğru yöne çevirmeliler.
*Kültür
Code review yapmadan, pair programming yapmadan, DevOps yaklaşımını oturtmadan bu işi yapamazsınız. Mikroservis mimarisi sadece teknik bir yönelim değildir. Bağımsız takımların bağımsız bir şekilde geliştirme, değişiklik ve yaygınlaştırma yapabileceği bir kültürün oturması gerekir. Klasik waterfall metodolojileri ile bu tarz bir işe girişemezsiniz, girişmemelisiniz.
Sonuç
Dünyada firmalar hatta ülkeler inanılmaz rekabet içerisindeler ve büyük kurumsal firmalar ürünlerini eğer yüksek performanslı uygulamalar ile sunabilirlerse bu rekabette şansları var. Günümüzde kurumsal firmalar artık iş yapmıyor, adeta yazılım yapıp, yazılım ile iş üretiyor durumuna geçtiler. İyi performans gösteren IT organizasyonları yazılımlarını daha hızlı, güvenli ve sık sık dağıtabiliyor. Ayrıca iyi performans gösteren IT organizasyonlarına sahip firmalar iş olarak da daha iyi performans gösteriyor, kârlılık, üretkenlik ve pazar payında da öne çıkıyorlar. Başka bir deyişle, eğer kurumsal bir firma yaptığı işte başarılı olmak istiyorsa yazılım geliştirmede de ustalaşmış ve başarılı olmak zorundadır.
Bunun için de hangi mimariyi kullanacaklarını iyi seçmeliler. Her ne kadar monolitik mimari hala masada duruyor olsa da hız, performans, markete hızlı çıkış (time to market) gibi konular önemli ise bu durumda mikroservis mimarisinden kaçmak çok da mümkün görünmüyor.
Referanslar
https://chrisrichardson.net/post/microservices/2020/02/18/why-microservices-part-1.html
https://www.thoughtworks.com/insights/blog/microservices-architecture-for-enterprises
https://www.sayonetech.com/blog/why-your-enterprise-applications-need-microservice-architecture/
