AKKA.NET

AN INTRODUCTION

🔗 AkkaIntro.SeanKilleen.com

What We'll Cover

  • Why this Matters
  • Reactive Manifesto
  • History / overview
  • Concepts & Benefits
  • Demos

AKKA-KNOWLEDGEMENTS

Roger Johansson

AKKA-KNOWLEDGEMENTS

Petabridge

Hi! 👋 I'm Sean.

WHY THIS MATTERS

Reactive Manifesto

http://www.reactivemanifesto.org

We need to evolve with our users' expectations.

Reactive Systems Are:

  • Responsive
  • Resilient
  • Elastic
  • Message-Driven

As a Result, They Are:

  • Flexible
  • Loosely-coupled
  • Scalable
  • Easier to Change
  • Fault tolerant
  • Fast

OVERVIEW

OVERVIEW

Actors: Not New

OVERVIEW

Where are the actors?

OVERVIEW

Akka and Akka.NET

CONCEPTS

CONCEPTS

Everything is an Actor

CONCEPTS

Encapsulation

CONCEPTS

Immutable Messages

CONCEPTS

Actors by Reference

CONCEPTS

Props

Every Actor Has:

  • Address
  • Context
  • Supervision
  • Mailbox
  • Lifecycle

ADDRESSING

Protocol

akka.tcp://MySystem@localhost:8080/user/HelloWorldActor

ADDRESSING

System

akka.tcp://MySystem@localhost:8080/user/HelloWorldActor

ADDRESSING

Address

akka.tcp://MySystem@localhost:8080/user/HelloWorldActor

ADDRESSING

Path

akka.tcp://MySystem@localhost:8080/user/HelloWorldActor

CONTEXT

FAULTS

Classic .NET System

FAULTS

Error Kernel

FAULTS

Strategies

BENEFITS

BENEFITS

Async by Default

BENEFITS

Recoverability

BENEFITS

Cheap!

BENEFITS

Location Transparency

BENEFITS

Easy State Machines

BENEFITS

Configurability

Scaling Up & Out:

The 👏 Same 👏 Thing

DEMOS!

🎶 We've Only Just Begun 🎶

  • Persistence
  • Clustering
  • Streaming

Want More?

Thanks!

Previously: Old school request/response. Not good enough now

Carl Hewitt -- 1973 white paper

Erlang Scala (Box) LinkedIn (Java Akka) Orleans (Xbox – Halo) WhatsApp Telecom etc. Finance | Data crunching | Event Streams Neural networks

Port of Java Akka

OOP Everything is an object; AM everything is an actor Container for State, Behavior, Mailbox, Children, Supervision

ActorRef encapsulates Behavior / responsibility Functions as one unit

Context.ActorOf is used to create children Pretty subtle in that it's not always available However, should know that every actor has one

Event-driven thread; no polling Behavior, State, Supervision One Message at a time from Mailbox Transport agnostic

Think of a classic OOP System Exceptions may or may not bubble up Unclear who is responsible for handling errors

System and User actors Parent is responsible for children Thinking about it up front at dev time

One for one vs. All for One Easy custom supervisory structures

Who here writes great async code always? Your async code is probably terrible Async without the cruft Easier to reason about

Child actors vs character actors Scale out work across many actors Push dangerous work into child actors

No CPU unless a message is actually processing ~2.5 million actors per GB 50 million messages / sec on single machine

Think Cell phone grid You don't need to care where the actor lives Can be changed via configuration without code updates Same / different process, same / different machine

Become / Unbecome Can change how it will process next message

HOCON: Human-Optimized Config Object Notation Fallback and layered configs

Single Core at first

Maybe then multi-core Maybe then you'd adapt to use TPL or async / await What happens when it's not enough?

This is a key concept. It's just code you write now Adding more cores and more machines is the same Reduce cost of change

Persistence: Journal of events using a base class (and snapshots!) Clustering: Add / remove notes without adjusting. Peer to peer, gossip/consensus, trivial scale-out Also poison pills: ordinary message that stops an actor Also dead letters: When an actor terminates, sends messages here for recovery Also service bus interoperability Also .NET Core

OSS is awesome -- get involved!