Mikroservis kavramı, ilk konuşulmaya başladığı zaman servis odaklı mimari(SOA) için alternatif bir mimari model olarak yorumlandı. Ancak kesinlikle SOA’ya alternatif bir model ya da yaklaşım değil. Bunun altını özellikle çizmek isterim. Mikroservisleri, SOA mimarisinin karmaşıklığını, pratikleştiren ve yönetimini kolaylaştıran bir kavram olarak yorumlayabiliriz.

Mikroservisler(Microservices), SOA mimarisi ile uygulama geliştirmek için tercih edilebilecek bir yaklaşım, bir mimari stil…

Burada önemli olan kelime “tercih“.  İhtiyaçlar doğrultusunda, getirilerini ve götürülerini ölçüp, biçip tercih edilmeli. Açıkcası mikroservisler sizi alıp, Mars’a götürmüyor; ya da tüm problemlerinizi düzeltmiyor. Getirilerinin yanında, götürüleri ve belli bir olgunluk seviyesinde olmak gibi şartları var.  Bu şartları sağlayabilecek olgunlukta ne kadar olursanız, o kadar faydasını görürsünüz.

Mikroservis mimari stili ile geliştirilen uygulamalar, pratikte bir birinden bağımsız bir kaç servisin beraberce kullanıldığı uygulamalar olarak karşımıza çıkıyor. Mobil, web ya da masa üstü, hatta hatta konsol uygulamaları, bu sayede aynı servisleri kullanarak geliştiriliyor. Dolayısıyla, aynı iş mantığı farklı platformalara kolaylıkla sağlanıyor. Microservices’lerin en önemli noktası; bu servislerin kendi başlarına çalışan, tek bir sorumluluğu olan, bağımsız servisler olmalarıdır. Mesela Amazon’nun web sitesi bir çok servis(microservice) ile geliştirilmiş bir web uygulaması. Aynı servisleri Amazon’nun mobil uygulaması ve B2B uygulamaları da kullanmakta.

Mikroservisler iş mantıklarını ve kurallarını kendi içinde tutmalıdırlar. “Ne yapıldığı” servisler tarafında, “nasıl yapıldığı” ise servisleri kullanan uygulamalar tarafında olmalıdır. Bu sayede iş mantığı tek bir yerde olup, sadece orada gelişecektir.

İş kabiliyetlerine göre ayrıştırılan servisler, tek başlarına çalışabilen servisler olmalıdır. Dolayısıyla platform, sistem, dil ya da framework bağımlılıkları yoktur. Yani bir e-ticaret sitesindeki kategori yönetimini sağlayan servisler .NET ile yazılabilirken, ürün görsellerini sağlayan servis node.js ile geliştirilebilir. Ödeme servisleri Scala ile olurken, istatistiksel verileri sağlayan kısımlar R dili ile yazılabilir. .NET servisleri, Windows sunucularda olurken, node.js *Unix tabanlı bir sistemde bulunabilir. Bu sayede belli bir teknolojiye bağımlılık da ortadan kalkmış oluyor.

Bu servislerin bağımsızlık ilkesi, servislerin değişikliğini ve deployment’ını kolaylaştırıyor. Yani görselleri sağlayan servisdeki bir geliştirme, diğer servislerden bağımsız,  başka hiç bir servisi etkilemeden kolaylıkla yapılabilir. Benzer yaklaşım ile servislerin deployment’ları da bir birinden bağımsız ve bir birini etkilemeyecek şekilde gerçekleşebilir. Bu getirinin tabi ki bir şartı var. Oldukça düzgün, oturmuş ve sorunsuz bir Continuous Integration(CI) yönteminizin olması gerekmekte. Yani kodlarınız düzenli bir şekilde, belli aralıklar ile ortak kod deposuna gönderilmesi ve orada hatasız bir şekilde build edilmesi otomatik bir şekilde gerçekleşmeli. Aynı şekilde servisleri versiyonladığınız bir yönteme de sahip olmanız gerekmekte.

