first editorial pass and add to toc

Signed-off-by: Hannah Hunter <[email protected]>

Author: hhunter-ms

articles/container-apps/TOC.yml

@@ -161,6 +161,10 @@
       href: storage-mounts.md
     - name: Plan for disaster recovery
       href: disaster-recovery.md
+    - name: Dapr
+      items:
+      - name: Scale Dapr components with KEDA
+        href: dapr-keda-scaling.md
 - name: Tutorials
   expanded: true
   items: 

articles/container-apps/dapr-keda-scaling.md

@@ -5,24 +5,34 @@ author: hhunter-ms
 ms.author: hannahhunter
 ms.service: container-apps
 ms.topic: how-to 
-ms.date: 04/07/2023
+ms.date: 04/10/2023
 ---
 
 # Scale Dapr components with KEDA scalers for Azure Container Apps
 
-When scale rules are omitted on an Azure Container Apps resource, the container app is created with a default scale rule. If the resource receives no incoming traffic over a duration of five minutes, that default rule scales all replicas down to zero.
+When scale rules are omitted on an Azure Container Apps resource, the container app is created with a default scale rule. If the resource receives no incoming traffic over a duration of five minutes, that default rule scales all replicas down to zero. This behavior can be problematic and unexpected when leveraging Dapr components, specifically pub/sub subscriptions and input bindings. 
 
-This behavior can be problematic and unexpected when leveraging Dapr components, specifically pub/sub subscriptions and input bindings. This is due to how the mechanism for subscriptions and input bindings work. Unlike normal http flows, subscriptions and input bindings follow a "pull" message/event exchange model. In this case the Dapr sidecar from the subscriber service "pulls" messages rather than waiting for the message broker/event deliverer to initiate a connection. As a result, since the "puller" logic is in the Dapr sidecar, when it scales down to zero, the "puller" is stopped and there's no mechanism for it to know when to resume or scale back up from zero.
+Using KEDA scalers, you can scale your application and its Dapr sidecar when it has scaled to zero with inbound events and messages. However, configuring _both_ a Dapr component and a corresponding KEDA scaler is not intuitive.
 
-KEDA scalers is one possible solution for scaling an application and its sidecar when it has scaled to 0 and incoming events and messages are inbound. With KEDA, there is a process that's outside of the application, which is never scaled down to zero that can wawtch for new messages/incoming events. It can then scale the receiving application as needed based on the number of incoming messages/events.
+todo: solution - if it's redundant or complex, then why?
 
-However, there is complexity and redudancncy with the experience that is offered today. A Dapr component and a corresponding KEDA scaler are two separate configurations and it's not intuative that a KEDA scaler is often needed.
+## Configure container apps for scaling
 
-The following scenario outlines a simple scenario with two microservices - a publisher and subscriber. In a loop, the publisher is continuously publishing messages via the Dapr pub/sub API to the topic ‘orders’ in Azure Service Bus. The order-processor container app is subscribed to the ‘orders’ topic and is receiving  and processing the messages as they arrive. 
+In this scenario:
+1. In a loop, a `checkout` publisher container app continuously publishes messages via the Dapr pub/sub API to the `orders` topic in Azure Service Bus.
+1. An `order-processor` subscriber container app subscribed to the `orders` topic receives and processes messages as they arrive.
 
-Let’s look at the Bicep for both Container Apps – the checkout and order-processor service as well as the Dapr Azure Serivce Bus component:
+Let’s look at the Bicep for:
+- The `checkout` and `order-processor` container apps
+- The Dapr Azure Serivce Bus component
 
-#### Checkout Container App (Publisher)
+todo: need actual steps - so far it's more of a scenario concept, user isn't walking through any steps.
+
+### Publisher container app
+
+The `checkout` publisher is a headless services that you want to run indefinitely and never scale down to zero. 
+
+Set the `minReplicas` to "1", which ensures the container app does not follow the default behavior. 
 
 ```bicep
 resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
@@ -80,11 +90,10 @@ resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
 }
 ```
 
-Since the checkout container app is a headless services that we want to run indefinitely and never scale down to 0, we are setting the min replicas to 1, which ensures the container app does not follow the default behavior of scaling to 0 after 5 minutes. 
+### Dapr component
 
-Next, we will look at the configuration for the Dapr component for connecting to Azure Service Bus:
+Next, configure the Dapr component for connecting to Azure Service Bus via a connection string.
 
-#### Order-Processor Container App (Subscriber)
 ```bicep
 resource daprComponent 'daprComponents' = {
     name: 'orderpubsub'
@@ -112,11 +121,9 @@ resource daprComponent 'daprComponents' = {
   }
 ```
 
-In the above example, the component is configured to connect to Azure Service Bus via a connection string. 
-
-Lastly, we'll review the `order-processor` container app:
+### Subscriber container app
 
-#### Order-Processor Container App (Subscriber)
+In the `order-processor` subscriber, you'll add a custom scale rule on the resource for the type `azure-servicebus`. With this scale rule, KEDA can scale up the container app and its Dapr sidecar, allowing incoming messages to be processed again while order-processor is scaled to zero.
 
 ```bicep
 resource orders 'Microsoft.App/containerApps@2022-03-01' = {
@@ -178,6 +185,7 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
           ]
         }
       ]
+      // Set the scale property on the order-processor resource
       scale: {
         minReplicas: 0
         maxReplicas: 10
@@ -206,32 +214,6 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
 }
 ```
 
-Notice the scale property on the resource:
-
-```bicep
-scale: {
-  minReplicas: 0
-  maxReplicas: 10
-  rules: [
-    {
-      name: 'topic-based-scaling'
-      custom: {
-        type: 'azure-servicebus'
-        metadata: {
-          topicName: 'orders'
-          subscriptionName: 'orders'
-          messageCount: '30'
-        }
-        auth: [
-          {
-          secretRef: 'sb-root-connectionstring'
-          triggerParameter: 'connection'
-          }
-        ]
-      }
-    }
-  ]
-}
-```
+## Next steps
 
-This is a custom scale rule for the type “azure-servicebus”. This scale rule is needed to ensure that when a message comes into the Azure Service Bus while the order-processor is scaled to 0, that KEDA can scale up the container app, along with its Dapr sidecar so messages can be processed again. 
+[Learn more about using Dapr components with Azure Container Apps.](./dapr-overview.md)