Mikroservis nedir?

Mikroservis, yazılım geliştirme süreçlerine mimari bir yaklaşımdır. Bir mimari çerçeve olarak, mikroservisler dağıtılır ve esnek bir şekilde birleştirilir, bu nedenle bir ekibin değişiklikleri tüm uygulamayı bozmaz. Mikroservisleri kullanmanın avantajı, geliştirme ekiplerinin değişen ihtiyaçlarını karşılamak için yeni uygulama bileşenlerini hızla oluşturabilmesidir.

Bir mikroservis mimarisini daha geleneksel, monolitik yaklaşımlardan ayıran şey, bir uygulamayı temel işlevlerine nasıl ayırdığıdır. Her işleve hizmet adı verilir ve bağımsız olarak oluşturulup dağıtılabilir, yani bireysel hizmetler diğerlerini olumsuz etkilemeden çalışabilir (ve başarısız olabilir). Bu, DevOps’un teknoloji yönünü benimsemenize ve sürekli yineleme ve teslimi (CI/CD) daha sorunsuz ve ulaşılabilir hale getirmenize yardımcı olur.

Bir çevrimiçi perakendeciye yaptığınız son ziyareti düşünün. Ürünlere göz atmak için sitenin arama çubuğunu kullanmış olabilirsiniz. Bu arama bir hizmeti temsil ediyor. Belki ilgili ürünler için öneriler de görmüşsünüzdür—alışveriş yapanların tercihlerinden oluşan bir veri tabanından alınan öneriler. Bu da bir hizmettir. Çevrimiçi bir sepete bir ürün eklediniz mi? Tahmin ettiniz, başka bir hizmet.

Bu nedenle bir mikroservis, bir uygulamanın temel işlevidir ve diğer hizmetlerden bağımsız olarak çalışır, ancak bir mikroservis mimarisi, bir uygulamanın temel işlevlerinin gevşek bir şekilde birleştirilmesinden daha fazlasıdır; bu, geliştirme ekiplerini ve hizmetler arası iletişimi hazırlayacak şekilde yeniden yapılandırmakla ilgilidir.

Bu nasıl elde edilir? Mikroservisleri dağıtmak için hizmet odaklı mimarinin (SOA) temellerini uyarlayarak.

Uygulamaları temel işlevlerine ayırmak ve monolitlerin tuzaklarından kaçınmak tanıdık geliyorsa, bunun nedeni mikroservislerin mimari stilinin, zaten iyi kurulmuş bir yazılım tasarımı stili olan hizmet odaklı mimariye (SOA) benzer olmasıdır.

Tanıdık Süreçler

Uygulama geliştirmenin ilk günlerinde, mevcut bir uygulamada yapılan çok küçük değişiklikler bile, kendi kalite güvence (QA) döngüsüne sahip bir toptan sürüm güncellemesi gerektiriyordu ve bu da birçok alt ekibi potansiyel olarak yavaşlatıyordu. Tüm uygulamanın kaynak kodu tek bir dağıtım biriminde (.war veya .ear gibi) yerleşik olduğundan, bu yaklaşıma genellikle “monolitik” denir. Bir uygulamanın bir kısmındaki güncellemeler hatalara neden olursa, her şeyin çevrimdışına alınması, ölçeğinin küçültülmesi ve düzeltilmesi gerekiyordu. Bu yaklaşım küçük uygulamalar için hala geçerli olsa da, büyüyen işletmeler hizmet dışı kalma sürelerini göze alamaz.

Uygulamaları bir kurumsal hizmet veri yolu (ESB) aracılığıyla iletişim kuran ayrık, yeniden kullanılabilir hizmetler halinde yapılandıran hizmet odaklı mimariye girin. Bu mimaride, her biri belirli bir iş süreci etrafında düzenlenen bireysel hizmetler, kendilerini ESB aracılığıyla paylaşmak için bir iletişim protokolüne (SOAP, ActiveMQ veya Apache Thrift gibi) bağlıdır. Birlikte ele alındığında, bir ESB aracılığıyla entegre edilen bu hizmet paketi bir uygulamadan oluşur.

Bir yandan bu, hizmetlerin aynı anda oluşturulmasına, test edilmesine ve ayarlanmasına izin verir; artık tek parça geliştirme döngüleri olmaz. Öte yandan, ESB, tüm sistem için tek bir başarısızlık noktasını temsil ediyor – bu nedenle, bir bakıma, monoliti ortadan kaldırma çabası yalnızca yeni bir tane yarattı: potansiyel olarak tüm organizasyonu tıkayabilecek ESB.

SOA’dan mikroservislere

Fark ne? Mikroservisler birbirleriyle genellikle durum bilgisi olmadan iletişim kurabilir, bu nedenle bu şekilde oluşturulan uygulamalar hataya daha dayanıklı olabilir ve tek bir ESB’ye daha az bağımlı olabilir. Bu ayrıca, mikroservisler dilden bağımsız uygulama programlama arabirimleri (API’ler) aracılığıyla iletişim kurabildiğinden, geliştirici ekiplerinin kendi araçlarını seçmesine olanak tanır.

SOA’nın tarihi göz önüne alındığında, mikroservisler aslında o kadar da yeni bir fikir değil. Bununla birlikte, kapsayıcı teknolojilerindeki gelişmeler sayesinde mikroservisler daha uygulanabilir hale geldi. Linux kapsayıcıları ile artık bir uygulamanın birden çok parçasını bağımsız olarak, aynı donanım üzerinde, ayrı parçaları ve yaşam döngüleri üzerinde çok daha fazla kontrol ile çalıştırabilirsiniz. API’ler ve DevOps ekipleriyle birlikte kapsayıcılı mikroservisler, bulutta yerel uygulamaların temelidir.

Ve zorluklar?

Kuruluşunuz bir mikroservis mimarisine geçmeyi düşünüyorsa, yalnızca uygulamaları değil, insanların çalışma şeklini de değiştirmeyi bekleyin. Organizasyonel ve kültürel değişiklikler, kısmen zorluklar olarak tanımlanır, çünkü her ekip kendi dağıtım ritmine sahip olacak ve kendi müşteri grubuyla benzersiz bir hizmetten sorumlu olacaktır. Bunlar tipik geliştirici kaygıları olmayabilir, ancak başarılı bir mikroservis mimarisi için gerekli olacaktır.
Daha fazla: DevOps

Bunlarda ilgini çekebilir

Önceki yazı
PaaS, IaaS ve SaaS Nedir?
Sonraki yazı
Doğru Azure hizmetlerini nasıl seçersiniz?