10 : Dapr - not to be confused with dapper

18 Feb 2022

Dapr - not to be confused with dapper! Andy and Rowan chat about what Dapr is (Distributed application runtime) and what problems it is trying to solve. 

Random fact

You've heard the term "I will be back in a jiffy" - it's a real measurement of time.


While watching the dotnet conf videos showing what dapr (https://dapr.io/) is interested to learn more about how it works and what you can do with it.

dotnet conf video (Nov 2021):

  • Paul Yuknewicz (Yuk-nevich) - Building Microservices with Dapr and .Net
  • Jessica Deen - Microservices Made Easy - Helm, K8, Dapr, Bridge to K8, Github Actions
  • Others from Dapr conf
  • older video from 2020
    • Cecil Phillip - Adding a little Dapr to your microservices - server side blazor demo with dapr

What is it? What problems does it solve?

  • Distributed application runtime
  • Only 2 years old
  • Fully open source, building with the community
  • Microservice dev is difficult:
    • Best practices to get scale, resilience, security
    • Limited tools to do this
    • For existing runtimes are locked in - languages / frameworks
    • different frameworks have different strengths - windows, linux, kubernetes
      • find the right combination can be hard
    • Many systems are polyglot and use lots of different stacks, frameworks and tools
      • .Net
      • Python
      • Ruby on Rails
      • Java
      • Go
  • platform agnostic microservice development,
  • bigger picture - microservice dev made easy - local dev, deployment to test, production deployment

How does it work / architecture?

  • Summary - Apis to build portable and reliable microservices
  • key concepts - components and sidecars
    • components are building blocks that microservices need
      • All your service needs to be able to do is to talk http (grpc)

      • service to service communication

        • resilient, secure and portable by default
        • best practices like retries, backoffs, mTLS communications etc built in
          • mTLS - Mutual TLS

            Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.

            mTLS is often used in a Zero Trust security framework* to verify users, devices, and servers within an organization. It can also help keep APIs secure.

      • state persistence - redis, cosmos db, mongodb, couchbase, mysql, postgres, cassandra

      • name resolution - used with the service invocation building block

      • secret management

      • pub / sub model, lots of brokers supported - very cool and easily coded via the dapr clients

      • Bindings -external service can call into dapr which is then passed to you service

        • Integrations with: Apple Push Notifications (APN), Cron, GraphQL
      • distributed tracing - zipkin - comes by default

      • virtual actors - like AKKA - for thousands and thousands of objects

      • configuration store - new

      • middleware - auth2, spiffe (identity control plane for distributed systems), rate limit, bearer token, uppercase - make your own

      • Controllable via config!!

  • sidecars - the workhorse of dapr. Makes it easy to leverage all of the above without having to re-architect
    • the hidden star of dapr

    • (localhost port: 3500) will make a whole host of apis to your service

      • all without having to rewrite
      • you connect to one thing (the sidecar) and can discover all other services and use components
    • lightweight process that generally runs alongside your service process (on vm / physical machine that is on localhost) (on k8 that is in the same pod)

    • service A → Service A sidecar (grpc under the hood)→ service B sidecar → Service B

    • sidecar uses grpc under the hood, so very fast

    • Lovely way to abstract all of the components away from your service - your service only needs to talk to its sidecar

    • .Net client makes it even easier -

      • invoke method
      • await client.InvokeMethodAsync<object, Account>("routing", "deposit", data, cancellationToken)

      save state

      • await client.SaveStateAsync(storeName, stateKeyName, state, cancellationToken: cancellationToken); Console.WriteLine("Saved State!")
  • cli
    • dapr run
      • Run your service and sidecar
        • dapr run --dapr-grpc/http-port —app-port —app-id dotnet run / java -jar
    • dapr dashboard - starts the dapr dashboard
    • K8 tools
      • dapr status - show service status in a K8 cluster
      • dapr components - list components in a K8 cluser
    • local dev tools like
      • dapr publish - publish a pub-sub event, test a service as you are developing it
  • hosting models
    • local dev - great, and easy to get going
      • out of the box uses docker desktop - creates a redis container (state management), zipkin container (tracing)
    • k8 - local or prod - helm charts are supported to inject dapr into deployments
    • vm / physical hardware
  • Uses open standards - cloud events, open telemetry
    • Use Zipkin - distributed tracing built in
    • AMQP - messaging, pub/sub etc
  • extensible - you can build your own components

We worked on a project together a few years back that was trying to introduce a Microservices architecture

That project ran into the common issues of - no central logging or a design for centralising logs, not knowing exactly how things were going to be organised, services that talked directly to each other (and failed it they couldn't), how/where to store shared data e.g. I want the a client address - do I have it in a local store do I ask the client service for it?, service dependency suddenly multiplied - you needed to run 5 or more services running locally to get yours working, no versioning - when something in a service changed it broke all dependent services, not being allowed to use docker, having different versions of software installed in different ways, no buy in from IT, not having a DevOps culture - all while a 3rd party company was writing the replacement frontend and driving the requirements of the services.

Do you think dapr have been able to help with some or all of these issues?


OS project/utility of the week

LinqPad - just released version 7. I've been using it since 2009. Really useful for trying out code snippets, ideas or using it as a utility - command line runner. Also connects to data sources like SQL Server and allows you to use LINQ to query them.

Written by Joseph Albahari - author of C#9 in a nutshell and a C# MVP

Free version and paid version - well worth it (~$59) - can be used on 3 machines + 3 virtual machines.

Nice set of samples is provided - things like What's new in C#9, F# tutorial, Reactive extensions, C#9 in a Nutshell.

.Dump - a built in extension that makes it really easy to look at any data