Ana içeriğe geç
Version: 1.0.1

Microservices Nedir?

Microservices yani mikroservis mimarisi farklı iş yeteneklerinin birbirinden bağımsız bir şekilde yapılandırıldığı mimari bir modeldir. Bu mimaride büyük sistemler her biri farklı bir işten sorumlu ve birbirinden bağımsız daha küçük servislere ayrılır. Sahne arkasında tüm bu servisler microservice (mikroservis) olarak adlandırılır.

Mikroservis kısaca bağımsız çalıştırılabilen, her birinin ayrı ve belirli bir sorumluluğu olan küçük servis demektir.

Bu yaklaşım SOA’dan (Service Oriented Architecture) ilham almıştır ve her ikisi de client-server yani istemci-sunucu mimarisinden gelmektedir. Fakat mikroservis mimarisi servis odaklı mimarinin (SOA) tasarım ilkeleri birebir aynı değildir. SOA ile arasında farklılıklar bulunmaktadır. Service Oriented Architecture kurumsal seviyede bir mimari iken Microservice Architecture uygulama seviyesinde bir mimaridir.

İlk olarak Martin Fowler ve James Lewis tarafından tartışılan mikroservis mimarisi dağıtım kolaylığı, esneklik ve ölçekleme gibi çeşitli avantajlar sağlar.

Mikroservis mimarisinin en önemli özelliklerinden biri veri yapılarını paylaşmamasıdır. Her mikroservis kendi veri depolama alanına sahiptir (veritabanı şeması veya tablo gibi.) Yani her biri kendi veri modelinden ve verilerinden sorumludur. Diğer servisler sahibi olmadığı depolama alanına erişemezler.

Microservice kavramını daha iyi anlayabilmek için öncelikle monolitik mimarinin ne olduğunu ve iki mimari arasındaki farkların ne olduğunu bilmek gerekir.

Mikroservice ve Monolitik Uygulamalar​

Monolithic architecture yazılımın self-contained(kendi kendine yeten) olarak tasarlanması anlamına gelmektedir. Bir standart doğrultusunda “tek bir parça” olarak oluşması da diyebiliriz. Bu mimarideki component’ler loosely coupled olmasından ziyade, interdependent olarak tasarlanmaktadır.

Genel olarak uygulamanın tek parça olması hem büyük hem karmaşık olmasına neden olur. Birbirine sıkı bir şekilde bağlı bileşenlerden birinin çökmesi tüm sistemi olumsuz etkiler. Yani monolitik sistem başarısız olursa verilen her hizmet çalışmayı durdurur.

Ayrıca monolitik uygulamalar yüksek maliyetli ve zaman alıcı işleri nedeniyle çok esnek değildir.

Mikroservices çalışma mantığında ise yalnızca bir parçanın bulunduğu monolitik mimarinin aksine her bir servis farklı bir parça olarak ele alınır. Mikroservis mimarisi, dağıtım kolaylığı, esneklik ve ölçekleme gibi avantajlar sağlar.

microservices-vs-monolith.png

Monolitik Mimari Avantajları ve Dezavantajları​

Uygulama dünyasında günümüze kadar eşlik eden monolithic yaklaşım getirdiği büyük avantajların yanında kritik dezavantajlar da barındırmaktadır.

Avantajlar;

  • Yönetilebilirliği, geliştirilebilirliği, bakımı ve monitoring’i(izleme) oldukça kolaydır.
  • Küçük ve orta ölçekli projeler için geliştirilmesi hızlı ve maliyetsizdir.
  • Component ve fonksiyonlar çalışma açısından kendi aralarında tutarlı ilişki kurabilmektedirler.
  • Transaction yönetimi oldukça rahat ve irade altındadır.

Dezavantajlar;

  • Tüm hizmetler tek bir uygulama üzerinden sunulmaktadır. Böylece herhangi bir noktada düzeltme veya geliştirme yapılması gerektiği taktirde uygulama baştan sona tekrar derlenmesi gerekmekte ve böylece uygulamanın varsa yayın durumu kısmi kesintilere gireceği anlamına gelmektedir.
  • Tüm bileşenler bütünsel bir parça içerisinde tek bir bütün olarak değerlendirilmektedir. Bu durumda bir noktada yapılan çalışmanın alakasız başka bir noktayla olan teması yüzünden bloklanması ve süreçten etkilenmesi demektir.
  • Monolithic yapılanmanın en kısır noktalarından biri bütünsel yaklaşımın getirdiği tek dil ve platform bağımlılığıdır. Uygulamanın bütünsel olarak inşa edilmesi tüm modüllerin aynı dil ve platformda inşa edilmesi mecburiyeti doğurmaktadır. Böylece farklı dil ve platformun kullanılamamasından dolayı ihtiyaç doğrultusunda dil ve platformun amacı dışına çıkılabilmekte ve birçok gereksiz iş yüküne sebep olunabilmektedir.
  • Takım çalışmalarından birden fazla kişi tarafından geliştirilen uygulamalarda ister istemez birçok kod ve yapı karmaşası meydana gelmektedir.
  • Uygulama tek çatı altında geliştirileceği için tüm component ve modüller kendi aralarında sıkı sıkıya bağlılık göstereceklerdir.
  • Bu bağımlılıklardan kaynaklı olarak ufak bir noktadaki değişiklik başka alanlarda yeni değişikliklere sebep olabilmektedir.
  • Versiyon yönetimi zorlaşır.

