Prólogo
Con la ola de adopción de la nube en curso, se está produciendo un cambio importante hacia el desarrollo "nativo de la nube", a menudo creado con arquitecturas de microservicios. Estos microservicios son sin estado y con estado, y se ejecutan en la nube y el perímetro, adoptando la diversidad de lenguajes y marcos disponibles actualmente. Este cambio empresarial está controlado por las fuerzas del mercado de un tiempo de comercialización más rápido, así como por la escala y la eficacia de la creación de servicios para la nube. Incluso antes de la COVID-19, la adopción de la nube se aceleraba para las empresas y los desarrolladores tenían que hacer aún más para realizar la creación de estas aplicaciones del sistema distribuido, y eso solo se ha acelerado desde entonces. Los desarrolladores de empresas buscan centrarse en la lógica de negocios, a la vez que se centran en plataformas para convertir sus aplicaciones en escalado, resistencia, mantenimiento, elasticidad y otros atributos de arquitecturas nativas de la nube, por lo que también hay un cambio hacia plataformas sin servidor que ocultan la infraestructura subyacente. No es de esperar que los desarrolladores se conviertan en expertos en sistemas distribuidos. Aquí es donde Dapr da pasos para ayudarle, tanto si se está creando en infraestructuras como Kubernetes como en una plataforma sin servidor.
Dapr está diseñado como una plataforma de modelo de programación de microservicios empresarial, centrada en el desarrollador, con el mantra "cualquier lenguaje, cualquier marco, ejecutar en cualquier lugar". Hace que la creación de aplicaciones distribuidas sea fácil y portátil en cualquier infraestructura, desde la nube pública, hasta el perímetro jerárquico e incluso hasta dispositivos IoT de nodo único.Surgió de nuestras experiencias de creación de servicios en Azure, así como del tiempo dedicado a trabajar con clientes que compilaron aplicaciones en Azure Kubernetes Service y Azure Service Fabric. Una y otra vez, vimos problemas comunes que tenían que solucionar. Quedó claro que era necesario proporcionar una "biblioteca" de procedimientos recomendados de microservicios comunes que los desarrolladores podían usar, no solo en las nuevas aplicaciones de greenfield, sino también para ayudar en la modernización de las aplicaciones existentes. En el mundo nativo de la nube en contenedores, distribuido y en red, el modelo sidecar ha surgido como el enfoque preferido, de la misma manera que se prefieren los archivos DLL en la generación de cliente/servidor. El uso de sidecar y API de Dapr le proporciona, como desarrollador, toda la funcionalidad de los sistemas distribuidos, con la facilidad de una sola llamada local HTTP o gRPC.
Para abordar la amplia gama de escenarios a los que se enfrentan los desarrolladores, Dapr proporciona características como la administración de estados, la invocación de servicio a servicio, pub/sub y la integración en sistemas externos con enlaces de E/S, que se basan en los desencadenadores y enlaces de Azure Functions. A su vez, aprovechan el modelo de componentes de Dapr, que permite "intercambiar", por ejemplo, distintos almacenes de estado subyacentes, sin tener que cambiar ningún código, lo que hace que el código sea más portátil, más flexible y que permita la experimentación de lo que mejor se adapte a sus necesidades. Los desarrolladores no necesitan aprender e incorporar SDK de servicio en su código, preocuparse por la autenticación, la administración de secretos, los reintentos o el código condicional que tiene como destino entornos de implementación específicos.
En este libro se muestra cómo Dapr reduce el tiempo de desarrollo y el mantenimiento general del código al "daperizar" incrementalmente la aplicación de referencia canónica de .NET, eShop. Por ejemplo, en la implementación original de eShop, se escribieron cantidades significativas de código para abstraer entre Azure Service Bus y RabbitMQ para publicar eventos entre servicios. Todo este código se puede descartar y simplemente reemplazar por la API pub/sub de Dapr y el modelo de componentes que tenían una gama aún más amplia de agentes pub/sub, en lugar de solo dos. El modelo de actor de Dapr, cuando se usa en la aplicación de eShop reprocesada, muestra la facilidad de crear aplicaciones de flujo de trabajo de larga duración, con estado, controladas por eventos, con todas las dificultades de simultaneidad y multiproceso eliminadas. Al final de este libro, verá la simplificación drástica que Dapr aporta al desarrollo de aplicaciones y creo firmemente que todos los desarrolladores que se lanzan a un recorrido de creación de aplicaciones nativas en la nube deben aprovechar Dapr.
Anunciamos públicamente Dapr con la versión v0.1 en octubre de 2019 y ahora, un año y medio después, me complace decir que Dapr está listo para el uso de producción con la versión v1.0. La obtención de Dapr a v1.0 ha sido realmente un esfuerzo de la comunidad. Ha sido increíble ver la comunidad de código abierto en torno a Dapr y crecer desde que se anunció por primera vez: de 114 colaboradores en octubre de 2019 a más de 700 a principios de 2021, un aumento seis veces mayor en 16 meses. Las contribuciones al proyecto han ido a todos los repositorios de Dapr y han abarcado desde abrir incidencias, comentar propuestas de características, proporcionar ejemplos y, por supuesto, contribuir con código. Las partes de los miembros de la comunidad del proyecto han contribuido al máximo, como el entorno de ejecución de Dapr, los documentos, la CLI, los SDK y la creación de un ecosistema enriquecido de componentes. Mantener esta apertura es fundamental para el futuro de Dapr.
Sin embargo, Dapr acaba de empezar y debería esperar ver más funcionalidades de Dapr y más compatibilidad con Dapr en los servicios de Azure. Esperamos que aproveche Dapr para que pueda centrarse en su lógica de negocios principal y acelerar el desarrollo de microservicios. Me complace que se una a nosotros en la comunidad de Dapr en este recorrido en https://github.com/dapr/ y en Discord https://aka.ms/dapr-discord .
Los sistemas distribuidos modernos son complejos. Comience con servicios pequeños, de acoplamiento flexible e implementables de forma independiente. Estos servicios cruzan los límites de proceso y servidor. A continuación, consumen diferentes tipos de servicios de respaldo de infraestructura (bases de datos, agentes de mensajes, almacenes de claves). Por último, estas piezas dispares se componen juntas para formar una aplicación.
Mark Russinvl Director técnico y técnico de Azure Microsoft