¿Qué es DAPR?

DAPR o Distributed APlication Runtime es una tecnología soportada por la Cloud Native Computing Foundation que ayuda a construir aplicaciones distribuidas o microservicios en entornos multi-cloud de una forma más sencilla, portable y eficiente, todo ello siguiendo una serie de best practices aceptadas por la industria global en cuanto a rendimiento, resiliencia y seguridad.

DAPR proporciona un conjunto de APIs que se integran con las aplicaciones cliente de forma no intrusiva con runtimes o entornos de ejecución separados pero conectados (patrón sidecar). DAPR puede ser ejecutado en cualquier infraestructura on-premise, edge o cloud (Azure, AWS, GCP, Alibaba, Kubernetes o máquinas virtuales).

El uso de estas APIs pretende mejorar los tiempos de desarrollo. DAPR permite a los desarrolladores centrarse en la lógica de negocio en lugar de dedicar tiempo en resolver problemas recurrentes de infraestructura, al mismo tiempo que contribuye a crear un código más simple. 

Integración No Intrusiva: Patrón Sidecar

La integración de DAPR en nuestras aplicaciones cliente se realiza mediante patrones no intrusivos tipo sidecar. 

En arquitectura de aplicaciones un sidecar es un proceso o contenedor que se conecta con la aplicación cliente de forma no intrusiva. Se ejecuta de forma separada pero cercana, normalmente en el mismo host o pod, proporcionando aislamiento y servicios comunes a su aplicación cliente. Recibe este nombre porque se asemeja al típico sidecar acoplado a una motocicleta. El sidecar va donde su cliente va.

Algunas de las propiedades fundamentales de este patrón de diseño son:

• El sidecar no es necesariamente parte de la aplicación cliente, simplemente se conecta y comparte su ciclo de vida. La aplicación cliente puede consumir sidecar de terceras partes, como es el caso de DAPR.
• El sidecar es independiente de la aplicación cliente en términos de entorno de ejecución (proceso o container) y lenguaje. La aplicación y el sidecar pueden utilizar diferentes lenguajes en su implementación reduciendo la dependencia directa entre ellos. DAPR está escrito en Go.
• El sidecar es ejecutado en entornos de ejecución (proceso o container) cercanos a la aplicación cliente (normalmente mismo host o pod) resultando en comunicaciones con latencias bajas.
• La aplicación cliente delega en el sidecar tareas comunes de comunicación, proxy con servicios externos, logging, tracing, etc. Cómo estos servicios son implementados es transparente a la aplicación cliente, que sólo interactúa con el sidecar en base a interfaces compartidos.

¿Por qué usar DAPR?

Los desarrolladores pueden focalizarse en el desarrollo de la lógica de negocio de las aplicaciones en lugar de dedicar tiempo adicional a solucionar problemas repetitivos de infraestructura tales como comunicaciones entre microservicios, estrategias de discovery, interacciones con brokers para crear patrones pub/sub o coreografías, servicios de caché, interacciones de entrada/salida con servicios externos, encriptación, logging u observabilidad.

Las APIs proporcionadas por DAPR están categorizadas de forma lógica a modo de building blocks los cuales a su vez contienen un conjunto de componentes modulares que proveen de implementaciones específicas para interactuar con servicios o componentes externos en cualquier cloud (Azure Service Bus, AWS SQS, Event Hub, Kafka, Functions, Lambdas, etc.) o incluso on-premise (Rabbit MQ, Redis, etc.). La aplicación cliente delega al componente DAPR toda la implementación e interacción con dichos servicios subyacentes. Nuestras aplicaciones tan sólo necesitan comunicarse con su sidecar y éste se encargará del resto.

DAPR es agnóstico a la plataforma en la que se ejecuta ya sea on-premise, edge o cloud (Azure, AWS, GCP, Alibaba, Kubernetes o VMs).

Si en algún momento necesitamos sustituir un servicio en un cloud concreto utilizado por nuestra aplicación (por ejemplo, Azure Service Bus) por otro en un cloud distinto (por ejemplo, AWS SQS o GCP PubSub), no haría falta modificar nuestro código. El cambio tan solo consistiría en modificar la configuración y el componente proporcionado por DAPR.

