dapr / dapr

Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.

Any language, any framework, anywhere

Dapr is a portable, serverless, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

Dapr codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is independent and you can use one, some, or all of them in your application.

We are a Cloud Native Computing Foundation (CNCF) incubation project.

Goals

• Enable developers using any language or framework to write distributed applications
• Solve the hard problems developers face building microservice applications by providing best practice building blocks
• Be community driven, open and vendor neutral
• Gain new contributors
• Provide consistency and portability through open APIs
• Be platform agnostic across cloud and edge
• Embrace extensibility and provide pluggable components without vendor lock-in
• Enable IoT and edge scenarios by being highly performant and lightweight
• Be incrementally adoptable from existing code, with no runtime dependency

How it works

Dapr injects a side-car (container or process) to each compute unit. The side-car interacts with event triggers and communicates with the compute unit via standard HTTP or gRPC protocols. This enables Dapr to support all existing and future programming languages without requiring you to import frameworks or libraries.

Dapr offers built-in state management, reliable messaging (at least once delivery), triggers and bindings through standard HTTP verbs or gRPC interfaces. This allows you to write stateless, stateful and actor-like services following the same programming paradigm. You can freely choose consistency model, threading model and message delivery patterns.

Dapr runs natively on Kubernetes, as a self hosted binary on your machine, on an IoT device, or as a container that can be injected into any system, in the cloud or on-premises.

Dapr uses pluggable component state stores and message buses such as Redis as well as gRPC to offer a wide range of communication methods, including direct dapr-to-dapr using gRPC and async Pub-Sub with guaranteed delivery and at-least-once semantics.

Why Dapr?

Writing highly performant, scalable and reliable distributed application is hard. Dapr brings proven patterns and practices to you. It unifies event-driven and actors semantics into a simple, consistent programming model. It supports all programming languages without framework lock-in. You are not exposed to low-level primitives such as threading, concurrency control, partitioning and scaling. Instead, you can write your code by implementing a simple web server using familiar web frameworks of your choice.

Dapr is flexible in threading and state consistency models. You can leverage multi-threading if you choose to, and you can choose among different consistency models. This flexibility enables you to implement advanced scenarios without artificial constraints. Dapr is unique because you can transition seamlessly between platforms and underlying implementations without rewriting your code.

Features

• Event-driven Pub-Sub system with pluggable providers and at-least-once semantics
• Input and output bindings with pluggable providers
• State management with pluggable data stores
• Consistent service-to-service discovery and invocation
• Opt-in stateful models: Strong/Eventual consistency, First-write/Last-write wins
• Cross platform virtual actors
• Secret management to retrieve secrets from secure key vaults
• Rate limiting
• Built-in Observability support
• Runs natively on Kubernetes using a dedicated Operator and CRDs
• Supports all programming languages via HTTP and gRPC
• Multi-Cloud, open components (bindings, pub-sub, state) from Azure, AWS, GCP
• Runs anywhere, as a process or containerized
• Lightweight (58MB binary, 4MB physical memory)
• Runs as a sidecar - removes the need for special SDKs or libraries
• Dedicated CLI - developer friendly experience with easy debugging
• Clients for Java, .NET Core, Go, Javascript, Python, Rust and C++

Get Started using Dapr

See our Getting Started guide over in our docs.

Quickstarts and Samples

• See the quickstarts repository for code examples that can help you get started with Dapr.
• Explore additional samples in the Dapr samples repository.

Community

We want your contributions and suggestions! One of the easiest ways to contribute is to participate in discussions on the mailing list, chat on IM or the bi-weekly community calls. For more information on the community engagement, developer and contributing guidelines and more, head over to the Dapr community repo.

Contact Us

Reach out with any questions you may have and we'll make sure to answer them as soon as possible!

Platform	Link
💬 Instant Message Chat (preferred)
📧 Mailing List	https://groups.google.com/forum/#!forum/dapr-dev
🐤 Twitter	@daprdev

