Bir yazılımın dağıtım ve bakım sürecinde yönetilmesi gereken birçok unsur vardır. Bunlar arasında sanal makine (VM) sağlama, yamalama, kimlik doğrulama ve yetkilendirme, web yükü dengeleme, depolama entegrasyonu ve yedeklilik, ağ güvenliği, yedekleme ve kurtarma ile denetim yer alır. Tüm bunlara ek olarak, uyumluluğun yönetilmesi ve tüm bu süreçlerin sorunsuz yürütülmesi gerekir. Bu süreçleri kolaylaştırma modern bir mimari işle mümkündür.

Bu işlevleri sağlamak için gereken tüm araçları entegre etmek ve bunların sorunsuz bir şekilde birlikte çalışmasını sağlamak zor olabilir. Farklı sistemleri entegre ederken genellikle şu gibi sorunlarla karşılaşırsınız:

  • Ölçeklenebilirlik: Sistem üzerindeki yük arttıkça mimari bileşenleri dikey veya yatay olarak ne kadar kolay ölçeklendirebiliriz?
  • Ayrılabilirlik (Decoupling): Sistemin bileşenlerinden birini minimum değişiklik veya kesintiyle benzer bir ürünle değiştirebilir misiniz? İdeal bir mimaride her bir sistem bileşeni, mimarinin diğer bölümlerinin nasıl çalıştığıyla ilgilenmemelidir.
  • Yaşam Döngüsü Yönetimi (Lifecycling): Bir bileşeni güncellemeniz gerektiğinde, bu değişiklik diğer bileşenleri etkilemeden yapılabiliyor mu? Yedeklilik, yüksek erişilebilirlik ve felaket kurtarma, sağlam bir mimari tasarımın önemli bileşenleridir.
  • Mimari Esneklik: Bir sistemin bileşenleri, diğer bileşenlerin nerede çalıştığını önemsememelidir. Ağ gecikmesi, performans ve bölgesel erişilebilirlik önemli faktörler olsa da, bir bileşenin genel bulutta, özel bulutta, şirket içi altyapıda veya uç bilişim ortamında çalışması, diğer bileşenlerin davranışını etkilememelidir.

GAMES Mimari Kalıpları

Her kuruluşun farklı ihtiyaçları vardır ve belirli iş fonksiyonlarını desteklerken bazı konuları göz önünde bulundurmak gerekir. Bunlar:

  • Konum: Sistem şirket içinde mi, bulutta mı çalışmalı? Eğer bulutta olacaksa, özel mi yoksa genel bulut mu kullanılmalı?
  • Yazılım: Fiziksel bir sunucuda mı, bir sanal makinede mi, bir konteyner içinde mi yoksa SaaS (Hizmet olarak Yazılım) olarak mı tüketilmeli?
  • Entegrasyon: Sistemler doğrudan bağlantı, API çağrıları veya diğer yöntemlerle mi entegre olmalı?

Yıllar boyunca müşteriler ve şirketlerle yapılan etkileşimlere dayanarak, aşağıdaki beş bileşenin tüm yazılım süreçleri için basit, ölçeklenebilir ve esnek bir mimari sunduğunu gördük:

  1. GitOps (Kodsal Yapılandırma)
  2. API
  3. Mikro hizmetler
  4. Aracı (Broker) üzerinden olay odaklı fonksiyonlar
  5. Paylaşılan Hizmetler Platformu

Bu üstteki bileşenlerin İngilizce isimlerinin baş harfleri yan yana geldiğinde GAMES diye okunduğundan mimari kalıpların ismi bu şekilde anılmakta.

GitOps ve Kodsal Yapılandırma

GitOps veya kodsal yapılandırma yaklaşımı, kodu (uygulama işlevselliği ve yapılandırması) ve altyapıyı tek bir kaynak olarak Git depoları üzerinden yönetme yöntemidir. Ana noktalar şunlardır:

  • Altyapı ve uygulama yapılandırması Git üzerinde sürümlenir.
  • Yapılandırmalar otomatik olarak Git’ten uç noktalara senkronize edilir.
  • Drift tespiti, görselleştirme ve düzeltme sağlanır.
  • Kompleks dağıtımlar için senkronizasyon sırası hassas şekilde kontrol edilebilir.
  • Git’teki herhangi bir sürüme geri alma veya ileri taşıma mümkündür.
  • Manifest şablonlama desteği
  • Senkronizasyon durumu ve geçmişine dair içgörü
  • Kubernetes üzerinde GitOps’u uygulamak için yaygın kullanılan bir araç ArgoCD‘dir.

GitOps uygulama teslim modelini aşağıdaki üst düzey diyagram modeliyle daha iyi anlayabilirsiniz:

