SOA(Service Oriented Architecture) ve Monolithic Sistem Nedir?

Günümüzde proje mimarileri SOA(Service Oriented Architecture) temeline dayanmaktadır.100 lerce proje geliştirilmiş bir şirket düşünün. Zaman içinde bu uygulamalar giderek artmış ve aynı veritabanı üzerine kullanılan bir sürü proje olmuş. Her projenin ekstra ihtiyaçları doğrultusunda veritaban tabloları giderek artmış, üzerine yapılan sorgular giderek artmış ve karmaşıklık bu işi başka bir şekilde çözmeye itmiş. SOA ve monolithic sistemler sayesinde verinin yönetimi, business mantıklarının tekrar tekrar yazımının engellendi, uygulamaların direk veritabanı katmanına erişmesi yerine önünde tekrar kullanabilen servislerin bulundu.

Üstte gördüğünüz SOA Mimari grafiğini basitçe Veri Katmanı, İş Katmanı ve Arayüz Katmanı olarak düşünebiliriz. Tüm bileşenler veya uygulamalar tek bir Container içerisinde katmanlı yapı içerisinde kodlanıyordu. Daha sonra sistemler ve projeler biraz daha geliştikten sonra WSDL dediğimiz kavramlar ile birlikte SOA(Servis Odaklı Mimari) ler gelişmeye başladı. Bunun ile birlikte Servis yönetimini ve SOA sorunlarını gidermeye çalışan ESB’ler çıktı.Peki nedir bu ESBler?

ESB (Enterprise Service Bus) Nedir?

ESB ;  SOA mimarisinin uygulanması için bir kalıp (pattern) görevini gören, çeşitli altyapısal hizmetleri sunan, heterojen ortamlarda dahi çalışabilen, böylelikle entegrasyonu kolaylaştıran hafif bir altyapı mimarisidir. Bu altyapı yeni bir ürün kategorisi olarak ortaya çıkmakta veya mevcut ürünler ESB özellikleri ön plana çıkarılarak pazarlanmaktadır. Bu tanım sonrası ESB , SOA ile bağlantılı oluşu kafa karışıklığına neden oluyor. ESB Kurumsal Veri Yolu (KVY) şeklinde ifade edilebilir. SOA kavramı ise Servis Odaklı Mimari şeklinde kullanılabilir ikisi farklı sistemlerdir.

JAVA tabanlı sistemlerde yaygın olarak kullanılmaktadır. Bu mimarinin ilk olarak çıkışı 2002 yılında Gartner Group ta , Roy W. Schulte ‘a atfedilir. SONIC Software de çalışan David Chappell, “The Enterprise Service Bus” isimli bir kitap ile bu mimariden bahsetmiş, ancak uzun yıllar öncesinde de bu mimarinin isimlendirilmeden kullanıldığına dair ortak bir inanç bulunmaktadır. ESB’ler ; servisleri ve uygulamaları entegre etmek için esnek bir yapı sağlarlar. Servisler arası mesajları yönlendirirler. Servis ve isteği yapan arasında protokol dönüşümü , mesaj dönüşümü yaparlar. Farklı protokollerle mesajlaşmayı desteklerlerler. Bir protokolden diğerine dönüşümü sağlayabilirler. Sadece SOAP mesajları değil, farklı mesaj tipleriyle de çalışabilirler. (JMS, REST, XML vs.). Yani farklı platform ve sistemlerin birbirleriyle “konuşabilmelerini” sağlarlar.  ESB ile birlikte kurumlar, mevcutta var olan uygulamalar arasındaki entegrasyon yapılarını yeniden şekillendirmektedirler. Buna göre artık “Miras(Legacy)” adını verdiğimiz kurum içerisindeki eski uygulamalara, yatırım kaybı olarak bakılmamaktadır. Bu uygulamalardan modüler servisler üretilerek bir yandan uygulamalar arasındaki entegrasyon ihtiyaçları giderilirken diğer yandan servis odaklı yeni bir hizmet mantığına geçilmektedir. Artık “Peer to Peer”  olarak bilinen her uygulamanın bir diğer uygulama ile entegrasyonu yöntemi terk edilirken, bunun yerine bütün uygulamaların üzerinde yeni bir katman olarak “ESB” konumlandırılmaktadır.Alt kısımda gördüğünüz gösterimde farklı yazılım uygulamalarının, kullandığı farklı iletişim protokollerine göre birbirleri ile ESB altyapısını kullanarak nasıl haberleştiklerinin gösterimini görürsünüz.

Özetle ESB nin görevleri :

• ESB’ler dağıtık Servisleri birleştirmeye, çalıştırmaya ve yönetmeye yarar.
• ESB’ ler dağıtık çalışan, standartlara dayanan entegrasyon ve kurumsal bir altyapı sunar.
• Geleneksel sistemler sıkı semantik bağlarla kurulmuştur eğer bu semantik zincirinin bir halkası kırılırsa bütün zincir kırılmış olur. Halbuki ESB’ler semantik dönüşümlerini mümkün kılar.
• ESB fiziksel bağlantıları soyutlaştırır böylelikle konum bağımsızlığı kazanılır.
• ESB içinde iş süreçlerini uygulayabilecek yada iş mantığını uygulayabilecek araçlar bulunabilir.
• ESB içeriğe göre akıllı mesaj yönlendirmesi yada filtreleme bulundurabilir.
• ESB’ler farklı protokollerle mesajlaşmayı destekler. Bir protokolden diğerine dönüşümü sağlayabilir.
• Sadece SOAP mesajları değil, farklı mesaj tipleriyle de çalışabilir. (JMS, REST, XML vs.)
• Servislere Güvenlik hizmetleri sağlayabilir onları koruyabilir.
• Hizmet Seviyesi Anlaşmalarına (SLA) dayanarak servisleri gözlemleyebilir ve alarmlar oluşturabilir.