Community Call

Every two weeks we host a community call to showcase new features, review upcoming milestones, and engage in a Q&A. All are welcome!

📞 Visit https://aka.ms/dapr-community-call for upcoming dates and the meeting link.

Videos and Podcasts

We have a variety of keynotes, podcasts, and presentations available to reference and learn from.

📺 Visit https://docs.dapr.io/contributing/presentations/ for previous talks and slide decks.

Contributing to Dapr

See the Development Guide to get started with building and developing.

Repositories

Repo	Description
Dapr	The main repository that you are currently in. Contains the Dapr runtime code and overview documentation.
CLI	The Dapr CLI allows you to setup Dapr on your local dev machine or on a Kubernetes cluster, provides debugging support, launches and manages Dapr instances.
Docs	The documentation for Dapr.
Quickstarts	This repository contains a series of simple code samples that highlight the main Dapr capabilities.
Samples	This repository holds community maintained samples for various Dapr use cases.
Components-contrib	The purpose of components contrib is to provide open, community driven reusable components for building distributed applications.
Dashboard	General purpose dashboard for Dapr
Go-sdk	Dapr SDK for Go
Java-sdk	Dapr SDK for Java
JS-sdk	Dapr SDK for JavaScript
Python-sdk	Dapr SDK for Python
Dotnet-sdk	Dapr SDK for .NET
Rust-sdk	Dapr SDK for Rust
Cpp-sdk	Dapr SDK for C++
PHP-sdk	Dapr SDK for PHP

Code of Conduct

Please refer to our Dapr Community Code of Conduct

dapr's Issues

Manually create GitHub release for June

Update Readme diagrams

Iteration Plan for June 2019

This plan captures our work in June. This is a 2-week iteration. We will ship our June Update in early July.

Theme

• Being the very first Plan, we'll focus on putting the process and logistics in place to ship a release.
• Customer ready demo to show the capabilities of Actions

Endgame

June 24th, 2019: Endgame begins
July 2nd, 2019: Endgame complete

The endgame details for this iteration are tracked #2

Plan Items

Below is a summary of the top level plan items.

Legend of annotations:

Mark	Description
🏃	work in progress
✋	blocked task
💪	stretch goal for this iteration
🔴	missing issue reference
🔵	more investigation required to remove uncertainty
⚫️	under discussion within the team

Runtime

• Create basic test cases for components @Haishi2016 #9
  • Moved to July 2019 iteration
• Update Readme.md diagrams @likamrat #5

Demo/Sample

• Create samples @Haishi2016 @yaron2 #7

Engineering Systems

• Import code @yaron2 #4
• Import demo app code @yaron2 #6
• Create Makefiles @yaron2 #8
• Setup CI @lukekim #3

Create logo for Dapr

Create a logo for Actions.
Latest date needed 1 month before public preview.

Code documentation

100% of exported methods should be documented.

Update/fix documentation for June 2019 Endgame

Redis Streams for Pub Sub

Actions k8s - change sidecar injection to Admission Controller

Add reminder, timer capabilities for Actors

Reminders are a mechanism to trigger persistent callbacks on an actor at specified times, reminders are fired even if an actor is deactivated. Reminder firing keeps an actor active.
Timers are fired only when actor is active, it could have been activated by a method call or reminder call. Timer firing doesn't keep an actor active.
Similar to following: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-timers-reminders#actor-reminders

Local zero to hero getting started sample update

Rename assigner to placement

Separate Actions APIs (gRPC & HTTP) implementations from protocols into its own Go pkg

We should consider to separate Action API from transmission protocols (HTTP/gRPC). This will allow some flavor of client/edge applications (such as Mobile apps and IoT edge apps) to leverage Actions API in-proc without hosting a web server.
Architecturally, we should have Actions API hosted on a Actions Host, which exposes Actions APIs through supported protocols such as HTTP and gRPC.

Provide api to query actors alongwith their active/inactive status

