Processes & Grains — A Journey in Orleans

16925e7df06e14eb8d36263b4a8c31b4?s=47 Evadne Wu
February 01, 2020

Processes & Grains — A Journey in Orleans

16925e7df06e14eb8d36263b4a8c31b4?s=128

Evadne Wu

February 01, 2020
Tweet

Transcript

  1. Processes & Grains: A Journey in Orleans Evadne Wu Your

    Fellow Bodgemaster ev@radi.ws twitter.com/evadne
  2. Myself Programmer & Future Memester Inquiries: ev@radi.ws Arguments: twitter.com/evadne

  3. 1 Journey to Orleans

  4. One Stateful Server (Pet) Server Database

  5. One Stateful Server (Pet) Server State Stored Here Database

  6. Multiple Stateless Servers Server Load Balancer Server Server Server Database

  7. Multiple Stateless Servers Server Load Balancer Server Server Server State

    Stored Here Database
  8. No Consistency Server Load Balancer Server Server Server Database Cache

  9. No Consistency Server Load Balancer Server Server Server Database Cache

    Also Here State Stored Here
  10. Problems Infrastructure Sprawl: It is not uncommon to have to

    spin up many more servers dealing with caching/ searching than those hosting the actual application Invalidation Issues: Loss of ACID guarantee from the database, often accepted as trade-off
  11. Historical Context Orleans: Distributed Virtual Actors for Programmability and Scalability

    Philip A. Bernstein, Sergey Bykov, Alan Geller, Gabriel Kliot, Jorgen Thelin Microsoft Research Abstract High-scale interactive services demand high throughput with low latency and high availability, difficult goals to meet with the traditional stateless 3-tier architecture. The actor model makes it natural to build a stateful middle tier and achieve the required performance. However, the popular actor model platforms still pass many distributed systems problems to the developers. The Orleans programming model introduces the novel abstraction of virtual actors that solves a number of the complex distributed systems problems, such as reliability and distributed resource management, liberat- ing the developers from dealing with those concerns. At the same time, the Orleans runtime enables applications to attain high performance, reliability and scalability. This paper presents the design principles behind required application-level semantics and consistency on a cache with fast response for interactive access. The actor model offers an appealing solution to these challenges by relying on the function shipping paradigm. Actors allow building a stateful middle tier that has the performance benefits of a cache with data locality and the semantic and consistency benefits of encapsulated entities via application-specific operations. In addition, actors make it eas o implemen hori on al, social , relations between entities in the middle tier. Another view of distributed systems programmabil- ity is through the lens of the object-oriented program- ming (OOP) paradigm. While OOP is an intuitive way to model complex systems, it has been marginalized by the popular service-oriented architecture (SOA). One can still benefit from OOP when implementing service components. However, at the system level, developers
  12. Historical Context A⁄e > With or without cache, a stateless

    middle tier does not provide data locality since it uses the data shipping paradigm: for every request, data is sent from storage or cache to the middle tier server that is processing the request.
  13. Historical Context B⁄e > The actor model offers an appealing

    solution to these challenges by relying on the function shipping paradigm.
  14. Historical Context C⁄e > Actor platforms such as Erlang and

    Akka […] still burden developers with many distributed system complexities because of the relatively low level of provided abstractions and system services.
  15. Historical Context D⁄e > The key challenges are the need

    to manage the lifecycle of actors in the application code and deal with inherent distributed races, the responsibility to handle failures and recovery of actors, the placement of actors, and thus distributed resource management.
  16. Historical Context E⁄e > To build a correct solution to

    such problems in the application, the developer must be a distributed systems expert.
  17. 2 Orleans Primer

  18. None
  19. Grain = identity +behavior[+ state ] User / jack@email.com In

    -memory or persisted class User : Grain , IUser
  20. None
  21. Orleans Grains… …represent single-threaded processes; …can be configured to allow

    reentrant calls; …are scheduled cooperatively (never preempted); …are automatically activated to handle messages; …are automatically deactivated by the runtime.
  22. Orleans Hosts (Silos)… …are responsible for hosting grains; …communicate with

    each other to form a cluster; …have view of where grains are at all times.
  23. 3 In Through the BEAM

  24. None
  25. Erleans: Erlang Orleans

  26. Erleans: Short Overview Each activated grain runs in one process.

    Process Registration is delegated to lasp_pg. ETS-backed provider for state persistence included! Grains are implemented as callback modules to :erleans_grain (similar to GenServer)
  27. Erleans: Alternatives Swarm / Horde can be used to implement

    the distributed Registry. Barring that, pg2 (part of Erlang kernel) can be considered as well. The gen_statem behaviour in OTP can be used to implement deactivation timeout. An Elixir wrapper, GenStateMachine, can also be used if desired.
  28. Erleans: Alternatives Swarm / Horde can be used to implement

    the distributed Registry. Barring that, pg2 (part of Erlang kernel) can be considered as well. The gen_statem behaviour in OTP can be used to implement deactivation timeout. An Elixir wrapper, GenStateMachine, can also be used if desired.
  29. 4 Time for Science

  30. None
  31. Rules A live cell with fewer than 2 live neighbors

    dies; A live cell with more than 3 live neighbors dies; A live cell with 2 or 3 live neighbours still lives; A dead cell with 3 live neighbors comes to life.
  32. Demo: Inefficient Life Persistence (Default vs Custom) Communication Parallelisation