"Event Thinking" – The Hollywood Principle

	Wolfman Jack says: "Don't call us.         We'll call you."

tags: streaming actor EDA OpenEMIT

Author: George WillisThu, Apr 19, 2018

---

What is the Hollywood Principle?

An "Inversion of Invocation" design pattern (for those familiar with the IoC design pattern.)

Transform "Explicit Invocations" into "Implicit Invocations"

Explicit Invocation

"The way you do it now."

Tightly coupled: The caller specifies the target

• coupling to add() is hardcoded in all cases below

result = add(1,2)          // Procedural style
    
result = (int 1).add(2)    // OOP style

add(resultCallback(),1,2)  // Async style

Explicit Invocation – Deep Call Stacks

Explicit Invocation – "Pass Back"

• Results must be routed back, not forward

  • Inherent in recursive orchestration models

• Context held "open"

  • deep stacks => large context
  • RMI => contextual locks by other hosts
    • But those hosts could fail? What about hung context? How is that handled?
      • Timeout Exceptions (Identify)
      • Recover to previous workflow "state" and restart from waypoint (Remediate)

  "Wait – we don't program around state transitions any more than we invoke asynchronously!

We need to rethink distributed state from the ground up!

Software Evolution

• Embarrasing industry trends
  • Majority of POs state:
    • (temporal) quality goes down with each release
    • (capacity) quality goes down as system grows (scaling)
  • Many IT shops adopt a "fair of failure" mentality and "sunset" systems based on refactoring not requirements

Technical debt of refactoring and extending is too high

Implicit Invocation ("We'll call you")

A foundational shift – what Gartner calls "Event Thinking".

Publish/Listen – a cousin to Pub/Sub

Think "Hooks" for loose coupling  

• Hook : I'll use {–- in homage to markdown