This allows customers to query the actors and delete all the state for inactive actors.
Similar to following
https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.actors.iactorservice.getactorsasync?view=azure-dotnet#Microsoft_ServiceFabric_Actors_IActorService_GetActorsAsync_Microsoft_ServiceFabric_Actors_Query_ContinuationToken_System_Threading_CancellationToken_

Add api to delete all the state for an actor

Provide api to delete all the state for an actor alongwith any metadata stored for it.
This is in addition to the api to delete a state with a particular key.

Allow configurable logging levels

Iteration Plan for July 2019

This plan captures our work in July. This is a 4-week iteration. We will ship our July Update in early August.

Themes

• Improve project testability, supportability, extensibility and ability to contribute
• Unblock the C# Actors support

Endgame

July 29th, 2019: Endgame begin
August 2nd, 2019: Endgame complete

The endgame details for this iteration are tracked

Plan Items

Below is a summary of the top level plan items.

Legend of annotations:

Mark	Description
🏃	work in progress
✋	blocked task
💪	stretch goal for this iteration
🔴	missing issue reference
🔵	more investigation required to remove uncertainty
⚫️	under discussion within the team

Spec

• #94 Migrate spec from old org to new org

Runtime

• #43 Rename assigner to placement area/assigner area/runtime
• #84 Add skeleton release notes file for 0.2.0-alpha
• #79 Design doc and review for decision on separation of state stores & message buses outside of Bindings
• #76 Separate Actions APIs (gRPC & HTTP) implementations from protocols into its own Go pkg
• #83 API versioning in Spec and implementation
• #78 Change the interface of Bindings

Demo/Sample

• Add Redis.yaml to kubernetes sample area/sample #108
• Update standalone sample to remove complexity area/sample #107
• Add container devops information in samples area/sample #106

CLI

• #70 Review and adjust CLI versioning to match with runtime
• actionscore/cli - Actions CLI should be named as actions.exe for Windows (14)

Engineering Systems

• #81 Create Actions Azure subscription
• #82 ESRP onboarding
• #99 change runtime image in actions.yaml

Create Helm chart for k8s-operator

Change Event Sources to Bindings

Allow UserActorCode to provide Settings in /actions/config callback

@amanbha which settings?

Add delete state API

Create basic test cases for old components (retroactive technical debt)

Remove configuration_v1alpha1 and eventing_v1alpha1 from Runtime

Move components to separate repository

Create samples

Create release notes for June 2019 release

Allow HOST_IP to override for both kubernetes/standalone modes

Service method invocation protocol needs to be consistent between local and remote

The syntax for calling a method should be http://localhost:65101/action/mynode/orders/neworder

This includes having multiple paths e.g. /orders/neworder. This is required for the default Express 4 nodejs app created in VS2019 to work, which is being used in nodejs sample.

Import code

Kubernetes zero to hero getting started sample update

Update proto service to match HTTP API

Now that the API is (relatively) final for the first release, we should bring our gRPC implementation to be on par with our HTTP implementation.

• Proto file update
• Runtime gRPC implementation
• Documentation

Add api to get all stored state names for the actor

https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.actors.runtime.iactorstatemanager.getstatenamesasync?view=azure-dotnet#Microsoft_ServiceFabric_Actors_Runtime_IActorStateManager_GetStateNamesAsync_System_Threading_CancellationToken_

Add deactivation of Actors after a period of inactivity

Add deactivation of Actors after a period of inactivity. This will allow actor instances to be GC'd.
This will call the Deactivate endpoint in user code with Actor id to be deactivated. Consider batching for perf.

Garbage collection and deactivation for Reliable Actors is explained here;
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle#actor-deactivation

Create CONTRIBUTING.md

Create Release pipeline

Change the interface of Bindings

Dependent on #79

• Create structured request/responses
• Allow metadata for each Binding

Set up CI with Azure Pipelines

Resend state when app comes back in standalone mode

The side car needs to re-send state (while holding other requests) when the app recovers from a crash in standalone mode.

