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.       Competing Consumers – This enables multiple concurrent consumers to process messages received on the same messaging channel. It addresses specific challenges in the messaging category.

2.       Compute Resource Consolidation - This consolidates multiple tasks or operations into a single computational unit. It is widely applicable to many implementations.

3.       CQRS – These segregates operations that read data from those that update data by directing them to different interfaces.  This helps with performance and efficiency.

4.       Deployment stamps – These deploy multiple independent copies of application components, including data stores.

5.       Event sourcing – This uses an append only store to record the full series of events that describe the actions taken on data in a specific domain.

6.       External configuration store – This moves configuration information out of the application deployment package to a centralized location.

7.       Federated Identity – This delegates authentication to an external identity provider.

8.       Gatekeeper – This protects applications and services by using a dedicated host instance as a man-in-the-middle position. The host brokers services to a client, validates and sanitizes requests and passes requests and data between them.

9.       Gateway Aggregation -  This uses a gateway to aggregate multiple individual requests into a single request.

10.   Gateway offloading – The shared or specialized service functionality is offloaded to gateway proxy.

11.   Gateway Routing – This routes requests to multiple services using a single endpoint.

12.   Geodes – This deploys backend services into a set of geographical nodes. Each node can service any client request in any region.

13.   Health Endpoint Monitoring – This is crucial for external tools to continually monitor the health of a service through an exposed endpoint.

14.   Index table – This creates indexes over the fields in the data stores which comes useful for querying.

15.   Leader election – This coordinates the actions performed by a collection of collaborating task instances in a distributed application by electing one instance as the leader that assumes responsibility for managing the other instances.

16.   Materialized view – This generates prepopulated views over the data in one or more data stores so that the query for the view does not need to be run again and the view is available to subsequent queries.

17.   Pipes and filters – these separate the execution into stages that form a series. Those stages become reusable.

18.   Priority queue – These requests are sent to services so that the requests with a higher priority are received and processed before others.

19.   Publisher/Subscriber - This enables an application to produce events for interested consumers without coupling the producer to the consumers. It also allows fan-out of events to multiple parties.

20.   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.

 

 https://1drv.ms/w/s!Ashlm-Nw-wnWhKdun2-8IUJ19Or-Og

Sample python implementation:

#! /usr/bin/python

def determining_root_cause_for_api(failures):

 Return cluster_centroids_of_top_clusters(failures)

def batch_cluster_repeated_pass(api, failures)

 api_cluster = classify(api, failures)

 proposals = gen_proposals(api_cluster)

 clusters = [(FULL, api_cluster)]

 For proposal in proposals:

 Cluster = get_cluster_proposal(proposal, api, failures)

 clusters += [(proposal, cluster)]

 Selections = select_top_clusters(clusters)

 Return api_from(selections)

Def select_top_clusters(threshold, clusters, strategy = goodness_of_fit):

 return clusters_greater_than_goodness_of_fit_weighted_size(threshold, clusters)