This is a continuation of the article introduced here: https://1drv.ms/w/s!Ashlm-Nw-wnWhKdmXP_0_c--oqotlA?e=KDRRVf. It describes the design patterns for considerations in hosting solutions on Azure public cloud.

1.       Queue based load leveling – this uses a queue that acts as a buffer between a task and a service that it calls so that intermittent heavy workloads can be staged and smoothly processed.

2.       Retry  - Enable an application to handle anticipated, temporary failures when it tries to connect to a service or network resource by transparently retrying an operation that's previously failed.

3.       Scheduler agent supervisor - Coordinate a set of actions across a distributed set of services and other remote resources.

4.       Sequential convoy - Process a set of related messages in a defined order, without blocking processing of other groups of messages.

5.       Sharding - Divide a data store into a set of horizontal partitions or shards.

6.       Sidecar - Deploy components of an application into a separate process or container to provide isolation and encapsulation.

7.       Static content hosting - Deploy static content to a cloud-based storage service that can deliver them directly to the client.

8.       Strangler fig - Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.

9.       Throttling - Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service.

10.   Valet Key - Use a token or key that provides clients with restricted direct access to a specific resource or service.

11.   Minimal design – use what is always necessary and no more.

The top ten design principles cited in the documentation for Azure services are:

1.       Designing for self-healing when failures occur

2.       Making all things redundant so that there is no single point of failure.

3.       Minimizing co-ordination between application services to achieve scalability.

4.       Designing to scale out horizontally adding or removing instances as demand rises.

5.       Partitioning around limits such that it works around database, network or compute limits.

6.       Designing for operations – so that there are enough tools for them to use.

7.       Using managed services – to leverage Platform as a service rather than Infrastructure-as-a-service

8.       Using the best data store for the job so that the data fits

9.       Designing for evolution so that application changes are easy

10.   Building for the needs for the business where every decision is driven by business requirements.