start actors overview edit

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>

daprdocs/content/en/developing-applications/building-blocks/actors/actors-overview.md

@@ -8,7 +8,6 @@ aliases:
   - "/developing-applications/building-blocks/actors/actors-background"
 ---
 
-## Introduction
 The [actor pattern](https://en.wikipedia.org/wiki/Actor_model) describes actors as the lowest-level "unit of computation". In other words, you write your code in a self-contained unit (called an actor) that receives messages and processes them one at a time, without any kind of concurrency or threading.
 
 While your code processes a message, it can send one or more messages to other actors, or create new actors. An underlying runtime manages how, when and where each actor runs, and also routes messages between actors.
@@ -27,13 +26,16 @@ The actor design pattern can be a good fit to a number of distributed systems pr
 * You want to work with single-threaded objects that do not require significant interaction from external components, including querying state across a set of actors.
 * Your actor instances won't block callers with unpredictable delays by issuing I/O operations.
 
-## Actors in dapr
+## Actors in Dapr
 
 Every actor is defined as an instance of an actor type, identical to the way an object is an instance of a class. For example, there may be an actor type that implements the functionality of a calculator and there could be many actors of that type that are distributed on various nodes across a cluster. Each such actor is uniquely identified by an actor ID.
 
 <img src="/images/actor_background_game_example.png" width=400>
 
-## Actor lifetime
+### How it works
+
+
+### Actor lifetime
 
 Dapr actors are virtual, meaning that their lifetime is not tied to their in-memory representation. As a result, they do not need to be explicitly created or destroyed. The Dapr actor runtime automatically activates an actor the first time it receives a request for that actor ID. If an actor is not used for a period of time, the Dapr actor runtime garbage-collects the in-memory object. It will also maintain knowledge of the actor's existence should it need to be reactivated later.
 
@@ -45,13 +47,13 @@ This virtual actor lifetime abstraction carries some caveats as a result of the
 
 An actor is automatically activated (causing an actor object to be constructed) the first time a message is sent to its actor ID. After some period of time, the actor object is garbage collected. In the future, using the actor ID again, causes a new actor object to be constructed. An actor's state outlives the object's lifetime as state is stored in configured state provider for Dapr runtime.
 
-## Distribution and failover
+### Distribution and failover
 
 To provide scalability and reliability, actors instances are distributed throughout the cluster and Dapr  automatically migrates them from failed nodes to healthy ones as required.
 
 Actors are distributed across the instances of the actor service, and those instance are distributed across the nodes in a cluster. Each service instance contains a set of actors for a given actor type.
 
-### Actor placement service
+#### Actor placement service
 The Dapr actor runtime manages distribution scheme and key range settings for you. This is done by the actor `Placement` service. When a new instance of a service is created, the corresponding Dapr runtime registers the actor types it can create and the `Placement` service calculates the partitioning across all the instances for a given actor type. This table of partition information for each actor type is updated and stored in each Dapr instance running in the environment and can change dynamically as new instance of actor services are created and destroyed. This is shown in the diagram below.
 
 <img src="/images/actors_background_placement_service_registration.png" width=600>
@@ -67,7 +69,7 @@ When a client calls an actor with a particular id (for example, actor id 123), t
 
 Note: The Dapr actor Placement service is only used for actor placement and therefore is not needed if your services are not using Dapr actors. The Placement service can run in all [hosting environments]({{< ref hosting >}}), including self-hosted and Kubernetes.
 
-## Actor communication
+### Actor communication
 
 You can interact with Dapr to invoke the actor method by calling HTTP/gRPC endpoint.
 
@@ -81,7 +83,7 @@ Another, and perhaps more convenient, way of interacting with actors is via SDKs
 
 Refer to [Dapr Actor Features]({{< ref howto-actors.md >}}) for more details.
 
-### Concurrency
+#### Concurrency
 
 The Dapr actor runtime provides a simple turn-based access model for accessing actor methods. This means that no more than one thread can be active inside an actor object's code at any time. Turn-based access greatly simplifies concurrent systems as there is no need for synchronization mechanisms for data access. It also means systems must be designed with special considerations for the single-threaded access nature of each actor instance.
 
@@ -91,11 +93,11 @@ Actors can deadlock on each other if there is a circular request between two act
 
 <img src="/images/actors_background_communication.png" width=600>
 
-#### Reentrancy
+##### Reentrancy
 
 To allow actors to "re-enter" and invoke methods on themselves, see [Actor Reentrancy]({{<ref actor-reentrancy.md>}}).
 
-### Turn-based access
+#### Turn-based access
 
 A turn consists of the complete execution of an actor method in response to a request from other actors or clients, or the complete execution of a timer/reminder callback. Even though these methods and callbacks are asynchronous, the Dapr actor runtime does not interleave them. A turn must be fully finished before a new turn is allowed. In other words, an actor method or timer/reminder callback that is currently executing must be fully finished before a new call to a method or callback is allowed. A method or callback is considered to have finished if the execution has returned from the method or callback and the task returned by the method or callback has finished. It is worth emphasizing that turn-based concurrency is respected even across different methods, timers, and callbacks.
 
@@ -105,3 +107,21 @@ The following example illustrates the above concepts. Consider an actor type tha
 
 <img src="/images/actors_background_concurrency.png" width=600>
 
+## Try out actors
+
+### Tutorials
+
+Want to put the Dapr actors API to the test? Walk through the following quickstart and tutorials to see actors in action:
+
+| Quickstart/tutorial | Description |
+| ------------------- | ----------- |
+| [Bindings quickstart]({{< ref bindings-quickstart.md >}}) | Work with external systems using input bindings to respond to events and output bindings to call operations. |
+| [Bindings tutorial](https://github.com/dapr/quickstarts/tree/master/tutorials/bindings) | Demonstrates how to use Dapr to create input and output bindings to other components. Uses bindings to Kafka. |
+
+### Start using actors directly in your app
+
+Want to skip the quickstarts? Not a problem. You can try out the actors building block directly in your application. After [Dapr is installed]({{< ref "getting-started/_index.md" >}}), you can begin using the actors API starting with [the how-to guide]({{< ref howto-actors.md >}}).
+
+
+
+## Next steps