It really depends on what challenges are you facing, I wouldn't refactor an entire application to use Dapr if that application is all being coded and changed by the same team. Dapr can help when you have different teams to unify approaches.
Are you guys so much HIGHed ? Why should i use dapr when we have spring? If you will use .NET (which has no other option then dapr - i got that) then it makes sense, but in java??? come on !!!! For other reasons there are a lot of service meshes (for logging,audits etc.) So again, why use dapr? To have limited api? Even kafka is known about using own binary protocol made them really consitent etc. And dapr is rest api.... Again, WHY???
@@sawekpiotrowski4371 I will be very interested in hearing which challenges are you facing, Dapr is an open source project, so if we get feedback from users we can make it better
First of all, it is not an All or Nothing product. It is not intrusive, even you can use it with a service mesh. In products where you are using azure service bus, I would use it before spring cloud for azure products. If you want to use a durable execution framework, you can do it as well. For actor model ( virtual actors ), the complexity is reduced compared to akka.
@@manuelmoya6607 Thank you for your comments. While we continue to use DAPR due to existing dependencies within our codebase on it, its long-term viability is questionable for several reasons. DAPR acts as an extra abstraction layer for functionalities like secrets management and pub/sub, as well as a proxy for mTLS and tracing. This additional layer has not only introduced greater complexity but also brought a range of specific bugs that impact our operations (many of them in DAPR itself). From our real-world experience with actual project, the drawbacks, including the added complexity and maintenance challenges, significantly outweigh the benefits. Therefore, I am inclined to recommend against adopting DAPR by default for new projects.
The video for screen is lagging slightly behind the audio.
Very interesting. Will it be optimal to refractor a multimodule spring application to use dapr?
It really depends on what challenges are you facing, I wouldn't refactor an entire application to use Dapr if that application is all being coded and changed by the same team. Dapr can help when you have different teams to unify approaches.
Many have tried to solve the challenges of distributed systems, all failed.
Are you guys so much HIGHed ? Why should i use dapr when we have spring?
If you will use .NET (which has no other option then dapr - i got that) then it makes sense, but in java??? come on !!!!
For other reasons there are a lot of service meshes (for logging,audits etc.)
So again, why use dapr?
To have limited api? Even kafka is known about using own binary protocol made them really consitent etc.
And dapr is rest api....
Again, WHY???
We are currently using DAPR in a project and looking at the result I can confidently say that it creates more problems than it solves
@@sawekpiotrowski4371 I will be very interested in hearing which challenges are you facing, Dapr is an open source project, so if we get feedback from users we can make it better
@@sawekpiotrowski4371 It is your point of view. Dapr is not intrusive, why are you using it if it is causing those problems? ( just curious )
First of all, it is not an All or Nothing product. It is not intrusive, even you can use it with a service mesh. In products where you are using azure service bus, I would use it before spring cloud for azure products. If you want to use a durable execution framework, you can do it as well. For actor model ( virtual actors ), the complexity is reduced compared to akka.
@@manuelmoya6607 Thank you for your comments. While we continue to use DAPR due to existing dependencies within our codebase on it, its long-term viability is questionable for several reasons. DAPR acts as an extra abstraction layer for functionalities like secrets management and pub/sub, as well as a proxy for mTLS and tracing. This additional layer has not only introduced greater complexity but also brought a range of specific bugs that impact our operations (many of them in DAPR itself). From our real-world experience with actual project, the drawbacks, including the added complexity and maintenance challenges, significantly outweigh the benefits. Therefore, I am inclined to recommend against adopting DAPR by default for new projects.
@hashicrop nomad