🏴‍☠️Yol Haritamız

Mikroservis Mimari’ler İçin Yol Haritası

Mikroservis Mimari 2011 yılındaki ilk telaffuzundan bugüne kadar popülerliğini gün geçtikçe artırdı. Birçok ekip mevcut Monolith uygulamalarının yenilenme sürecinde veya yeni başlanacak projelerde Mikroservis Mimari’yi tercih etmeye başladı.Bu bölümde, bu mimariyi uygulamadan önce bilmemiz gereken konular ve işe koyulduktan sonra bizleri nelerin beklediğine dair önemli noktalara değineceğiz.

Konuyu aşağıdaki 4 başlık altında inceleyeceğiz;

• Uygulamanın Mikroservis Mimari’ye Uygunluğu

• Mikroservis Mimari’ye Geçiş İçin Hazır mıyız?

• Mikroservis Mimari’yi Uygularken Yapılan Hatalar

• Tavsiyeler

Mikroservis Mimari’yi Uygulamalı mıyız?

Bu çok önemli soru üzerinde belki de günlerce düşünüp konuşmak gerekirken, buna lüzum dahi görmeden biraz da gaza gelerek, “Mikroservis Mimari’ye geçiyoruz !” diyerek, yeterli ar-ge yapmadan kolları sıvayan bir çok ekip olduğuna eminim. Aksi halde bu kadar “başarısızlık hikayesi” ortaya çıkmazdı diye düşünüyorum. Bu başarısızlık hikayelerinin anlatıldığı bazı makalelere, arama motorları üzerinden aratarak sizlerde kolayca ulaşabilirsiniz.

Bu bölümde madde madde “Mikroservis Mimari’yi Uygulamalı mıyız?”sorusuna nasıl cevap aramamız gerektiğine bakacağız. Eğer burada bahsedilen sorunlar veya iyileştirmeler sizin için geçerli değilse Mikroservis Mimari’yi uygulamak için geçerli bir sebebiniz yoktur diyebiliriz.

Belirli Bir Teknoloji / Dil Ekosisteminde Sıkışmak

İçerisinde çeşitli modüller barındıran monolith yapıda bir uygulama düşünelim. Monolith yapıdan dolayı tüm kodumuz tek bir proje yani tek bir repository içerisinde.

Talep doğrultusunda projenize yeni eklenecek olan bir özellik için görüntü işleme yapmanız gerekiyor. Kullanıcılarınızın ara yüzden yükleyeceği araba fotoğraflarından plaka tanımlaması yaparak sisteminizde bu plakanın kayıtlı olup olmadığına bakmanız gerekiyor. Bu durumda uygulamayı geliştirdiğiniz programlama dili ve teknolojilerle bu özelliği geliştirmeniz gerekmekte. Eğer diliniz bu iş için pek elverişli bir dil değilse, hem geliştirme eforunuz artacak hem de belki ciddi performans sorunları yaşayacaksınız.

Bu işlemi yapan bağımsız bir servis geliştirelim, ve bu servisi istediğimiz farklı bir dille (go, python vs..) geliştirerek hem performans kazanımı elde edelim hem de teknoloji stack’ imizi genişletelim diye düşünmeye başladıysanız, Mikroservis Mimari sizin için uygun olabilir.

Yüksek Ölçeklenebilirlik

Yok biz böyle iyiyiz dediniz monolith yapıda devam ediyorsunuz ve kullanıcı sayınız da gün geçtikçe artıyor. Derken bizim görüntü işleme modülünün çok geç yanıt döndüğü şikayetleri gelmeye başlıyor. Mimariyi, gelen image’ leri kuyruklayıp tek tek kuyruktan alarak işleme üzerine kurmuşsunuz. Önceleri performans sorununuz yokken sisteme bir t anında yüklenen fotoğraf sayısı arttıkça kuyrukta bekleme süreniz de uzadı ve neticede kullanıcılarınız mutsuz.

Bu durumda sunucunuzda kaynak arttırımı yapıp, uygulamanızı dikey ölçekleyebilir (bir yere kadar) veya bir kaç sunucu daha devreye alıp yatay ölçeklendirmeye gidebilirsiniz. Peki görüntü işleme modülü dışında kalan modüllerde de bu ölçeklenme ihtiyacı söz konusu mu? Cevabınız hayır ise, tek bir servisi dilediğinizce yatay/dikey ölçekleyebilme imkanını elde edeceğiniz Mikroservis Mimari’yi düşünebilirsiniz.

Kolay ve Hızlı Release Çıkabilme

