Deploying Azure Serverless

Most of what was covered in the previous chapter could apply to any serverless product; even runtimes that seem unique are fairly similar. You can easily find analogues for most of the previous chapter in AWS or Google Cloud. In this chapter, you will learn about Azure-specific features. You'll integrate your function with other Azure services to create a serverless RESTful API. Azure Application Insights will also be integrated into your solution, providing your support team with unparalleled data about what your application is doing. Finally, your serverless functions will be secured using API keys, to prevent unauthorized use.

By the end of this chapter, you will be able to:

• Integrate an Azure Function with Cosmos DB
• Combine a complete logging and monitoring solution with Azure Application Insights
• Secure your Azure Functions using API keys
...

Integrating with Other Azure Services

As a developer, you are constantly asked if your service can talk to a new product. There is an emphasis on moving from the walled garden architecture of old to open, modular, easy-to-integrate services. Even software companies are struggling to catch up with this new demand, with many products still shipping as closed systems, without basic API layers.

So far, Cosmos DB has been mentioned several times in this book, but what is it? It's Microsoft's flagship cloud database. It's a fully elastic, dynamically resourced database which is schema agnostic. It has multiple APIs available. It has a native SQL API, which supports JSON documents, a MongoDB API, a Cassanda API, a Graph API and a Key-Value pair API. It can be tuned to maximum performance/parallelism and lower consistency, or back to the more traditional Atomicity, Consistency...

Logging with Application Insights

One of the most important operational requirements for software is that your company understand what the application is doing and can triage responses to errors. This is generally achieved via some form of logging, and there is a service in Azure for this, called Application Insights. It's a very sophisticated application health monitoring tool that combines out-of-the-box monitoring, like processor loads, RAM usage, and errors, with specific logging that the developer has to implement. While Azure Functions don't really have concerns with processor loads or RAM usage, it useful to know the average length of calls, how many instances are being spun up, and hourly spend.

In the next example, you will add Azure Application Insights integration to your previous two functions, to enable effective support.

...

Security with API Keys

The standard way of securing APIs on the Internet is through the use of keys and secrets, and a serverless API is no different. You should secure every function you create with at least function-level authorization, unless there is a compelling argument for it being public. You should definitely secure your data-input APIs and any output APIs with sensitive information on them. Public-facing APIs are an interesting case for serverless, because you are charged per request. This means that a malicious actor could DDoS your public function and hit you where it hurts the wallet. Friendly users with valid keys could inadvertently do this as well if they don't rate-limit their requests. A good solution to this, and a generally good solution for API's in general, is to use an API proxy. Microsoft has one called the Azure API Gateway, or there are other...

Summary

In this chapter, you learned how to deploy a serverless API backed by an infinitely scalable database and fronted by an infinitely scalable web application. You covered more of the nuts and bolts of connecting serverless code to other services, along with logging and security considerations. Having the serverless code implement the API may feel like an over-complication at the moment (why not call the Cosmos DB directly from the controller of the MVC client application?), but the benefits of it being loosely coupled to the web application while the functions are also loosely coupled to each other will become apparent later.

Now that you've covered the basics of creating a simple architecture, we can add some more interesting features and components in the next chapter.