Learning Objectives
By the end of this chapter, you will be able to:
- Create a Function-as-a-Service
- Use a Database-as-a-Service
- Create a serverless web application
This chapter will cover the main components that are required to make a complete serverless architecture, beyond the FaaS components (Azure Functions).
Introduction
Serverless architecture, while still a small field, has continued to grow as a topic of interest in software development. Some serverless architectures are now becoming highly complex, powering massively scalable applications that deliver business value across domains. As serverless architecture advances in complexity, it presents unique challenges that aren't really present in other approaches, or if they are present, they are hidden by the other, more major issues that plague those approaches. This book will give you a pragmatic, rational, and experience-based approach to architecting your serverless solution to minimize issues and maximize scalability.
Let's first define Serverless. The current working definition of serverless that's defined in this book is as follows: "A service that abstracts away all server details, provides reactive scaling to demand, and is charged on a resource-usage-based payment model". This encompasses serverless databases and takes into account reactive scaling. Serverless fits use cases from simple web applications to massively scaled and complex applications with millions of users. This book will help you build from a simple web application (with the capability to scale to millions of users with no extra effort from the developers) to a complex application, thus utilizing security, observability, queuing, and caching.
Incorporating serverless components in other styles of architecture is relatively straightforward—for instance, it is easy to use a Function-as-a-Service as a simple replacement for a RESTful API. This approach generally works well, and you can gain large advantages by doing this. To fully realize the benefits of serverless, however, a complete serverless architecture is needed. Building one of these once will also change the way you think about application architecture, meaning that even if you have requirements that demand a non-serverless component, you can still keep the rest of the architecture serverless-first. The components that are covered in this chapter are Function-as-a-Service (FaaS), the Serverless Database, and the Serverless Website. Other components that will be covered later are queues, event hubs, authentication services, and monitoring and logging services.
Function-as-a-Service with a Simple HTTP Trigger
The core component of any serverless architecture is the Function-as-a-Service. The idea of any Function-as-a-Service is basically this: you write your code, send it to your cloud provider, and they handle every aspect of making that available to yourself and your customers. This means developers focus purely on the business logic, and not on unrelated technical things. This also means developers can deliver value much faster, and in a modern business, this is the single-most important advantage you can have.
If you've completed the previous book, Beginning Serverless Architectures with Microsoft Azure, you will know about Azure's product in this area very well: Azure Functions. Azure Functions can be written in C# (.NET Core 2), F# (.NET Core 2) or Javascript (Node 8 and 10). There's a plethora of other languages with varying levels of support, such as Python, Java, and PowerShell, but as they are in preview or marked as experimental, they won't be covered here, and they aren't advised for production use. The experimental languages, and Python and Java in their preview states, have very poor performance as well. Azure Functions also comes in two versions, 1.x and 2.x. We will solely be using version 2.x in this book.
Note
1.x's underlying infrastructure is written in .NET and 2.x's is written in the newer, faster, and cross-platform .NET Core. Version 2 is now in General Availability, and therefore it is advised to only use it for new projects (unless you have some strong dependency on a .NET-only library). It would also be advisable to convert any existing functions to version 2 for the performance benefits alone, but it's also likely that version 1 will eventually be deprecated. If you are looking for support for other languages, Java is the most likely next language to be fully supported by Azure Functions and there are a large number of unsupported yet reasonably functional languages. Alternatively, AWS Lambda supports Java, Go, and Python, in addition to C# and Node.js.
Exercise 1: Creating an Azure Function
In this exercise, you will be learning how to create a function, which is the most important component of any serverless architecture, in C#. We will be using Azure Functions to do this. We will also see how to run this function locally and in the cloud:
- Let's begin by first creating our Azure function. Create a new folder in your development area called ProductsApi. Open a command-line tool inside the folder and open Visual Studio Code by typing code . or clicki...