Create Makefiles

Actor specific end to end tests for daily test runs and for CI/CD

Add functional tests for daily test runs and for CI/CD. These tests should cover functionalities for Dapr runtime sidecar.

Some Examples are below: (below list is not comprehensive and should be expanded based on feature set):
Core Dapr functionality can be tested using Redis cache. Tests for individual bindings will be added for each binding or may be the same tests can be run for multiple bindings.

For Dapr actors functionality in runtime, following should be covered:

1. Actor activation/deactivation.
2. Actor turn based concurrency & reentrancy.
3. Actor user service failover form 1 node to another.
4. Actor Reminder/Timer firing.
5. Actor state management.
6. Actor Query
7. Actor Deletion
8. Actor repartitioning.
9. Actor routing invocation on correct instance/node..

For State storage via Dapr runtime, following should be covered:

1. State addition
2. State update.
3. State deletion.

For Pub/Sub via Dapr runtime, following should be covered:

1. Publish.
2. Subscribe.

Import demo app code

Allow Reentrancy for Actors

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-reentrancy

Remove local state endpoint and use API instead

Add transactional state API for Actors

The api can receive a state list:
Key1, Value1, Update
Key2, Value2, Delete
Key3, Value3, Update
Actions runtime should apply these changes transactionally to the underlying state store.

Review using Microsoft Container Registry (MCR)

Review Docker image tagging scheme (arch specific?)

Enable secure communication between Action<->Action & Action<->Assigner

Enable secure communication between Action->Action & Action->Assigner
This secure communication should allow for user/platform to provide key/cert and allow for key/cert rollover.

Swagger spec for RESTful API

Add query parameter support to gRPC

We should pass along query parameters to applications when gRPC protocol is used, as we do for HTTP protocol.

June 2019 Endgame

This is the endgame schedule for June 2019 Iteration.

Schedule

End game master: @msfussell
End game buddy: @yaron2
06/24 Code freeze for the endgame
07/01 Endgame complete
07/02 Release date

Monday 24th - Prepare endgame

• Code freeze at 5pm PST
• Update build pipeline with version support @lukekim
• Set version environment variable in build & release pipelines @yaron2
• Create release branch @yaron2
• Complete final build
• Manually test Build
  • Demo scenario validation @Haishi2016
• All closed feature-requests have a verification-needed tag

Tuesday 25th- Fixing and testing

• Remind team members to assign issues that they intend to fix to the current milestone
• Fixing
• Testing
• Verification
• Test Build
  • Build successful for all platforms

Wednesday 26th - Fixing and testing

• Remind team members to assign issues that they intend to fix to the current milestone
• Fixing
• Testing
• Verification
• Test Build
  • Build successful for all platforms

Thursday 27th - High Priority fixing and testing

• Fixing (scrutiny sets in - major bugs only - to be discussed in stand-up meeting, labeled as "candidate"
• Release notes updated @yaron2 @msfussell #48
  • release notes are collected in a file named Month_Year.md in this docs repo directory.
• All issues verified
• Create candidate release
• Zero to hero samples @ryanvolum #45 #46
• Demo scenario validation @Haishi2016
• Sanity check of each candidate release build
  • Windows
    • x64 (done via samples)
  • OS X
    • x64 (done via samples/demos)
  • Linux
    • x64 (done via samples)
    • ARM @likamrat

Friday/Monday 1st - High Priority fixing and testing

• Announce July master is open for business
• Polish release notes
• Cherry-pick hand-picked and reviewed changes to /docs/release/<x.y>
• Documentation updated
• Create new candidate release if needed
  • Sanity check of each candidate release build
    • Windows
      • x64
    • OS X
      • x64
    • Linux
      • x64
      • ARM
• Release notes sign-off
• Final demo scenario validation
• Add a git tag to HEAD of <x.y> in format x.y.z

Review and adjust CLI versioning to match with runtime

Take Helm as a guide.