Serverless API Management Herkesin İhtiyacı

Adavapuru’ndaki limon suyu sıkan aletleri satan dayıları hatırladıysanız haklısınız 🙂 Ama şaka yapmıyorum, API Management herkesin ihtiyacı. Özellikle Serverless dünyasındaysanız ve taze taze ilk API’ınızı Azure Functions ile açıp Consumption Plan’ın serin diyarlarında ayranınızı yudumluyorsanız… tamam zevzekliği bir kenara bırakıyorum. API açtınız, kullandığınız kadar da ödüyorsunuz… peki müşteriye açtınız API’ı… ya deli gibi kullanırlarsa? Mobil uygulamaya gömdünüz API’ı, ya biri sniff edip sizin API üzerine kendisi app yazıp store’a atarsa? Fark ettikten sonra ne kadar sürede tepki verebileceksiniz? Yoksa store’lara app update çıkmadan durumdan kurtulamayacak mısınız? Hadi herşey yolunda gitti, API’ı kırmanız gerekiyor, API versioning için hazırlık yapmış mıydınız? Belki de başkalarından API alıp kullandınız, adamlar şema değiştirdi, siz uygulamaları zamanında güncelleyebildiniz mi? Aklımızda çılgın sorular. Cevapları API Management.

Nedir API Management?

Bu kısmı kısa tutamaya çalışacağım. Bu yazıdaki amacımız tüm API Management dünyasını keşfetmek değil. Sadece Serverless bakış açısı ile bakarak API Management satmaya çalışacağım size 🙂 İşinize yarayacak, emin olun. Kaba tabiri ile API Management size API’larınızı yönetme konusunda yardımcı olur 🙂 yani? API’larınızı yayınlar, nasıl kullanılabilecekleri konusunda kurallar koymanıza yardım eder, API’lara erişimi yönetir, API’ları kullanacak kişilere yaşayacak bir çatı verir, API dokümantasyonunuzu barındırabilir, API’larınıza kullanacak kişilere API üyelikleri vermeniz için gerekçi araçları sunar, bu üyelikleri hem sizin hem de üyelerin kullanabilmesi ve yönetebilmesi için gerekli altyapıyı verir, API’larınızı kullanım istatistiklerini tutar, ve performance raporları çıkarır. Tüm bunların üzerine bazı API Management ürünleri caching, request/response transformasyonu, hatta full API translation’a kadar uzanır. SOAP web servisinizi REST olarak açtıracak kadar ileri gidebilir.

Tabi biz bunların hepsi ile ilgilenmeyeceğiz. İtiraf etmek gerekirse tüm bu özelliklere sahip API Management ürünleri çok da uzun değiller. Azure tarafında da durum aynen böyleydi. Microsoft’un yaklaşık altı yıl önce Apiphany adındaki API Management şirketini / ürünü satın alması ile başladı macera. Ürün kallavi, kurumsal bir üründü. Bu çerçevede de pahalıydı. O nedenle, öyle önüne gelen provision edip kullanamıyordu. Hele Serverless dünyası düşündüldüğünde, kullandığım kadar öderim kafası hiç uyuşmuyordu. Ta ki API Management için Consumption Plan duyurulana kadar. Aralık 2018’de Preview olarak duyurulduktan sonra Consumption Plan API Management için 2019 Mayıs sonunda GA oldu!

API Management Consumption Plan

Apiphany zamanından kalan API Management aslında multi-tenant olmayan bir mimariye sahipti. İlk zamanlarda bir service account provision etmek bir saati geçiyordu. Altı yıl süren çalışmalarla bugün Consumption Plan’deki bir API Management hesabı dakikalar içinde ayağa kalkıyor. Tabi Consumption Plan’in bazı mantıklı, bazı da mantıksız eksikleri var 🙂 Örneğin Cache yok. Diğer Pricing Tier’larda built-in cache gelirken Consumption Tier’da önbellek yok. İstersen harican Redis alıp bağlayabilirsiniz. Yönetmesi size kalır. Bu eksik kısmen mantıklı ve tam olarak eksik de sayılmaz. Diğer yandan Active Directory entegrasyonu desteği yok. Bu eksik bence salt müşteri profili ve fiyatlandırma politikasından kaynaklanıyor. Virtual Network desteği de yok. Bunu Azure DC mimarisini bilenler mantıklı bulacaklardır 🙂 Multi-tenant olan her yere VNet desteği geliyor. Zamanla buraya da gelir diye tahmin ediyorum. Tabi müşterilerden istek gelirse. Multi-Region deployment yok. Bu da atla deve değil ama hafif can sıkıcı. Tüm bu eksiklere baktığımızda aslında şu anki Consumption Plan’i global scale’de serverless deploymentı olanlar için değil de ufak çapta serverless kullanıp sadece maliyet avantaşı için serverless’a yaklaşanlar hedeflenmiş gibi duruyor. Pazar araştırmalarına bakmadım ama Serverless’ın tek avantajının granular billing olmadığını tartışmaya gerek yok sanırım. 😉

