Docs Issue: Describe in docs how coyote is different from existing Microsoft Actor frameworks

[yahorsi]

Currently Microsoft has at least: Service Fabric Actors Dapr Coyote Orleans ...

So, in order to understand what coyote is and what it is best for we need at least some understanding about:

• the reason, it's been created
• how it is different from others
• what are scenarios to use coyote and what are scenarios to consider other frameworks
• what's scenarios Azure team used it in and why they have chosen coyote instead of Service Fabric, please NOTE that in the past Microsoft advertised Service Fabric as a service that is used internally by Azure a lot

PS See here https://twitter.com/RogerAlsing/status/1246504499784581124

[akashlal]

Hi @yahorsi. Thanks for the question. We have tried to address it in our FAQs. It is obviously an important question so we're happy to have a discussion on it.

The reason Coyote has been created

Today, we all build highly concurrent systems, designed to defending against race conditions, arbitrary faults, etc. But how do we test such systems? How do we know that we got the code right? These questions were the motivation behind creating Coyote.

Coyote focusses on writing specifications and providing high-coverage testing via systematic testing. The capability of writing better tests, getting (much) better coverage, accelerates the development process.

How is it different from other actor implementations

Coyote does not have a distributed runtime, so it cannot be a replacement for systems like Orleans, Dapr, Service Fabric, etc., each of which provide distributed hosting goodies such as state persistence, networking, load-balancing, etc.

Coyote embodies its ideas in programming models such as actors and tasks. Each of these only have in-memory representations. Think of them in the same way as C# Tasks: they're just programming constructs.

We believe Coyote is complimentary to these other frameworks. Some Azure teams, for instance, use Service Fabric for hosting their application and Coyote for expressing the logic. We have also seen instances where Reliable Actors were used, and each Reliable actor hosted a Coyote StateMachine inside. (The ReliableActor would receive messages and use them to drive the state machine.) Coyote testing vets correctness, and Service Fabric provides all the hosting capabilities.

We would welcome further suggestions on how best to leverage the respective strengths of these systems. Coyote has minimal dependencies, so it should be easy to integrate.

What scenarios to use Coyote as opposed to other systems?

As mentioned above, using Coyote does not rule out the other systems. Use Coyote when there is complexity in your design and you're interested in high-coverage testing of your logic (against concurrency, failures, timers, race conditions, etc.)

Coyote is not just for distributed systems. You can use it for single-box scenarios as well, e.g., asynchronous code using Tasks (running on a multi-core machine).

[pdeligia]

Closing this for now as it was answered.