Mikroservis Mimari Avantajları ve Dezavantajları​

Monolitik mimarinin getirdiği çoğu dezavantajı avantaja çevirse de mikroservis mimarininde kendine has avantajları ve dezavantajları vardır.

Avantajları;

  • Uygulama boyutundan bağımsız olmak üzere yeni bir özelliğin eklenmesi veya mevcut yapının bakımı sadece ilgili servislerle ilgilendirme gerektireceğinden dolayı oldukça kolaydır.
  • Ekip çalışmasına yatkındır. Özellikle ekibe yeni katılım gösteren arkadaşların devasa bir proje ve kod içerisinde kaybolmasının önüne geçmekte, sadece ilgileneceği servisin kaynağını çözümlemesi gerekmektedir.
  • Yapılan işlemler neticesinde servislerin birbirlerinden bağımsız olması tek başına scale edilebilmesini sağlamaktadır.
  • Versiyon yönetimi oldukça kolaydır.
  • Her bir servis ihtiyaca göre farklı dil ve platformda yazılabilmektedir.

Dezavantajları;

  • Birden fazla service ve birden fazla veritabanı söz konusu olacağı için transaction yönetimi zorlaşacaktır.
  • Servislerin yönetilebilirliği ve monitoring’i zorlaşacaktır.

Mikroservice Mimari Best Practice’leri(2023)​

Mikroservis mimarinin özelliklerinden biri de sürekli gelişiyor olmasıdır. Bu nedenle, mühendislerin her zaman yaklaşan değişikliklerden haberdar olmaları ve best practiceleri sürekli olarak yenilemeleri gerekir.

1. Mikroservisleri net bir şekilde tanımlayın

Startuplardan Fortune 50 şirketlerine kadar uzanan BT kuruluşlarının çoğu mikroservis mimarisini kullanır. Ancak bir başkası için işe yaramış olması sizin için de işe yarayacağı anlamına gelmez. Bir mikroservis mimarisinin teknolojinize katabileceği değeri net bir şekilde anladığınızdan emin olun ve buna göre en mantıklı araçlara yatırım yapın.

Business functionlar, servisler ve mikroservis arasında net bir ayrım olmalıdır. Bu sınırlar olmadan, mikroservisleriniz çok büyük olabilir; bu da mikroservis mimarinin avantajlarından faydalanılamayacağı anlamına gelir.

Ya da bir diğer ihtimalle, çok fazla sayıda mikroservise sahip bir yapı olma olasılığı vardır. Bu, operasyonel yönetim maliyetlerinizin fırlamasına neden olur ve bu muhtemelen faydaları gölgede bırakır.

Önemli olan, uygulama içi fonksiyonlara göre özel servisler tasarlayarak bir denge sağlamaktır.

2. Mikroservisleri ayrı olarak deploy edin ve barındırın

Her servisin kaynaklarını en aza indirmek istiyorsanız mikroservisleri ayrı ayrı dağıtmak önemlidir. Mikroservisleri barındırmak için dedicated infrastructure kullanarak bunları diğer servislerdeki hatalardan izole edebilirsiniz. Bu, sistemde tam bir kesinti olma olasılığını en aza indirir.

Ek olarak, containerize mikroservisler, mikroservis bağımsızlığından ödün vermeden platformun birlikte çalışabilirliğini sağlar.

3. Domain Driven Design (DDD) ile mikroservisler oluşturun

Domain Driven Design (DDD), pratik kurallar ve fikirler kullanarak object-oriented bir modeli kullanan bir tasarım ilkesidir. Spesifik olarak, business domainleri etrafında mikroservisler tasarlamayı içerir.

4. Bütün paydaşların sürece dahil olacağının farkında olun

Mikroservis mimariyi uygulamak, mühendislik ekibinizden daha fazla katılım gerektirir. Dönüşümün maliyetleri, iş etkisi ve organizasyonel yeniden yapılanma, ilgili tüm paydaşların desteğini almayı gerektirir.

Bu paydaşlar, yönetici ekibinizi de içerir ve kuruluşun tamamına kadar uzanır. Mikroservis mimarisi, kültürel bir dönüşüm ve işletmenizin çalışma biçiminde bir değişiklik gerektirir. Bu, sadece yukarıdan aşağıya değil, aşağıdan yukarıya katılım gerektirir.

5. Her mikroservisin veri depolaması için unique provizyonlamalar yapın

Veriler tüm mikroservislerde API'ler aracılığıyla paylaşılabilir ve paylaşılmalıdır, ancak her birinin kendine özel veri depoları olmalıdır. Birden çok mikroservis aynı veri depolama alanını paylaşıyorsa bu, hizmetler arasında bağlılığa yol açarak mikroservislerin amacını tamamen ortadan kaldıracaktır.