Özetle ESB nin faydaları :

• Entegrasyon maliyetlerinde tasarruf
• Toplam sahip olma maliyetlerinde tasarruf
• Daha kısa servis geliştirme zamanları
• Kurumsal Süreç otomasyonu için altyapının oluşturulması
• Kurumda var olan uygulamaların kolayca servis haline dönüştürülmesi
• Servislerin kolaylıkla farklı Protokollere açılımının sağlanması (Protokoller arası geçişlilik)

Mikroservis Nedir?

Mikroservis en kısa tabiriyle , küçük , otonom ve bir arada çalışan servislerdir.  Yazılım projesine yeni fonksiyonellikler eklendikçe , kodlar büyür.  Bir zaman sonra,  projeye hakim olmak, eklentiler yapmak ve karşımıza çıkan sıkıntıları çözmek zor bir hal almaya başlar. Normalde, monolitik bir proje içerisinde , bu gibi problemlerle mücadele edebilmek için kodumuzda olabildiğince soyutlamalar ve modüller oluştururuz.

Monolithic vs Mikroservis Mimarileri?

Yukarıdaki resimde de görüldüğü üzere monolitik bir uygulamada tüm uygulama direkt olarak tek bir database’e bağlıdır ve bu birazdan bahsedeceğimiz büyük sorunları da beraberinde getirir. Mikroservis mimarisinin yaptığı, uygulamamızı olabildiğince ufak ve kendi database’ine sahip servislere bölmek ve bu şekilde çalıştırmaktır.

Mikroservis yapısı sürekli ve plansız bir şekilde büyüyen monolitik yapıdaki servislerin, beraberinde getirdiği karmaşıklığı ve yönetim zorluklarını çözmeye odaklanmaktadır. Kesinlikle SOA’ya alternatif bir model değildir. Mikroservis mimarisinin avantajları:

• Servisler farklı dillerde ve farklı framework’lerde geliştirilebilir.
• Birbirlerinden bağımsız olarak her bir servis değişebilir, kolay test ve build yapılabilir.
• Continuous delivery’e olanak sağlar ve hızlı deployment’lar gerçekleştirilebilinir.
• Her bir servisi birbirinden bağımsız olarak scale edebilme olanağı sağlar.
• Her bir servis birbirinden bağımsız olacağı için, code base’i sade ve maintenance’ı kolay olacaktır
• Versiyonlama kolay bir şekilde yapılabilecektir.
• Mikroservisler statelesstir. Herhangi bir nesnenin state bilgisini tutmaz.
• Mimarinin en baştan kurulmasına gerek yoktur, ürün geliştikçe mimaride gelişir.
• Ekibe sonradan katılanlar projeye daha kolay adapte olur.
• Mikroservislerin sırasını ve hiyerarşisini değiştirmeye imkan verir.
• Uygulamanın daha esnek, daha reusabe ve daha scalable olmasına imkan verir.

Mikroservislerinde kendilerine göre dezavantajları vardır. Bunlar;

• Birbirlerinden bağımsızlaşan farklı servisler aynı objeleri kullanacaklarından dolayı kaçınılmaz bir kod tekrarı meydana gelecektir.
• Servisler farklı platform ve ortamlarda çalışabileceklerinden dolayı yönetim ve monitoring maliyeti ortaya çıkacaktır.
• Birden çok database ve transaction’ların yönetimi zor olabilir.

Microservislere Hazır Mıyız?

Ekip ve Şirket yapısının değişmesi gerekiyor. Demin yukarıda bahsettiğimiz farklı konularda uzmanlaşmış birbirlerinden ayrı çalışan ekip elemanlarının (Arayuz, Spring, Veritabanı ve Sistemci) olacak şekilde ekipler haline getirilmesi gerekir ki, bu da çok maliyetli bir iştir. Bunun yerine son dönemde Full Stack Developer kavramı popülerleşmeye başlamıştır. Uygulama yükleme ve geliştirme araçlarının giderek gelişmesi Bulut/Container Servislerinin giderek artması, Yazılım kısmında frameworklerin artması (Spring, Hibernate, AngularJS). Artık uygulama geliştiricilerinin Full Stack Developer olmasına imkan tanımaktadır.

Microservislerin çok ufak şekilde hızlı bir şekilde gerçekleştirebilmeniz için sistem içerisinde aşağıdakine benzer mircroservislerinizin hazır olması gerekiyor.

Mikroservis Mimarisine Geçilirken Karşılaşılabilecek Bazı Sıkıntılar…

• Önceki sistemde RDBMS kullanılıyorsa çoğu sorgunun değişmesi gerekebilir. Örneğin, her servisin kendi database’i olacağından join kullanımını önceki sistemdeki halinden farklılaştırılmak zorunda kalınacaktır.
• Kullanıcı session yönetimi yapısı farklılaştırılmak zorunda kalınabilir.
• Servisler farklı platformda ve ortamlarda çalışabileceğinden, bunların yönetim ve monitoring maliyeti doğacaktır.
• Fazlaca database ve transaction yönetimi zor olabilir.