Azure Service Fabric and the Actor Model: when did we forget Object Orientation?

Editor's Notes

• #4: The demos are based in software that is in preview. Problems are to be expected. The programming model underlying this approach is different from what has been the best practice in the age of SOA. Questions: [Hands raised] Who has used Azure Web and Worker Roles? Who has developed services-driven systems with stateless services?
• #5: Service Fabric enables you to build and manage scalable and reliable applications composed of microservices running at very high density on a shared pool of machines (commonly referred to as a Service Fabric cluster). Powers a huge set of Microsoft Services: Azure SQL Database, Azure DocumentDB, Cortana, Power BI, Microsoft Intune, Azure Event Hubs, Skype for Business and others It provides a sophisticated runtime for building distributed, scalable stateless and stateful microservices. Also provides comprehensive application management capabilities for provisioning, deploying, monitoring, upgrading/patching, and deleting deployed applications. Service Fabric is tailored to creating “born in the cloud” services that can start small, as needed, and grow to massive scale with hundreds or thousands of machines, creating Service Fabric clusters across availability sets in a region or across regions. Fundamental concepts The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages. An actor is a computational entity that, in response to a message it receives, can concurrently: - send a finite number of messages to other actors; - create a finite number of new actors; - designate the behavior to be used for the next message it receives. There is no assumed sequence to the above actions and they could be carried out in parallel. Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns ofpassing messages.[8] Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created. The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.
• #7: Executables Any exe, in any language and programming model. Packaged as Application, it gets versioning, upgrade, monitoring, health, etc. Reliable Services Stateless & stateful services Uses SDK Reliable Actors Stateless & stateful actor objects Uses SDK
• #18: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-reliable-collections/ Reliable Collections can be thought of as the natural evolution of the System.Collectionsclasses: a new set of collections that are designed for the cloud and multi-computer applications without increasing complexity for the developer. As such, Reliable Collections are: Replicated: State changes are replicated for high availability. Persisted: Data is persisted to disk for durability against large-scale outages (for example, a datacenter power outage). Asynchronous: APIs are asynchronous to ensure that threads are not blocked when incurring IO. Transactional: APIs utilize the abstraction of transactions so you can manage multiple Reliable Collections within a service easily. Reliable Collections provide strong consistency guarantees out of the box in order to make reasoning about application state easier. Strong consistency is achieved by ensuring transaction commits finish only after the entire transaction has been applied on a quorum of replicas, including the primary. To achieve weaker consistency, applications can acknowledge back to the client/requester before the asynchronous commit returns. The Reliable Collections APIs are an evolution of concurrent collections APIs (found in theSystem.Collections.Concurrent namespace): Asynchronous: Returns a task since, unlike concurrent collections, the operations are replicated and persisted. No out parameters: Uses ConditionalResult to return a bool and a value instead of out parameters. ConditionalResult is like Nullable but does not require T to be a struct. Transactions: Uses a transaction object to enable the user to group actions on multiple Reliable Collections in a transaction.
• #21: http://stackoverflow.com/questions/34308701/service-fabric-deactivate-pause-vs-deactivate-restart
• #23: Executables Any exe, in any language and programming model. Packaged as Application, it gets versioning, upgrade, monitoring, health, etc. Reliable Services Stateless & stateful services Uses SDK Reliable Actors Stateless & stateful actor objects Uses SDK
• #24: The easiest way to visualize the Actor pattern at work is to look at human society . Each human (actor) is an independent entity . We all hold our own attributes, and we make decisions based on our knowledge (state and behaviour) and in reaction to the surrounding stipulates (messages) . We communicate with (send messages to) each other . Similarly, if a system can be described by a number of independent, interactive actors, it can be modelled using the Actor pattern . For example, in a multiplayer game, each player can be considered as an actor; in an e-commerce system, each shopping cart can be considered as an actor; in an Internet of Things (IoT) scenario, a sensor can be considered as an actor . A player, a shopping cart, and a sensor don’t seem to have anything in common, yet because they all have states, they all demonstrate some behaviours, and they all represent independent entities, they can be abstracted as actors . Good for representing discrete, independent entities e.g. IoT devices, workflow actions, shopping carts, domain entities, etc.
• #25: - The Actor concept was originated in the early 70 in order to do large scale parallel processing and is becoming more popular with the advent of cloud computing. It’s meant to make writing distributed applications easier by dividing the problem in multiple units of state and computation that can run in parallel. Each unit in a simple single-threaded. Actors are actually very similar to objects in the way they represent state with some logic that operates on that state. These actors communicates with each other using asynchronous messages. - Running the actors on top of Service Fabric, you get the reliability of code as well as state and all other benefits of Service Fabric platform, like security, placement and resource balancing, zero downtime upgrade, locally replicated stores. What is an actor? - An independent unit of compute and [persistent] state with large number of them executing in parallel: an instance of a class - Communicates with other actors using asynchronous messaging - Has single threaded execution - turn based concurrency - Good for representing discrete, independent entities e.g. IoT devices, workflow actions, shopping carts, domain entities, etc. Actors are virtual, which means logically they always exist . You don’t need to create or destroy an actor . When you need to talk to an actor, you just use the actor proxy to send a message to it, Service Fabric will activate the actor if it hasn’t been activated or if it has been deactivated . After an actor hasn’t been used for a while, Service Fabric automatically will deactivate the actor to reduce resource consumption .
• #36: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-lifecycle/ http://stackoverflow.com/questions/38271377/azure-service-fabric-how-to-find-out-if-an-actor-already-exists
• #37: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-timers-reminders/
• #38: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-timers-reminders/
• #39: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-timers-reminders/
• #42: Logo font: Monserrat Regular Logo color: #9a8e5e (154,142,94)