Eğer mikroservisler ile uğraşmaya başladıysanız service mesh ve API gateway kavramlarının sıkça konuşulduğunuz duyuyorsunuzdur. Mikroservisler, monolith uygulamaların ölçekleme, esneklik ve hızlı geliştirme/deploy etme konusunda ki kısıtlamalarına çözüm getirirken; servislerin yönetimi, uygulama geliştirme pratikleri ve servislerin hem bir birleri hem de dış dünyayla olan iletişimin düzenlenmesi anlamında yeni zorluklar doğurmuştur. API GW ve Service Mesh özellikle microservicelerin iletişimini düzenleyen hem de güvenliklerine katkıda bulunan ama rolleri sıkça karıştırılan iki bileşendir.

Aralarındaki farkı iyicene anlayabilmek için her birine detaylı bakalım.

Service mesh; servislerin bir birleriyle konuşmasını sağlayan mikroservislerin kendi aralarındaki iç trafiğini(east-west) yöneten bir alt yapı bileşenidir, network seviyesinde L4 ve L7’de çalışmaktadır.

Service mesh’in başlıca özellikleri:

• Servisler arasında ki trafiğin yönlendirilmesi; mikroservis aynı platform(k8 gibi) üzerinde bulunan başka bir mikroservisi çağırmak istediğinde bu servisin hangi pod üzerinde bulunduğu, pod içerisinde kendisine en yakın container’ın hangi node üzerinde bulunduğunu ve trafiğin container’lar arasında dağıtılmasından sorumludur.
• Rate limiting; bir birini çağıran servislerin eş zamanlı kaç adet çağrıda bulunabileceğini ve/veya requestin büyüklüğünü belirleyebilir.
• Retry; birbirini çağıran servislerde, yanıt alamama durumunda iletişimi tekrar deneme sayısını, bu sayıyı aştığında ise circuit breaker sürecini ayarlayabilirsiniz
• A/B testing için servis çağrılarının mesela %90’ını v1’e yönlendirirken geri kalanların v2’e yönlendirilmesini sağlayabiliriz; eski sürümün trafiği yavaş yavaş azaltılırken, gelen request’ler yeni sürüme yönlendirilir (Strangler Pattern). Özellikle 7/24 trafik alan finans uygulamaları, e-ticaret siteleri için çok değerli bir özelliktir.
• Servisler arası network seviyesinde iletişimi kontrol ettiğinden dolayı service mesh bize oldukça detaylı metrikler sunabilmektedir, bu metrikleri hem performans analizi için hem de servislerin health check’i için kullanabiliriz.
• Güvenlik tarafındaysa iki önemli rol üstlenmektedir; birincisi servisler arasında ACL’ler ile erişim yetkilerini tanımlanması ve mutual TLS kullanarak ek bir güvenlik oluşturulması.

Yukarda yazdığım tüm özellikleri servis mesh kullanmak yerine uygulama içerisine mantığı gömerek gerçekleştirmekte mümkün ancak hem sürdürmesi zordur hem de yapılar çok büyüdükçe yönetilmesi imkânsızlaşır, bunun yanında uygulamamız içerisinde temel fonksiyonuyla alakasız işlevleri de gömerek mikroservisin felsefesinden de uzaklaşmış oluruz.

Service mesh ise sidecar denilen bir yapı sayesinde kendini pod’un içerisine dâhil ediyor ve pod içerisindeki tüm içeri ve dışarı doğru olan trafiği kontrol ederek yukarıdaki fonksiyonları sağlayabiliyor. Bunun en büyük artısıysa kodumuzda herhangi bir değişiklik yapmamıza gerek olmaması.

API Gateway fonksiyonuna gelirsek aslında mikroservis yapılarından daha öncede var olan ama mikroservisler ile beraber popülerliği artan başka bir yapı taşıdır. Service mesh’den farklı olarak API GW kuzey-güney trafiğini tek bir noktadan yönetmek için kullanılır veya veri merkeziniz içerisinde iki farklı teknolojiye sahip servislerin konuşması için de kullanılabilir.

