Microsoft Azure ile katma değerli projeler geliştirmek, müşteri veya kurumumuza minimum maliyet ile maksimum faydayı sağlamak hepimizin motivasyon kaynağı. Ancak taktir edersiniz ki; artık Azure üzerinde sanal sunucu koşturmanın ötesinde işler yapmamız gerekiyor. Aksi durumda maliyetler artmaya devam eder ve yönetilebilirlik oranı düşer. Bu da dijital dönüşüm başlığı altında çokça savunduğumuz “buluta geçiş” vizyonumuzu zedeleyecek önemli bir unsur.
Bahsettiğim bu durumu göz önünde bulunduracak olursak; kurumlardaki uygulamaları en verimli ve en uygun maliyetli hale getirmek yani gerçekten konsolide etmek için en doğru yöntem, kurumdaki uygulamaları ya da servisleri iyi anlamak ve Azure üzerinde verilen doğru servis ile bu uygulamanın modernizasyonunu sağlamak olacaktır.
Ancak; Event Hubs ve Event Grid gibi bazı servisler “e aynı şey” dedirtebiliyor. Bizde aslında bu yazıda senaryolar ile bu servislerin farklarını betimlemeye çalışacağız.
Yazıda önce Event ve Mesaj kavramlarını tanımlayacağım, ardından Azure Event Hubs, Azure Event Grid ve Service Bus hizmetlerinin tanımlarını yapacağım. Tanımlarda örnekler de yer alacak.
Event
Event, herhangi bir durum değişikliğinin basit bir bildirimidir. Event’i yaratan uygulama, event’in nasıl kullanılacağına karışmaz veya sonra ne olacağını beklemez. Uygulama Event’i yaratır ve kendi işine devam eder. Örneğin “ürün alımı tamamlandı, 01.01.2020-15:00PM” şeklinde bir event bırakır ve görevini tamamlar.
Daha sonra tüketici yani bu Event’i kullanacak olan uygulama; bu event’in nasıl kullanılacağına kendisi karar verir. Mesela bir web servisi düşünelim. Bu servis Event’in içeriğini izliyor ve eğer “Sipariş tamamlandı” şeklinde bir event düşerse lojistik departmanına bilgi gönderiyor. “Sipariş tamamlanamadı” şeklinde bir event görürse de destek ekibine detayları gönderiyor gibi örnekleyebiliriz.
Kısaca Event bu örnekteki gibi basit bir olay bilgisidir. Servisler ve/veya uygulamalar bu event’leri izleyerek aksiyon alırlar. Ancak yazılımla çok ilgili değilseniz şöyle düşünebilirsiniz; ben sipariş yaratıldı olayını görebilmek için para verip bir servis mi alacağım? Bunu DB’ye de yazarım, text dosyasına da. Haklısınız. Ama, büyük bir e-ticaret sitesi düşünün. Bir olay nerede başladı hangi badireleri atlattı bunu bilmek onca aksiyon arasında bunu anlamlandırmak değerli ve zor bir iştir. Yukarıdaki sadece küçük bir örnekti. Bu örneği; paketlendi, kargolandı, yüklemede kırıldı, iade edildi, sonra tekrar paketlendi gibi o siparişe ait tüm aktiviteleri görürsünüz. Bu şekilde düşündüğümüzde Event’in uygulamadaki yerini daha iyi anlayabiliriz.
Sonuç olarak Event; seri halinde gerçekleşen olayları rapor eder. Olaylar zamana göre sıralanmıştır ve birbirini takip eden olaylardır. Olayı üreten uygulamanın olay ile hiçbir ilişkisi yoktur. Başka servisler olayları izler, okur veya kullanır.
İki tip event vardır. Bunlar; Discrete (Ayrık) ve Series(Seri veya Dizi)
Discrete Event’ler:
Örneğimizi hatırlayarak okuyacak olursanız; ayrık Event’ler durum değişikliklerini tutar. Yine detay yok. Sadece fatura kesildi. Event sadece faturanın kesildiği bilgisini içerir ve öylece durur. Neden öylece durur dedik? Çünkü yazdığımız gibi bu event’i kullanacak servis ne yapacağına karar verir.
Series Event’ler:
Seri halindeki Event’ler ise aslında birbiri ile ilişkili ayrık olayların bir süreci betimlemesine deriz. Yine açıklamadaki gibi; ödeme alınması, fatura kesilmesi, depoya düşmesi ve kargoya çıkması ayrı ayrı Event’dir ama bir dize oluşturur. IoT cihazlarından gelen telemetri dataları veya uygulama loğları bu duruma örnek olabilir.
Mesaj
Mesaj Event ’den farklı olarak oluşturduğu iletinin (mesajın) nasıl kullanılacağını ve kullanıldığını bekler. Örneğin bankaya girdiniz, oturum açtınız ve size bir mesaj geldi. Sistem bu mesajın ulaştığını, içerisindeki kodu uygulamaya girdiğinizi ve oturumu açtığınızı görmek ister. Bunu bekler yani. Sonuçta da Event ’de olduğu gibi bir aktivite haritası görürsünüz. İstek geldi, mesaj gitti, kod girildi ve başarılı oldu şeklinde. Dolayısıyla önemli farkımız şu ki; Mesaj sonucu bekler, içeriği bilir, tüketicinin yanı kullanacak olan uygulamanın nasıl kullanacağını bilir hatta ona göre data üretir. Bu arada mesaj tam datayı içerir. Event gibi özet bir bilgi değildir. Event sipariş oldu der mesela, mesaj ise siparişin tüm detaylarını bilir.
| Hizmet | Amaç | Tür | Kullanılması gereken durumlar |
| Event Grid | Abonelik ile çalışan basit olay günlükleri | Event dağıtımı (ayrık) | Durum değişikliklerine yanıt verme |
| Event Hubs | Büyük veri işlem | Event akışı (seri) | Telemetri ve dağıtılmış veri akışı |
| Service Bus | Uygulamalar arası mesajlaşma/veri iletişimi. | İleti | Sipariş işleme ve finansal işlemler |
Event Hubs Nedir?
Event Hubs full managed, basit, ölçeklenebilir ve güvenilir bir gerçek zamanlı veri alım hizmetidir. Herhangi bir kaynaktan saniyede milyonlarca event yayınlar.
Aşağıdaki görseli inceleyecek olursak; en soldaki sarı kutular oluşan olaylar. Olayların tamamı Event Hubs’a post ediliyor (Sarı ile yakılanlarda kullanılan protokoller). Event Hubs partition mantığı ile çalışıyor ve dataları birden fazla partition’da tutuyor. Consumer’lar/Tüketiciler/Alıcılar ise bu event’leri kullanıyor. Dolayısıyla milyonlarca servis aynı event’i anında okuyabilir ve işler. Veya tam tersi Event Hubs milyonlarca kaynaktan aynı anda event alıp içerisinde barındırır.
NOT: Event Hubs, “Partition Consumer Pattern” kullanır. Bu anahtar kelimeler ile çalışma mantığı hakkında daha fazla bilgiye ulaşabilirsiniz.
Event Grid Nedir?
Event Grid ise biraz daha basit ortamlarda kullanılan çok hızlı devreye alacağınız basit bir servistir. (Event Hubs’a göre tabi ki)
Teknik olarak bir uygulama ya da servis Event Grid’e abone olur ve evet yollamaya baslar. Sonra siz bu event’ten yola çıkarak isterseniz webhook endpoint’ine gönderirsiniz veya Event Hub/Stream Analytics gibi bu olayı yorumlayacak diğer servise gönderirsiniz. Azure Storage veya Resource Group gibi objelerde bile Event Grid’e abone etmek ister misiniz diye ayarlar görebilirsiniz. Aşağıdaki görsele bakarak bir örnek yazalım hemen.
En sol abone olan uygulamalar ve/veya servisler. Ortada Event Grid ve en sağda ise event grid’in üzerindeki verileri yolladığı olay yorumlayıcılarıdır.
Kucuk bir senaryo vermem gerekirse;
1. Azure Blob Storage Event Grid’e abone edildi.
2. Event Grid artık bu Storage üzerindeki tüm aktiviteleri biliyor. Create, delete, update vs.
3. Sizde bu stor edilmiş olaydan yola çıkarak Azure Automation ve/veya Logic Apps ile IT ekibine mail atabilirsiniz.
Tabi ki bu çok basit oldu. Bunu daha katma değer sağlayacak senaryolar ile kullanmak faydalı olacaktır. Örneğin Azure SQL açılırsa veya Red Hat VM açılırsa haber ver gibi. Çünkü maliyetli bir VM bu ve kontrolsüz açılmış olabilir. Gibi ?
Service Bus Nedir?
FIFO yöntemi ile çalışan, uygulama ve/veya servisleriniz arasındaki mesaj/veri iletişimini sağlayan bir Hybrid entegrasyon hizmetidir. Aslında bir Messaging as a Service (MaaS) hizmeti.
FIFO: First-in-First-Out / İlk giren ilk çıkar yöntemidir.
Service Bus ile on-prem uygulamalarınızın veri alışverişini de yönetebilirsiniz. Birden fazla uygulama aynı Service Bus’ı kullanabilir ve bunlar izole çalışabilir. Gelen mesajların kuyruk süreleri, süre dolduğunda ne yapılacağı gibi yapılandırmalara olanak tanır.
Azure Service Bus; tüm uygulamalarınız için bir mesajlaşma omurgasıdır. Temel olarak tüm uygulamalar ve hizmetlerdeki verileri XML, JSON veya metin biçiminde diğer servisleriniz ile paylaşır/aradaki veri alışverişini sağlar.
Service Bus Namespace: Bir Service Bus içerisinde birden fazla namespace oluşturabilirsiniz. Bunları birbirinden izole uç noktalar gibi düşünebiliriz. Service Bus oluşturulduğunda yapacağımız ilk iş namespace oluşturmaktır. Bütün olay bunun üzerinden gerçekleşecek çünkü. Azure Portal üzerinden veya Service Bus Explorer ile namespace oluşturabilirsiniz.
Eline sağlık.