Why create a serverless application?
Building a serverless application allows you to focus on the code of your application instead of worrying about the management and operation of the infrastructure.
You are no longer forced to think about commissioning or configuring servers because AZURE does it for you. This reduces your infrastructure management burden and helps you reduce time to market.
There are four big advantages to building a serverless application:
 No infrastructure management |  Dynamic scalability |  Faster time to market |  More efficient use of resources |
| Using fully managed services enables developers to avoid administrative tasks and focus on core business logic. With a serverless platform, you simply deploy your code, and it runs with high availability. | With serverless computing, the infrastructure dynamically scales up and down within seconds to match the demands of any workload. | Serverless applications reduce the operations dependencies on each development cycle, increasing development teams’ agility to deliver more functionality in less time. | Shifting to serverless technologies helps organizations reduce TCO and reallocate resources to accelerate the pace of innovation. |
How can I create a serverless application?
You can create a serverless web application using several AZURE services. Each service is fully integrated and does not require you to commission or manage servers. All you need to do is configure them and upload your application code to Azure Function, a serverless computing service.
This tutorial will show you how to build your first serverless web application’s architecture.
Setting up the environment:
Before you start you must have a Microsoft Azure account, you will need a valid and active Azure account. You can use a free Azure account (Limited) or a pay as you go account.
After creating your azure account and subscribing, the first thing to do is to :
1/ Create a Resource Group 1 to make it easier to apply access controls, monitor activity, and track the costs related to specific workloads.
You decide how you want to allocate resources to Azure resource groups based on what makes the most sense for your organization, but as a best practice, we suggest assigning resources with a similar lifecycle to the same Azure resource group, so you can easily deploy, update, and delete them as a group.
Then you have to:
2/ Create a Virtual Network 2 that enables Azure resources to securely communicate with each other, the internet, and on-premises networks.
You can also divide your VNet into multiple subnets for organization and security, in our case we divided our Vnet into two subnets:
3/ Create a Virtual Subnet “API Subnet” which contains our code and the APIs linked to this code.
4/ Create a Virtual Subnet “Static Content Subnet” which contains the static content hosted on the cloud.
By default, there is no security boundary between subnets, so ressources in each of these subnets can talk to one another. However, you can:
5/ Set up a Network Security Group 3 (NSG) which allows you to control the traffic flow to and from subnets and to and from the ressources.
1 Is a container that holds related Azure resources for ease of management.
2 Is the fundamental building block for your private network in Azure.
3 Contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources.
This architecture shows first how the user will connect via the internet to create his azure subscription and then set up his network infrastructure on the azure cloud.
Once the network infrastructure is ready, you can move on to the implementation of your services.
First you have to:
6/ Create a Blob Object Storage Account 4 to store all our data.
Second you have to:
7/ Create a Function App 5 to host the execution of our functions and to group them as a logical unit for easier management, deployment, scaling, and sharing of resources.
To store unstructured and JSON data, Combined with Azure Functions, we have to:
8/ Create an Azure Cosmo DB 6 account that makes storing data quick and easy with much less code than required for storing data in a relational database
Cosmo DB It is a good choice for any serverless application that needs low order-of-millisecond response times, and needs to scale rapidly and globally.
4 Is an Azure resource that allows you to store tables, queues, files, blobs (objects), and virtual machine disks.
5 Is a serverless compute option. It uses an event-driven model, where a piece of code (a “function”) is invoked by a trigger.
6 Is a multi-model database service. For this scenario, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client.
This architecture shows the link between the two subnets, so that azure functions can communicate with the Blob Object Storage Account.
Cloud functions are great. Who does not like automatic scalability and hands-off infrastructure management? HTTP-triggered Azure functions however are exposed to the public Internet. So if we want to use them, we’d want to take steps to secure those functions from malicious attacks.
One of the solutions is to insert another level of indirection. Azure API Management Service can help to secure your APIs.
In a high-level view, APIM will stand between the client and the function endpoint, managing authentication and access, while the function will be protected by the Azure Active Directory.
So to ensure this security you have to:
9/ Create an API Management 7.
And
10/ Create an Active Directory 8.
7 Provides an API gateway that sits in front of the HTTP function. You can use API Management to publish and manage APIs used by client applications.
8 Users sign into the web application by using their Azure AD credentials. Azure AD returns an access token for the API, which the web application uses to authenticate API requests
In this architecture, the client application is a single-page application that runs in the browser. This type of client application cannot keep a client secret or a hidden authorization code, so the implicit grant flow is appropriate.
To set up authentication:
- Enroll an application in your Azure AD tenant. This generates an application ID, which the client includes with the login URL.
- Enable Azure AD authentication in the Function application.
- Add the validate-jwt policy to API management to pre-authorize the request by validating the access token.
NB: It is recommended to create separate application registrations in Azure AD for the client application and the primary API. Grant the client application permission to call the API. This approach gives you the flexibility to define multiple APIs and clients and control permissions for each.
Here’s the overall flow of the 6th step:
- The user clicks the “Sign in” link in the web application.
- The browser is redirected to the Azure AD sign in page.
- The user signs in.
- Azure AD redirects back to the client application, including an access token in the URL fragment.
- When the web application calls the API, it includes the access token in the Authentication header. The application ID is sent as the audience (‘aud’) claim in the access token.
- The back-end API validates the access token.
And finally we need a solution for rapidly delivering high-bandwidth content
And for that you have to :
11/ Create a Content Delivery Network 9(CDN) that ensures delivery by caching application content in strategically placed physical nodes around the world.
This architecture shows a serverless web application. The application manages static content from Azure Blob Storage and implements an API using Azure Functions. The API reads data from Cosmos DB and returns the results to the web application.
9 Cache content for lower latency and faster delivery of content, as well as providing an HTTPS endpoint.