Bu yaklaşımın faydaları şunlardır:

  • GitOps, yapılandırma kaymasını (configuration drift) önlemenizi sağlar. Örneğin, uygulama yapılandırmasının durumu ve gerçek platform yapılandırması, sıkı tanımlamalar içeren Git depolarına uyumlu hale getirilir. Bir tutarsızlık olması durumunda, GitOps, Git’te yapılandırılmış olan verilere göre farklılıkları yeniden hizalar.
  • “Build” araç zincirlerinin dağıtım ortamlarından ayrılmasına (decoupling) olanak tanır. Örneğin, farklı geliştirme ekipleri farklı araçlar kullanarak yazılım bileşenlerini oluşturabilir (bir ekip Jenkins kullanırken, bir diğer ekip Azure DevOps kullanabilir), ancak bu bileşenlerin farklı ortamlara dağıtımı tek bir araç (ArgoCD) ile yönetilebilir.
  • Tüm yazılım bileşenlerine erişimi olan bir “Tanrı Modu” (God Mode) araç zincirine artık ihtiyaç kalmaz. Bu da güvenlik ekiplerini sevindirir 😊

API

API (Uygulama Programlama Arayüzü), bir yazılım bileşeniyle etkileşim kurmak için yayınlanan bir yöntemler tanımıdır. API’nin en büyük avantajlarından biri, bileşenlerin birbirinden ayrılmasını (decoupling) sağlamasıdır. Temel olarak, iki tür API vardır:

  • Harici API: Kullanıcı memnuniyetini artırmayı, müşteri kaybını azaltmayı ve hizmet tüketimini artırarak gelir elde etmeyi amaçlar.
  • Dahili API: Maliyetleri azaltmayı ve inovasyonu desteklemeyi amaçlar.

Kuruluşlar, bir API’nin yayınlanmasına ilişkin politika ve güvenlik tanımlayarak dahili ve harici API politikalarını uygular. Bu politikayı uygulamanın bir yolu, API geçidi (API gateway) kullanmaktır. API geçidi, kimlik doğrulama, yetkilendirme, denetim günlükleri ve hız sınırlama gibi tutarlı bir güvenlik özellikleri seti sunar. Ayrıca, API çağrılarıyla ilgili analizler sağlayarak, sistemler arasında değerin nasıl dağıtıldığına dair içgörü kazandırır.

Bu yetenekler sayesinde yalnızca yetkili kişiler veya sistemler bir API’ye erişebilir ve bunu hem güvenli bir şekilde hem de kuruluşun belirlediği ticari sözleşmelere uygun olarak yapabilir.

API kullanımının birkaç önemli avantajı vardır:

  • API’nin uygulanması ile hizmetin tanımı birbirinden ayrılır (decoupling).
  • API sistemi herhangi bir altyapıda barındırılabilir, farklı ortamlar arasında kolayca taşınabilir veya yayılabilir. Bu da bağımsızlık ve taşınabilirlik sağlar.
  • API, uç noktalar arasında bir sözleşme sunduğu için, her bileşen bağımsız olarak yaşam döngüsüne alınabilir. Böylece tüm uç noktaları aynı anda güncellemek yerine, her bileşeni ayrı ayrı yönetmek mümkün olur.

Mikro Hizmetler

Mikro hizmetler, monolitik mimarilere karşı geliştirilen ve özellikle bulut tabanlı teknolojilerle ilişkilendirilen bir yazılım geliştirme yaklaşımıdır. Bir monolitin aksine, mikro hizmet tabanlı bir uygulama, API’ler aracılığıyla birbirleriyle iletişim kuran bağımsız hizmetlerden oluşur.

Tüm işlevlerin ve hizmetlerin tek bir uygulama içinde, birbirine bağlı ve tek bir birim olarak çalıştığı (monolitik yapı) bir sistem yerine, mikro hizmet tabanlı bir uygulama, hafif API’ler aracılığıyla iletişim kuran bağımsız hizmetlerden oluşur. Bu sayede, uygulamanın farklı işlevleri bağımsız olarak dağıtılabilir, yönetilebilir ve çalıştırılabilir.

Bir uygulamanın bileşenleri bu şekilde ayrıldığında, geliştirme ve operasyon ekipleri birbirine engel olmadan eş zamanlı olarak çalışabilir.

Aşağıdaki diyagram, monolitik bir uygulama ile mikro hizmet tabanlı bir uygulama arasındaki farkı göstermektedir.

Mikro hizmetlerin temelini oluşturan en önemli teknolojilerden biri konteynerleştirme (containerization) yöntemidir. Konteynerler, bir uygulamanın geliştirme (dev), test ve üretim (production) gibi farklı ortamlar arasında kolayca taşınmasını sağlar.

Konteynerleştirme, bağımsız yazılım satıcıları (ISV) pazarında önemli bir trend haline gelmiştir ve günümüzde giderek daha fazla yazılım, varsayılan olarak konteynerleştirilmiş uygulamalar olarak sunulmaktadır.