API GW kullanmanın faydaları;

• Soyutlama(Abstraction): API GW başka servisler ve istemciler için tek bir çağrı ve cevap noktası olduğundan dolayı arka taraftaki karmaşık yapıdan sizi soyutlar ve daha bütüncül bir deneyim sunar. Bir kredi kartı hesap özeti ödeme servisiniz olduğunu düşünün; bu servis aracılığıyla hesabınızdaki paranın bir kısmıyla ödeme yapmak istediniz de arka tarafta sırayla şu servisler kullanılacaktır;
  • Müşterinin bu işlemi yapma yetkisi kontrolü
  • Hesap durumu ve bakiyesi uygunluğu kontrolü
  • Ödeme yapılan kuruma para transferinin gerçekleştirilmesi
  • Bakiye güncellemesi
  • Ara yüzde işleme ait dekontun gösterilmesi veya adımlardan herhangi birinde hata varsa tüm yapılan işlemlerin geri alınması.

Yukarıda özetlediğim işlem adımlarının her biri farklı bir veya daha fazla servise denk gelmektedir; her biri için client farklı farklı çağrılar yapabilir veya API GW üzerinden tek bir çağrının yapılmasını sağlayıp arkadaki orkestrasyon/çoklu işlemi saklayabilir. Bunun hem performansa hem de geliştirme süreçlerinin yalınlığına katkısı pozitiftir.

• Kimlik doğrulama(Authentication): API GW arkasında bulunan servislere ulaşabilmek için gerekli tokenların olup olmadığını kontrol eder veya authentication için gerekli servisleri arka tarafta çağırabilir.
• Trafik Kontrolü: Yapılan çağrıların belli IP’lerden gelmesi, belli bir büyüklüğü geçememesi veya belirli bir süre içerisinde yapılabilecek maksimum çağrı sayısını belirleyebiliriz. Özellikle servislerimizi DDoS gibi saldırılara veya gereğinden fazla çağrılarak sistemi yormasına karşı korumak için ek bir önlem olarak kullanılabilir.
• API’lerin izlenmesi ve ücretlendirilmesi: Bu iki fonksiyon bir birinin tamamlayıcısıdır, API çağrıları üzerinden metrik toplayarak hem ileride problemlerin çözümü için veri biriktirirken, ileride dışarıya açtığımız servisleri ücretlendirebilir veya en çok/az kullanılan servisleri kolayca bulabiliriz.
• Dönüşüm(Transformations): API GW’in kullanım avantajlarından biri de eski veya farklı protokol kullanan uygulamaları bir biriyle konuşabilmesi için gerekli dönüşümü yapabilmesidir. Hem eski legacy uygulamaların yeni yapıyla entegre çalışabilmesi için kritik bir özelliktir, hem de bu tür dönüşüm fonksiyonlarını uygulama içerisine gömmeyerek uygulamanın taşınabilirliğini ciddi oranda artırmış oluyoruz.
• Önbellek(Cache): API GW istenirse önbellek görevi de görerek response time’ı azaltabilir, pek tercih edilen bir özelliği olmamakla beraber sık çağrılan ve görece az güncellenen API’lar için ideal olabilir.
• Güvenlik: Kimlik doğrulama ve trafik kontrolü’nün yanında aynı zamanda TLS, mTLS veya header kontrolleri bu katman üzerinde yapılabilir, böylece uygulamalar güvenlik sorumluluğunun bir kısmını API GW’e devretmiş olur.

API GW’in tam işlevini pekiştirmek için sıkça kullanılan bir senaryoyu konuşmak istiyorum. Birincisi, istemci(client) backend servislerinin karmaşıklığından soyutlamak ve çoklu servis çağrılarında verileri tek bir noktada toparlayıp o şekilde cevap vermek.