myEvent.publish(aTopic):
    
  {--- aTopic.aListener1                  // Listeners can filter (optional)
  {--- aTopic.anActor2                    // Ingest/Emit Contract Queue Workers
  {--- aTopic.aListener3.anActor3         // Filtered Actor
    
=========================================================================================

dataCollectedEvent = [...] 
dataCollectedEvent.publish(Users.Create)  // Emit trigger event
   
// Users.Create:dataCollectedEvent Listeners
  {--- addCredentialsToLDAP               // Ingest into Active Directory
                                          // Emit Users.Create.Credentials:savedEvent
  {--- addEmailToMailgun                  // Ingest into User Notification domain
  {--- addToDiscus                        // Ingest into Social Engagement domain
      
// Users.Create.Credentials:savedEvent Listeners
  {--- sendConfirmationEmailToUser
      
// Users.Create Multi-Event "Merge" Listeners
  {--- EndProcess(span=2s)                // Upon completion of several parallel Actors/subflows, Emit User.Create:endFlowEvent

Value Proposition

Evolutionary Architectural Style – Achieves loose-coupling of autonomous execution bundles (container runtimes) by moving coupling from "callers" (a.k.a. Commanders, Orchestrators) to autonomous listeners known as Actors (Choreography, flocks of birds). Each Actor hooks into an event stream.  

• Extend via new hooks to existing events without impacting existing workflows – just like in ETL

• Solves coupling isues where other approaches like Service Registry (ESBs) and Service Discovery solutions:

  • move the issue to a mediation layer (reduces impact of change, but does not remove the need to reconfigure)

  • add additional machinery, complexity, latency and resource utilization to an otherwise lean microprocess

• Solves coupling issues at the fundamental and foundational level – invocation.

• Naturally Async() – no "blocking"

  • Foundationally faster and more efficient
  • Results move forward – not back
    • Think "incredibly fast bucket brigades"

• Naturally Efficient – deep, resursive call stacks of locked, distributed context (resources) replaced with atomic, ephemeral Actor Lifecycle context

• Naturally Resilient – in contrast, Orchestration is a Resilience Antipattern, due to:

  • critical dependency of all services/steps/transformations on one component
  • locked context on multiple machine of the distributed call stack when a call fails to return (syncronous)
  • incremental state backups not available for instant recovery (remediation) – not part of the "style"
  • incremental monitoring not a fundamental capability, and parked on most DevOps Roadmaps (alarming)

• Naturally Visible – Day 1 Monitoring of each state change, filtered by topic(s), subtopic, Domain Entities. They are called "listeners", and they are built into the runtime as a foundational component.

• Naturally Scalable – "'cause concurrency ain't easy, so stop sharing forks" – employ Parallel Processing instead.

  • Scaling workload is all about distributing workload, and if workers keep sharing workspace resources, the result is predictively Contention@Scale.

  • An autonomous (atomically isolation) multi-tasking environment is required. This is why Container Multitenancy is another "Pillar of Digital Transformation"

• Naturally BPM Aligned: Naturally Decomposes Business Processes/Steps into Topics/Events

Event-Driven Architecture

"Event-Driven Architecture is the optimal and natural solution to Recovery, Scaling and Velocity – Event Thinking, the foundation of true Digital Transformation."
_{-George Willis}

Recovery Axiom:

Tracking "state transition of processing" is required to enable recovery from prior recorded state – like nautical waypoints.

• Recovery is a key Resiliency/Availability concept.

• Failures on commodity devices are a statistical certainty.

• Must achieve HADR-as-a-Service.

"Embrace Failure" by deploying innate recovery of prior state.

If the last state saved is hours old, you lose hours of processing.

If saved state is millaseconds old, you recover instantly!

Events are fine-grained, immutable state transition ledger entries recorded in a Distributed Log.

Deep Dive into Event-Driven Microservices

Summary Comparison of Invocational Styles

Properties	Explicit Invocation	Implicit Invocation	Notes
Complexity	High	Low	Events are simple
Evolution	Low	High	POs currently report quality issues over releases.
Scaling Multi-tasking	Concurrency	Parallelism	The key to Scalabinf workload.
Microservices Execution Coupling (Flow)	Centralized Orchestration[1]	Independent Choreography with Oversight	Flocks are choreographed, independent actors. What if orchestrator goes down? More dependency.
BPM Alignment	Low No clear model	High
Resilience@Scale	Low	High	Today's systems do not solve "First things First" – Resilience@Scale. Foundational problems of lean scaling, host isolation, host failure, network partitioning, snd others are not solved by the platform – "out-of-the-box".
Visibility Monitoring	Extra. Add Monitoring Traffic, Infrastructure, and Integration Code	Foundational Listeners
Process Efficiency	Distributed Call Stacks[2], Synchronous "blocking" by default, Return to Caller ("Pass Back")	Actor Context, Async by design, notify/emit ("Pass Forward")
Process Integrity	Currently, Ingestion throttling involves discarding invocations to maintain Transactional rates	Ingestion throttling involves backpressure on upstream event publishers to preserve all invocations
Network Efficiency	WET[3]. Requires client caching to be DRY, and that's extra	DRY[3:1] "Don't Repeat Yourself", Content-Centric Networking (CCN)	Events are communicated "once", while in CPU cache!
Theorhetical Background	REST Dissertation[4]	Promise Theory[5], Configuration Management (CM)[6], Smalltalk MVC	"Events" have been around as long as Ethernet! (Xerox PARC)

---

1. Youtube: "Who Needs Orchestration? What You Want is Choreography." ↩︎

2. Lightbend/Akka: "How the Actor Model Meets the Needs of Modern, Distributed Systems" ↩︎

3. Wikipedia: Don't Repeat Yourself (DRY Principle) ↩︎ ↩︎

4. 2000 Roy Fielding: "Architectural Styles and
   the Design of Network-based Software Architectures" ↩︎

5. Wikipedia: Promise Theory ↩︎

6. Mark Burgess: Promise Theory – What is it? ↩︎