The lab is divided into the following sets of exercises. Each set covers a group of related patterns demonstrated through a simple application written in .NET Core/ASP.NET Core and deployed to an Azure service as applicable

1. The Circuit Breaker Pattern is implemented using a popular package called Polly, which also provides a framework for other patterns like Retry
2. Health Monitoring is built using the standard ASP.NET Core extension Microsoft.AspNetCore.Diagnostics.HealthChecks
3. The interesting aspect about this pattern is how Health Monitoring and Circuit Breaker can be integrated. The working sample can be found in the Set1 folder. The snippet of code of how this works (with very little code) is shown below.
4. In this implementation, the Circuit Breaker automatically switches to an Open State after two failed requests. The circuit is open for 30 seconds and a successful request comes through, the the circuit status switches to Closed. These state transitions also automatically switch the state of the Health Monitoring to Unhealthy and Healthy respectively.
5. A Transient Http Error Policy is also added to the Http Client, which automatically adds a retry should a request fail. Subsequent calls will be made in 1, 5 and 10 seconds after failure.

 var basicCircuitBreakerPolicy = Policy
                .HandleResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)
                .CircuitBreakerAsync(2, TimeSpan.FromSeconds(30), OnBreak, OnReset, OnHalfOpen);

services.AddHttpClient<ITemperatureService, TemperatureService>("TemperatureService")
                .AddPolicyHandler(basicCircuitBreakerPolicy)
                .AddTransientHttpErrorPolicy(builder =>
                    builder.WaitAndRetryAsync(new[]
                    {
                        TimeSpan.FromSeconds(1),
                        TimeSpan.FromSeconds(5),
                        TimeSpan.FromSeconds(10)
                    }));     

services.AddHealthChecks()
    .AddCheck("Temperature Service", () =>
    {
        return basicCircuitBreakerPolicy.CircuitState switch
        {
            CircuitState.Open => HealthCheckResult.Unhealthy(),
            CircuitState.HalfOpen => HealthCheckResult.Degraded(),
            _ => HealthCheckResult.Healthy()
        };
    });

services.AddHealthChecksUI((settings =>
{
    settings.AddHealthCheckEndpoint("Weather Service", "/hc");
})).AddInMemoryStorage();     

1. The sample code is in the Set2 folder.
2. The following code is added in the ConfigureServices method, where an in-memory cache is configured. (On similar lines, you could configure a distributed cache with Azure Redis):

var policyRegistry = AddInMemoryCache(services);

services.AddHttpClient<ITemperatureService, TemperatureService>("TemperatureService")
    .AddPolicyHandlerFromRegistry((pairs, message) => 
        policyRegistry.Get<IAsyncPolicy<HttpResponseMessage>>("CachingPolicy"));

3. In the Configure method, you setup the caching policy. In this particular case, cache expires after 30 seconds

 registry.Add("CachingPolicy", Policy.CacheAsync<HttpResponseMessage>(cacheProvider, TimeSpan.FromSeconds(30)));

4. The sample leverages Polly's Caching policy to cache Http Responses for a given context. Caching is implemented for the Temperature (GetCelcius) service, with a key for every location passed to the Service.

public async Task<HttpResponseMessage> GetCelsius(int locationId)
{
    var httpRequestMessage = new HttpRequestMessage(HttpMethod.Get,
        new Uri(_client.BaseAddress + $"celsius/{locationId}"));

    httpRequestMessage.SetPolicyExecutionContext(new Context($"GetCelsius-{locationId}"));

    return await _client.SendAsync(httpRequestMessage);
}

4. When you run the application (F5 in Visual Studio), you can see that Temperature service is called the first time and not called for the next 30 seconds (The response is cached in memory).

