Merge pull request #250733 from yungezz/iac

add solutions to IaC limitation

Author: ttorble

articles/service-connector/known-limitations.md

@@ -13,23 +13,25 @@ author: mcleanbyron
 
 In this article, learn about Service Connector's existing limitations and how to mitigate them.
 
-## Limitations to automation
+## Limitations to Infrastructure as Code (IaC)
 
-Service Connector has been designed to bring the benefits of easy, secure, and consistent backing service connections to as many Azure services as possible. To do so, Service Connector has been developed as a plugin-resource provider. This allows Service Connector to be integrated into other services. 
+Service Connector has been designed to bring the benefits of easy, secure, and consistent backing service connections to as many Azure services as possible. To do so, Service Connector has been developed as an extension resource provider.
 
-Unfortunately, this also has some limitations. These mainly impact automation scenarios where an Azure Resource Manager (ARM), Bicep or Terraform template defines these resources explicitly. Since Service Connector often modifies resources on a user’s behalf, this behavior can cause conflicts between the way a compute service instance, such as Azure Container Apps, and a Service Connector connection are created. For example, by default, the container application has managed identity (MI) disabled, whereas Service Connector enables it if the user chooses MI as an authentication method. If you run into issues which you believe are bugs that fall outside of the scenario described here, please [file an issue with us](https://github.com/microsoft/azure-container-apps/issues/new/choose). 
+Unfortunately, there are some limitations with IaC support as Service Connector modifies infrastructure on users' behalf. In this scenario, users would begin by using Azure Resource Manager (ARM), Bicep, Terraform, or other IaC templates to create resources. Afterwards, they would use Service Connector to set up resource connections. During this step, Service Connector modifies resource configurations on behalf of the user. If the user reruns their IaC template at a later time, modifications made by Service Connector would disappear as they were not reflected in the original IaC templates. An example of this behavior is Azure Container Apps deployed with ARM templates usually have Managed Identity (MI) disabled by default, Service Connector enables MI when setting up connections on users' behalf. If users trigger the same ARM templates without updating MI settings, the redeployed container apps will have MI disabled again.
 
-We’re working on improving this experience over the next releases. Until then, we suggest the following: 
+If you run into any issues when using Service Connector, [file an issue with us](https://github.com/Azure/ServiceConnector/issues/new). 
 
-- When automating an Azure Container App application using Service Connector, we recommend the use of the [multiple revision mode](../container-apps/revisions.md#revision-modes) to avoid sending traffic to a temporarily non-functional app because the Service Connector resource hasn’t been created yet and the application therefore won’t be able to rely on it. 
+## Solutions
+We suggest the following solutions: 
 
-- The order in which automation operations are performed matters greatly. Ensure your connection endpoints are there before the connection itself is created. Ideally, create the backing service, then the compute service, and then the connection between the two. This ensures that Service Connector has the ability to interact with both ends of the connection in order to configure them appropriately. 
+- Use Service Connector in Azure portal or Azure CLI to set up connections between compute and backing services, export ARM template from these existing resources via Azure portal or Azure CLI. Then use the exported ARM template as basis to craft automation ARM templates. This way, the exported ARM templates contain configurations added by Service Connector, reapplying the ARM templates doesn't affect existing application.
 
-- Prior to crafting your automation templates, check to see if there’s been any configuration drift, and whether a resource might have been changed. A good way of doing this would be to use the portal to create and configure your resources as desired and then utilize the available ARM export functionality to pull the latest configuration in the form of an ARM template format as your basis for your automation template.
+- If CI/CD pipelines contain ARM templates of source compute or backing services, suggested flow is: reapplying the ARM templates, adding sanity check or smoke tests to make sure the application is up and running, then allowing live traffic to the application. The flow adds verification step before allowing live traffic.
 
-## Limitations to Azure App Service deployment slots
+- When automating Azure Container App code deployments with Service Connector, we recommend the use of [multiple revision mode](../container-apps/revisions.md#revision-modes) to avoid routing traffic to a temporarily nonfunctional app before Service connector can reapply connections.
+
+- The order in which automation operations are performed matters greatly. Ensure your connection endpoints are there before the connection itself is created. Ideally, create the backing service, then the compute service, and then the connection between the two. So Service Connector can configure both the compute service and the backing service appropriately. 
 
-If you’re using App Service and have [more than one deployment slot](../app-service/deploy-staging-slots.md), Service Connector won't work. If deployment slots are critical to your way of working, we recommend [using app settings](../app-service/configure-common.md). 
 
 ## Next steps