Mikroservis – mikroservis mimarisi olarakta bilinir – aşağıdaki hizmetlerle uygulama yapısında bir mimari stilidir.
- Yüksek oranda bakım yapılabilir ve test edilebilir (Highly maintainable and testable)
- Uygulamalar arası bağlılık düşük (Loosely coupled)
- Bağımsız deployment (Independently deployable)
- Yaptığı işlere göre organize edilir (Organized around business capabilities)
- Küçük ekipler tarafından sahiplenebilir (Owned by a small team)
Mikroservis mimarisi, hızlı, sık ve güvenilir teslimatlar, karmaşık uygulamalar sağlar. Ayrıca, teknoloji yapınızın gelişmesini sağlar. Yani farklı teknolojileri kullanma imkanı verir.
Şimdiyse monolitik ve mikroservis mimarisinin detaylarına bakalım.
Server-side bir kurumsal uygulama geliştiriyorsunuz. Uygulamanız masaüstü tarayıcılar, mobil tarayıcılar ve native mobil uygulamalar olmak üzere çok çeşitli farklı clientları desteklemeli. Uygulamanız 3. parti uygulamaların tüketmesi için API’lere sahip olabilir. Web servisler veya bir mesaj broker (RabbitMQ, Kafka vb.) aracılığıyla diğer uygulamalarla entegrasyonu olabilir. Uygulama, business mantığını kullanarak istekleri (HTTP istekleri ve mesajları) işler; bir veritabanına erişir; diğer sistemlerle mesaj alışverişi yapar ve bir HTML/JSON/XML yanıtı döndürür. Uygulamanın farklı işlevsel alanlarına karşılık gelen mantıksal bileşenler vardır.
Uygulamanın nasıl deploy edileceği problemlerden biridir. Ve aşağıdaki maddeler kapsayan bir sistem istiyorsunuz:
- Uygulama üzerinde çalışan geliştiriciler takımına sahipsiniz
- Yeni ekip üyeleri hızlı bir şekilde üretken olmasını istiyorsunuz
- Uygulamanın anlaşılması ve değiştirilmesinin kolay olmasını istiyorsunuz
- Uygulamanın sürekli dağıtımını yapmak istiyorsunuz
- Ölçeklenebilirlik ve kullanılabilirlik gereksinimlerini karşılamak için uygulamanın birden çok örneğini birden çok makinede çalıştırmak istiyorsunuz
- Gelişmekte olan teknolojilerden (framework, programlama dilleri vb.) yararlanmak istiyorsunuz.
Müşterilerden sipariş alan, stok kontrolu yapan, ödemeyi doğrulayan ve kargolama gerçekleştiren bir e-ticaret uygulaması oluşturduğunuzu düşünelim. Uygulama, kullanıcı arayüzünü uygulayan StoreFrontUI ve ödeme kontrolü, stok takibi ve sevkiyat siparişlerinin bakımı için bazı backend hizmetleri dahil olmak üzere çeşitli bileşenlerden oluşur.
Şimdi gelin yukarıdaki uygulamayı ve problemi Monolitik Mimari ve Mikroservis mimarisi açısından inceleyelim.
Monolitik Mimari Nedir?
Monolithic mimari 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, birbirine bağlı olarak tasarlanmaktadır.
Uygulama, tek bir monolitik uygulama olarak deploy edilir. Örneğin, bir Java web uygulaması, Tomcat gibi bir web kapsayıcısında çalışan tek bir WAR dosyasından oluşur. Kullanılabilirliği ölçeklendirmek ve iyileştirmek için uygulamanın birden çok örneğini bir load balancer arkasında çalıştırabilirsiniz.
Monolitik Mimari kullanıldığında uygulama ilk etapta aşağıdaki faydaları sağlar:
Monolitik Mimari Avantajları
- Geliştirme yapmak kolaydır – Mevcut geliştirme araçlarının ve IDE’lerin amacı, monolitik uygulamaların geliştirilmesini desteklemektir.
- Deploy etmek kolaydır – WAR dosyasını (veya dizin hiyerarşisini) uygun çalışma zamanında dağıtmanız yeterlidir.
- Scale etmek kolaydır – Uygulamanın birden çok kopyasını bir yük dengeleyicinin arkasında çalıştırarak uygulamayı ölçeklendirebilirsiniz.
Ancak, uygulama büyüdükçe ve ekip büyüdükçe, bu yaklaşımın giderek daha önemli hale gelen bir dizi dezavantajı vardır:
Monolitik Mimari Dezavantajları
- Ekibinize yeni katılan birisinin projeyi anlaması ve üzerinde değişiklik yapması zor bir hale gelir. Bunun sonucunda geliştirme hızı yavaşlar. Ayrıca, projedeki modüler yapı zamanla bozulabilir çünkü bir sınır bulunmamaktadır. Ek olarak, bir değişikliğin nasıl doğru bir şekilde uygulanacağını anlamak zor olabileceğinden, kodun kalitesi zamanla düşer.
- Aşırı yüklenmiş IDE – Uygulama zamanla büyüyeceği için kullandığınız IDE’lerin uygulamayı çalıştırma performansı düşecektir. Bu yüzden developerların üretkenliği azalacaktır.
- Aşırı yüklenmiş Web Container – Uygulama ne kadar büyükse, başlatılması o kadar uzun sürer. Container’in başlamasını beklerken boşa harcanan zaman nedeniyle developer üretkenliği üzerinde büyük bir etkisi olur. Ayrıca deployment bu durumdan etkilenir.
- Sürekli deployment sürecinin zorlaşması – Büyük bir monolitik uygulama da sık deploymentlar için bir engeldir. Bir bileşeni güncellemek için tüm uygulamayı yeniden deploy etmenizi gerektirir. Bu, değişiklikten etkilenip etkilenmediklerine bakılmaksızın arka plan görevlerini (örneğin bir Java uygulamasındaki Quartz işleri) kesintiye uğratır ve muhtemelen sorunlara neden olur. Ayrıca güncellenmemiş bileşenlerin doğru şekilde başlamama olasılığı da vardır. Sonuç olarak, yeniden deployment ilişkili risk artar ve bu da sık güncellemeleri engeller.
- Uygulamayı ölçeklendirmek zorlaşır – Monolitik bir mimari, yalnızca bir boyutta ölçeklenebilir. Uygulamanın daha fazla kopyasını çalıştırarak artan işlem hacmiyle ölçeklenebilir. Hatta bazı cloud servisler, kopya sayısını yüke göre dinamik olarak ayarlayabilir. Ancak öte yandan, bu mimari artan bir veri hacmiyle ölçeklenemez. Uygulama örneğinin her kopyası tüm verilere erişecek, bu da önbelleğe almayı daha az etkili hale getirir ve bellek tüketimini ve Giriş/Çıkış trafiğini artırır. Ayrıca, farklı uygulama bileşenlerinin farklı kaynak gereksinimleri vardır, biri yoğun CPU’luyken diğeri yoğun bellekli olabilir. Monolitik bir mimariyle her bileşeni bağımsız olarak ölçekleyemeyiz.
- Ölçeklendirirek geliştirmeyi engeller – Monolitik bir uygulama aynı zamanda ölçeklendirerek geliştirmenin önündeki bir engeldir. Uygulama belirli bir boyuta ulaştığında, mühendislik ekiplerini belirli işlevsel alanlara odaklanan ekiplere bölmek yararlıdır. Örneğin, UI ekibine, ödeme ekibine, stok ekibine vb. sahip olmak isteyebiliriz. Monolitik bir uygulamanın sorunu, ekiplerin bağımsız çalışmasını engellemesidir. Ekipler, geliştirme çabalarını ve deploymentlerı koordine etmelidir. Bir ekibin değişiklik yapması ve ürünü güncellemesi çok daha zordur.
- Bir teknolojiye uzun vadede bağlılık gerektirir – Monolitik bir mimari, geliştirmenin başlangıcında seçtiğiniz teknoloji çevresiyle (ve bazı durumlarda bu teknolojinin belirli bir sürümüyle) evli olmaya zorlar 🙂 Monolitik bir uygulama ile daha yeni bir teknolojiyi aşamalı olarak benimsemek zor olabilir. Örneğin, JVM’yi seçtiğinizi düşünelim. Java’nın yanı sıra Groovy ve Scala gibi Java ile güzel bir şekilde birlikte çalışan diğer JVM dillerini kullanabileceğiniz için bazı dil seçenekleriniz var. Ancak JVM olmayan dillerde yazılan bileşenlerin monolitik mimarinizde yeri yoktur. Ayrıca, uygulamanız daha sonra geçersiz hale gelen bir framework kullanıyorsa, uygulamayı aşamalı olarak daha yeni ve daha iyi bir çerçeveye taşımak zor olabilir. Daha yeni bir platform çerçevesi benimsemek için, riskli bir girişim olan tüm uygulamayı yeniden yazmanız gerekebilir.
Monolitik mimariyi analiz ettik, şimdiyse gelin mikroservis mimarisine bakalım.
Mikroservis Mimarisi Nedir?
Mikroservis mimarisi kavramını yazımızının başında tanımlamıştık. Tekrar özetlemek gerekirse, mikroservis mimarisi birbirinden bağımsız olarak çalışan ve birbirleriyle haberleşen bireysel servislerdir. Her servis kendisine ait olan iş mantığını yürütür ve diğer servislerin iş mantığı ile ilgilenmez.
Mikroservis Mimarisi kullanıldığında uygulama aşağıdaki faydaları sağlar:
Mikroservis Mimarisi Avantajları
-
Büyük, karmaşık uygulamaların sürekli teslimini ve dağıtımını (continuous delivery and deployment) sağlar:
- Kolay bakım yapılabilir – Her servis oldukça küçüktür bu yüzden kolayca anlaşılabilir ve değişiklik yapılabilir.
- Daha iyi test edilebilir – Servisler küçüktür ve hızlı test edilebilir.
- Daha iyi deployment – Servisler bağımsız olarak deploy edilebilir.
- Daha iyi takım yönetimi – Her takım bir veya birden fazla küçük servis ile ilgilenir.
- Her takım diğer takımlardan bağımsız olarak kendi testlerini gerçekleştirebilir, ürünü güncelleyebilir ve servisini ölçeklendirebilir.
- Her mikroservis oldukça küçüktür.
- Developerlar tarafından kolayca anlaşılabilir.
- IDE kullanımı hızlıdır bu yüzden developerlar daha üretken olurlar.
- Uygulama hızlıca çalıştığından dolayı, geliştiriciler üretken olur ve deployment hızlanır.
- Hata durumları izoledir. Örneğin bir serviste bellek yetersizliği varsa sadece o servis etkilenir, diğer servisler çalışmaya devam eder. Ancak monolitik mimaride hatalı çalışan bir sistem tüm sistemi çökertebilir.
- Bir teknolojiye uzun vadede bağlılık gerektirmez. Yeni bir servis geliştirirken farklı bir teknoloji kullanabilirsiniz. Benzer şekilde, mevcut bir hizmette büyük değişiklikler yaparken, onu yeni bir teknoloji yığını kullanarak yeniden yazabilirsiniz çünkü değişiklik yapmak kolaydır.
Mikroservis Mimarisi Dezavantajları
- Developerlar, dağıtık sistemin karmaşıklığıyla uğraşabilirler:
- Servisler arası iletişim kurulmalıdır ve fail durumları başak çıkabilmelidir.
- Birden çok servisi kapsayan istekleri uygulamak daha zordur.
- Servisler arasındaki etkileşimleri test etmek daha zordur.
-
Birden çok servisi kapsayan istekleri uygulamak, ekipler arasında dikkatli bir koordinasyon gerektirir.
- Developer araçları/IDE’ler monolitik yapılar için geliştirilmiştir, dağıtık uygulamalar geliştirmek için destekleri yoktur.
- Deployment karmaşıklığı olabilir. Production’da, birçok farklı servisten oluşan bir sistemi devreye almanın ve yönetmenin operasyonel karmaşıklığı da vardır.
- Bellek tüketimi artabilir.
Son olarak mikroservis mimarilerinde veri tutarlılığı (data consistency) en önemli konulardan biridir. Diğer bir yandan mikroservis mimarisini ne zaman kullanmalıyız da aklımıza gelen sorulardan biridir. Gelecek yazılarda bunlardan bahsediyor olacağım.
Kaynaklar
https://microservices.io/
https://smartbear.com/solutions/microservices/