“En ufak bir değişiklikte koca uygulamayı olduğu gibi deploy ediyoruz” tarzı cümleler kurmaya başladıysanız, veya geliştirme süreci tamamlanan ve acilen devreye alınması gereken bir özelliği, projedeki bağımlılıklardan ötürü yeterince hızlı bir şekilde devreye alamıyorsanız, sizin gözünüz gibi bakıp büyüttüğünüz monolith uygulamanızın irili ufaklı servislere bölünme zamanı gelmiş olabilir.

Mikroservis Mimari’ye Geçiş İçin Hazır mıyız?

Önceki bölümde bahsettiğimiz konulardan sonra bu mimariye ihtiyacınız olduğuna kanaat getirdiniz. Peki nereden başlamalısınız? Yine madde madde inceleyelim;

Güçlü Bir DevOps Ekibi

Mikroservis Mimari’yi uygulayabilmek için en önemli şeylerden birisi hatta belki de en önemlisi DevOps kültürünün benimsendiği ve hakkıyla uygulandığı bir ekip veya ekipler oluşturabilmektir.

Martin Fowler, Mikroservis Mimari'nin getirdiği operasyonel yükü taşıyabilmenin güçlü bir DevOps takımına sahip olmaktan geçtiğini söyler. Öncelikle, servislerinizin building, configuration ve deploying süreçleri için bir CI/CD pipeline’ı tasarlamanız ve hayata geçirmeniz gerekiyor. Aksi halde çok fazla operasyonel yükle karşı karşıya kalabilir, dolayısıyla çok fazla vakit (nakit) kaybına uğrayabilirsiniz.

İlk etapta bazı süreçleri manüel yürütebilirsiniz belki. Ancak servis sayınız arttıkça ve production ortamınızı hazırlama zamanı geldiğinde artık full-automated olmanız gerekecektir.

En Az Bir Cloud Provider Üzerinde Uzmanlaşmak

Servislerinizi on-premise olarak kendi organizasyonunuz içerisinde kendi alt yapı ve ekipmanlarınızla yayınlayabilirsiniz elbette. Her ne kadar tavsiye edilen yöntem bu olmasa da en azından ilk etapta bu şekilde ilerlenebilir.

Ancak ilerleyen zamanlarda ürününüz live olmadan önce bir cloud provider (aws, google cloud, azure vs.) ile, cloud-based mimariye geçerek, hem operasyonel yükünüzü azaltıp hem de çok trafiği olan servisleriniz için auto-scale tarifeyi uygulayabilirsiniz. Bizim sunucular ayakta mı, ram/cpu yetersiz mi kaldı gibi soruları hayatınızdan çıkarmak sizin elinizde.

En Az Bir Container Teknolojisi Üzerinde Uzmanlaşmak

Container ve Container Orchestration araçlarının kaynak kullanımı ve ölçeklenebilirlik konuları başta olmak üzere bizlere kazandırdıkları hepimizin malumu. Monolith yapıdaki bir uygulamada, yani tek bir uygulamamız varken bile fayda sağlarken, söz konusu Mikroservis Mimari olduğunda adeta vazgeçilmez bir hal alıyor demek herhalde abartı olmaz.

‌Yine ilk etapta bir Container teknolojisi olmaksızın da ilerlenebilir. Mikroservis Mimari’nin benimsenmesi ve prensiplerine uygun şekilde hayata geçirilmesinin ardından, sıra deployment mekanizmasını değiştirmeye geldiğinde sanal makinalardan container’lara geçiş süreci başlatılmalı ve ardından bir container orchestration aracıyla dönüşüm tamamlanmalıdır. Sanal makinalar yerine Container'ları kullanmanın avantajları bu yazının konusu olmadığından burada kesmekte fayda görüyorum.

Gelişmiş Monitoring ve Notification Araçları

Birbirinden bağımsız olarak hayatına devam eden ve uygulamanın büyüklüğüne göre onlarca hatta yüzlerce sayıda olabilen mikroservis’lerin anlık olarak monitor edilebilmesi son derece önemlidir. Bu servislerden herhangi birinde meydana gelecek bir sorunun en hızlı şekilde ilgili yerlere sms, e-mail vb. gibi kanallardan bildirimi, sorunun hızlıca çözümü ve uygulamanın hayatını sürdürebilmesi adına çok kritiktir. Dolayısıyla Mikroservis Mimari’yi uygulamadan önce bu ihtiyaca cevap verebilecek bir monitoring aracının da devreye alınması veya en azından ön araştırmasının yapılması şarttır.

Bu monitoring ve alert ihtiyacı için kullanılabilecek bir çok ücretli veya ücretsiz açık kaynak araç mevcuttur.

