YAZILIM MİMARİSİ
Microservices Nedir ?
Bu yazımda Microservices Nedir kavramını anlatmaya çalışacağım. Monolithic/Layered → SOA ve daha sonrasında SOA → Microservices geçiş sürecini ve mimari farklılıklarından bahsedeceğim.
Kurumsal uygulamalar geliştirilirken eskiden Monolithic/Layered dediğimiz esasa göre gerçekleştiriliyordu. N Tier dediğimiz bu mimariyi basitçe Veri Katmanı, İş Katmanı ve Arayüz Katmanı olarak ayırıyorduk. Tüm bileşenler veya uygulamalar tek bir Container içerisinde katmanlı yapı içerisinde kodlanıyordu.
Katmanlı Mimari hakkında daha fazla bilgi edinmek için bu yazımı okuyun
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ı.
SOA (Service Oriented Architecture) hakkında daha fazla bilgi edinmek için bu yazımı okuyun
SOA ve ESB’ler dışarıdan görüldüğü gibi kolay şeyler değil tabi.
- Ekiplerin birbirleri ile planlı çalışması gerekiyor.
- Entegrasyon Takımının sürekli olarak ekipleri toplayıp servislerin versiyon kontrolünü ve değişen servis kontrolünü takip etmesi gerekiyor.
Bu seferde servislerin yönetimi her ne kadar ESB gibi altyapılar olsa bile işin doğası gereği çok sancılı bir sürece dönüşüyor.
Normalde EKİP’leri incelediğimizde ekiplerin
Arayüz ekipleri : Mobil (IOS, Android, Windows Phone Developer) / Web (HTML, JS, CSS, Angular, React vb..) konularda arayüz, usability vb konularda uzmanlaşmış ekipler oluyor.
Middleware ekipleri: Spring, Integration, Messaging Queue, J2EE, Web sunucuları, ESB, SOA mimarileri, Web Servisleri gibi business katman konusunda uzmanlaşmış ekipler
Veritabanı ekipleri : MSSQL , MySQL, Oracle, NoSQL veritabanlarından, tablo yapılarından, nasıl sorgu yazılması gerekliliğinden, backup, replikasyon alma sorumluluğunda olan başka ekiplerdir.
Sistem Ekipleri: Uygulamaların kurulacağı, depolanacağı ortamların kurulması, Firewall ve güvenlik ayarlamaları, yetki ayarlamaları, Bulut ve Container ortamlarının hazırlanması sorumluluğunda olan ekiplerdir.
Microservices
Mikroservis sadece bir işi yapan, bir fonksiyonaliteyi gerçekleştiren çok küçük kod parçacıkları. Geliştirme süreçleri, bağımlılıkları, boyutları olabildiğince küçük olan atomik servislerdir diyebiliriz.
Bu servisler herhangi bir dil ile geliştirilebilir. java, c#, ruby, phyton vb. diller kullanarak geliştirme yapabilirsiniz.
Microservisler stateless’dir. Herhangi bir nesnenin state’ini tutmaz.
Microservisler WSDL’daki XSD kontraktları yerine Consumer Driven Contract’lar oluşturarak servis sağlayanın bir kod değişiminin hangi servis tüketicilerini etkilediği , ilgili servis tüketicilerin testleri çalıştırılarak gerçekleştiriliyor.
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 (Arayüz, 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 ve DevOps 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, React). Artık uygulama geliştiricilerinin Full Stack Developer olmasına imkan tanımaktadır.
Microservislerin faydaları;
- mimarinin en baştan kurulmaya çalışmaması,
- ürün geliştikçe mimarinin gelişmesi.
- ekibe sonradan katılan bir kişinin bu kadar büyük bir yapıya, mimariyi öğrenmesi yerine, bu kişinin hangi dilde ve hangi DB ortamında işi yapmasını biliyor ise bu ortamda bu ufak iş mantığını geliştirme imkanı vermesi.
- aynı zamanda bu atomik yapıların sırasını ve hiyerarşini değiştirme imkanı vermesi,
- uygulamanın daha esnek,
- tekrar kullanılabilir
- ölçeklenebilir olmasına imkan vermesidir.
SOA mimarisinde merkezde orchestration mekanizması(ESB) ile tüm iş akışlarında(business flow) merkezdeki yapı tarafından organize ediliyor. Önceki yazılarımda Mediator pattern’i ile benzerlik kuran bu yapı. Giderek merkezin yükünü arttırmaya başlıyor. Hem network , hemde çalışan sorumluluğu açısından bu servisleri orkestra eden kişilere bağımlılık inanılmaz boyutlara ulaşıyor.
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.
Microservis iş mantığı bir Container içerisinde saklı. (Siz bu Container isterseniz Docker olarak düşünebilirsiniz) Bu dışarıya Servis veriyor ve bir takım servisleri kullanıyor. İçerisinde Config, Policy(Kurallar), Security(Güvenlik) ve Veriyi tutuyor.
Yukarıdaki şekilde ortak altyapı servisleri hazır olan bir sistemin iş mantıklarını ve akışları ile eklemek oldukça kolay olacaktır.
- Management Service: Container yönetim Servisi (Kubernetes, EKS, Fargate, Lambda … farklı farklı yönetim seviyelerini görebilirsiniz)
- Service Registry Service: Microservislerin kayıtlarını tutan ve arayanlara bunun bilgilerini sağlayan servisler.
- Authorization/Authentication Service: Kimlik Doğrulama ve Yetkilendirme Servisi (Auth0, Cognito, … )
- Logging / Transaction Logging Service: Loglama Servisi
- Usage Tracking Service: Kullanım Takibi
- Persistance Service: Depolama Servisleri
- Business Reference Service
- Location Service: Lokasyon servisleri
- Config Mngt Service: Konfigürasyon Servisleri
- Monitoring Service: Distributed(Dağıtık) bir sistem üzerinde çalışan tüm servisleri görüntüleme , izleme servisi
- Testing Service: Microservis test için kullanabileceğiniz servislerin bulunması,
- Key Service, Policy Management Service, Cache Service vb..
Bu kadar çok servisin bir sürü sanal makineye kurulumunun manual olarak yapılması imkansız. Bunun için “Infrastructure As a Code” IaC kavramını geliştirmişler. Infrastuctrure’ları (Altyapıları) kod ile ayağa kaldırıp uygulamaların bu infrastructure’lar üzerine hızlıca çalışmasını sağlıyorlar. (Örneğin AWS Cloudformation)
CI/CD (Continues Integration ve Continues Delivery) kavramlarının çok iyi oturması gerekiyor. Herhangi T anında belirlenen X sunucularına, Y,Z Feature set değişikliklerini deploy edebilme yeteneğidir.
Referanslar
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