Bu yaklaşım sayesinde:

  • Kaynak kullanımı iyileştirilir: Konteynerler, yalnızca çalıştırılan uygulamanın ihtiyaç duyduğu kütüphaneleri içerir.
  • Geliştirme döngüleri kısalır: Geliştirme ekipleri, bekleme süresi olmadan hızlıca geliştirme ve test ortamlarını yeniden oluşturabilir.
  • Taşınabilirlik artar: Konteynerler, çalıştırıldıkları işletim sistemini bilmeden çalışabilir.
  • Güvenlik iyileştirilir: Konteynerler, yalnızca gerekli bileşenleri içerdiğinden saldırı yüzeyi azalır.

Aracı Üzerinden Event Odaklı Fonksiyonlar

Bir olay aracısı, büyük miktarda veriyi hızlı bir şekilde aracılık etmekten sorumludur. Verilerin konuya göre sınıflandırılmasına olanak tanır, böylece belirli bir konudaki uygulamalar yalnızca ilgili bilgileri alabilir.

Geleneksel olarak, her veri türü doğrudan belirli bir uygulamaya (güvenlikteki günlükler, teminatta performans ölçümleri vb.) bağlanır. Bu verilere erişmek isteyen başka bir uygulama, bu veriyi barındıran uygulama ile entegrasyon yapmak zorunda kalır. Bu durum karmaşık ve maliyetli hale gelebilir. Bir aracı kullanıldığında, bir grup yayıncı ve tüketici belirli konulardan veri yayınlar veya tüketir, bu da veriye genel erişimi basitleştirir.

Brokering teknolojisi örneklerinden biri Kafka’dır. Aşağıda Kafka sistem bileşenlerinin basitleştirilmiş bir görünümü gösterilmektedir.

API kullanımına benzer şekilde, bir aracı (broker) kullanmak, olay uç noktalarının (üreticiler ve tüketiciler olarak sonuçlanan) ayrışmasına olanak tanır.

Bu fikir, gelen bilgileri işlemekle sorumlu olan bileşenin bunu kendi hızında yapabilmesini sağlarken, aynı zamanda belirli bir konuda bilgi gönderen sistemler için esneklik sunmaktır. Örneğin, bu, iki sistem arasındaki geçiş sırasında veya mevcut bir sistemin bir konuda yayın yaparken başka bir altyapıya taşındığı bir geçiş sürecinde (belki de bir bulut geçişi sırasında) kullanılabilir.

Bu yaklaşım, olay bildirimlerini (producers) ve tüketicileri (consumers) birbirinden bağımsız hale getirerek:

  • Dayanıklılığı artırır: Bir bileşen, kesinti sonrası iyi bir durumdan devam edebilir.
  • Bağımsız ölçeklendirme sağlar: Üreticiler ve tüketiciler birbirlerinden bağımsız olarak ölçeklenebilir.

Paylaşılan Hizmetler Platformu

Konteynerler, modern mimarilerin temelini oluşturan önemli bir teknolojidir. İlginç bir şekilde, daha önce tartışılan tüm platform fonksiyonları “containerized” uygulamalar olarak dağıtılabilir: GitOps, API geçitleri, olay aracısı ve mikro hizmetler kendileri.

Bu, iş uygulamaları veya fonksiyon gruplarını farklı altyapılarda (özel sunucular veya sanal makineler gibi) dağıtmanız gerekmediği anlamına gelir. Ayrıca her birini kendi araçları ve süreçleriyle bağımsız olarak yönetmeniz de gerekmez. Artık bu uygulamaları ve fonksiyonları tek bir konteyner ortamında yönetmek için ortak bir platform sağlamak mümkündür.

Bu yaklaşım, hizmetleri tek bir platforma devrederek uygulamaların yönetimini basitleştirir. İdealde, bu platform aynı zamanda altyapıdan bağımsızdır ve tekrarlanabilir patternler ve dağıtım için bütünlüklü bir set sağlar.

Sonuç

Mikro hizmetler, küçük ve modüler bileşenler oluşturarak hızlı ve kolay entegrasyon imkanı sunar. GAMES olay odaklı mimarisi, GitOps, API, mikro hizmetler ve olay aracılarından oluşan tam bir paylaşılan hizmetler platformu sunarak:

  • Bileşenlerin şeffaf bir şekilde taşınmasını sağlar.
  • Farklı sistemlerin kolayca entegre olmasına olanak tanır.
  • Altyapıdan bağımsız çalışabilen esnek çözümler üretir.

Günümüz yazılım dağıtımlarında, yönetimi kolay ve verimli bir platform sunmak büyük önem taşımaktadır. Bu yönde büyük kolaylık sağlayan bu çözümü detaylıca dinlemek isterseniz bizimle her zaman iletişime geçebilirsiniz: info@quasys.com.tr

Kaynak: https://www.redhat.com/en/blog/event-driven-architecture-modern-applications

Yorumlar kapalı.