Agenda #netcoreconf Agenda https://jmfloreszazo.com Introducción Si nunca has visto que es, aquí tienes la introducción Teoría No es que sea densa pero debemos manejar ciertos elementos Manos a la obra Ejemplos sencillos y otros para que los estudies
#netcoreconf ¿Dónde se utiliza Microsoft Orleans Framework? ▪ Azure IoT Digital Twins ▪ Azure Machine Learning ▪ Azure PlayFab ▪ Azure Active Directory ▪ Skype ▪ Dynamics 365 Fraud Detection ▪ Otras ¯\_(ツ)_/¯ Microsoft ▪ Halo ▪ Age of Empires ▪ BigPark ▪ Minecraft ▪ Gears of War Xbox Game Studios ▪ Visa ▪ Honeywell Devices ▪ Mesh Systems ▪ Appliciata Limited ▪ Drawboard ▪ YouScan Otros Probado en batalla por Microsoft: tanto internamente como en clientes propios y externos
#netcoreconf Microsoft Orleans y el modelo de actor(1/3) ▪ No estamos ante algo nuevo; el modelo de actores comienza su estudio en 1973. Microsoft Orleans lleva una década con nosotros y en .NET 7 continua mejorando, ahora es parte del Core. ▪ Microsoft Orleans es un proyecto Open Source que proporciona un modelo simple de programación para construir software que puede escalar desde una sola máquina a cientos de servidores, es decir, un modelo simple para implementar el modelo de actores. ▪ Podríamos asociar a Orleans como un runtime distribuido que permite desarrollar en .NET software capaz de procesar grandes volúmenes de datos y desplegar en la nube u on-premises. ▪ Orleans es un framework que provee de muchas características de sistemas distribuidos. ▪ Este framework logra una abstracción tal que nos evita mucha complejidad. ▪ Por último Orleans nos permite que un solo desarrollador pueda crear un entorno escalable sin tener a una persona experta en desarrollo de sistemas distribuidos.
#netcoreconf Microsoft Orleans y el modelo de Actor(2/3) ▪ Los framework de Modelo de Actor se basan en pasar mensajes entre actores, y los actores se crean según sean necesario. Estos modelos pueden aprovechar la concurrencia de los multiprocesadores y las abstracciones del software; lo que nos permite procesar millones y millones de mensajes en tiempo real (casi, el tiempo real no existe). ¿Qué es un Actor?. Es toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Y ¿qué es un Modelo de Actor?. …un modelo matemático de computación concurrente que trata al “actor” como primitiva universal de las computación concurrente… Carl Hewitt
#netcoreconf Microsoft Orleans y el modelo de Actor(3/3) ▪ Otros frameworks de Modelo de Actor (akka o proto.actor), requieren mucho más trabajo tales como la monitorización y el ciclo de vida. Con Orleans nos evitamos todo esto. Por regla general un sistema de actores necesita de un equipo con mucha experiencia y conocimientos. Microsoft Orleans Framework nos ayuda a reducir estas barreras. Documentación de Microsoft Orleans
#netcoreconf Hitos DAPR/Azure Comienza una colaboración que esta siendo muy utilizada. Observación Investigación, estudio, análisis, … que aportan puntos de vista e información para mejoras. Documentación Orleans aparece por primera vez en al portal de documentación de Microsoft. Orleans v7 & .NET 7 Se libera la versión 7 con muchos ejemplos para usarlo en Azure. Y entra a formar parte del Core de .NET 7. Verano 2021 Otoño 2021 Invierno 2022 Primavera 2022 Noviembre 2022
#netcoreconf Orleans es la pieza que faltaba en ASP.NET(3/3) Frontends El cluster de Orleans puede estar en cualquiera de los host (ya sea uno o varios) Backend Storage
#netcoreconf ¿Qué es un Grano?(1/2) La "primitiva de procesamiento distribuido" de Orleans en el contexto de una aplicación ASP.NET ▪ Entidades que comprenden la identidad, el comportamiento y el estado definidos por el usuario. ▪ Deben ser una Clase C#. ▪ Son monohilo y asíncrono. ▪ Comunicación mediante paso de mensajes. ▪ Los mensajes se ponen en cola. ▪ Un grano NO puede acceder o modificar un estado externo.
#netcoreconf ¿Qué es un Silo?(1/3) "Primitiva de procesamiento distribuido" que hospeda uno o varios granos ▪ Hospeda los granos. ▪ Gestiona el ciclo de vida de los granos. ▪ DLL .NET / Aplicación de consola. ▪ Diseñados para trabajar juntos (en clúster).
#netcoreconf Actors vs Virtual Actors Resource Manager Actores Expertos en sistema distribuidos Requiere un trabajo a bajo nivel Life Time-Span Handling Recovery Saving State Actor Creation Handling Failures Silos Actores Virtuales Baja complejidad Virtual Actor Creation Interfaces VS
#netcoreconf ¿Cuándo elegir Orleans?(1/3) ▪ Los casos de uso anteriores, los he mostrado para que veáis la solidez de Orleans. Sin embargo no tenemos por que trabajar en una aplicación de mercado de valores para considerar la implementación de Orleans como una posible solución. Las herramientas se seleccionan en función de los objetivos comerciales, el crecimiento y la interactividad con el cliente que nos solicita el proyecto. ▪ Una regla general, muy común, es que si esperas que los elementos escalen más allá de un solo servidor, deben ser simultáneos y elásticos, Orleans podría ser una decisión acertada. ▪ Muchas aplicaciones se pueden dividir de microservicios a actores virtuales; sin embargo, no todas las aplicaciones deben dividirse en granos. ▪ Técnicamente, los elementos que se correlacionan con los proyectos de Orleans son los siguientes: ₋ Cientos o incluso billones de objetos que están débilmente acoplados. ₋ Entidades atómicas que pueden ejecutarse en un único subproceso. ₋ Actividades interactivas, como respuestas y solicitudes. ₋ El requerimiento o crecimiento de más de un servidor. ₋ No se requiere manejo holístico ya que los granos mantienen sus tareas.
#netcoreconf ¿Cuándo elegir Orleans?(2/3) Para proporcionaros una mayor comprensión, ejemplo como el siguientes cumplen todos esos requisitos: Internet de las cosas: miles de millones de señales de dispositivos que se comunican con el clúster, lo que desencadena varios eventos, como un cambio de temperatura. Mantener transacciones individuales a escala global requiere armonización de la aplicación, alta concurrencia y alta elasticidad. Por tanto, es igual de importante entender cuándo no elegir una tecnología o framework. Orleans es un gran marco para construir aplicaciones distribuidas. Pero si tienes un solo grano que acapara el 50% de todas las solicitudes, será un desafío escalar el sistema. Si tienes una solicitud que necesita comunicarse con otros 50 granos para atender la respuesta, agregarás latencia y tendrá un impacto en el rendimiento. El principal problema en ambos escenarios es la granularidad. Por tanto el principal hándicap es conocer que el estado sea naturalmente particionable y que los granos se puedan mapear muy (muy) bien. En resumen, siempre ten presente la granularidad mientras trabajas con Orleans. Es posible que Orleans no sea la mejor opción cuando los datos se comparten entre granos, cuando hay una pequeña cantidad de entidades que tienen subprocesos múltiples, cuando se requiere coordinación con muchos otros granos para atender una solicitud, o en el caso de operaciones que se ejecutan para un largo tiempo.
#netcoreconf ¿Cuándo elegir Orleans?(3/3) Sirve para No sirve para Cuando tienes sistemas con una gran cantidad de entidades. Cuando tienes sistemas estrechamente acoplados que no tienen perspectiva de sistema distribuido. Cuando tienes sistemas poco conectados y almacenamiento en cache inteligente. Cuando tienes pocos componentes y objectos. Cuando te ves obligado a ejecutar una aplicación en más de 1 servidor (durante horas o picos, como un Black Friday) Cuando tienes la intención de realizar tareas de informática defensiva. Cuando tu aplicación necesita tiempo de inactividad cero. Cuando tienes actores que necesitan acceso directo a memoria. Cuando tu cliente necesita respuesta rápidas. Cuando es necesaria una cooperación global para el funcionamiento de la aplicación. Cuando tienes aplicaciones que tienen varios actores con una vida útil larga (productos, inventarios, etc.) o cortas (transacciones de pago, pedidos, compras, etc.) Cuando administras múltiples versiones de granos es muy complejo y se vuelve inmanejable. Y te obliga a mantener granos con estado A o estado B.
#netcoreconf ¿Orleans un framework para Microservicios? Discusión abierta y sobre la cual hay distintos puntos de vista. Orleans es un framework que nos puede ayudar a la implementación de microservicios, pero que no conforma un framework de implementación de microservicios en si mismo. Orleans nos ayuda en el desarrollo del sistema encargándose de la facilidad del desarrollo, escalabilidad, resiliencia y la baja latencia. Por tanto podríamos decir que cada grano es un nano-servicio y combinando varios granos entre si, se formaría un microservicio.
#netcoreconf Ejemplo de alto nivel(1/3) Storefront Service Order Service Customization Service Manufacturing Service Reservation Service Reservation State Reservation Item State Inquiry Reserve Manofacturate Visión de una aplicación sin actores. Puedes aplicar escalado de K8s.
#netcoreconf Ejemplo de alto nivel(2/3) Storefront Service Order Service Customization Service Manufacturing Service Reservation Service Reservation State Reservation Item State Inquiry Reserve Manofacturate Visión de una aplicación con actores: silo y granos. Reservation Item Actor /Item01 Reservation Item Actor /Item02
#netcoreconf Ejemplo de alto nivel(3/3) Aplicación adecuada No se necesita una coordinación global o en menor escala entre unas pocas entidades a la vez. La escalabilidad y el rendimiento de la ejecución se logran paralelizando y distribuyendo una gran cantidad de tareas, en su mayoría independientes, sin un punto único de sincronización. Aplicación Inadecuada Se necesita coordinación global y/o consistencia. Tal coordinación global limitaría severamente el rendimiento de una aplicación basada en Orleans. Orleans fue construido para escalar fácilmente a una escala global sin necesidad de una coordinación manual profunda. ¿Cuál aproximación sería la adecuada para este ejemplo?
#netcoreconf Algunas características de .NET7 para Orleans ▪ Existe un salto de versión, lo que en primavera del 2022 sería la versión 4 salta a ser la versión 7 debido a la integración con el .NET 7. Una muy buena noticia, ya que pasa a ser un proyecto del core de ASP.NET, la pieza perdida del Lego. Cuidado que la migración de v3 a v7, no es automática y rompe. ▪ Es aproximadamente un 40% más rápido que la versión anterior según el test de este artículo. ▪ Mejoras en la confiabilidad y la flexibilidad. ▪ Granos POCO, granos que no heredan de ninguna clase base especial, para posibilitar un mejor testing. ▪ Nuevo serializador más rápido y compatible con el sistema de tipos enriquecidos de .NET, incluidos genéricos, polimorfismos, ... ▪ Nuevo sistema RPC más rápido, más flexible. ▪ Compatibilidad con Open Telemetry / Distributed Tracing.
#netcoreconf Manos a la Obra(3/4) Nuestra Web API sube a Azure Una serie de recomendaciones Test con JMeter y ¿qué diferencia tengo con un desarrollo clásico?
#netcoreconf La DEMO: Wanderland https://github.com/bradygaster/Wanderland Crear la infra igual que en la demo anterior Descargar fichero de deploy del App Service Créditos: https://github.com/bradygaster
jmfloreszazo
line_developers_tw
sansan_randd
minorun365
fedepaol
asei
mtx2s
dahatake
utam0k
yuya4
otanet
yamamuteki
sansantech
addyosmani
phodgson
eileencodes
kevinliebholz
holman
skipperchong
morganepeng
paigeccino
maltzj
sonatard
samanthasiow