Her Mikroservis İçin İzole Bir Veri Tabanı

Mikroservis Mimari, her servisin kendine ait, diğer servisler tarafından doğrudan erişime kapalı, izole bir veri depolama alanı olmasını gerektirir.

Monolith bir uygulamanın servislere ayrıştırılması konusunda, veri tabanı kısmı ilk etapta pek düşünülmeyebiliyor. Servisler şekillenmeye ve monolith yapıdan kopmaya başladıkça veri tabanlarının izolasyonu konuşulmaya başlanıyor. Tam bu noktada mevcut veri tabanının büyüklüğü ve tasarım kompleksliği aşılması gereken büyük bir sorun olarak karşımıza çıkıyor. Eğer bu sorun bir şekilde aşılamazsa, ya Mikroservis Mimariden vazgeçiliyor (servisleri ayrıştırmak için boşa harcanan efor), ya da izole veri tabanı konusundan taviz verilerek her servis ortak bir veri tabanını kullanacak şekilde ilerleniyor, ki bu Mikroservis Mimari'nin temel prensiplerinden olan "bağımsızlık" prensibine aykırı bir durum. Bu yüzden Mikroservis Mimari’ye dönüşümde ilk önce veri tabanı kısmını tasarlamak ve mevcut veri tabanının servislere özel olarak ayrışıp ayrıştırılamayacağı, bu işin eforunun ne olacağı konusunda biraz kafa patlatmak gerekiyor.

Mikroservis Mimari’yi Uygularken Yapılan Hatalar

Bu mimariyi uygularken zaman içerisinde mimarinin temelini oluşturan prensipler ihlal edilebiliyor. Bunu iki nedene bağlayabiliriz. Birincisi temel prensipleri tam olarak anlayıp benimsemeden, aceleyle işe koyulmak. İkincisi, izole veri tabanı başlığı altında bahsettiğimiz istemeden de olsa bilinçli olarak verilen veya verilmek zorunda kalınan bazı tavizler. Şimdi bu mimariyi uygularken aklımızın bir köşesinde sürekli tutmamız gereken önemli noktalardan bahsedelim;

Servisler Arası Ortak Kütüphane (library) Kullanmamaya Çalışın

“E hani DRY (don’t repeat yourself) prensibine ne oldu? Aynı kodları her serviste tekrar tekrar yazacak mıyız?” diye düşünebilirsiniz.

Öncelikle tekrarlı kod oranımızı mümkün olduğunca azaltmamız gerekiyor tabi, DRY prensibinde bahsedilen konu bussiness logic’i içeren kod parçacığının sadece bir kere yazılması. Ancak Mikroservis Mimari'de işler biraz değişiyor. Eğer ortak kullanılan fonksiyonlarınızı bir kütüphane haline getirir ve servislerinizi bu kütüphanelere bağımlı hale getirirseniz mikroservice mimarinin sağladığı en büyük kazanımlardan birinden bir miktar taviz vermiş olacaksınız. Bu kazanım bir önceki bölümde prensip olarak dile getirdiğimiz, bağımsızlık prensibidir.

Unutmayın; bu mimaride her servis bağımsız olarak geliştirilip, yine bağımsız olarak release edilebilmelidir. Peki bu durumda servislerin ortak olarak kullandıkları kodlar için nasıl bir yol izlememiz gerekiyor? Şu 3 seçenekten birisini tercih edebiliriz;

1- Servisler arası tekrarlı kodu kabullen.(Bir noktaya kadar)

2- Ortak kodlar business logic içeriyorsa yeni bir shared service oluştur.

3- Eğer mümkünse, servisleri yeniden dizayn et ve yeni alt Mikroservis/ler oluştur.

Bir Servisin Diğer Bir Servisin Verisine Erişim Yöntemi

İzole veri tabanı maddesinde biraz bahsetmiştik, burada biraz detaylandıralım. İzole’den kasıt, bir servisin veri tabanına erişimin sadece o servis üzerinden olmasıdır. Yani bir servis başka bir servisin veri tabanına doğrudan erişim sağlayamaz, erişmesi gerekiyorsa veri tabanının sahibi olan ilgili servis üzerinden erişmelidir. Yani bir client gibi http isteğinde bulunmalıdır. Bu kuralda yine ihlal edilebilen kurallar arasında sayılabilir.

Genelde performans endişesinden dolayı yapılan bu hatada, A servisi B servisine istekte bulunmak yerine, doğrudan B servisinin veri tabanına erişerek, Mikroservis Mimarinin gevşek bağlılık (loosely coupled) prensibinin ihlaline neden olmaktadır. Bu ayrıca A servisi daha kompleks ve bakımı zor bir hale getirecektir.

