Remove language references. The links will automatically localize for…

… users. (#165)

README.md

@@ -2,7 +2,7 @@
 
 There is no doubt that building containerized applications and following a microservices architecture is one of the most common software architecture patterns observed in the past couple of years.
 
-Microsoft Azure offers different services to package, deploy, and manage cloud-native applications, each of which serves a certain purpose and has its own pros and cons. This [page](https://learn.microsoft.com/en-us/azure/container-apps/compare-options) provides a good comparison between the available services to host and manage cloud-native containerized applications in Azure.
+Microsoft Azure offers different services to package, deploy, and manage cloud-native applications, each of which serves a certain purpose and has its own pros and cons. This [page](https://learn.microsoft.com/azure/container-apps/compare-options) provides a good comparison between the available services to host and manage cloud-native containerized applications in Azure.
 
 Whereas building cloud-native apps on Azure Kubernetes Service (AKS) is powerful,  there is a bit of a learning curve needed when it comes to creating and configuring the cluster, configuring networking between microservices, services discovery, certificates provisioning, and, lastly, managing the cluster over the lifetime of the application.
 

docs/aca/00-workshop-intro/1-aca-core-components.md

@@ -15,7 +15,7 @@ The Container App Environment is a secure boundary around several Container Apps
 Used to provide monitoring and observability functionality. Each environment will have its own Log Analytics workspace and will be shared among all container apps within the environment.
 
 1. **Container Apps**
-Each container App represents a single deployable unit that can contain one or more related containers. Using more than one container in a container app is an advanced use case. For this workshop we will deploy a single container in each container app. More about multiple containers in the same single Azure Container App can be found [here](https://docs.microsoft.com/en-us/azure/container-apps/containers#multiple-containers){target=_blank}.
+Each container App represents a single deployable unit that can contain one or more related containers. Using more than one container in a container app is an advanced use case. For this workshop we will deploy a single container in each container app. More about multiple containers in the same single Azure Container App can be found [here](https://docs.microsoft.com/azure/container-apps/containers#multiple-containers){target=_blank}.
 
 1. **Revisions**
 For each container app, you can create up to 100 revisions. Revisions are a way to deploy multiple versions of an app where you have the option to send the traffic to a certain revision. You can select if revision mode will support one or multiple active revisions at the same time to support A/B testing scenarios or canary deployments. A container app running in single revision mode will have a single revision that is backed by zero-many Pods/replicas.

docs/aca/00-workshop-intro/4-prerequisites.md

@@ -12,8 +12,8 @@ The workshop is divided into separate modules. Each module will guide you throug
 Make sure you have your development environment set up and configured.
 
 1. An Azure account with an active subscription - [Create an account for free](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio){target=_blank}
-1. .NET SDK 8 or a higher version (we primarily focus on LTS versions) - [Install](https://dotnet.microsoft.com/en-us/download){target=_blank}
-1. PowerShell 7.0 or higher version (For Windows Users only!) - [Install](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4#installing-the-msi-package){target=_blank}
+1. .NET SDK 8 or a higher version (we primarily focus on LTS versions) - [Install](https://dotnet.microsoft.com/download){target=_blank}
+1. PowerShell 7.0 or higher version (For Windows Users only!) - [Install](https://learn.microsoft.com/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4#installing-the-msi-package){target=_blank}
 1. Docker Desktop - [Install](https://docs.docker.com/desktop/install/windows-install/){target=_blank}
    > As of November 2024, Docker Desktop continues to be free for education purposes. Please consult the [Docker Desktop license agreement](https://docs.docker.com/subscription/desktop-license/) for any updates.
 1. Visual Studio Code - [Install](https://code.visualstudio.com/){target=_blank}

docs/aca/00-workshop-intro/index.md

@@ -5,7 +5,7 @@ title: Introduction
 
 ## Description
 
-The Building Microservice Applications with Azure Container Apps workshop will provide you with the practical knowledge to create, deploy, and operate an enterprise level microservice application deployed on the latest serverless containers offering, [Azure Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/overview){target=_blank}. We will demonstrate enabling different components like Dapr which will allow you to address common challenges when building an event driven distributed application while keeping your code platform agnostic. In addition to this, you will get familiar with the built-in autoscaling capabilities in Azure Container Apps using KEDA and how to control spending by scaling down to zero replicas.
+The Building Microservice Applications with Azure Container Apps workshop will provide you with the practical knowledge to create, deploy, and operate an enterprise level microservice application deployed on the latest serverless containers offering, [Azure Container Apps](https://learn.microsoft.com/azure/container-apps/overview){target=_blank}. We will demonstrate enabling different components like Dapr which will allow you to address common challenges when building an event driven distributed application while keeping your code platform agnostic. In addition to this, you will get familiar with the built-in autoscaling capabilities in Azure Container Apps using KEDA and how to control spending by scaling down to zero replicas.
 
 ## Objectives & Outcomes
 

docs/aca/01-deploy-api-to-aca/index.md

@@ -167,7 +167,7 @@ We will be using Azure CLI to deploy the Web API Backend to ACA as shown in the
     ```
 
 ???+ tip "Cloud Adoption Framework Abbreviations"
-    Unless you have your own naming convention, we suggest to use [Cloud Adoption Framework (CAF) abbreviations](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations){target=_blank} for resource prefixes.
+    Unless you have your own naming convention, we suggest to use [Cloud Adoption Framework (CAF) abbreviations](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations){target=_blank} for resource prefixes.
 
 - Create a resource group to organize the services related to the application, run the below command:
 
@@ -239,7 +239,7 @@ We will be using Azure CLI to deploy the Web API Backend to ACA as shown in the
     --output tsv
     ```
 
-- Create an [Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview?tabs=net){target=_blank} instance which will be used mainly for [distributed tracing](https://learn.microsoft.com/en-us/azure/azure-monitor/app/distributed-tracing){target=_blank} between different container apps within the ACA environment to provide searching for and visualizing an end-to-end flow of a given execution or transaction. To create it, run the command below:
+- Create an [Application Insights](https://learn.microsoft.com/azure/azure-monitor/app/app-insights-overview?tabs=net){target=_blank} instance which will be used mainly for [distributed tracing](https://learn.microsoft.com/azure/azure-monitor/app/distributed-tracing){target=_blank} between different container apps within the ACA environment to provide searching for and visualizing an end-to-end flow of a given execution or transaction. To create it, run the command below:
 
     ```shell
     # Create Application Insights instance
@@ -336,14 +336,14 @@ We will be using Azure CLI to deploy the Web API Backend to ACA as shown in the
     ```
 
 ??? tip "Want to learn what the above command does?"
-    - Ingress param is set to `external` which means that this container app (Web API) project will be accessible from the public internet. When Ingress is set to `Internal` or `External` it will be assigned a fully qualified domain name (FQDN). Important notes about IP addresses and domain names can be found [here](https://learn.microsoft.com/en-us/azure/container-apps/ingress?tabs=bash#ip-addresses-and-domain-names){target=_blank}.
+    - Ingress param is set to `external` which means that this container app (Web API) project will be accessible from the public internet. When Ingress is set to `Internal` or `External` it will be assigned a fully qualified domain name (FQDN). Important notes about IP addresses and domain names can be found [here](https://learn.microsoft.com/azure/container-apps/ingress?tabs=bash#ip-addresses-and-domain-names){target=_blank}.
     - The target port param is set to 80, this is the port our Web API container listens to for incoming requests.
     - We didn't specify the ACR registry username and password, `az containerapp create` command was able to look up ACR username and password and add them as a secret under the created Azure container app for future container updates.
     - The minimum and the maximum number of replicas are set. More about this when we cover Autoscaling in later modules. For the time being, only a single instance of this container app will be provisioned as Auto scale is not configured.
-    - We set the size of the Container App. The total amount of CPUs and memory requested for the container app must add up to certain combinations, for full details check the link [here](https://docs.microsoft.com/en-us/azure/container-apps/containers#configuration){target=_blank}.
+    - We set the size of the Container App. The total amount of CPUs and memory requested for the container app must add up to certain combinations, for full details check the link [here](https://docs.microsoft.com/azure/container-apps/containers#configuration){target=_blank}.
     - The `query` property will filter the response coming from the command and just return the FQDN. Take note of this FQDN as you will need it for the next step.
 
-    For full details on all available parameters for this command, please visit this [page](https://docs.microsoft.com/en-us/cli/azure/containerapp?view=azure-cli-latest#az-containerapp-create){target=_blank}.
+    For full details on all available parameters for this command, please visit this [page](https://docs.microsoft.com/cli/azure/containerapp?view=azure-cli-latest#az-containerapp-create){target=_blank}.
 
 - You can now verify the deployment of the first ACA by navigating to the link at the end of the above script or to the [Azure portal](https://portal.azure.com){target=_blank} and selecting the resource group named `tasks-tracker-rg` that you created earlier. You should see the 5 resourses created below.
 ![Azure Resources](../../assets/images/01-deploy-api-to-aca/Resources.jpg)

docs/aca/03-aca-dapr-integration/index.md

@@ -26,7 +26,7 @@ The Tasks Tracker microservice application is composed of multiple microservices
 we need to account for failures, retries, and timeouts. While Azure Container Apps features the building blocks for running microservices, using the Distributed Application Runtime (Dapr) provides an even richer microservices programming model.
 
 Dapr includes features like service discovery, pub/sub, service-to-service invocation with mutual TLS, retries, state store management, and more.
-Here is a good [link](https://learn.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/service-invocation){target=_blank} which touches on some of the benefits of the Dapr service invocation building block which we will be building upon in this module.
+Here is a good [link](https://learn.microsoft.com/dotnet/architecture/dapr-for-net-developers/service-invocation){target=_blank} which touches on some of the benefits of the Dapr service invocation building block which we will be building upon in this module.
 Because the calls will flow through container sidecars, Dapr can inject some useful cross-cutting behaviors that are meaningfully abstracted from our application containers.
 
 Although we won't tap into all these benefits in this workshop, it's worth noting that you will probably need to rely on these features in production:

docs/aca/04-aca-dapr-stateapi/index.md

@@ -296,7 +296,7 @@ To add the component file state store, add a new folder named **components** und
     - We've used the name `statestore` which should match the name of statestore we've used in the `TaskStoreManager.cs` file. As well, we have set the metadata key/value to allow us to connect to Azure Cosmos DB.
     - We've updated the other metadata keys such as `database`, `collection`, etc... to match the values of your Cosmos DB instance. For full metadata specs, you can check this [page](https://docs.dapr.io/reference/components-reference/supported-state-stores/setup-azure-cosmosdb/){target=_blank}.
     - By default, all dapr-enabled container apps within the same environment will load the full set of deployed components. By adding `scopes` to a component, you tell the Dapr sidecars for each respective container app which components to load at runtime.
-    Using scopes is recommended for production workloads. In our case, we have set the scopes to `tasksmanager-backend-api` which represents the dapr-app-id which is associated to the container app that needs access to Azure Cosmos DB State Store as this will be the application that needs access to Azure Cosmos DB State Store. More about scopes can be found on this [link](https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#component-scopes){target=_blank}.
+    Using scopes is recommended for production workloads. In our case, we have set the scopes to `tasksmanager-backend-api` which represents the dapr-app-id which is associated to the container app that needs access to Azure Cosmos DB State Store as this will be the application that needs access to Azure Cosmos DB State Store. More about scopes can be found on this [link](https://learn.microsoft.com/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#component-scopes){target=_blank}.
 
 !!! note
     Dapr component scopes correspond to the Dapr application ID of a container app, not the container app name.
@@ -344,9 +344,9 @@ If we need to totally omit the key prefix, so it is accessed across multiple Dap
 
 #### 3.3 Configure Managed Identities in Container App
 
-As we highlighted earlier, we'll not use a connection strings to establish the relation between our Container App and Azure Cosmos DB when we deploy to ACA. Cosmos DB Master Key/Connection string was only used when debugging locally. Now we will rely on Managed Identities to allow our container app to access Cosmos DB. With [Manged Identities](https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml){target=_blank} you do't worry about storing the keys securely and rotate them inside your application. This approach is safer and easier to manage.
+As we highlighted earlier, we'll not use a connection strings to establish the relation between our Container App and Azure Cosmos DB when we deploy to ACA. Cosmos DB Master Key/Connection string was only used when debugging locally. Now we will rely on Managed Identities to allow our container app to access Cosmos DB. With [Manged Identities](https://learn.microsoft.com/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml){target=_blank} you do't worry about storing the keys securely and rotate them inside your application. This approach is safer and easier to manage.
 
-We will be using a `system-assigned` identity with a role assignment to grant our Backend API container app permissions to access data stored in Cosmos DB. We need to assign it a custom role for the Cosmos DB data plane. In this example ae are going to use a [built-in role](https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#built-in-role-definitions){target=_blank}, named `Cosmos DB Built-in Data Contributor`, which grants our application full read-write access to the data. You can optionally create custom, fine-tuned roles following the instructions in the [official docs](https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac){target=_blank}.
+We will be using a `system-assigned` identity with a role assignment to grant our Backend API container app permissions to access data stored in Cosmos DB. We need to assign it a custom role for the Cosmos DB data plane. In this example ae are going to use a [built-in role](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac#built-in-role-definitions){target=_blank}, named `Cosmos DB Built-in Data Contributor`, which grants our application full read-write access to the data. You can optionally create custom, fine-tuned roles following the instructions in the [official docs](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac){target=_blank}.
 
 #### 3.3.1 Create system-assigned identity for our Backend API Container App
 
@@ -385,7 +385,7 @@ Keep a note of the property `principalId` as we are going to use it in the next
 #### 3.3.2 Assign the Container App System-Identity To the Built-in Cosmos DB Role
 
 Next, we need to associate the container app system-identity with the target Cosmos DB resource.
-You can read more about Azure built-in roles for Cosmos DB or how to create custom fine-tuned roles [here](https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#built-in-role-definitions){target=_blank}.
+You can read more about Azure built-in roles for Cosmos DB or how to create custom fine-tuned roles [here](https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac#built-in-role-definitions){target=_blank}.
 Run the command below to associate the container app `system-assigned` identity with `Cosmos DB Built-in Data Contributor` role.
 
 !!! note
@@ -407,7 +407,7 @@ az cosmosdb sql role assignment create `
 
 We are almost ready to deploy all local changes from this module and the previous module to ACA. But before we do that, we need one last addition.
 
-We have to create a [dapr component schema file](https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#component-schema){target=_blank} for Azure Cosmos DB which meets the specs defined by
+We have to create a [dapr component schema file](https://learn.microsoft.com/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#component-schema){target=_blank} for Azure Cosmos DB which meets the specs defined by
 Azure Container Apps. The reason for this variance is that ACA Dapr schema is slightly simplified to support Dapr components and removes unnecessary fields, including `apiVersion`, `kind`, and redundant metadata and spec properties.
 
 #### 3.4.1 Create an ACA-Dapr Component File For State Store Management
@@ -482,7 +482,7 @@ az containerapp dapr enable `
     This `dapr-app-id` will be used for service discovery, state encapsulation and the pub/sub consumer ID.
     - We've set the `dapr-app-port` which is the port our applications are listening on which will be used by Dapr for communicating to our applications.
 
-    For a complete list of the supported Dapr sidecar configurations in Container Apps, you can refer to [this link](https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#dapr-enablement){target=_blank}.
+    For a complete list of the supported Dapr sidecar configurations in Container Apps, you can refer to [this link](https://learn.microsoft.com/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#dapr-enablement){target=_blank}.
 
 #### 3.4.5 Deploy New Revisions of the Frontend Web App and Backend API to Container Apps