Hizmet ağı, bir uygulamanın ayrı bölümlerinin birbiriyle iletişim kurmasını sağlamak için bir ağ üzerinden hizmetten hizmete iletişimi kontrol eden bir BT altyapısı katmanıdır. Bulut tabanlı bir mimaride kapsayıcılar arasındaki iletişimi sağlamak için genellikle zarif bir yaklaşım olarak kullanılır.
Ancak kapsayıcılı, hibrit ortamlardaki uygulamalar arasındaki veri iletişiminin optimizasyonu, karmaşıklığın ve hatta maliyetin üstesinden gelinmesine yardımcı olabilirken, bu mutlaka bir hizmet ağı mimarisini zorunlu kılmaz.
Makine kimlik yönetimi tedarikçisi ve Kubernetes danışmanı Venafi’de çözüm mimarı olan Steve Judd, uygulama mantığını ağ oluşturma tarafından ayırmak için bir hizmet ağı kullanmanın her kuruluş için karmaşık BT yönetimi baş ağrılarını mutlaka azaltmayacağı konusunda uyarıyor. Ancak bazı güvenlik avantajları sağlar.
Kubernetes kapsayıcılarının bir tür ağ üzerinden birbirleriyle konuşması gerekir. Ancak Computer Weekly’ye, herhangi bir kabın bir kümedeki diğer herhangi bir kapsayıcıyla “konuşabildiği” düz bir iletişim mimarisine sahip olmanın sorunlu olduğunu söylüyor.
Judd, “Güvenlik nedeniyle, muhtemelen bu iş yüklerinden bazılarını izole etmek istiyorsunuz, böylece istedikleri şeyle konuşmakta özgür olmayacaklar,” diye ekliyor Judd. “Karşılıklı TLS aracılığıyla birbirleriyle etkili bir şekilde kimlik doğrulaması yapabilmek için farklı kapsayıcıları isteyebilirsiniz. [transport layer security]”
Kötü niyetli aktörler, bulut yerel mimarilerini hedefleyebilir, bu nedenle ağ optimizasyonu ve yönetimi düşünülürken güvenlik ve uyumluluk hususları kilit önemde olmaya devam eder. Baş bilgi güvenliği görevlileri (CISO’lar) karşılıklı TLS gerektirebilir. Varsayılan olarak hizmet ağı, bu güvenlik sertifikalarının bağımsız bir şekilde yönetilmesine yardımcı olabilir.
Judd, Linkerd veya Istio dahil olmak üzere başlıca hizmet ağı seçeneklerinin karşılıklı TLS portunu kutudan çıkarır çıkarmaz sağladığını ve Istio’nun Linkerd’den daha “mutfak lavabosu” yaklaşımı olduğunu söylüyor.
Karmaşıklık artı – veya bazıları için eksi
Şimdilik, bankalar ve diğer finansal hizmet sağlayıcılar gibi yüksek oranda düzenlenmiş sektörler ve sektörler, hizmet ağı teknolojilerinin en büyük uygulayıcıları olacak gibi görünüyor. Bunun nedeni, bir hizmet ağının bir Kubernetes ortamında belirli düzenleyici uyumluluk gereksinimlerini karşılamanın bir yolunu sunmasıdır.
Judd şöyle açıklıyor: “Mikro hizmet uygulamalarında çalışan uygulamalara dokunmanız gerekmiyor. Karşılıklı TLS’ye ve şifrelenmiş trafiğe sahip olmanızı umursamalarına gerek yok çünkü bu, bu mikro hizmetlere harici olarak yapılıyor. Tek bildikleri, bu tür bir bağlantı noktasıyla konuşabildikleri ve diğer uçtaki şeyin yanıt verdiği.
Böyle bir ağ mimarisi, bir kümedeki iki kapsayıcı veya iş yükü arasında gidip gelen her bir isteği yakalayarak güçlü gözlemlenebilirlik de sağlar.
Judd, “İzlenebilirlik gibi şeyler yapabilir, gecikme, hacim ve bant genişliği vb. açısından performans için çok daha iyi ölçümler elde edebilirsiniz, ayrıca trafik yönetimi ve kontrolü için ağ politikaları türleri elde edebilirsiniz” diyor.
Bu tür bir izlenebilirlik, BT departmanlarına daha fazla dayanıklılık için “devre kesici” modellerini uygulama yeteneği sunar; örneğin, birincisi belirli bir saniye içinde yanıt veremezse farklı bir iş yüküne geçişe olanak tanır.
Judd’a göre bir hizmet ağı, mikro hizmetlerin yükseltilmesi söz konusu olduğunda daha fazla seçenek sunar.
Bir uygulamanın beş “birinci sürüm” mikro hizmetten oluştuğunu ve tüm ağ trafiğinin aralarında mutlu bir şekilde gittiğini varsayalım. Bu mikro hizmetlerden birini ilk anda tüm trafiği gönderme taahhüdünde bulunmadan ikinci sürüme yükseltmek isterseniz, belirli bir ölçüye göre bir trafik dilimi gönderebilirsiniz.
Mikro hizmetlerin kademeli olarak kullanıma sunulmasının yanı sıra, hizmet ağı ağ trafiğini “anladığından”, test sırasında bunu ağ yapılandırmasına ekleyebilirsiniz.
Judd, “Buna ‘kanarya salımı’ denir, kanaryanın kömür madenindeki kanaryanın ölüp ölmediğini anlaması gibi,” diyor Judd. “’Tüm trafiğimin %5’ini bu yeni hizmete gönder’ deyin ve izleyin. Performans gösteriyor gibi görünüyorsa, ‘Şimdi %50 gönder’ diyebilirsiniz.”
Ancak Judd’ın işaret ettiği gibi, Istio’nun daha “mutfak lavabosu” teklifi oldukça karmaşık olabilir ve doğru olması için büyük miktarda yapılandırma ve ilgili bilgi gerektirir. “O zaman sorun giderme için yıllarca harcamanız gerekebilir, belki. Yani bu bir dezavantaj, ”diyor.
Linkerd, kutudan çıkar çıkmaz çok daha ince bir ağ sunar, ancak çeşitli diğer teknolojilerle entegrasyonlara sahiptir. Judd, kanarya dağıtımlarında, bu yönü ağın bir parçası olarak sağlamak için farklı bir araçla entegre edeceğinizi söylüyor.
Bununla birlikte, hizmet ağını özellikle seçmeniz gerekmiyorsa gereksinimler başka bir şekilde karşılanabilir. Muhtemelen bugün dünyadaki tüm Kubernetes kümelerinin yalnızca yaklaşık %15’i bir hizmet ağı çalıştırıyor. Judd, bu %15’lik payın büyük bir kısmının Istio ile ilgili hizmet ağı olduğunu, geri kalanının büyük ölçüde Linkerd olduğunu söylüyor.
Dış kaynak kullanımı bir seçenek olmaya devam ediyor
Confluent’in saha baş teknoloji sorumlusu (CTO) Kai Waehner, bir hizmet ağına başlamak söz konusu olduğunda, BT departmanlarının bir dizi seçeneğe sahip olduğunu belirtiyor: Istio ve Envoy ile çalışmak veya Sidecar ile Linkerd veya bazı hizmetleri hedeflemek “Kasanın altında” hizmet olarak yazılım (SaaS) sağlama yoluyla ağ yetenekleri.
“Müşterilerimiz bize ‘Biz sadece hizmetinizi kullanmak istiyoruz ve bunu dahili olarak optimize etmelisiniz’ dediler. Yazılım sağlayıcıları bunu sizin yerinize yapabilir, bu yüzden umursamanıza gerek kalmaz” diyor.
Bir çekirdek motor, daha düşük bir toplam maliyet için dahili sonlandırmalar, hız sınırlayıcı bağlantılar ve dahili olarak fiziksel küme trafiğini bağlayarak veya yönlendirerek ağ oluşturma ve yönlendirme optimizasyonlarını yönetebilir. Waehner, Confluent gibi sağlayıcıların hizmet ağ modellerini dahili olarak uyguladığına dikkat çekiyor.
Doğru yapılandırma ile optimize edilmiş ağ bağlantıları ve ağ performans modellerindeki aktarımlarla maliyet azaltılabilir. Bu, “büyük sözleşme bulutunun” ötesinde, hücresel ağ için en önemli kullanım durumudur, diyor.
Tech Mahindra’da 5G ve ağ hizmetleri işinin küresel başkanı Manish Mangal, şirketin optimize edilmiş iletişim ve çoklu bulut dağıtımları için telekomünikasyon ağlarının bulut tabanlı platformlarını 5G’ye taşırken bir hizmet ağı kullandığını söylüyor.
Mangal, “Müşterilerimize, çok az hizmet kodu değişikliğiyle veya hiç hizmet kodu değişikliği olmadan, geniş ölçekte ve coğrafyalarda hizmetlerin güvenliğini sağlamak, bağlanmak ve izlemek için Istio gibi hizmet ağı mimarilerini öneriyoruz” diyor.
Bir hizmet ağının, verimli trafik yönlendirme, yük dengeleme, trafik şifreleme ve güvenlik, gözlemlenebilirlik ve izleme, hizmet esnekliği ve hizmet keşfi ile dağıtılmış sistemler genelinde ağ performansına yardımcı olabileceğini, kesinti süresini ve potansiyel olarak maliyeti de azaltabileceğini söylüyor.
“Konteynerler ve mikro hizmet uygulamaları – ve geliştiricileri – ağ yönlendirmesinin karmaşıklığından ve güvenlik gereksinimlerinden mantıksal izolasyon gerektirebilir. Bir hizmet ağı tarafından sağlanan soyutlama, fiziksel ağdan bağımsız olarak mikro hizmetlerin hızlı ve esnek bir şekilde devreye alınmasını sağlar.”
Mangal, hizmet ağı uç noktalarının herhangi bir kapsayıcı tabanlı mimaride ve bulutlar arasında çalıştırılabileceğini ve bulutlar arası hizmet sunumu için gecikme ve performans ölçümlerini takip edebileceğini söylüyor. Ancak Mangal’ın belirttiği gibi, hizmet ağı teknolojisi, dağıtılmış kapsayıcı tabanlı uygulamalarla yazılım merkezli bir şekilde çalışmaya yönelik nispeten yeni bir yaklaşım olarak kabul ediliyor.
Bir kuruluş bir hizmet ağına ihtiyaç duyduğuna karar verdiğinde, kısa listede görünebilecek bir dizi sağlayıcı vardır. Giderek daha karmaşık ve heterojen ağ topolojilerini daha yazılım tanımlı bir şekilde yönetmek için yaklaşık 12 hizmet ağı markası mevcuttur. Her birinin farklı güçleri ve özellik setleri olacaktır. Örneğin, bir kuruluş, genellikle Kubernet’lerde desteklenmeyen, güvenlik ve uyumlulukla ilgili birden çok gereksinime sahip olduğuna karar verebilir. Bu gereksinim, hizmet ağ platformu seçimini belirler.
Sonra mimari uyum sorunu var. Dynatrace’de EMEA çözüm mühendisliğinden sorumlu başkan yardımcısı Roman Spitzbart’a göre, bir hizmet ağı, yüksek oranda dağıtılmış ve mikro hizmet tabanlı bir kurumsal mimari kullanan bir kuruluş için çok uygundur. Ek gözlemlenebilirlik araçları anlamına gelen mimarinin net bir şekilde anlaşılması gerekir. Ancak ek araç kullanmak, işlerin ters gitmesi için daha fazla fırsat sunar.
Bu belki de daha küçük kuruluşların bir hizmet ağını düşünürken karşılaştıkları engellerden biridir. “Yalnızca büyük kuruluşlar bu karmaşıklık düzeyine gitmeye isteklidir; onlar için faydalar yeterince büyük olacaktır. Küçük kuruluşlar için, hizmet ağının baş ağrısı olacağını söylemek istemiyorum, ancak çok fazla fayda sağlamayan çok fazla karmaşıklık olacak,” diyor Spitzbart.