DAPR es agnóstico al lenguaje utilizado en nuestras aplicaciones. DAPR proporciona SDKs en los principales lenguajes (C++, Go, Java, Javascript, .Net, PHP, Python, Rust) para comunicarse con los sidecar. No es necesario instalar ningún otro SDK adicional específico asociado a los servicios externos. El objetivo es ese mismo. Un solo SDK para comunicar con el sidecar y delegar en él la implementación de las interacciones con el exterior.

Building blocks

Como se anticipó en el apartado anterior DAPR proporciona un conjunto de APIs categorizadas de forma lógica a modo de building blocks.

Los building blocks disponibles a fecha de escritura de este artículo (versión 1.9 del DAPR runtime) son:

• Service to service Invocation. Utilizado para llamadas directas entre servicios internos. Proporciona discovery automático en cualquier host ya sea en local o kubernetes, seguridad mTLS y mecanismos de retry.
• State Management. Proporciona componentes para uso de cachés locales a servicios o globales. Facilita la creación de patrones cache-aside.
• Publish and Subscribe. Utilizado para la implementación de event-driven architectures con una amplia lista de brokers disponibles (Azure Service Bus, AQS SQS, GCP Pub/Sub, Rabbit MQ, etc.)
• Bindings (Input/Output). Utilizado para reaccionar a cambios o interactuar con servicios externos (bases de datos, colas, almacenamiento de ficheros, etc.) mediante triggers de entrada/salida.
• Observability. Proporciona logging y tracing a través de todas las comunicaciones con los sidecar.
• Secrets. Gestión segura de secretos, passwords o información confidencial.
• Configuration. Gestión global de la configuración con notificación de cambios.
• Distributed Lock. Proporciona bloqueos en recursos compartidos para evitar problemas de concurrencia.

Componentes

Cada building block incluye un conjunto de componentes modulares. Un componente es una implementación específica proporcionada por DAPR para interactuar con un servicio externo. La aplicación cliente delega al componente DAPR toda la implementación con el servicio subyacente y sólo necesita comunicarse con su sidecar a través de las APIs proporcionadas. El sidecar se encargará de todo lo demás proporcionando abstracción a la aplicación cliente con respecto al servicios externo.

El uso de componentes puede hacerse de forma progresiva. Tan sólo es necesario usar aquellos que necesitamos en nuestras aplicaciones en cada momento. DAPR, en la inicialización de los correspondientes sidecar, detectará, validará y activará los componentes que han sido configurados. La configuración se realiza mediante uso de simples ficheros YAML.

Cada componente ofrecido por DAPR tiene su grado de madurez etiquetado con versiones alpha, beta y stable. Estas versiones son diferentes a las del runtime de DAPR. Por tanto, antes de usar un componente concreto se recomienda consultar la documentación para conocer su grado de madurez y en entornos de producción, hacer uso del componente que pretendemos utilizar sólo con versiones estables.

También es importante confirmar si la implementación del componente soporta todas las características actuales ofrecidas por el servicio subyacente (Azure Service Bus, AWS SQS, etc.). La comunidad que soporta DAPR necesita adaptar sus implementaciones a las nuevas características de los servicios gestionados. La propia implementación, capaz de cubrir toda la funcionalidad del componente y el desfase en adaptarse son quizás los desafíos más importantes a los que DAPR debe enfrentarse.

¿Qué no es DAPR?

DAPR no es un service mesh (Istio, Linkerd, etc.). Ese no es su objetivo. DAPR pone el foco en la mejora del desarrollo de microservicios mediante la utilización de building blocks mientras que un service mesh lo hace en proveer de servicios de networking avanzados.

Aunque DAPR comparte alguna de estas ventajas (service discovery, service invocation, mTLS, tracing o políticas de retry), no dispone de mecanismos avanzados de networking a nivel routing o balanceo de cargas. DAPR simplemente usa identificadores a nivel aplicación para proporcionar mecanismos de discovery y comunicación entre servicios internos.

Autor del artículo

Jose Antonio Muro

Solution Architect