6. Observability’e yatırım yapın

Mikroservis mimarisi, monolit mimariden kat kat daha karmaşıktır. Bu nedenle, geleneksel monitoring yöntemleri beklendiği gibi sonuç vermez. Bu nedenle, mikroservis dönüşümünüzün bir parçası olarak bir observability platformuna yatırım yapmalısınız.

Observability platformları, metric, log ve trace’leri toplayarak tüm verilerinizi tek bir konumda toplayarak en önemli insightları ortaya çıkarır. Hatayı hangi mikroservis tetiklemiş olursa olsun, sorunların temel nedenlerine kadar izleyebilirsiniz. Bu şekilde, geliştirme ekibiniz bir sorunu teşhis etmek için daha az, sorunu düzeltmek için daha fazla zaman harcayabilir.

Mikroservis Mimari Ne Zaman Kullanılmalı?​

Bu mimari servislerde sık güncelleme ihtiyacı olan uygulamaların modern ihtiyaçlarını karşılamak için alternatif bir mimari olarak geliştirilmiştir. Mikroservis mimarisinin temel amacı uygulamayı küçük bağımsız servislere bölmektir. Mikroservis mimari daha önce de belirttiğimiz gibi farklı ve benzersiz iş yetenekleri olan bağımsız süreçlerin oluşturduğu bir mimaridir.

Çok sık ölçeklendirme gereken bir uygulamada bu mimari önemli faydalar sunar (scalability-ölçeklenebilirlik prensibi.) Onun için sık ölçeklendirme ihtiyacı varsa bu mimari kullanılabilir. Örneğin bir servise yapılan istek diğer servislere nazaran çok arttıysa sadece bu servisin sayısını artırabiliriz. Monolitik uygulamada olduğu gibi tüm sistemi artırmamıza gerek kalmaz.

Ya da başka bir örnek; haftanın bazı günlerinde kampanya çıkılan bir uygulamayı düşünelim. Bu uygulamada trafik kampanya günleri çok yüksek, diğer günler çok düşük olacaktır. Bu günlere özel olarak ölçeklendirme yapabiliriz. Bunun için auto-scaling özelliği olan PaaS ürünleri de bulunmaktadır. Tabi bunu auto-scaling olmadan da düzenleyebiliriz.

Büyük bir sistem ve burada çalışması gereken çok sayıda insan kaynağı varsa, böl parçala yönet mantığıyla iş akışları ayrılarak burada mikroservis mimari uygulanabilir.

Bir servisin durması, hata vermeye başlaması (availability-kullanılabilirlik oranının düşmesi) sistemin diğer fonksiyonlarını etkilememesi için kullanılabilir. Bu prensip isolation of failure (hata izolasyonu) olarak geçer.

Bazı hizmetlerin, fonksiyonların sürekli güncellenmesi gerekiyorsa bu mimari ile tüm sistemin elden geçirilmesi gerekmez. Çünkü servisler birbirinden tamamen bağımsızdır. Bu da iş birimlerinin pazara çıkma hızını artırmasına yardımcı olur.

Ayrıca günümüzün iş gereksinimlerine ve çözümlerine ayak uydurmak için günümüzün programlama dillerinde veya teknoloji ürünleriyle eski uygulamaları yeniden yazmanız gerektiğinde de kullanabilirsiniz.

Mikroservis Mimari Ne Zaman Kullanılmamalıdır?​

Bunu netleştirmek için öncelikle uygulamayı mikroservislere bölmeye ihtiyaç olup olmadığını sormamız gerekir. Mikroservis mimari sistem karmaşıklığını çözmede yardımcı olur. Onun için karmaşık yani kompleks sisteminiz yoksa kullanmanıza gerek yoktur.

Çok sık ölçeklendirmeye ihtiyacınız yoksa kullanılmasına ihtiyaç olmayacaktır.

Uygulama kapsamı çok net değilse operasyonel eforlar, geliştirme eforları, bakım gibi konularda ek yük ve maliyet çıkabilir.

Kurumlar ya da geliştirme ekipleri genellikle modaya uyarak genellikle mikroservis dünyasına atlamaya ve bir an önce kullanmaya hazırdır. Geçişi sırf bunun uğruna yapmak işletmelerin Conway yasasında belirtilen duruma gitmesine neden olabilir. Conway’s Law kısaca uygulamaların mimari yapılarının, kullanıcıların ihtiyaçlarına değil de uygulamayı oluşturan ekibin yapısına yakından benzeme eğiliminde olduğunu belirten bir özdeyiştir.

Genelde büyük işletmelerde bu değişim esnasında bir iki mikroservisi küçük ekiplere atamak yerine büyük ekiplerin birçok mikroservisi geliştirme eğilimi olabilir. Bu mikroservisler de kullanıcı gereksinimlerine göre değil de ekibin yapısına göre şekillenebilir. Bu da istenen bir durum değildir.

Ayrıca daha teknik açıdan bakacak olursak; bu mimaride sistematik sorunları bulmak daha zordur. Örneğin sorun analizi için genelde birden fazla log dosyasını birleştirme ihtiyacı olur.

Kaynaklar;