Dapr – Distributed Application Runtime | Hacker News Reader

Dapr – Distributed Application Runtime

dapr.io

126 pointskiyanwang48 comments

I've spent some time reading the docs and still don't understand what Dapr is. Is it something like jBoss Fuse but for cloud era?

Of course, I'm not entitled to good documentation for open source project, I realise it. But let me just share my personal preferences.

When I encounter new library/framework/service I want to know 2 things:

1. What problem(s) does it intend to solve?

2. What are the closest alternatives and how this thing compares to those alternatives?

In most docs I encounter it's either hard or impossible to find this information.

It is a microservice chassis https://microservices.io/patterns/microservice-chassis.html At scale you have lots of teams writing their own boiler plate and getting it right or wrong. This solves that at the application level. Steel toe is another option by pivotal. You can see an example of how cross cutting concerns can be solved in this mindmap https://www.alanmbarr.com/blog/images/cross_cutting_concerns...

Dapr's solving distributed systems development at scale. Basically as you grow your team from a handful of people to many separate teams all working on different products, the technical architecture also evolves from monolith to SOA and then microservices. It's the natural logical evolution of anything at scale. Dapr is attempting to provide the primitives you'd need to build any sort of software at scale. Usually this buckets into; authentication/authorization, configuration, data storage, pubsub messaging and a handful of other things.

Full disclosure: I'm the author of Micro (https://github.com/micro/micro) which bakes in the same primitives but also focuses solely on development in the Go language.

Yes, but what is it? A set of libraries? Container config? A cli tool? You need to dig quite far through the docs to find that out.

It is a sidecar which sits alongside your application. You can access it via http or grpc. They additionally provide multi-language sdks for it. Think database + sdks but for distributed systems.

Most importantly to me, it offers both REST and interface-based programming models allowing the consumer to decide how they want to operate with it.

It is a server which sits alongside your application. You can access it via http or grpc. They additionally provide multi-language sdks for it. Think database + sdks but for distributed systems.

> It is a server which sits alongside your application. You can access it via http or grpc.

Why?

If I have microservice A and B - how is A and B different/better with this sidecar?

> Cloud-native

I read those two words as "bullshit". It's the new "blockchain" in my mental space.

Also, after reading the entirety of that page I still have no idea what this is or what it does. Simply terrible, who is this marketed to?

Serious question: why? It's a buzzword for sure, but there are billions of dollars being invested in real companies with real customers solving real problems that all would identify as cloud native.

All it means is 'we existed after the cloud started to gain traction. We won't have an on-prem option, we're much more likely to integrate with things like Docker and Kubernetes, and our licensing model will accommodate now-normal things like autoscaling and containerisation'.