Authentication, Throttling Gibi İşlemlerin Merkezileştirilmemesi

Bu maddeyi Throttling (Rate Limiting) üzerinden ele alabiliriz. Çok sayıda Mikroservis ’e sahip bir sisteminiz var ve her uygulamada olduğu gibi sizin uygulamanız için de client istatistikleri çok önemli. Hangi client veya hangi kanallardan (web, mobil) hangi servisler ne sıklıkla tüketiliyor? Hangi servislere daha çok yük biniyor? gibi soruların cevaplarını merkezi bir yapı üzerinden almak en doğrusu. Bu yapılar Api Gateway olarak adlandırılan servislerdir. Bu yapılar ile client’lardan gelen tüm istekler bir veya daha fazla olabilen api gateway’ler üzerinden ilgili servislere erişir.

Data önce deneyimle fırsatı da bulduğum IBM’in Datapower isimli gateway’i ilk aklıma gelen örnek. Bunun yanında open source ve tamamen ücretsiz olan çok başarılı api gateway’ler de mevcut. (Kong, Tyk vs.)

Api gateway kullanılmadığı takdirde, Rate Limiting ve benzeri işlemler her servis özelinde tek tek geliştirilmek zorunda kalınacak ki bu da bir süre sonra servisleri daha kompleks bir hale getirerek bakım maliyetlerini artıracaktır. Bir diğer sorun tabi gereksiz harcanan efor olacaktır. Api gateway ile merkezileştirilebilecek işlemler, her yeni doğan Mikroservis için yeniden tek tek geliştirilmek zorunda kalınacaktır. Api gateway’ler oldukça yetenekli araçlardır, ve Mikroservis mimari’de kullanımlarının bir çok faydası vardır. Öyle ki tek başına ayrı bir yazı konusu olacak genişlikte olduğundan burada kesmekte fayda görüyorum.

Tavsiyeler

Startup’lar veya olgunlaşmış ekiplerdeki yeni başlanacak olan projeler için tavsiyeler;

Eğer yazılım ekibiniz 2–5 kişilik bir ekipse ve ileride bu ekibi büyütme planlarınız yoksa, monolith başlamanızda fayda var. Zaten kısıtlı sayıdaki iş gücünüzü Mikroservis Mimari’nin getirdiği operasyonel yükün altında ezmek istemezsiniz.

Bu 2–5 kişilik ekibiniz için yakın zamanda büyüme planlarınız var, veya sıfırdan yeni ekip veya ekipler kuruyorsunuz diyelim. Bu durumda da aynı şekilde monolith olarak başlamanızı öneririm. Yani bana göre yeni uygulamalar için başlangıç her zaman monolith olmalı. Ekibiniz ve uygulamanız büyüdükçe, servislerinizin sınırları daha da netleşmeye başladıkça, DevOps alt yapınızı oluşturup, mimari değişikliğe gidebilirsiniz.

Monolith den Mikroservis Mimari’ye dönüşüm için tavsiyeler;

Bu işi kesinlikle hafife almayın ve sizi neyin beklediğini iyice araştırmadan ilk kazmayı vurmayın. Yukarıda mümkün olduğunca özet haline getirmeye çalıştığım maddelerden her birisi, işe başlamadan önce ve başladıktan sonra bir şekilde karşınıza çıkacaktır emin olun.

Mikroservis Mimari’ye dönüşümde Netflix’in hikayesi oldukça bilinen bir hikayedir. Monolith uygulamayı Cloud-Based Mikroservis Mimari’ye dönüştürme işine yanılmıyorsam 2009–2010 gibi başladılar ve bitirdiklerinde 2016 ya gelinmişti. Belki sizin sisteminiz bu denli büyük ve kompleks değildir, ancak işin ciddiyetini ve açılması gereken çok fazla kilit olduğunu Netfilix’in hikayesinden anlamak mümkün.

Toparlarsak; Mikroservis Mimari’ye girmek aslında DevOps kafasına girmek olmalı diyebiliriz. Sadece teknik değil, organizasyonel ve kültürel bir değişim gerektirdiğinin bilincinde olunmalı. Geliştiricilerin sürecin her aşamasında etkin rol oynaması gerekiyor. Eğer daha önce hiç Mikroservis Mimari ve DevOps konuları hakkında deneyim edinmemiş bir ekip ile yola çıkıyorsanız, en azından temel konular hakkında bir eğitim ile işe başlamak bana göre elzemdir. Bu size vakit kazandıracağı gibi daha emin adımlarla ilerlemenize de imkan sağlayacaktır.