Figures renumbered and chapter titles corrected (#43207)

* Figures renumbered.

* Chapter and unit title edits.

* Apply suggestions from code review

---------

Co-authored-by: David Pine <[email protected]>

Author: alistairmatthews

docs/architecture/distributed-cloud-native-apps-containers/cloud-native-identity/identity-server.md

@@ -50,7 +50,7 @@ You can add it to your applications using its NuGet packages. The main package i
 
 ## Configuration
 
-IdentityServer supports different kinds of protocols and social authentication providers that can be configured as part of each custom installation. This is typically done in the ASP.NET Core application's `Program` class (or in the `Startup` class in the `ConfigureServices` method). The configuration involves specifying the supported protocols and the paths to the servers and endpoints that will be used. Figure 11-2 shows an example configuration taken from the IdentityServer Quickstart UI project:
+IdentityServer supports different kinds of protocols and social authentication providers that can be configured as part of each custom installation. This is typically done in the ASP.NET Core application's `Program` class (or in the `Startup` class in the `ConfigureServices` method). The configuration involves specifying the supported protocols and the paths to the servers and endpoints that will be used. The following code shows an example configuration taken from the IdentityServer Quickstart UI project:
 
 ```csharp
 public class Startup

docs/architecture/distributed-cloud-native-apps-containers/cloud-native-resiliency/cloud-infrastructure-resiliency-azure.md

@@ -45,7 +45,7 @@ To architect redundancy, you need to identify the critical paths in your applica
 
 - **Plan for multiregion deployment.** If you deploy your application to a single region, and that region becomes unavailable, your application will also become unavailable. This may be unacceptable under the terms of your application's service level agreements. Otherwise, consider deploying your application and its services across multiple regions. For example, an Azure Kubernetes Service (AKS) cluster is deployed to a single region. To protect your system from a regional failure, you might deploy your application to multiple AKS clusters across different regions and use the [Paired Regions](/azure/virtual-machines/regions#region-pairs) feature to coordinate platform updates and prioritize recovery efforts.
 
-- **Enable [geo-replication](/azure/sql-database/sql-database-active-geo-replication).** Geo-replication for services such as Azure SQL Database and Cosmos DB will create secondary replicas of your data across multiple regions. While both services automatically replicate data within the same region, geo-replication protects you against a regional outage by enabling you to fail over to a secondary region. Another best practice for geo-replication centers around storing container images. To deploy a service in AKS, you need to store and pull the image from a repository. Azure Container Registry integrates with AKS and can securely store container images. To improve performance and availability, consider geo-replicating your images to a registry in each region where you have an AKS cluster. Each AKS cluster then pulls container images from the local container registry in its region as shown in Figure 6-4:
+- **Enable [geo-replication](/azure/sql-database/sql-database-active-geo-replication).** Geo-replication for services such as Azure SQL Database and Cosmos DB will create secondary replicas of your data across multiple regions. While both services automatically replicate data within the same region, geo-replication protects you against a regional outage by enabling you to fail over to a secondary region. Another best practice for geo-replication centers around storing container images. To deploy a service in AKS, you need to store and pull the image from a repository. Azure Container Registry integrates with AKS and can securely store container images. To improve performance and availability, consider geo-replicating your images to a registry in each region where you have an AKS cluster. Each AKS cluster then pulls container images from the local container registry in its region as shown in Figure 9-4:
 
     :::image type="content" source="media/replicated-resources.png" border="false" alt-text="A diagram showing replicated resources across multiple regions.":::
 
@@ -61,11 +61,11 @@ The cloud thrives on scaling. The ability to increase or decrease system resourc
 
 - **Partition workloads.** Decomposing domains into independent, self-contained microservices enables each service to scale independently of others. Typically, services will have different scalability needs and requirements. Partitioning enables you to scale only what needs to be scaled without the unnecessary cost of scaling an entire application.
 
-- **Favor scale-out.** Cloud-based applications favor scaling out resources as opposed to scaling up. Scaling out (also known as horizontal scaling) involves adding more service resources to an existing system to meet and share a desired level of performance. Scaling up (also known as vertical scaling) involves replacing existing resources with more powerful hardware (more disk, memory, and processing cores). Scaling out can be invoked automatically with the autoscaling features available in some Azure cloud resources. Scaling out across multiple resources also adds redundancy to the overall system. Finally scaling up a single resource is typically more expensive than scaling out across many smaller resources. Figure 6-6 shows the two approaches:
+- **Favor scale-out.** Cloud-based applications favor scaling out resources as opposed to scaling up. Scaling out (also known as horizontal scaling) involves adding more service resources to an existing system to meet and share a desired level of performance. Scaling up (also known as vertical scaling) involves replacing existing resources with more powerful hardware (more disk, memory, and processing cores). Scaling out can be invoked automatically with the autoscaling features available in some Azure cloud resources. Scaling out across multiple resources also adds redundancy to the overall system. Finally scaling up a single resource is typically more expensive than scaling out across many smaller resources. Figure 9-5 shows the two approaches:
 
     :::image type="content" source="media/scale-up-scale-out.png" alt-text="A diagram showing the differences between scale up (vertical scaling) versus scale out (horizontal scaling)." border="false":::
 
-    **Figure 9-6**. Scale up versus scale out
+    **Figure 9-5**. Scale up versus scale out
 
 - **Scale proportionally.** When scaling a service, think in terms of *resource sets*. If you were to scale out a specific service dramatically, what impact would that have on back-end data stores, caches, and dependent services? Some resources such as Cosmos DB can scale out proportionally, while many others can't. You want to ensure that you don't scale out a resource to a point where it will exhaust other associated resources.
 

docs/architecture/distributed-cloud-native-apps-containers/cloud-native-resiliency/resilient-communication.md

@@ -30,15 +30,15 @@ A better approach is an evolving technology entitled *Service Mesh*. A [service
 
 :::image type="content" source="media/service-mesh-with-side-car.png" alt-text="A diagram showing a service mesh using sidecars." border="false":::
 
-**Figure 9-7**. Service mesh with a sidecar
+**Figure 9-6**. Service mesh with a sidecar
 
 In the previous figure, note how the proxy intercepts and manages communication among the microservices and the cluster.
 
 A service mesh is logically split into two disparate components: A [data plane](https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc) and [control plane](https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc).
 
 :::image type="content" source="media/istio-control-and-data-plane.png" alt-text="A diagram showing a service mesh control and data plane" border="false":::
 
-**Figure 9-8.** Service mesh control and data plane
+**Figure 9-7.** Service mesh control and data plane
 
 Once configured, a service mesh is highly functional. It can retrieve a corresponding pool of instances from a service discovery endpoint. The mesh can then send a request to a specific instance, recording the latency and response type of the result. A mesh can choose the instance most likely to return a fast response based on many factors, including its observed latency for recent requests.
 

docs/architecture/distributed-cloud-native-apps-containers/data-patterns/azure-caching.md

@@ -26,11 +26,11 @@ Also consider caching to avoid repetitive computations. If an operation transfor
 
 ## Caching architecture
 
-Cloud native applications typically implement a distributed caching architecture. The cache is hosted as a cloud-based backing service, separate from the microservices. Figure 5-15 shows the architecture.
+Cloud native applications typically implement a distributed caching architecture. The cache is hosted as a cloud-based backing service, separate from the microservices. Figure 8-14 shows the architecture.
 
 ![A diagram showing how a cache is implemented in a cloud-native app.](media/distributed-data.png)
 
-**Figure 5-15**. Caching in a cloud-native app
+**Figure 8-14**. Caching in a cloud-native app
 
 The previous figure presents a common caching pattern known as the [cache-aside pattern](/azure/architecture/patterns/cache-aside). For an incoming request, you first query the cache (step \#1) for a response. If found, the data is returned immediately. If the data doesn't exist in the cache (known as a [cache miss](https://www.techopedia.com/definition/6308/cache-miss)), it's retrieved from a local database in a downstream service (step \#2). It's then written to the cache for future requests (step \#3), and returned to the caller. Care must be taken to periodically evict cached data so that the system remains timely and consistent.
 

docs/architecture/distributed-cloud-native-apps-containers/data-patterns/data-driven-crud-microservice.md

@@ -16,13 +16,13 @@ From a design point of view, this type of containerized microservice is very sim
 
 ![Diagram showing a simple CRUD microservice internal design pattern.](media/internal-design-simple-crud-microservices.png)
 
-**Figure 6-4**. Internal design for simple CRUD microservices
+**Figure 8-15**. Internal design for simple CRUD microservices
 
 An example of this kind of simple data-drive service is the catalog microservice from the eShop Reference Architecture sample application. This type of service implements all its functionality in a single ASP.NET Core Web API project that includes classes for its data model, its business logic, and its data access code. It also stores its related data in a database running in SQL Server (as another container for dev/test purposes), but could also be any regular SQL Server host:
 
 ![Diagram showing a data-driven/CRUD microservice container.](media/simple-data-driven-crud-microservice.png)
 
-**Figure 6-5**. Simple data-driven/CRUD microservice design
+**Figure 8-16**. Simple data-driven/CRUD microservice design
 
 This diagram shows the logical Catalog microservice, that includes its Catalog database, which can be or not in the same Docker host. Having the database in the same Docker host might be good for development, but not for production. When you are developing this kind of service, you only need [ASP.NET Core](/aspnet/core/) and a data-access API or ORM like [Entity Framework Core](/ef/core/index).
 
@@ -36,13 +36,13 @@ To implement a simple CRUD microservice using .NET and Visual Studio, you start
 
 ![Screenshot of Visual Studios showing the set up of the project.](media/create-asp-net-core-web-api-project.png)
 
-**Figure 6-6**. Creating an ASP.NET Core Web API project in Visual Studio 2019
+**Figure 8-17**. Creating an ASP.NET Core Web API project in Visual Studio 2019
 
 To create an ASP.NET Core Web API Project, first select an ASP.NET Core Web Application and then select the API type. After creating the project, you can implement your MVC controllers as you would in any other Web API project, using the Entity Framework API or other API. In a new Web API project, you can see that the only dependency you have in that microservice is on ASP.NET Core itself.
 
 ![Screenshot of VS showing the NuGet dependencies of Catalog.Api](media/simple-crud-web-api-microservice-dependencies.png)
 
-**Figure 6-7**. Dependencies in a simple CRUD Web API microservice
+**Figure 8-18**. Dependencies in a simple CRUD Web API microservice
 
 The API project includes references to Microsoft.AspNetCore.App NuGet package, that includes references to all essential packages. It could include some other packages as well.
 
@@ -247,7 +247,7 @@ This means you can complement your API with a nice discovery UI to help develope
 
 ![Screenshot of Swagger API Explorer displaying eShopOContainers API.](media/swagger-metadata-eshoponcontainers-catalog-microservice.png)
 
-**Figure 6-8**. Swashbuckle API Explorer based on Swagger metadata—eShopOnContainers catalog microservice
+**Figure 8-19**. Swashbuckle API Explorer based on Swagger metadata—eShopOnContainers catalog microservice
 
 The Swashbuckle generated Swagger UI API documentation includes all published actions. The API explorer is not the most important thing here. You can use tools like [swagger-codegen](https://github.com/swagger-api/swagger-codegen) which allow code generation of API client libraries, server stubs, and documentation automatically.
 
@@ -285,11 +285,11 @@ Once this is done, you can start your application and browse the following Swagg
   http://<your-root-url>/swagger/
 ```
 
-You previously saw the generated UI created by Swashbuckle for a URL like `http://<your-root-url>/swagger`. In Figure 6-9, you can also see how you can test any API method.
+You previously saw the generated UI created by Swashbuckle for a URL like `http://<your-root-url>/swagger`. In Figure 8-20, you can also see how you can test any API method.
 
 ![Screenshot of Swagger UI showing available testing tools.](media/swashbuckle-ui-testing.png)
 
-**Figure 6-9**. Swashbuckle UI testing the Catalog/Items API method
+**Figure 8-20**. Swashbuckle UI testing the Catalog/Items API method
 
 The Swagger UI API detail shows a sample of the response and can be used to execute the real API, which is great for developer discovery.