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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.