que es, aquí tienes la introducción Teoría No es que sea densa pero debemos manejar cierto vocabulario Ejemplos Ejemplos sencillos y otros para que los estudies
Microsoft: tanto internamente como en clientes propios y externos ▪ Halo ▪ Age of Empires ▪ BigPark ▪ Minecraft ▪ Gears of War Xbox Game Studios ▪ Azure IoT Digital Twins ▪ Azure Machine Learning ▪ Azure PlayFab ▪ Azure Active Directory ▪ Skype ▪ Dynamics 365 Fraud Detection ▪ Otras ¯\_(ツ)_/¯ Microsoft ▪ Visa ▪ Honeywell Devices ▪ Mesh Systems ▪ Appliciata Limited ▪ Drawboard ▪ YouScan Otros
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.
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
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
muy utilizada. Verano 2021 Otoño 2021 Invierno 2022 Primavera 2022 Noviembre 2022 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.
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. La "primitiva de procesamiento distribuido" de Orleans en el contexto de una aplicación ASP.NET
granos. ▪ Gestiona el ciclo de vida de los granos. ▪ DLL .NET / Aplicación de consola. ▪ Diseñados para trabajar juntos (en clúster). “Primitiva de procesamiento distribuido" que hospeda uno o varios granos
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
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. ¿ elegir Orleans? (1/3)
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. ¿ elegir Orleans? (2/3)
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. ¿ elegir Orleans? (3/3)
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.
Reservation Service Reservation State Reservation Item State Inquiry Reserve Manofacturate de alto nivel (1/3) Visión de una aplicación sin actores. Puedes aplicar escalado de K8s.
Reservation Service Reservation State Inquiry Reserve Manofacturate Reservation Item Actor /Item01 Reservation Item Actor /Item02 Reservation Item State de alto nivel (2/3) Visión de una aplicación con actores: silo y granos.
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?
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.
jmfloreszazo
aeonpeople
nori_shinoda
mayumihirano
tsukuboshi
fumisuke
tacck
ornew
inesmontani
go_nishimoto
mame
akashi_sn
skmkzyk
akosma
reverentgeek
jonyablonski
addyosmani
jnunemaker
tammyeverts
kevinliebholz
shpigford
scottboms
quramy
ufuk
cromwellryan
