Advanced Serverless Architectures with Microsoft Azure

In this lesson, you will learn how to connect them up to deliver the first feature of your serverless application. Here, we will be covering asynchronous processing and caching as a way to increase the scalability of serverless architecture.

The microservices architecture advocates the splitting of the functionality of an application into the smallest possible pieces that can manage their own state. These microservices are then written, tested, and deployed independently.

Queues are a key asynchronous processing concept. In a queue, data points are added to the back of the queue and taken from the front. An example of this is a first-in-first-out data structure. In a cloud architecture, a queue will generally store events or messages from an upstream process until subscribers downstream have the time to process them.

The practice of storing previously requested data in a small, high-speed data layer and returning it, instead of requesting the data again, is called caching. Caching is a vast and complex topic, so this course will focus on the cheapest wins for your application rather than attempting to cover everything.

Asynchronous behavior is where the user performs an action and the application processes it when it has time, rather than keeping the user sitting there. Let’s look at it in detail.

Let us summarize what we learned from this lesson.

This lesson gives a description of Durable Functions and how they resolve some of the issues around errors spreading through a complex system, as well as assist in scaling.

Azure Durable Functions can be understood as asynchronous jobs that save their state and switch off while waiting for work to be completed. Let’s look at it in detail.

This section will explain how Azure Durable Functions can be used in workflows that involve human interaction.

Durable Functions allow you to express this error logic simply in code and in a fully serverless fashion. Let’s look at it in detail.

Let us summarize what we learned from this lesson.

This lesson introduces you to the unique security situation of serverless architectures and provides solutions to it.

Let's understand how serverless security is different from normal application security. The security story on serverless is mostly a good one. Because the underlying infrastructure is completely managed by the cloud provider, there are no out-of-date versions of software running on poorly maintained servers with unnecessary ports exposed. Azure is accredited with many different security standards and is generally considered to be very secure. The platform itself is actively protected against malware and DoS attacks.

In some ways, protecting your functions that need to be effectively public is the trickiest thing to do. Let's say you need to show your product list on your website to non-registered users (for why would anyone sign up to a store without being tempted by the products that are available?). You could have a key on the API, but this would need to be copied over to the end user's browser, rendering it public. To choose the right course of action to protect your functions, you need to know what you are protecting it from.

Login systems are a constant source of security flaws and errors. Many login systems have been created over and over again; the proverbial wheel has been constantly reinvented for many years. This is a serious issue as most of these login systems protect important client information. Even something as innocuous as a music service can provide vital data to a criminal looking to perform a spear phishing attack.

Let us summarize what we learned from this lesson.

This lesson covers observability, and explains how to leverage Application Insights to identify errors.

Observability is a measure of how much you can infer the inner workings of a closed system through external information. Observability in a software context is said to depend on three pillars: logs, metrics, and traces.

Application Insights will start collecting information about your application without you implementing any code yourself, simply by adding the SDK and connecting it to a valid Application Insights instance. You then need to add custom structured logs using the SDK. We will see how to do this in the following exercise.

You can also integrate Application Insights with client-side applications. There are SDKs available for iOS, Android, React Native, Xamarin, and vanilla JavaScript. This is a much more useful place for metrics in a serverless architecture. Client applications are very likely to be running on machines with very limited resources, such as old mobile phones. It's also useful to record your user flows. This is the journey your users take through your application from page to page. This can be useful for optimizing sales funnels.

Let us summarize what we learned from this lesson.

In this lesson, you will be carrying out a manual chaos experiment where you inject an error into your serverless architecture and then introduce a mitigation. You will build a full continuous integration and continuous deployment pipeline in Azure DevOps, before building a continuous chaos pipeline in Azure DevOps, which will allow you to build a regression suite of automated chaos experiments to prevent weaknesses reappearing.

Chaos engineering consists of testing software systems in production in order to build the systems' resilience to unexpected and unpredictable real-life failures. Simply put, an engineering team or automated software suite injects purposeful errors into production as part of experiments that then developers/engineers have to make their systems resilient to.

Automated deployments are fully scripted processes that deploy an application's code to a server or the cloud. This is in contrast to the manual deployments that you have been doing so far in this course using Visual Studio Code and typing each variable in manually.

Continuous Integration is closely associated with Automated Integration Testing. Automated Integration Testing is usually achieved by deploying a full or partial copy of a serverless microservice to an environment, inputting test data into the real deployed version of the serverless microservice, and checking how it behaves.

Let us summarize what we learned from this lesson.