Azure latest (and in my opinion greatest) trend is Serverless, it’s cool, anything serverless can scale seamessly and if done right, be elastic and adapt to a dynamically changing load… which makes it ideal for implementing Microservices..
That said I am pretty new to Azure at the moment but nonstop learning, about in 1 or 2 weeks to face the AZ-203 exam as mentioned some weeks ago…
But I like to play and this is the outcome of some trying and managing to get something close to a “proper” REST API endpoint in Azure, along with OpenAPI and some Azure provided goodies..
What and how?
So, what will we exacltly be doing and how will we do it?
I will be implementing a REST API endpoint using Azure Functions through a HTTP Trigger and C#, implementing it with Visual Studio 2019.
Then, I do plan to implement OpenAPI support with Azure API Management, which has several benefits as getting the documentation and test layer done almost automatically for us.
This said, I initially had thought of using an Azure Function Proxy (introduced by the end of 2017) as the front-end for the implemented API, which as well as some benefits like redirecting it to a Mock while the API is in development or being able to play between a Staging and an experimental new version of the API, etc.. But it seems that API Management does this and much more so I am unsure I will be using this feature… to understand it, this diagram might be of help:
So basically the Proxy acts as a facade between a user-consumer-publisher of our API and our API (Azure Function on the diagram). There we can do transformations of the request, response, redirect it to another Azure Function or service, etc..
As said, I’ll use API Management and not dig into Azure Functions Proxies.
Also, I do not plan into digging into authentication-authorization but that might change as we progress into it.
Azure Functions 101
Azure Functions are a great solution for running quick functions, this meaning 2,5 minutes for a HTTP based response (usually 5 minutes, modifiable up to 10 minutes).
They can be implemented with several languages, including C#, and supports dependencies as NuGet.
They Support integrated security with OAuth as Azure Active Directorz, Facebook, Google, Twitter, etc..
Integrates perfectly with various Azure and 3rd party services.
FaaS/LaaS or PaaS – mainly they are Serverless so that means “Function as a Service” or also named “Logic as a Service” but we can change the pricing plan from the default “Consupmtion” to “App Service”. So, basically a “Web API”. That said, the Consumption plan right now comes with 1 million executions for free a month, which is not bad, right?
Azure Functions Proxies
The Azure Function Proxies act as a single URI, a unified facade which we can use some redirections and transforms to our convenience, like:
- Request and Response overrides.
- Modify input request to send different HTTP verbs, headers or query parameters to a hidden backend service.
- Replace Backend response status code, headers and body.
This said, API Management supersedes Azure Function by large. That said, they have their role, if we only want to unify separate functions or API services into a single API, we should use Azure Functions Proxies.
If we want a API Management, then we know what to use.
That said, it might be interesting if we have a somehow complex environment. As said, an image is worth 1000 words:
So it could be used to unify several related API micro-services, whilst having a greater API facade which Manages them all.
Or to mock an Azure Function..
As we will implement something way simpler, I’d go for the API Management. Also, it seems more fun.
API Management
API Management enables a full fledged professional facade/gateway for our API, providing in-built services which support all that the Azure Functions Proxies can do plus:
- Load Balancing
- Hot Swapping
- Rate limiting
- Authentication and Authorization
- IP Whitelisting
- Access Policies
- Caching
- Subcriptions, including User and RBAC management
- Licensing
- Business Insights & Analytics
- Developer Portal (for ISV partners and-or internal use, including API documentation, interactive console, account creation and analytics on own usage..
API Management was launched on December 2018 and the consumption plan (which I plan to use) has been recently released (it was in preview) by the end of May 2019. the announcement clearly says that it is specifically meant for microservices.
Read more on the official Microsoft documentation on API Management or just get the whitepaper.
Next..
And that’s it for today, on our next entry we will create and verify our first REST api in C# with Azure Functions.
Happy coding!
Jose Luis Latorre's Blog (joslat) 