Al usar un conjunto de demonios, un pod de Dapr se ejecuta junto con sus cargas de trabajo. Cada vez que el programador de Kubernetes implementa una nueva instancia de su aplicación, implementará un nuevo demonio de Dapr, de modo que las API de Dapr siempre estén disponibles con una latencia mínima. Por supuesto, existe una desventaja, ya que este enfoque requiere más recursos del sistema que el uso de un sidecar. Si los recursos son un problema, puede usar Dapr como una implementación de Kubernetes, instalando una instancia del entorno de ejecución de Dapr por clúster. El orquestador de Kubernetes determinará qué nodo usa para Dapr, por lo que puede haber latencias de red entre las cargas de trabajo y las API. Es posible que deba repensar cómo maneja su aplicación los mensajes y qué modelo de consistencia usa. La mayoría de las actualizaciones en Dapr 1.14 son mejoras de las características existentes, como el rendimiento y la seguridad, que, junto con los cambios más grandes, deberían facilitar la creación e implementación de aplicaciones Dapr en las nubes y herramientas de desarrollo que elija. Entre los muchos SDK disponibles, la implementación .Net ofrece un conjunto completo de funciones, que incluyen compatibilidad con actores y herramientas de flujo de trabajo de Dapr. Si prefiere Python, Go, JavaScript o incluso Java, puede encontrar versiones estables del SDK; C++ y Rust están en desarrollo.