Actors

[jochumdev]

@g41797 brought up the idea of adding 'Actors' to go-orb.

Actors in dapr are described here: https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/
and here https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/ - the Overview is very informative.

[jochumdev]

runner

Intro

In the concept below I outline a yaml configuration where I show the most features I would love to have in a runner.
A runner could be a Service that run's these.

The runner would be custom compiled with some easy instructions so it can serve for example "shared.proto.userpb.v1".

The Dream

runner:
  name: "user_register"
  version: v0.0.1

  arg: shared.proto.userpb.v1.UserReq
  result: shared.proto.userpb.v1.UserResponse

  hooks:
    - name: checked
      arg: shared.proto.userpb.v1.User
    - name: notified
      arg: shared.proto.userpb.v1.User
    - name: verified
      arg: shared.proto.userpb.v1.User
    - name: failed
      arg: shared.proto.userpb.v1.User
    - name: registered
      arg: shared.proto.userpb.v1.User

  # run is the pipeline to call
  run:
    - description: Verify the User
      action: orb_call
      service: user.svc.orb.org
      endpoint: User.Verify
      success:
        - description: Send verfication mail
          action: orb_call
          service: mail.svc.orb.org
          endpoint: MailUser.Verify
          # Means keep the previous result
          pipe: false

       - description: Wait for answer
          action: orb_poll_call
          service: user.svc.orb.org
          endpoint: User.Verified
    
    - hook: checked

    - action: orb_call
      # orb_call or better go-orb/client can find an endpoint without knowing the service.
      # service: db.svc.orb.org
      endpoint: DBUser.Store
      success:             
        - action: orb_call
          service: mail.svc.orb.org
          endpoint: MailUser.Notify

     - description: Do something in parallel
       action: orb_parallel
       run:
         - action: orb_call
         - action: orb_call
  sucess:
    - hook: registered
  error:
    - hook: failed
    - action: orb_return_err

[g41797]

Actors - theory
Actors model
Misty Actors

[g41797]

Actors - junior point of view
Actors are:

• applications within process
• work on own threads/goroutines
• no rpc, no sync call - negotiation via asynchronous message send
• internal "microservices"

go-orb supports components:

type Component interface {
	// Start the component. E.g. connect to the broker.
	Start() error

	// Stop the component. E.g. disconnect from the broker.
	// The context will contain a timeout, and cancelation should be respected.
	Stop(context.Context) error

	// Type returns the component type, e.g. broker.
	Type() string

	// String returns the component plugin name.
	String() string
}

There are two kinds of components:

• passive, don't have own threads, part of pipe-line for example middleware filter/transformer, life cycle - within call
• active, have own threads and life cycle e.g. server

active components of go-orb are already async internal applications and without much efforts can be actors
Why we need this complication? - because it simplifies design of the process and implementation.
Explicit declaration component has own "main" thread and possibility to negotiate allows simpler components management, adds ability to implement house keeping and background processing, not directly result of client's requests.

The hardest part of adding Actors - changing of mindset, not interface

[g41797]

go-orb components as actors:

type Sender interface {
	Send(msg TBD)
}

type Component interface {
	// Async Start, result will be returned as message
	Start(ack Sender)
	// Async Stop, result will be returned as message
	Stop(ctx context.Context, ack Sender)

	Type() string
	String() string

	// Passive components should return nil, err
	Mailbox() (Sender, error)
}

no need to call components Actors. Enough to mention similarity in readme, doc and tags

[Davincible]

@g41797 hi, just watched the youtube video referenced. From what I understand, the actor model is just a different design pattern to set up a distributed system.

Orb provides the fundamental building blocks (interfaces + implementations) to build any distributed system, with whatever communication style you prefer sync or async, over rpc or event messages, and with that provides the building block to implement an actor model distributed system.

It's an interesting paradigm, although I am not sure yet if I'd design my services this way personally, it should be possible.

Is there anything fundamental that you would like to see in the Orb framework to aid in setting up an actor model architecture?

I have no background knowledge on the actor model so if I am misunderstanding something please fill me in

[g41797]

I'd like to add some life to orb components
and to process based on orb
I am not talking about distribute system at all
I am talking about modular design of single stand alone process
And without convenient negotiation between parts it's just big collection of pipelines.

Regarding implementation I wrote above my proposal:

• async Start and Stop
• possibility to send message to component
• also I expect that component can get these messages via own queue

It allows to build process as set of "internal microservices"

I tried to explain this approach in my first open source project sputnik

[g41797]

@jochumdev wrote in his e-mail: Just found dagu is that something we could implement/add?

Great! You found what I tried and could not explain - Use cases:

• Data Pipeline Automation: Schedule ETL tasks for data processing and centralization.
• Infrastructure Monitoring: Periodically check infrastructure components with HTTP requests or SSH commands.
• Automated Reporting: Generate and send periodic reports via email.
• Batch Processing: Schedule batch jobs for tasks like data cleansing or model training.
• Task Dependency Management: Manage complex workflows with interdependent tasks.
• Microservices Orchestration: Define and manage dependencies between microservices.
• CI/CD Integration: Automate code deployment, testing, and environment updates.
• Alerting System: Create notifications based on specific triggers or conditions.

Usual flow of go-orb based process (simplified ofc.):

• recv request from client/another microservice
• process it
• send response

For this or similar flows current architecture is good enough.
But for implementation of use cases above we need more active help from infrastructure.

Like moving from non multi-threaded OS and APIs to multi-threading with well defined MT communication.

Many years ago this kind of s/w called Application server