Tüm bunları yazdım ama işin en güzel tarafı tabi ki Consumption Plan ve Serverless tarafı. Yani scaling ile uğraşmak zorunda kalmamak ve kullandığınız kadar ödemek. Diğer tüm API Management Pricing Tier’lara baktığınızda hepsinde bir provisioning var, ve limitleri aşarsanız sizin müdahale etmeniz veya müdahale edecek sistemleri kurmuş olmanız gerekiyor.

Peki nasıl olacak bu işler?

Konumuz Azure Functions olmadığı için hazırlık kısmını hızlı geçeceğim. Ama görmüş olalım diye aşağıya ekran görüntüsü koyuyorum.

Yeni bir Funcion App yaratıp için de varsayılan şablon kodlardan birini aldım. Artık URL’i olan ve bize Merhaba diyebilen bir Serverless Function’ımız var. İkinci adımda API Management hizmetini alacağız.

Yukarıda da gördüğünüz üzere formu dolduruyoruz. Buradaki Organization Name bizim API Management portalimizde gözükecek olan şirket ismi. İşin enteresan tarafı Consumption Plan’de dışarıya açabileceğimiz Developer Portal özelliği gelmiyor. Normalde API Management hesabı aldığımızda bize ayrı bir portal verilir. Orada bir sürü şey yapılabilir 🙂 Hatta müşterilerinize, API’larınızı kullanacak olan kişilere bu portali verip API’ları kullanabilmeleri için üyelik almalarını, access key almalarını vs sağlayabilirisiniz. Tüm bunları müşterileriniz kendileri yapabilirler bu harici portal üzerinden. Consumption Plan’de şimdilik bu portal yok 🙁 ama bilgiler alınıyor. Bu da insanda “herhalde zamanla gelecek” hissiyatı yaratıyor.

Bu adımdaki admin e-mail de önemli. Buradaki admin e-mail API Management hesabınızın admin e-maili. Her türlü API Management iletişimi o e-mail ile yapılır. Sizin de hissedebileceğiniz üzere sanki Azure Portal’ine sonradan tünemiş bir ürün gibi duruyor API Management 🙂 Zaten öyle.

Son olarak Consumption Plan seçmeyi unutmuyoruz tabi.

Yola çıkmaya hazırız. Gateway URL’i yukarıdaki görebilirsiniz. Şimdilik orada birşey yok. Birazdan olacak 🙂

API’larımızı eklemeden önce API Management’ta bir ürün tanımlamamız gerek (Aslında şart değil, Consumption Plan’e özel başka bir alternatif daha var, yazının sonunda bahsedeceğim). Bu ürün bizim API’larımızı gruplayacağımız mantıksal grup. Bu ürünü ister üyelikle satarsınız, ister açık saçık koyarsınız 🙂 Karar sizin. Tabi tekrar ediyorum, consumption plan’de developer ve customer portal yok 🙂 Buradaki çoğu altyapı ve süreç diğer planlar için hazırlandığından dolayı bazı gereksiz yapılar mevcut. Tabi duruma şöyle de bakabilirsiniz, eğer ileride eksik özellikleri edinmek için diğer planlara geçmek isterseniz herşey hazır olacak.

Bir sonraki adımda en sağ taraftaki “API” sekmesine geçerseniz API Management’ınıza API Import edebileceğiniz ekrana gelirsiniz. Burada birçok seçenek var. Bizim seçeceğimiz Azure Function App olacak. Birkaç tıklama ile Azure Subscription içerisindeki tüm Function App’ler ve içlerinde API’lar listelenecek. İstediğinizi seçin 🙂

Son anda Import noktasında bu API’yı bir ürüne eklememiz gerek. Bir önceki adımda yarattığımız ürüne ekleyebiliriz. Ekran görüntüsündeki her metin kutusunu anlatmıyorum 🙂 Adından anlaşılıyordur sanırım.

İşte geldik API Management’ın etli kısmına 🙂 API’ımız ile ilgili yapabileceğimiz çoğu şey burada. Bu API’da GET metodu ile ilgilenelim şimdilik. Yukarıdaki ekran görüntüsünden “GET”i seçerseniz karşınıza aşağıdaki gibi bir görüntü gelecek.

Ekran görüntüsünü incelemeye ortadan başlamakta fayda var. Orta üstte “Inbound processing” yazan kısım API Management’a dışarıdan gelen talepleri Azure Function’a yollandığı kanalı temsil ediyor. “Outbound Processing” ise Azure Function’dan geleni dışarıya verildiği kanalı oluşturuyor.