Az önce dediğim iş kabiliyetlerine göre ayrışan bu servisler, bu ayrışmadan dolayı küçük olmalıdır. Tek bir sorumlukları olup, bu sorumlulukları sorunsuz bir şekilde gerçekleştirmelidirler. Bu da basit olmaları anlamına geliyor aslında. İş kabiliyetlerine göre basitlik kavramı değişse de, sonuçta tek bir sorumlulukları olduğu için karmaşıklıkları az olacaktır. Burada önemli olan anahtar kelime “sorunsuz“. Mikroservisler sorunsuz bir şekilde çalışmalıdır. Bu noktada test edilebilir şekilde geliştirilmeleri şartı ortaya çıkıyor. Servislerin sorunsuz olarak çalıştığını, hem birim testler ile hem de otomatikleşmiş testler ile sağlamak gerekli. Aksi takdirde problemi servisler, problemli uygulamalara yol açacaktır. Dolayısıyla test kültürünün takım ya da şirket içinde belli bir olgunluğa erişmiş olması gerekmekte.

Mikroservislerin en önemli özelliklerinden biri, “scale” edilebilir olmaları. Farklı sistemler ve platformlarda çalışabilen farklı servisler olarak geliştirildikleri için, ihtiyaça göre genişletilebilirler. Mesela yoğun “memory” kullanan bir servis ile yoğun I/O işlemi yapan bir servisi farklı şekillerde “scale” edip, kaynak kullanımını optimize etmek oldukça kolay olacaktır. Bu noktada microservices’lerin yönetimi ve monitör edilmesi şartı da karşımıza çıkacaktır. Dolayısıyla devops kültürünün yazılım ekibinde ya da şirkette kabul edilmiş ve oturmuş olması gerekmekte.

Bir çok servisin ortalıkta oluyor olması, bu servislerin monitör edilmesini gerektirecektir. Dolayısıyla öncelikle bu alt yapıyı sağlayan bir platform kurmak ya da araç kullanmak gerekli. Mümkün olabildiğince bu monitör alt yapısı ayrıntılı olmalıdır. Servislerin log’ları, servislere yapılan request sayıları, servis süreleri, servisleri kimlerin çağırdığı gibi kavramları merkezi bir yerden yönetebilmek servislerin operasyon kalitesini arttıracaktır.

Mikroservis mimari stilinin en zor noktası, servislerin büyüklüğü yönetmek. Servisler adet olarak çok fazla büyür ise, sorumlulukları tek bir  servis altında toplanacak şekilde, bir servismiş gibi ele almakta fayda olacaktır. Servislerin içerikleri ve kabiliyetleri ise büyüklük konusunun bir başka noktası. Bu noktada servisin yaptığı işi bilen, sınırları ve ihtiyaçları net bir şekilde tanımlayan kişiler mutlaka olmalıdır. Ya iş birimleri, analistler ya da teknik olarak yetkin kişiler; ve bu kişiler mutlaka tecrübeli olmalıdır. Aksi takdirde servislerin içinde kaybolmak kaçınılmaz olacaktır.

Mikroservislerin temel karakteristik özelliklerini kısaca anlatmaya çalıştım. Anlaşılması ve gerçekleştirilmesi zor olanlara yer vermeye çalıştım. Pratik olarak uygulamak ya da bu mimari stile göre uygulama geliştirmek zor olsa da, imkansız değil. Ama ciddi bir geliştirme kültürü değişikliği şart. Full-stack geliştiriciler, devops’lar ve yazılım prensipleri ile ilgili farkındalık arttıkça, ciddi anlamda tercih edilebilecek ve belki SOA’nın uygulanabilirliğini kolaylaştıracak bir yaklaşım olacaktır. Umarım bazı kavramlar biraz daha netleşmiştir. Bir sonraki yazıya kadar, hatasız build‘ler…