EDIT: I wrote this before reading the article or many other comments. The fact that my description is basically right (other than missing that this is an open source project, so licensing terms aren't relevant) further proves my point that 'cloud native' isn't a buzzword, and has concrete meaning.

Maybe link to the 1.0 release announcement because that's the reason this was posted:

https://blog.dapr.io/posts/2021/02/17/announcing-dapr-v1.0/

Dapr is an open source, language-independent, cross-platform, k8s-friendly, cross-cloud and locally hostable approach to building distributed applications.

Having played a bit with it I'm really enjoying it.

What's cool about it? I kind of bounced off the front page of the site, I'd be really happy for a summary from someone using it.

Fair warning: I haven't specifically used dapr, but I have had a look at their docs and used similar tools in the past.

Deploying apps easily to "modern clouds" and taking advantage of their feature set requires some design decisions in your app. Generally, the biggest goal here is to be able to easily scale just by spinning up more copies, so your app needs to be able to run multiple copies in parallel serving requests without exploding. We call these types of applications "cloud native".

Additionally, if you go with a microservices style architecture (I'm not going to go into the pros and cons here), there's extra concerns with communication across the different services and similar.

Often, you'll end up reinventing the wheel and writing a ton of boilerplate to cleanly solve these issues. Also, your developers have to learn quite a bit to manage this well. Tools like dapr reduce the amount of code you need to write, and also do the best paractices for you so your dev team doesn't need to be an expert on 'the cloud' as well.

How does that differ from a Twelve-Factor App[0], which is already an established concept and seems to tackle most of those concerns? I don't think expecting your dev team to know that (or learn it) is too big of an ask.

[0]: https://12factor.net/

Dapr is a tool/library to implement some of those ideas, in particular factors 3, 4, 6, 8, and 9.

I feel like especially those factors mainly rely on framework (e.g. Rails) support and I don't see much benefit from an additional library there.

The main value proposition from what I can tell is the one of swappable components, but from my experience with other systems that try to achieve something similar it's likely a flawed one.

E.g. in a lot of ORM libraries you can _in theory_ easily swap your MySQL database for Postgres, but in practice if you actually want to make that transition (which also rarely tends to happen during the lifetime of a single project) it's such a big hassle that you didn't gain much from using the abstracted version. In the meantime you also often have to restrict yourself to the lowest common denominator that is supported by the specific implementations, so you loose out on a lot of powerful features.

Dapr gives you some capabilities that libraries don't have. at first we had the same concerns, but for our use case it works really well. We're using Dapr with Redis and it gives us state versioning using etags which is something Redis doesn't natively have. there's a bunch more features it adds like scoping and consistency.

Thanks I was really struggling to understand what is was about

I see after the .NET community complained about how similar it is to "Dapper" (an ORM) and the Dapr team publicly stated they would rename to avoid confusion - they decided to stick to the current name anyway. Classic MS naming.

Before 1.0 release there are a notification on home page, that it's not affiliated with Dapper. For quite a long time.

I only just came across this today but it looks amazing and I can’t wait to go kick the tyres on it.

It fits an interesting use case for me as well. I have a new project coming up where I want to basically move as much as possible in the direction of “cloud native best practices and patterns” but I want to incur the smallest possible cost for doing so in terms of effort and actual costs.

This seems like a potentially amazing out of the box experience that doesn’t require me to make drastic changes or also doesn’t require the kind of deep K8s (and surrounding ecosystem like linkerd etc) knowledge that would otherwise be required to set this up.

> I want to basically move as much as possible in the direction of "cloud native best practices and patterns" but I want to incur the smallest possible cost for doing so in terms of effort and actual costs.

Check out fly.io [0] which is likely the "smallest possible cost" you'd incur that otherwise may bloat up due to (drawing parallels to HashiCorp products) packaging and deploying with Waypoint, orchestrating with Nomad, and setting up networking with Consul. Dapr, if I understood it correctly, replaces only Waypoint and Consul, you're still left to deal with orchestration.

[0] https://news.ycombinator.com/item?id=22616857

Heh, I was asking earlier about what Dapr was because I was wondering how it might work on Fly. :)

In that case you might also be interested in Garden (https://github.com/garden-io/garden). It's an open source tool made for developing distributed systems / micro services. It abstracts most of the gnarly parts of K8s away and allows you to opt into them as needed. Full disclosure, I am affiliated so apologies for the shameless plug. But figured it might of interest to you.

>It abstracts most of the gnarly parts of K8s away

Jesus Christ, it's an abstraction for an abstraction for an abstraction… you get the idea.

Are there any abstractions for Garden, to hide its gnarly parts and operational complexity?

Thanks for the link. I just took a quick look and it seems like you’ve done a nice job tackling a lot of other parts that Dapr hasn’t.

Dapr and Garden are a really great combo. Dapr for dev concerns on k8s and Garden for managing deployments of microservices.

Can someone review Dapr, someone who used it fairly.

We run Dapr on GCP using GCP's Memorystore and accessing it with Dapr. Our deployments run on GKE, and we use Dapr for two things: state versioning with Redis, which we only get with Dapr and not with the native OSS clients, and a Dapr API called service invocation to discover and invoke other services across the cluster.

We looked into using a service mesh like Istio/Linkerd for the direct communications part but eventually decided that Dapr's explicit API approach makes more sense for us than a blackbox transparently intercepting our traffic. plus, these meshes were too cumbersome to setup.

Would be interested whether you spent any time getting Istio to work with Dapr and your experience?

The description and feature set sound like it is a platform built atop Kafka. Anyone with experience with it who can comment?

I believe it’s kind of like a plug and play approach to things like Kafka.

My understanding is that you have a set of core functionality that is entirely optional so you only run what you want and need. These features are defined at a high level like state management (persistence) or an event bus.

Dapr provides a unified API that sits on top of all this and allows you to swap out your event bus system from say Kafka to Google PubSub without any code changes.

But under the hood everything seems to operate via gRPC calls.

Edit: I just came across this link which puts together a solid explanation of what Dapr is and how it works https://thenewstack.io/how-microsofts-dapr-simplifies-develo...

I had no idea from the dapr website that it's a Microsoft project... that's an interesting approach. They're not even listed among the companies supposedly using dapr!

I'm not saying it's nefarious, it's kind of refreshing to let the project succeed on its own merits.

It seems pretty solid as an approach. The messaging I heard in an e-book they just released on it says this is everything we learned so far internally at Microsoft but also from our consulting services with other enterprises.

From what I’ve seen I think the abstractions they have focused on make a lot of sense and do a LOT to reduce the complexity of my own applications from both a code and operational point of view.

I’m excited to actually try it and see what the experience is like for someone coming strictly from the monolith world.

What is the name of the ebook?

You can find the book here https://aka.ms/dapr-ebook

Added few thoughts via this article on DAPR :

https://www.linkedin.com/pulse/dapr-distributed-application-...

I wasn’t able to determine who makes / sponsors this. For some reason, I thought it was Microsoft?

the Reg has more background https://www.theregister.com/2021/02/17/microsoft_dapr_1/

Dapr is one of several Microsoft-sponsored open-source projects around Kubernetes. Dapr was first announced in October 2019 and has been developed on GitHub.

The purpose of Dapr is to provide services, accessed via HTTP or gRPC, that can be called from any application, and meet some common requirements that can otherwise be tricky to implement. Specifically, Dapr provides:

* Service-to-service invocation

* State management: save and retrieve key/value pairs from a variety of stores such as Redis, CosmosDB, SQL Server or PostgreSQL

* Publish and subscribe

* Resource binding: Send, receive, and respond to events

* Virtual actors: Use actor pattern for stateless and stateful objects

* Distributed tracing: Uses W3C Trace Context standard to feed events to tracing and monitoring systems

* Secrets management: Safe storage and retrieval of credentials

A quick look at the committers confirms Microsoft e.g. https://github.com/yaron2

yes it seems to be microsoft owned

Started by Microsoft, Dapr put in place an open governance model starting in September https://blog.dapr.io/posts/2020/09/30/transitioning-the-dapr...

very interesting. somehow the docs.dapr.io is having TLS issues (expired/untrusted certs ?)

``` $ openssl s_client -connect docs.dapr.io:443 CONNECTED(00000003) depth=1 CN = SSL_DECRYPT_SVCA_UNTRUST verify error:num=19:self signed certificate in certificate chain verify return:1 depth=1 CN = SSL_DECRYPT_SVCA_UNTRUST verify error:num=10:certificate has expired notAfter=Jul 12 07:02:32 2019 GMT verify return:1 depth=1 CN = SSL_DECRYPT_SVCA_UNTRUST notAfter=Jul 12 07:02:32 2019 GMT verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "OpenDNS, Inc.", CN = docs.dapr.io notAfter=Feb 21 03:57:16 2021 GMT verify return:1```

Is this project similar to Eclipse Vert.x?

Isn’t this similar to AWS lambda?

AWS lambda is a hosted functions as a service and is about triggering code from events. Dapr is more like a library that runs next to your code as a sidecar providing you capabilities including being able to be triggered by events, but has other APIs such as state, secrets, pub/sub that are common when building apps when running on platforms like Kubernetes

Another win for Go.

not to be confused with Dapper

Reply on news.ycombinator.com