IP Filtering

Gelin Inbound Policy’lerden bir örnek yapalım. IP Filter Policy’ye direk seçip istediğiniz IP aralığını engelleyebilir, veya izin verebilirsiniz.

İzinleri verdikten sonra gelip bir request ile senaryoyu test edelim. Hemen Test tabına geçerseniz buradan test parametreleri verip örnek bir request gönderebilirsiniz.

Tabi burada IP bloklama veya izin verme noktasında eğer siz de benim gibi testi Azure Portal’dan yapacaksanız Azure’un IP’lerini bloklamanız gerekecek 🙂

API Versiyonlama

API Management size API versiyonlama konusunda da yardımcı olabilir. Normal şartlarda versiyonlamayı Function içerisinde halletmek gerekirken, ki bu cidden function kodunun içine ediyor, tüm bu mantığı API Management katmanına alarak arkada farklı version API’larınızı tamamen birbirinden bağımsız, hatta farklı deployment ortamları olarak bile tasarlayabilirsiniz.

Yukarıdaki ekran görüntüsünde de görüldüğü üzere API’ımıza gidip “Add Version” diyoruz.

Versiyonlama için birkaç seçeneğiniz var. URL, QueryString veya Http Header üzerinden versiyonlama. Benim favorim HttpHeader. Sebebini yorumlarda soran olursa anlatırım 😀

Görüldüğü üzere artık 2 farklı API sürümümüz var. Arkada her ikisi de şu an aynı Azure Function’ı çağırıyor. Bundan sonrası size kalmış. İster iki farklı Azure Function çağırın farklı versiyonlardan, ister alın Header’ı transforme edip başka bir şeye çevirip aynı Function’a paslayın (ki bu yaptığımız işi anlamsız kılar). Sonuç olarak 🙂 dışarıya açtığınız versiyonlama yapısı ve API schema’yı tutarlı tutarak içeride ne takla istiyorsanız atabilirsiniz.

Artık test sayfasına geçtiğinizde portal sizin yerinize version header bilgisini de koyacak ?

Subscription Yapısı

Normal Azure API Management hesaplarına göre Consumption Plan’da Developer Portal eksik olduğu için aslında bu service account’ların pek de subscription satmak veya self-service subscription vermek için kullanılamayacağını biliyor Microsoft 🙂 Bu sebeple Consumption Plan’lara özel olarak default bir subscription key geliyor ve bu key ile herşeye erişilebiliyor. Sanırım Consumption Plan API Management hesaplarının Serverless functionların önünde developerların kendi yönettikleri uygulamaların arkasında olacağını varsaymışlar ki isteyeceğiniz şeyin all-access-key olacağını düşünmüşler. Mantıklı 🙂

Ama tabi isterseniz ek subscription key’ler de yaratabilirsiniz. Daha önce yarattığımız “Product” konsepti tam da bu noktada işimize yarayacak.

Yeni bir subscription yaratırken ister Product, ister tekil olarak API seçebilirsiniz. Böylece aldığınız key sadece seçilen ürünün içerisindeki API’lara erişebilir. Key management işini de API Management’a atmış olduk. Tabi burada bahsettiğimiz API Access, bir anlamda Authentication, Authorization değil 🙂 Yani hala Function’larınız içerisinde bir Authentication kodu olması olası.

Daha neler neler…

Aslında bahsedilecek daha çok şey var 🙂 Ama bu yazının da bir yerde bitmesi gerek. Birincisi, Consumption Plan’den çıktığınız anda doğal olarak API Management ürün çok daha geniş özelliklere sahip bir ürüne dönüşüyor. Benim şahsi tahminim, zamanla bu özelliklerin yavaş yavaş kendini Consumption Plan tarafında da göstereceği yönünde. Diğer yandan bu yazıda değinmediğimiz bir nokta da kontrolümüzde olmayan API’ları alıp transforme edip API Management üzerinden açmak. Diyelim ki birileri size kel alaka bir API verdi ve bunu kendi uygulamanızdan kullanmanız gerekiyor. Adamlara güvenmiyorsunuz 🙂 Şema kırabilirler, hatta uptime garantisine de güvenmiyorsunuz. Araya API Management alırsanız hem kendi uygulamalarınız için şemayı consistent tutabilirsiniz hem de belki araya biraz caching alıp uptime’ı yükseltebilirsiniz, belki de down olarak üçüncü parti servisin uygulamanızı etkisini göğüslemek için kullanırsınız ara katmanı. Senaryolar çeşitlendirilebilir 🙂 Eğer ilginizi çekiyorsa yorumlarda yazabilirsiniz. Bir sonraki yazıda belki de bu konulara bakarız 🙂

Kendinize çok iyi bakın. Görüşmek üzere.