Book Image

Advanced Serverless Architectures with Microsoft Azure

By : Daniel Bass
Book Image

Advanced Serverless Architectures with Microsoft Azure

By: Daniel Bass

Overview of this book

Advanced Serverless Architectures with Microsoft Azure redefines your experience of designing serverless systems. It shows you how to tackle challenges of varying levels, not just the straightforward ones. You'll be learning how to deliver features quickly by building systems, which retain the scalability and benefits of serverless. You'll begin your journey by learning how to build a simple, completely serverless application. Then, you'll build a highly scalable solution using a queue, load messages onto the queue, and read them asynchronously. To boost your knowledge further, the book also features durable functions and ways to use them to solve errors in a complex system. You'll then learn about security by building a security solution from serverless components. Next, you’ll gain an understanding of observability and ways to leverage application insights to bring you performance benefits. As you approach the concluding chapters, you’ll explore chaos engineering and the benefits of resilience, by actively switching off a few of the functions within a complex system, submitting a request, and observing the resulting behavior. By the end of this book, you will have developed the skills you need to build and maintain increasingly complex systems that match evolving platform requirements.
Table of Contents (8 chapters)

Continuous Automated Chaos


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.

For example, you would deploy an Azure Storage Account, a Cosmos DB, the Product API Function App, and the Queue Functions Function App. You would then call the AddProducts function with some valid products and call the GetProducts function to check them. You would then do some error scenarios, calling the AddProducts function with an invalid key, calling it with malformed data, and so on. You would then destroy the entire environment without a trace to save money and prevent it from forming any kind of state that wasn't explicitly created by the tests. It's important not to leave the environment up because then the process won't be entirely...