1. In this lab, we are going to leverage Azure API management Service (PaaS) and add the weather API backends to it.
2. We can leverage the Temperature and Weather services created in Lab 2 as backend. Publish each of those to Azure app services. Navigate to each of the API endpoints and get the Open API/Swagger Spec (something like https://yourtemperatureservice.azurewebsites.net/swagger/v1/swagger.json).
3. Create a new API management service instance in the Basic tier (consumption tier does not support throttling)
4. Using the APIs specs from step #2, create two API backends from the Swagger JSON files.
5. While creating the API backends you can chose a different URL suffix for each service (like https://yourweatherservice-apim.azure-api.net/temperature/Celsius/{locationId}). So a single API management endpoint routes traffic to each of the backends based on URL paths
6. Consider any API and add an inbound policy to accommodate rate limiting like below:

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

1. Create an Azure Function App (consumption plan) and deploy two functions PerformTextAnalytics and SoundFileProcessor
2. The first stage goes through the SoundFileProcessor function which is trigger as messages are dropped into covid-voice-files Azure Storage queue. This function simulates sound file transcription and writes out a message in the transcribed-voice-files queue.
3. The second stage of the processing is to enrich the transcribed message with some text analytics. This is written as another Azure function PerformTextAnalytics which is triggered when queue messages are dropped into transcribed-voice-files. This function simulates the process of performing text analytics and the enriched message is dropped into the processed-voice-files Azure storage queue.
4. Use the QueueMessageGenerator console app to generate a given number of messages to the covid-voice-files Azure storage queue. This triggers the pipeline of processing explained in the steps before.

1. The samples are provided in the Set 3 folder.
2. Create a CosmosDB database with two containers, one that will serve data for querying, and one that will serve requests for any update or create operations.
3. The CQRSAndMediator project has a simple API controller (OrderController) which uses MediatR to send separate commands for creating an order and querying an order from their respective containers.

public class MakeOrderCommandHandler: IRequestHandler<MakeOrderRequestModel , MakeOrderResponseModel>
    {
        private readonly ICosmosDbService _cosmosDbService;

        public MakeOrderCommandHandler(ICosmosDbService cosmosDbService)
        {
            _cosmosDbService = cosmosDbService;
        }
        
        public async Task<MakeOrderResponseModel> Handle(MakeOrderRequestModel request, CancellationToken cancellationToken)
        {
            request.Id = Guid.NewGuid();
            await _cosmosDbService.AddOrderAsync(request);
            
            var result = new MakeOrderResponseModel
            {
                IsSuccess = true,
                OrderId = request.OrderId
            };
            return result;
        }
    }

public class GetOrderByIdQueryHandler : IRequestHandler<GetOrderByIdRequestModel, GetOrderByIdResponseModel>
    {
        private readonly ICosmosDbService _cosmosDbService;

        public GetOrderByIdQueryHandler(ICosmosDbService cosmosDbService)
        {
            _cosmosDbService = cosmosDbService;
        }
        
        public async Task<GetOrderByIdResponseModel> Handle(GetOrderByIdRequestModel request, CancellationToken cancellationToken)
        {
            return await _cosmosDbService.GetItemAsync(request.OrderId);
        }
    }

4. The OrdersMaterializedViewCreator project can be deployed to an Azure Function App, which will respond to the change feed on the order CosmosDB container. The changes are then written to the ordersmv container

[FunctionName("OrdersMaterializedViewCreator")]
        public static async Task Run([CosmosDBTrigger(
            databaseName: "%DatabaseName%",
            collectionName: "%SourceCollectionName%",
            ConnectionStringSetting = "ordersDbConnection",
            LeaseCollectionName = "leases",
            CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> input,
            [CosmosDB(
                databaseName: "%DatabaseName%",
                collectionName: "%ViewCollectionName%",
                ConnectionStringSetting = "ordersDbConnection"
            )]DocumentClient client,
            ILogger log)
        {
            if (input != null && input.Count > 0)
            {
                var p = new ViewProcessor(client, log);
                
                log.LogInformation($"Processing {input.Count} events");
                
                foreach(var d in input)
                {
                    var order = OrderModel.FromDocument(d);
                    await p.UpdateOrderMaterializedView(order);

                }    
            }
        }
    }

1. The Set5\ValetKey project has a simple console application that simulates the end user scenario of create a blob container, uploading some sample file and then generating a SAS URI, which is then used to download and print the contents of the file.

1. The Microservices folder has a C# solution with projects representing a small subset of the full eShop reference implementation from Microsoft.
2. The sample simulates the set of processes that are triggered on a ecommerce site after the user decides to checkout the order.
3. The solution does not have any database (only fake repositories are used) and employs a simple in-memory event bus for domain integration events used to communicate between different microservices (Order and Basket in this example)
4. Run the solution to check the flow of events and the sequence of processing. The solution uses MediaTr for command handling
5. The solution also showcases a typical solution structure that can be used in a typical microservices project.