Distributed Application Konusunu Tartışalım
Bu konuya girmeden önce “Distributed Application” konusunu biraz konuşmamız lazım. Neden bir uygulamayı oluşturmak için farklı sunucularda çalışan farklı databaseleri olan birçok küçük bileşene ayırıyoruz? Evet şu da tabii ki mümkün! Tüm uygulamayı monolit bir tasarım mantığı ile yazmak! Hatta çoğu zaman böyle yazmamak da bir hata.
Microservice konusunun son zamanlarda çok popüler olduğu kesin ve biz meraklı yazılımcılar bir ucundan tutup, hesap makinasına dahi mikroservis yazmaya başladık. Toplama işlemi için başka bir proje, çıkarma işlemi için ayrı bi uygulama gibi 🙂 . Bunun doğruluğu tartışılır tabii ki; imkan ve kaynak meselesi diyelim. Haa! Bir de kalp sağlığınızın ve psikolojinizin de müsait olması lazım! “Tabi Dapr gibi bir Distributed Application Runtime kullanmıyorsanız” deyip arada reklam da geçmek isterim.
“Microservices architecture, büyük ve kompleks uygulamaların geliştirilmesine ve yönetilmesine olanak tanır.” denir ya, yanlış tasarlarsanız ortaya çıkabilecek karmaşayı hayal bile edemezsiniz. Miksorservis hayali ile çıktığımız bu yol hatalı tasarımdan kaynaklanan sorunları çözebilmek için veritabanının ortak, uygulamaların ayrı yazıldığı ne idüğü belirsiz bir yapıya (mimari demiyorum özellikle) dönüşüverir.
Buraya kadar mikroservis mimarilerini yerdiğimiz doğrudur. Şimdi de yüceltme zamanı!
Doğru mimarileri esneklik, hız ve verimlilik, kolay yönetim, kaynak kullanımı konularında elimizi çok güçlendirdiği kesin. Her birinin detayına girmeyeceğim çünkü amacım tam olarak bu avantajları maksimum fayda ile kullanabileceğimiz mimariyi nasıl kurgulayacağımız ve bu kurguda Darp’ın rolü. Malum yukarıda bahsettiğim faydaları sağlamaya başlamak hem karmaşık problemlerin üstesinden kolaylalıkla gelmeyi, uygulamanın bütçesini daha düşük seviyelere çekmeyi, sürpriz problemlerden veya gece gelen acı telefonlardan kurtulmanızı sağlayabilir.
Distributed Application Runtime Olmadan İşleri Nasıl Hallediyorum?
Şimdi örnek bir problemi Distributed Application Runtime kullanmadan nasıl çözmeye çalıştığımı anlatayım size,
Çüzümleyeme çalıştığım sorunlarımdan birtanesi Distributed Transanction konusu, bunu bir event bus library kullanarak halletmeye çalışıyorum. Bu library Masstransit’in ta kendisi. Masstransit sizinde malumunuz Saga patterni uygulayabileceğiniz yerleşik bir alt yapı sunmakta.
Yapmış olduğunuz her bir transaction için bir event tetikleyip bu eventi StateMachine dediğimiz yapıda yöneterek devamında hangi eventleri fırlatması gerektiğini tanımladığımız, oluşan tüm bu hareketlerin de Redis’de ya da başka bir veritabanında loglayabilceğimiz bir alt yapı sunuyor. Dolayısıyla herhangi bir transaction işlemi gerçekleştiğinde bu transactionın etkilediği tüm microservisleri ve herhangi bir başarısızlık durumunda yine gerisin geriye tüm işlemlerin geri alınmasını sağlayacak yapıların statemachine de yöneteceğimiz hazır yapılar sunmakta.
Büyük ve karmaşık iş kuralları olan bir projede, onlarca statemachine tasarladığımızı düşünecek olursak, belli bir süre sonra yapıyı bir arkadaşımıza anlatmaya çalıştığımızda, tamamen akışları kurgulayan ekibin bile kafası karışmaya başlıyor.
Gönlümün Efendisi Dapr.io (Distributed Application Runtime)
Dapr tam olarak bu tarz karmaşık yönetim sorunlarına çözüm üretmek konusunda devreye giriyor. Çalışma mantığını şu şekilde ifade edebilirim. Uygulamanızın hangi dilde veya hangi teknoloji ile yazıldığı fark etmeksizin hemen önünde konumlandırdığı “sidecar” diye isimlendirdiğimiz küçük bir app yerleştiriyor. Artık bizim uygulamamız hemen önümüzde duran Dapr’ın bize sunduğu apiler ile konuşmaya başlıyor.
Sidecar ifadesinin dapr için ne ifade ettiğini sadece bir resimle anlatmaya çalışacağım.
Her bir Dapr sidecarın kendisine ait benzersiz bir kimliği var. Bu kimlik artık sizin uygulamanızı temsil ediyor. Uygulamaya erişmek isteyen başka bir api ya da client farketmeksizin artık uygulanın önünde duran sidecar Dapr uygulamasının apilerini biliyor ve sizin atadığınız benzersiz kimlik ile artık uygulamanıza ulaşıyor.
Uygulamanın hemen önünde duran sidecar ihtiyaç duyabileceğimiz, Pub-Sub, StateManagment, Service-to-Service Invocation, Secret, Aktors gibi tüm yeteneklerini yönetiyor. Siz sadece hemen önünüde duran sidecara isteğinizi Http-Api yada Grpc-Api olarak iletmeniz yeterli.
Sidecarın yönettiği birçok farklı kavramdan bahsettim. Pub-Sub, StateMachine gibi. Tüm bu konular ile devam edeceğim makalelerde ayrı ayrı senaryolar üretip örnekler yapacağım. Örneğin yukarıdaki Dapr’sız bir dünyada yaşadığım Distributed Transanction sorununu Pub-Sub ve Actor Model kullanarak ileriki makalelerde çözeceğiz.
Tüm bu yazının sonunda evet microservis mimarilerinin birçok zorlukları var . Tüm bu zorlukların üstesinden Darp isimli Distributed Application Runtime teknolojisini öğrenerek gelebileceğimiz fikrinin oluşmasını amaçladım. Gelecek örnekler ile beraber de bu fikri tek tek pekiştireceğiz.
Görüşmek üzere.
