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.
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.
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.
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
[+] [-] sesm|5 years ago|reply
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.
[+] [-] andendau|5 years ago|reply
[+] [-] asim|5 years ago|reply
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.
[+] [-] otabdeveloper4|5 years ago|reply
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?
[+] [-] Niksko|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] ofrzeta|5 years ago|reply
https://blog.dapr.io/posts/2021/02/17/announcing-dapr-v1.0/
[+] [-] yodon|5 years ago|reply
Having played a bit with it I'm really enjoying it.
[+] [-] tptacek|5 years ago|reply
[+] [-] h1fra|5 years ago|reply
[+] [-] lloydatkinson|5 years ago|reply
[+] [-] AlfeG|5 years ago|reply
[+] [-] mhoad|5 years ago|reply
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.
[+] [-] ignoramous|5 years ago|reply
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
[+] [-] eysi|5 years ago|reply
[+] [-] Music_Wise|5 years ago|reply
[+] [-] jerrlend|5 years ago|reply
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.
[+] [-] sriku|5 years ago|reply
[+] [-] mhoad|5 years ago|reply
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...
[+] [-] saddepalli|5 years ago|reply
https://www.linkedin.com/pulse/dapr-distributed-application-...
[+] [-] camdenlock|5 years ago|reply
[+] [-] homarp|5 years ago|reply
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
[+] [-] mirchiseth|5 years ago|reply
[+] [-] h1fra|5 years ago|reply
[+] [-] deadletter000|5 years ago|reply
``` $ 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```
[+] [-] otto_ortega|5 years ago|reply
[+] [-] the_arun|5 years ago|reply
[+] [-] sawfishman|5 years ago|reply
[+] [-] gatestone|5 years ago|reply
[+] [-] chillitom|5 years ago|reply