Book Image

Implementing Azure Cloud Design Patterns

By : Oliver Michalski, Stefano Demiliani
Book Image

Implementing Azure Cloud Design Patterns

By: Oliver Michalski, Stefano Demiliani

Overview of this book

A well designed cloud infrastructure covers factors such as consistency, maintenance, simplified administration and development, and reusability. Hence it is important to choose the right architectural pattern as it has a huge impact on the quality of cloud-hosted services. This book covers all Azure design patterns and functionalities to help you build your cloud infrastructure so it fits your system requirements. This book initially covers design patterns that are focused on factors such as availability and data management/monitoring. Then the focus shifts to complex design patterns such as multitasking, improving scalability, valet keys, and so on, with practical use cases. The book also supplies best practices to improve the security and performance of your cloud. By the end of this book, you will thoroughly be familiar with the different design and architectural patterns available with Windows Azure and capable of choosing the best pattern for your system.
Table of Contents (16 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

What is Resiliency?


On a cloud architecture (but in general on every IT system), you could have different events that could cause a failure of your solution. These failures could have a totally different nature, they could be hardware-related (a server goes down, a disk is corrupted and so on), they could be network-related (network glitches) or they could be data center-related (imagine a big problem on a data center or an Azure region).

When designing an architecture for the cloud, you need to have in mind that your solution could be affected by failures and you need to react to those failures, as soon as possible. This is the concept of Resiliency.

For a system, Resiliency (as a definition) is the ability to react to failures and continue to work. I've placed in evidence the word react because it's extremely important. You cannot totally avoid failures (some of them are totally unpredictable and not dependent on you), but you need to plan for a solution architecture that responds to failures...