Mesela aşağıdaki örnek uygulamada istemci son yapılan para transfer işleminin dekontunu gösterebilmek için 3 farklı servisin verilerine ihtiyaç duyuyor. İstemci 3 servisi de tek tek çağırıp onlardan topladığı verileri daha sonra kendi üstünde birleştirmek zorunda; burada ki problem istemcinin aslında aynı kaynağa 3 kere farklı çağrı yapması ve aralarındaki en yavaş çağrı süresi kadar başlayıp kendi üzerinde birleştirme işlemini yapıyor olması. Bu hem kaynak hem de ileride bu servislerden birinde yapılacak değişiklikte tüm istemcileri de güncelleme zorunluluğuna sebep olabileceğinden dolayı çok istenen bir durum değildir.

Bunun yerine araya bir API GW koyduğumuzda istemci sadece tek bir çağrı yaparak API GW’in gerekli API’ları çağırması veriyi toparlayıp tek bir cevap olarak dönüş yapmasını sağlayabiliriz. Bunun en büyük avantajları yavaş network(internet) üzerinden tek çağrı yapılırken, hızlı network üzerinden(internal) 3 çağrı yapıldığından toplam cevap süresi uygulama için azalacaktır; aynı zamanda API GW yapılan çağrıda hali hazırda güvenlik tokenlarının olduğunu görüp “Kimlik Doğrulama Servisini” hiç çağırmayabilir veya dekontun template’i zaten önbellekte olabileceğinden dolayı minimum çağrıyla istemciye cevap verilecektir.

Burada birçok yazılım mimari arkadaşım microservice tasarım modellerinden olan “service aggregator’u” neden tercih etmediğimi soruyorlar. Birincisi fonksiyon olarak benzer işleri yapabilseler de her bu tür servis için ayrı bir aggregator geliştirmek, bunun yaşam döngüsünü ve sürdürülebilirliğini yönetmek ek bir iş yükü getirecektir; bunun yanında API GW daha çok uç noktaya konulan ve istemcileri/3. Parti entegrasyonları karşılama görevini de üstleneceğinden dolayı dönüşüm, güvenlik, trafik yönetimi gibi rolleri de üstlenebilecek bir ürünün kullanılmasını daha doğru buluyorum.  Tabii sıkça service aggregator ve API GW’in beraber kullanıldığı tasarımlar görüyor olabilirsiniz, özellikle servisiniz için özel bir aggregation akışına ihtiyacınız varsa ve istemcilerin içerisine gömmek istemiyorsanız tercih edilmesi doğru bir yaklaşımdır.

Servicemesh ve API GW’in ne olduğunu açıkladığıma göre; en sık karşılaştığım soruya cevap vermeye çalışayım. ServiceMesh ve API GW bir birinin yerine geçebilir mi?

Hayır; birçok ortak özellikleri olmakla beraber ve birçok firmanın API GW ve service mesh ürünlerini tek bir marka altında sunmaya başlamasına rağmen rolleri farklıdır.

API GW; servislerimizi dışarıya nasıl sunacağımız, hangi güvenlik mekanizmasından geçireceğimiz ve farklı protokollerin bir biriyle konuşmasını düzenlerken; service mesh içerideki servislerin bir biriyle nasıl konuşması gerektiğini düzenler.

Aşağıda bir tabloyla özeti bulabilirsiniz;

API GW	Service Mesh
Kuzey-Güney trafiğini yönetir	Doğu-Batı trafiğini yönetir
Servislerin dış dünya tarafından kolay ve güvenli olarak tüketilmesini sağlar	Container networkü içerisindeki servislerin trafiğini kontrol eder ve yönetir
Dış çağrıları içerideki servislere adresler	İç kaynaklar arasında brokage servisi olarak çalışır
Üzerinde bulunan servisler bir iş fonksiyonuna göre tanımlanır(fatura kesimi, EFT başlat gibi)	Uygulamalar, veri merkezleri ve farklı networkler arasındaki fonksiyonları üstlenir; doğrudan bir iş fonksiyonuna bağlı değildir.

Vakit ayırıp okuduğunuz için teşekkürler.